Prometheus + Grafana вместо коммерческого APM: метрики, алерты, SLO

Почему компании уходят от коммерческого APM

Обычно толчок к отказу от коммерческого APM простой: стоимость растет быстрее пользы. Лицензии, оплата за хосты или за объем телеметрии, доплаты за новые модули - и мониторинг внезапно становится одной из самых дорогих строк в ИТ-бюджете.

Вторая боль - непрозрачность. Когда метрики, трассировки и алерты живут внутри «черного ящика», команде сложно понять, почему сработал сигнал, откуда взялась цифра в отчете и можно ли доверять расчетам.

Третья причина - контроль данных. Не всем подходит отправка телеметрии во внешний облачный сервис, особенно в госсекторе и финансовых организациях.

Переход на Prometheus и Grafana меняет привычный уклад. Разработчики чаще начинают думать в терминах «что измеряем» и «какой SLI отвечает за качество», а не «какую кнопку нажать в APM». Эксплуатация получает больше контроля: правила сбора, хранения и агрегации метрик становятся понятными и версионируемыми. Поддержке тоже обычно легче, если алерты и дашборды описывают пользовательскую боль (ошибки, задержки, недоступность), а не внутренние технические события.

За 2-4 недели при разумном объеме работ обычно можно получить ощутимый результат: базовые дашборды по сервисам и инфраструктуре (ошибки, задержки, нагрузка, насыщение ресурсов), первые полезные алерты без шквала уведомлений и общий язык с бизнесом через простые SLO (например, доступность и скорость ключевых операций).

Важно понимать границы. Prometheus и Grafana идеальны, когда вам нужны понятные метрики, свои правила алертов и контроль над данными. Они хорошо ложатся и на Kubernetes, и на классическую инфраструктуру: серверы, базы данных, API.

Другой инструмент может понадобиться, если вы хотите «из коробки» глубокую распределенную трассировку, профилирование кода, автоматический поиск причин (root cause) и богатую аналитику с минимальной настройкой. В таком случае open source стек часто дополняют отдельными решениями для трассировок и логов, а Prometheus + Grafana оставляют как основу для метрик и SLO.

Что вы теряете без APM и как это компенсировать

Если вы выбираете Prometheus + Grafana вместо коммерческого APM, вы получаете сильную базу по метрикам, но часть привычных функций пропадает. Это не катастрофа, если заранее понимать пробелы и закрыть их простыми дополнениями.

Чего чаще всего не хватает без APM «из коробки»:

• Сквозных трейсов по запросу (где именно в цепочке сервисов теряется время)
• Профайлинга (что именно грузит CPU или память внутри кода)
• Разбора ошибок на уровне конкретных запросов и пользователей
• Автоматической «склейки» логов, метрик и трейсов в один экран

При этом бизнес обычно приходит не за трейсами. Первые вопросы почти всегда практичные: система доступна или нет, насколько она медленная, сколько было ошибок, сколько длился простой и кто заметил проблему первым.

Компенсировать часть возможностей APM можно без усложнения стека, если держать фокус на трех источниках сигналов: метрики, логи и минимальные трейсы.

Практичный стартовый набор:

• Метрики: добавьте несколько ключевых показателей приложения (задержка, частота ошибок, нагрузка) поверх инфраструктурных.
• Логи: введите единый формат (время, сервис, request_id, уровень, сообщение) и договоритесь, что считается ошибкой.
• Базовые трейсы: начните с одного критичного сценария (например, авторизация или оформление заявки) и одной корреляции (request_id) между сервисами.
• Контекст инцидента: в алерте фиксируйте, что именно «сломалось» для пользователя (например, выросли 5xx и p95 задержки выше порога).

Отдельно стоит договориться о границах ответственности мониторинга. Мониторинг отвечает за раннее обнаружение и понятный сигнал (что, где, насколько плохо). Он не обязан автоматически объяснять первопричину на уровне строки кода. Для первопричины нужны люди, логи, иногда профайлер и отдельная диагностика.

Хорошая проверка на реализм: сможете ли вы по алерту за 5 минут ответить на три вопроса - это влияет на клиентов, это новая проблема или повтор, и кому бежать чинить (сервис, база, сеть, железо). Если да, отсутствие APM переживается спокойно.

Первые метрики: 4 сигнала, которые дают максимум пользы

Для мониторинга на Prometheus + Grafana удобно начать с четырех сигналов, которые почти всегда быстро дают понятную пользу: задержка, трафик, ошибки и насыщение. Они помогают ответить на главный вопрос дежурного: проблема в приложении, в зависимости или в ресурсе.

Что мерить в первую очередь

Latency (задержка). Измеряйте там, где пользователь реально чувствует время: на входе API (HTTP/gRPC), на обработке фоновой задачи и на ключевых внешних вызовах (БД, очередь, сторонний сервис). Среднее часто обманывает, поэтому смотрите перцентили: p50 (типично), p95 (большинство проблем), p99 (самые болезненные хвосты). Если у вас один endpoint медленный, а остальные быстрые, сводная метрика «по всему сервису» это спрячет.

Traffic (трафик). Считайте не «пакеты» и не CPU, а бизнес-нагрузку: запросы в секунду (RPS), число задач или сообщений, обработанные документы, транзакции. Важно иметь и общий поток, и разрез по ключевым ручкам или типам задач, иначе всплеск в одном месте выглядит как «все нормально».

Errors (ошибки). Ошибка - не только 500. Отдельно учитывайте 4xx (часто это продуктовые или интеграционные проблемы), таймауты, отмены, ретраи, исключения в приложении, ошибки БД. Разделяйте по типам, а не просто «error=true», иначе вы не поймете, что именно сломалось.

Saturation (насыщение). Это про «на пределе ли ресурс», даже если он еще не упал. Смотрите длину очередей, заполнение пулов соединений и потоков, время ожидания в очереди, CPU steal (особенно в виртуализации), iowait, долю занятых worker-ов. Пример: на стойке с серверами уровня S200 сервис может держать RPS, но рост очереди и ожидания в пуле БД покажет, что скоро пойдут таймауты.

Метки без взрыва кардинальности

Чтобы метрики были полезны и не «съели» Prometheus, держите метки минимальными и стабильными. Хороший базовый набор обычно такой:

• service (имя сервиса)
• endpoint или route (шаблон пути, без id)
• method (GET/POST)
• status_class (2xx/4xx/5xx) или код, если кодов мало
• dependency (имя внешней зависимости: db, queue, auth)

Избегайте меток с высокой уникальностью: user_id, request_id, полный URL, текст ошибки, имена файлов. Их место в логах и трассировке, а не в метриках.

Инфраструктура: базовые метрики серверов и среды

Когда нет коммерческого APM, именно инфраструктурные метрики первыми подсказывают, что происходит: это всплеск реальной нагрузки, поломка в окружении или медленная деградация. Важно собрать минимум, который помогает во время инцидента, а не просто красиво выглядит на графиках.

Начните с четырех зон: CPU, память, диск и сеть. Для каждой зоны полезнее смотреть не «проценты вообще», а признаки насыщения и задержек, которые напрямую влияют на пользователей.

• CPU: загрузка по ядрам, iowait (ожидание диска), длина очереди задач (load). Высокий % CPU не всегда проблема, а высокий iowait часто говорит о диске.
• Память: доступная память, swap (использование и активность), major page faults. «Памяти мало» может быть нормой из-за кэша, а рост swap и faults чаще похож на утечку или нехватку RAM.
• Диск: свободное место, скорость чтения и записи, задержки (latency), время занятости диска (util), число ошибок. Инциденты часто начинаются не с «0% места», а с роста задержек.
• Сеть: входящий и исходящий трафик, ошибки и дропы, повторные передачи (если доступны), задержка до ключевых узлов. Полезно видеть не только «сколько Мбит», но и качество.

Как отличать нормальный рост нагрузки от утечки или деградации? Сравнивайте «спрос» и «насыщение». Если растет трафик и CPU, но задержки диска и ошибки не растут, это похоже на нормальный пик. Если нагрузка стабильна, а latency диска, swap или сетевые дропы постепенно ползут вверх, это деградация. Для утечки памяти характерен монотонный рост потребления плюс рост swap или рестарты процессов.

Для VM и Kubernetes добавьте слой, который показывает, где именно «узкое место». В виртуализации важны steal time (когда гипервизор забирает CPU), давление на хранилище и «шум» от соседей. В Kubernetes смотрите не только node-метрики, но и requests/limits, перезапуски, throttling CPU и состояние дисков под PVC. Иначе можно долго спорить, «у нас мало ресурсов» или «приложение съело все лимиты».

Если есть доступ к датчикам, метрики питания и температуры часто дают ранний сигнал. Перегрев, деградация вентиляторов или проблемы с питанием могут проявиться раньше, чем упадет сервис. Это особенно полезно в стойках с серверами и СХД, где отказ иногда выглядит как «странные таймауты».

Чтобы разные площадки и команды смотрели на одно и то же, договоритесь о едином формате дашбордов: одинаковые названия панелей, единые пороги и одинаковые лейблы (площадка, роль, сервис). Тогда сравнение дата-центров, филиалов или кластеров будет занимать минуты, а не часы.

Метрики приложений и данных: что добавить поверх железа

Метрики CPU и памяти отвечают на вопрос «почему серверу плохо». Но чаще нужно понять другое: «почему пользователю медленно» и «где именно ломается цепочка». Для этого поверх инфраструктуры добавьте метрики приложения и его зависимостей.

Минимальный набор удобно собирать по слоям - так проще искать причину.

• HTTP/gRPC слой: частота запросов (RPS), доля ошибок (по кодам/статусам), задержка по перцентилям (p95/p99), таймауты, размер ответов.
• Очереди и фоновые задачи: длина очереди, время ожидания задачи до старта, число ретраев, доля задач в ошибке.
• База данных: активные соединения и очередь на соединение, медленные запросы (хотя бы топ по времени), блокировки и ожидания, лаг репликации (если есть реплика).
• Кэш: hit rate, задержка чтения и записи, заполнение, eviction (вытеснения).
• Бизнес-метрики: 1-2 показателя, понятные не инженерам. Например, «успешные платежи в минуту» и «время обработки заявки».

Небольшой пример: в системе обработки заявок для госорганизации время ответа API стало p99 = 5 секунд. Инфраструктура в норме. Метрики показывают рост длины очереди фоновой проверки и рост ретраев, а в БД - блокировки и увеличившийся лаг репликации. Видна цепочка: фоновые задачи копятся, начинают чаще перечитывать данные, БД блокируется, и пользователи ждут.

Чтобы метрики не превратились в шум, держите их «чистыми»:

• измеряйте задержку гистограммами и смотрите p95/p99, а не только среднее
• ограничивайте метки (не добавляйте user_id, order_id и другие уникальные значения)
• отделяйте ошибки пользователя (4xx) от ошибок сервиса (5xx) и таймаутов
• измеряйте зависимости отдельно (БД, кэш, внешние API), а не только общий тайминг

Такой набор дает достаточную видимость и для диагностики, и для будущих SLO: вы уже умеете измерять «успешно и быстро» на уровне пользователя, а не только «сервер включен».

Шаг за шагом: минимальная настройка Prometheus и Grafana

Начинайте не с сотен графиков, а с понятного минимума. Цель на первую неделю: уверенно видеть здоровье самых важных сервисов и быстро ловить явные сбои.

Сначала выберите небольшой набор целей: обычно хватает 5-15 компонентов, без которых «встает» бизнес. Это входные API, очередь, база данных, ключевые воркеры, балансировщик, пара критичных серверов.

1) Сбор метрик: минимум, который работает

Выстраивайте сбор так, чтобы его было легко поддерживать:

• Поставьте exporters там, где это дает быстрый результат: node_exporter для серверов, метрики самой базы (например, Postgres exporter) и метрики приложения (HTTP, ошибки, время ответа).
• Настройте service discovery, где это возможно (Kubernetes, Consul, cloud-теги). Если нет, начните со статического списка, но сразу договоритесь, кто его обновляет.
• Выберите частоту scrape по смыслу: 15-30 секунд для пользовательских API, 30-60 секунд для инфраструктуры, реже для «медленных» систем.
• Договоритесь о едином наборе меток: service, instance, environment, team. Без этого дашборды и алерты быстро превращаются в хаос.

Про хранение: в Prometheus проще всего стартовать с retention 7-15 дней, а дальше оценить объем. Для длинной истории обычно добавляют удаленное хранилище, но на старте важнее не «вечно хранить», а стабильно собирать и понимать данные.

2) Первые дашборды и контроль качества

Соберите четыре простых экрана: общий обзор (все сервисы), сервисный (один сервис подробно), инфраструктурный (CPU, RAM, диск, сеть) и отдельный для базы.

Перед тем как писать алерты, проверьте качество данных:

• нет ли пропусков (дыры в графиках часто означают проблемы со сбором, а не с сервисом)
• одинаковые ли единицы измерения (секунды vs миллисекунды, bytes vs MiB)
• не взрывается ли кардинальность (метки вроде user_id или request_id нельзя тащить в Prometheus)
• совпадают ли названия метрик и меток между командами

Пример: для стойки с серверами уровня GSE S200 вы быстро увидите, что жалоба «API тормозит» на деле совпадает с ростом iowait и заполнением диска, и это будет видно на одном экране без тяжелого APM.

Алерты без шума: правила, которые экономят время

Главная ошибка - алертить все подряд. Хороший алерт не просто сообщает, что что-то «случилось». Он говорит: «пользователю стало плохо, и это требует действий прямо сейчас».

Начинайте с симптомов, а не с причин. Симптомы - рост 5xx, падение успешных запросов, увеличение задержки, невыполнение фоновых задач. Причины - CPU, память, место на диске, проблемы сети. Причин может быть десяток, а симптом у клиента один. Поэтому первые алерты ставьте на то, что видно снаружи, а причины держите как подсказку для диагностики в дашборде.

Пороги задавайте так, чтобы они отражали отклонение от нормы, а не «красивое число». Часто лучше работают относительные пороги и перцентили: например, p95 задержки выше обычного уровня, или доля ошибок выросла в 3 раза относительно среднего за день. Когда есть SLO, удобнее мыслить burn rate: сколько «бюджета ошибок» вы тратите сейчас. Тогда алерт срабатывает не от единичного сбоя, а от скорости деградации.

Короткие всплески не должны будить людей. Используйте окна времени и задержки: правило «должно держаться 5-10 минут» обычно убирает большую часть шума. Для «флапающих» метрик полезно разделять предупреждение и критический алерт разными окнами.

Чтобы один инцидент не превращался в десять уведомлений, настройте группировку и дедупликацию в Alertmanager. Группируйте по смысловым меткам (например, service, cluster, environment), а не по каждому pod или instance. Один сервис упал - одно сообщение, внутри которого перечислены затронутые компоненты.

И наконец, каждый алерт должен вести к действию. Минимальный runbook в описании алерта:

• Проверь, действительно ли страдают пользователи: ошибки, p95/p99, успешные запросы.
• Посмотри, что изменилось: деплой, конфиг, внешняя зависимость.
• Ограничь ущерб: откат, отключение фичи, переключение на запасной контур.
• Собери данные для разбора: графики, логи, время начала.
• Если не решается за 15 минут - эскалируй по заранее согласованному списку.

Так алерты становятся редкими, понятными и полезными, а дежурство - спокойнее.

SLO с бизнесом: как договориться без лишней математики

SLO почти всегда ломается не на графиках, а на ожиданиях. Бизнес думает про клиентов и потери, команда - про метрики и логи. Чтобы договориться, начните с простого: что пользователь должен уметь делать и как часто это должно получаться.

SLI простыми словами: что измеряем глазами пользователя

SLI - это одна измеримая вещь, которая отражает опыт пользователя. Не «CPU 80%», а «операция прошла успешно и быстро». Для большинства сервисов хватает пары SLI:

• Доступность: доля успешных запросов (например, HTTP 2xx/3xx)
• Задержка: доля запросов быстрее порога (например, 95% быстрее 500 мс)
• Ошибки: доля 5xx или бизнес-ошибок (оплата не прошла, заказ не создан)
• Насыщение: очереди или таймауты, которые прямо ведут к отказам

SLI нужно считать там, где «болит» пользователю. Обычно это входной слой (ingress, API gateway) или ключевой endpoint.

SLO простыми словами: что обещаем и на какой период

SLO - это обещание уровня качества на период: «99,9% успешных запросов за 30 дней». Период нужен, чтобы редкие инциденты не превращались в ежедневную панику. Для внутренних сервисов иногда честнее брать неделю, для критичных внешних - месяц.

Дальше появляется error budget: разрешенная доля «плохого». При SLO 99,9% у вас 0,1% запросов могут быть плохими в периоде. Объясняйте это как компромисс: чем выше обещание, тем больше времени и денег уходит на надежность и тем сложнее выпускать изменения. Если бюджет выгорает, бизнес выбирает: заморозить релизы и чинить стабильность или принять риск и потери.

Перевод в язык денег и рисков делается через простые вопросы: сколько стоит час простоя для продаж, сколько жалоб выдержит поддержка, какие штрафы возможны по SLA, что будет с репутацией. Например, для сервисов со строгими ожиданиями (госструктуры, банки, клиники) часто разумнее фиксировать более высокий SLO на ключевые операции, а не на все подряд.

Чтобы не перегружать договор, фиксируйте 2-3 SLO на сервис и прямо пишите, что считается инцидентом:

• доступность ключевой операции (за период)
• задержка ключевой операции (процентиль и порог)
• время восстановления (например, 90% инцидентов закрываем за N часов)

Этого достаточно, чтобы и бизнес понимал цену качества, и команда могла настроить алерты и план работ без бесконечных споров.

Пример сценария: от метрик к SLO и алертам

Представьте сервис: внутренний портал для сотрудников, где они оформляют заявки в ИТ, кадровые запросы и доступы. В обычные дни нагрузка ровная, но каждый понедельник утром и в конце месяца бывают пики. Команда хочет заменить коммерческий APM на Prometheus и Grafana так, чтобы бизнес понимал, что считается нормой.

Начните с SLI, которые совпадают с тем, что видит пользователь. Для портала обычно достаточно трех:

• Доступность: доля запросов, которые вообще получили ответ (не 5xx и не таймаут).
• Время ответа: 95-й перцентиль (p95) по ключевой операции (вход, создание заявки).
• Успешность операций: доля успешных действий в бизнес-смысле (заявка создана и сохранена, а не просто вернулся статус 200).

Дальше сформулируйте SLO на месяц. Например: «за месяц доступность 99,9%, p95 для создания заявки не выше 1,2 секунды, успешность создания заявки не ниже 99,5%».

В Grafana полезно показывать не только «проценты», но и «сколько минут можно потерять». Для 99,9% в месяце это примерно 43 минуты недоступности. Так бизнесу проще: не спорить о цифрах, а видеть лимит времени, который можно потратить на сбои.

Теперь алерты. Чтобы Alertmanager работал без шума, удобно иметь два уровня: быстрый симптом и медленный тренд. Быстрый ловит реальную боль пользователя и будит сразу. Медленный предупреждает о деградации, но без ночных ложных срабатываний.

Пример набора алертов:

• Быстрый: доля 5xx или таймаутов по входу и созданию заявки выше 2% в течение 5 минут.
• Быстрый: p95 времени ответа по созданию заявки выше 2 секунд 5 минут подряд.
• Медленный: p95 растет неделю к неделе (например, среднее p95 за час выше базовой линии на 30% в течение 2 часов).
• Медленный: очередь задач или пул соединений с БД стабильно близки к лимиту 30-60 минут.

Когда SLO нарушается, включается понятие error budget - это «запас» допустимых проблем. Если бюджет выгорает быстрее плана (например, уже к 10-му числу месяца потрачено 70% лимита), договоритесь заранее, что происходит дальше.

Обычно работает такой порядок:

• Заморозка релизов, кроме исправлений инцидентов.
• План работ по техдолгу на 1-2 недели (оптимизация запросов, кэш, лимиты, ретраи).
• Пересмотр алертов и дашбордов: что не помогло, что было лишним.
• Возврат к feature-разработке только после стабилизации ключевых SLI.

Так Prometheus + Grafana превращаются из набора графиков в понятные правила: что важно, сколько «можно» сломать и когда команда обязана остановиться и чинить надежность.

Короткий чеклист и следующие шаги

После первых метрик и дашбордов важно быстро закрепить процесс, иначе мониторинг расползется в хаос, а алерты станут шумом.

Чеклист на запуск (1-2 дня)

Проверьте не только технику, но и ответственность: кто реагирует, кто принимает решения, кто общается с пользователями.

• Собраны 4 сигнала для ключевых сервисов: задержки, ошибки, трафик, насыщение ресурсов.
• Есть 2-3 дашборда: обзор сервиса, инфраструктура, зависимости (БД, очередь, внешние API).
• Настроены алерты только на симптомы для пользователя и на риски исчерпания ресурсов (с задержкой и подавлением дублей).
• У каждого алерта указан владелец и понятное действие: что сделать в первые 10 минут.
• Определено расписание дежурств и канал эскалации.

Чеклист на инцидент (первые 15 минут)

Начинайте с вопроса: это локальная проблема одного сервиса или общий сбой в инфраструктуре.

• Что видит пользователь: рост 5xx, таймауты, деградация скорости, падение успешности операций.
• Где узкое место: CPU, память, диск, сеть, лимиты контейнеров, пул соединений, очередь задач.
• Что изменилось: релиз, конфиг, миграция, рост нагрузки, сбой у провайдера или внешнего партнера.
• Что происходит с зависимостями: база данных (соединения, задержки), кэш, брокер сообщений.
• Как откатываемся и как фиксируем: временная мера (например, отключить тяжелую фичу), затем причина и задача в бэклог.

Полезно поставить ежемесячный ритм. Раз в месяц пересматривайте SLO (не стали ли они слишком мягкими или недостижимыми), удаляйте шумные алерты, проверяйте кардинальность меток (особенно user_id, URL с параметрами, trace_id) и обновляйте дашборды под новые зависимости.

Если стек растет на несколько площадок и команд, заранее договоритесь о стандартах: единые названия метрик и лейблов, общий набор дашбордов-шаблонов, отдельные пространства по командам и понятный каталог алертов с владельцами.

Следующий шаг после пилота часто упирается в инфраструктуру и поддержку: чтобы Prometheus, Grafana и хранение метрик работали стабильно, нужна надежная платформа и понятная ответственность за обслуживание. В таких проектах GSE.kz (gse.kz) может закрыть часть «земли» - поставить серверы S200 под мониторинг и платформенные нагрузки, а также помочь с системной интеграцией и поддержкой 24/7.