Алертинг в продакшене — это не про «чтобы пиликало». Это дисциплина: как из потока сигналов (alerts) сделать управляемые инциденты, доставить их нужной команде, подавить шум, эскалировать по времени и не потерять ничего важного во время падений.
В экосистеме Prometheus выбор часто упирается в два подхода: классический alertmanager (Prometheus Alertmanager) и встроенный в Grafana стек grafana alerting (Unified Alerting). Оба умеют отправлять уведомления в мессенджеры/почту/вебхуки, но заметно отличаются по архитектуре, маршрутизации и операционным сценариям.
Ниже — практичное сравнение: что где сильнее, какие есть подводные камни и как не промахнуться с выбором.
Где находится алертинг в системе monitoring: evaluation vs notification
Чтобы сравнение было честным, разделим две части:
- Оценка условий (evaluation): где выполняются правила вида «CPU > 90% 10 минут».
- Управление уведомлениями (notification management): дедупликация, группировка, routing, silence, повторные отправки, эскалации.
Исторически Prometheus делал evaluation правил, а Alertmanager — notification management. Grafana Alerting в современном виде старается закрыть обе части и унифицировать алерты для разных источников данных (метрики, логи и т.д.).
Prometheus Alertmanager: сильные стороны и ограничения
alertmanager — отдельный сервис, который получает firing/resolved alerts от Prometheus (и совместимых систем), применяет маршрутизацию и отправляет уведомления в разные каналы. Он «приземлённый»: минимум магии, максимум детерминизма, всё описывается конфигурацией.
Что в Alertmanager действительно спасает продакшен
Дедупликация и группировка. Alertmanager объединяет однотипные алерты (например, instance=... down на десятках узлов) в одно уведомление по ключам группировки. Это радикально снижает шум.
Routing по меткам. Типовой паттерн: метки severity, team, service, env определяют, кто получает alerts, в какой канал и с какой срочностью.
Silence и inhibition. Silence — ручное временное подавление по матчеру меток. Inhibition — автоматическое подавление вторичных симптомов при наличии первопричины (например, не слать «HTTP 5xx», если уже есть «backend down»).
Переносимость и предсказуемость. Конфиг в YAML + понятные зависимости. Это удобно для GitOps и воспроизводимых окружений.
Ограничения Alertmanager, которые лучше принять заранее
Он не вычисляет правила. Alertmanager — «приёмник и маршрутизатор». Если у вас много источников сигналов (не только Prometheus), придётся либо приводить их к совместимому формату, либо держать несколько контуров.
Конфигурация мощная, но «админская». Большие деревья маршрутизации превращаются в отдельный продукт: нужны соглашения по меткам, ревью и тестирование изменений.
On-call как продукт — не его задача. Расписания, эскалации «дежурный 1 → дежурный 2», acknowledge — обычно внешний слой (incident management), куда Alertmanager отправляет события.
Если вы строите классический стек Prometheus, держите под рукой отдельный разбор практик маршрутизации и тишин: routing/silence/templates в Alertmanager: практические паттерны.
Чтобы цепочка «Prometheus → Alertmanager → уведомления» не конкурировала с приложением за CPU/IO и переживала сбои продукта, часто выносят мониторинг на отдельные узлы. Для этого удобнее выделить отдельный VDS под Prometheus/Grafana/Alertmanager.
Grafana Alerting: сильные стороны и типовые сюрпризы
grafana alerting (Unified Alerting) — алертинг внутри Grafana: он может вычислять правила (в зависимости от источника данных), управлять контактными точками (Contact points), политиками уведомлений (Notification policies), группировкой, mute/silence-подобными механизмами и даёт единый UI для статусов и истории.
Где Grafana Alerting выигрывает в реальной эксплуатации
Единый интерфейс для нескольких источников. Когда в игре не только Prometheus-метрики, но и логи/трейсы/SQL-источники, удобно иметь одну витрину, один UX и единый процесс.
Быстрый старт для команд. Команды часто легче обучить работе в UI, чем заставить всех править YAML и проходить CI. Для небольших организаций это ускоряет внедрение алертинга.
Проще делегировать ответственность. Папки (folders), права и изоляция правил по командам делают модель «каждая команда владеет своими алертами» более управляемой, чем один огромный централизованный конфиг.
Где Grafana Alerting может создать проблемы
Сложнее обеспечить «один источник правды». Если часть алертов живёт в Git (Prometheus rules + Alertmanager), а часть в Grafana (в базе), появляется риск дрейфа: в тесте одно, в проде другое.
Grafana становится критичным компонентом. Если Grafana недоступна, нужно заранее понимать: продолжатся ли evaluation и доставка? Ответ зависит от режима развёртывания, наличия HA и того, где именно выполняется оценка правил.
Бэкапы/миграции надо проектировать. В «файловом» мире всё на ладони, в «UI-объектах» придётся дисциплинированно использовать provisioning/экспорт и контроль изменений.
Сравнение по ключевым темам: routing, silence, on-call
Routing: как доставить alerts «куда надо»
Alertmanager. Маршрутизация — дерево правил на основе меток. Сильная сторона — детерминированность: один и тот же alert всегда пройдёт по одному и тому же пути при одинаковых labels.
Grafana Alerting. Notification policies по смыслу похожи: матчат labels и выбирают contact points. Плюс — удобный UI и быстрый онбординг новых команд. Минус — при росте важно заранее договориться о контракте меток, иначе routing станет хаотичным.
Практический совет: независимо от инструмента, сначала договоритесь о словаре меток и сделайте его обязательным для всех алертов. Это окупается быстрее, чем любая тонкая настройка.
Минимальный набор меток, с которого обычно стоит начать:
severityteamserviceenv
Silence / Mute: как отключать шум безопасно
Alertmanager. Silence — понятный механизм: матч по меткам + окно времени + автор/комментарий. Отлично ложится на процедуры изменений: «глушим service=db на 30 минут, проводим миграцию».
Grafana Alerting. Подавление и mute-логика тоже есть, но они сильнее завязаны на структуру и права в Grafana (folders, permissions). Это удобно, но требует дисциплины доступа, иначе рискуете получить «тихий саботаж» критичных уведомлений.
Общий риск обоих подходов — «вечные» silences. Лечится процессом: лимит по времени, обязательный комментарий, регулярный аудит.
On-call и эскалации: где заканчивается алертинг и начинается инцидент-менеджмент
Ни Alertmanager, ни Grafana Alerting сами по себе не заменяют полноценный incident management (расписания, ротации, ack, эскалации). Но оба инструмента могут быть «передатчиком» в on-call слой.
- Alertmanager чаще используется как router, отправляющий события по webhook во внешнюю on-call систему.
- Grafana Alerting удобно использовать вместе с экосистемой Grafana и/или как единый центр уведомлений, тоже отправляя события наружу.
Если ваш главный запрос — дежурства и эскалации, проектируйте on-call как отдельный слой, а Alertmanager/Grafana используйте для корректного формирования, группировки и маршрутизации сигналов.
Надёжность и отказоустойчивость: что будет при падениях
Alertmanager обычно разворачивают в виде нескольких реплик. Даже если Grafana недоступна, цепочка «Prometheus → Alertmanager → уведомления» продолжит работать, потому что не зависит от UI.
Grafana Alerting по отказоустойчивости сильно зависит от топологии. Перед внедрением стоит ответить на три вопроса:
- Где выполняется evaluation правил и что будет при падении этого компонента?
- Насколько критична база Grafana и как устроены репликация/бэкапы?
- Как устроены повторы отправки уведомлений и дедупликация при кратковременных сбоях?
Если алертинг — линия обороны №1, избегайте архитектуры, где падение визуализации автоматически означает падение доставки критичных alerts.
GitOps и управление как код: где проще поддерживать порядок
Alertmanager органично живёт в GitOps: конфиг, ревью, проверки, деплой через CI/CD. Плюс — воспроизводимость и контроль изменений. Минус — без стандарта меток и культуры ревью конфиг быстро превращается в «лабиринт».
Grafana Alerting тоже можно вести как код, но это обычно набор практик (provisioning, экспорт, синхронизация между окружениями). Если этого не сделать, алерты начинают «жить в UI», и через полгода становится трудно понять, кто и зачем поменял политику.
Для старта полезно иметь отдельный контур синтетических проверок, чтобы ловить проблемы на уровне сетей и доступности ещё до метрик приложения: blackbox-алерты по HTTP/TCP/ICMP: настройка и примеры.
Если алерты ходят через вебхуки и внешние интеграции, часто всплывает вопрос доверия к endpoint’ам и защите транзита. В таких случаях имеет смысл сразу закладывать выпуск и ротацию SSL-сертификатов для внутренних панелей/шлюзов и публичных точек приёма.
Практика: гибридная схема «оба слоя» и как не утонуть в двойной настройке
В продакшене часто встречается гибрид:
- Prometheus оценивает rules и отправляет критичные S1/S2 алерты в Alertmanager как в максимально надёжный маршрутизатор.
- Grafana Alerting используется для дополнительных источников (например, по логам) и для менее критичных уведомлений, которыми владеют продуктовые команды.
Минус гибрида — два места, где можно ошибиться. Плюс — вы снижаете риск «единой точки отказа» и можете мигрировать по частям.
Минимальный пример маршрутизации в Alertmanager (скелет)
Смысл примера — показать структуру: общий маршрут, группировка и отдельные маршруты по team и severity. Под ваши каналы и интеграции блок receivers нужно адаптировать.
route:
receiver: default
group_by: ['alertname', 'service', 'env']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
routes:
- matchers:
- severity="critical"
receiver: oncall
- matchers:
- team="payments"
receiver: payments-team
receivers:
- name: default
- name: oncall
- name: payments-teamЧек-лист перед внедрением: чтобы alerts не превратились в шум
- Определите уровни критичности (например, S1/S2/S3) и ожидаемое время реакции.
- Стандартизируйте labels: минимум
severity,team,service,env. Проверьте, что они есть в каждом алерте. - Сделайте inhibition для типовых каскадов (симптомы подавляются при первопричине).
- Опишите процесс тишин: кто создаёт silence/mute, на сколько, с каким комментарием и как вы это проверяете.
- Тестируйте доставку: не только «сообщение пришло», но и группировка, повторы, resolved-уведомления.
- Добавьте runbook: что делать по алерту и где смотреть детали (дашборд, логи, трассировки).
Итог
Если вам нужен максимально надёжный и предсказуемый notification management для Prometheus-алертов — alertmanager остаётся эталоном: routing, silence, inhibition и дедупликация у него зрелые и хорошо подходят для продакшена.
Если важны единый интерфейс, алерты из разных источников и удобная модель делегирования ответственности командам — grafana alerting часто выигрывает по скорости внедрения и UX, но требует дисциплины в конфигурации, бэкапах и контроле изменений.
Выбирайте не по моде, а по операционной модели: кто владеет alerts, как устроен on-call, где хранится конфигурация, и что обязано продолжать работать, когда часть monitoring недоступна.
Если вы разворачиваете monitoring и алертинг на инфраструктуре, удобнее заранее планировать ресурсы и изоляцию под Prometheus/Grafana/Alertmanager на VDS (отдельно от приложений), чтобы падение продукта не тянуло за собой контур наблюдаемости.
