Prometheus Alertmanager против Grafana Alerting (2026): архитектура, возможности и когда использовать каждый из них

В большинстве систем наблюдаемости, работающих в проде более года, в итоге приходят к тому, что алертинг оказывается распределён между двумя системами: Prometheus Alertmanager обрабатывает алерты на основе метрик, а Grafana Alerting управляет всем остальным. Это создаёт проблему консолидации алертинга, когда команды on-call получают дублирующиеся уведомления, правила подавления находятся в двух местах, и никто точно не уверен, какая система является основной.

Вопрос простой: следует ли стандартизировать алертинг на Prometheus Alertmanager, перенести всё в Grafana Alerting или намеренно запускать обе системы? Ответ зависит от набора ваших источников данных, зрелости GitOps и того, как ваша организация управляет маршрутизацией on-call.

Обзор архитектуры

Prometheus Alertmanager: автономный компонент для приёма алертов

Alertmanager — это выделенный автономный компонент в экосистеме Prometheus. Он не обрабатывает правила оповещений самостоятельно. Вместо этого Prometheus (или совместимые инструменты, такие как Thanos Ruler или Mimir Ruler) обрабатывает выражения PromQL и отправляет оповещения в API Alertmanager. Затем Alertmanager обрабатывает дедупликацию, группировку, подавление и доставку уведомлений.

# Simplified Prometheus → Alertmanager flow
#
# [Prometheus] --evaluates rules--> [firing alerts]
#        |
#        +--POST /api/v2/alerts--> [Alertmanager]
#                                      |
#                          +-----------+-----------+
#                          |           |           |
#                       [Slack]    [PagerDuty]  [Email]

Вся конфигурация находится в одном YAML-файле (alertmanager.yml). Он включает в себя дерево маршрутизации, определения получателей и шаблоны подавлений. Нет базы данных, нет состояния, управляемого пользовательским интерфейсом — только файл конфигурации и необязательный локальный каталог для хранения состояния уведомлений и подавлений. Это делает его легко воспроизводимым и идеально подходящим для GitOps.

Для высокой доступности можно запустить несколько экземпляров Alertmanager в кластере на основе gossip. Они используют mesh-протокол для обмена состоянием подавлений и уведомлений, обеспечивая отсутствие дублирующихся или потерянных уведомлений при сбое.

Grafana Alerting: интегрированная платформа

Grafana Alerting (иногда называемая «Grafana Unified Alerting», представленная в Grafana 8) использует другой архитектурный подход. Она встраивает весь жизненный цикл алертинга — оценку правил, управление состоянием, маршрутизацию и уведомления — непосредственно в процесс Grafana. Внутри она использует форк Alertmanager для уровня маршрутизации и уведомлений.

# Simplified Grafana Alerting flow
#
# [Grafana Server]
#   ├── Rule Evaluation Engine
#   │     ├── queries Prometheus
#   │     ├── queries Loki
#   │     ├── queries CloudWatch
#   │     └── queries any supported datasource
#   │
#   ├── Alert State Manager (internal)
#   │
#   └── Embedded Alertmanager (routing + notifications)
#           |
#           +-----------+-----------+
#           |           |           |
#        [Slack]    [PagerDuty]  [Email]

Ключевое отличие заключается в том, что система оповещений Grafana самостоятельно оценивает правила оповещений, запрашивая данные из любого настроенного источника — а не только из Prometheus. Она может запускать оповещения на основе запросов к логам Loki, поисковых запросов Elasticsearch, метрик CloudWatch, запросов PostgreSQL или любого из более чем 100 плагинов источников данных, доступных в Grafana. Определения правил, контактные точки, политики уведомлений и интервал отключения хранятся в базе данных Grafana (или предоставляются через YAML-файлы и API Grafana).

Преимущества Alertmanager

Alertmanager является стандартом для production-среды с 2015 года. Более десяти лет использования в тысячах организаций сделали его одним из наиболее проверенных временем компонентов в экосистеме CNCF.

Декларативная конфигурация, изначально разработанная для GitOps

Вся конфигурация Alertmanager находится в одном YAML-файле. Никакого скрытого состояния в базе данных, никакой настройки через интерфейс, о которой кто-то забудет написать в документации. Вы храните этот файл в Git, проверяете изменения через pull request и разворачиваете его с помощью CI/CD-пайплайна, как любой другой код инфраструктуры.

# alertmanager.yml — everything in one file
global:
  resolve_timeout: 5m
  slack_api_url: "https://hooks.slack.com/services/T00/B00/XXX"

route:
  receiver: platform-team
  group_by: [alertname, cluster, namespace]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - match:
        severity: critical
      receiver: pagerduty-oncall
      group_wait: 10s
    - match_re:
        team: "^(payments|checkout)quot;
      receiver: payments-slack
      continue: true

receivers:
  - name: platform-team
    slack_configs:
      - channel: "#platform-alerts"
  - name: pagerduty-oncall
    pagerduty_configs:
      - service_key: ""
  - name: payments-slack
    slack_configs:
      - channel: "#payments-oncall"

inhibit_rules:
  - source_match:
      severity: critical
    target_match:
      severity: warning
    equal: [alertname, cluster]

Каждое изменение можно отследить. Откат выполняется через git revert. Это чрезвычайно важно, когда вы разбираетесь, почему алерт не сработал в 3 часа ночи.

Легкий и узкоспециализированный

Alertmanager выполняет одну задачу: маршрутизацию и доставку уведомлений. У него нет дашборда, движка запросов или плагинов источников данных. Такая узкоспециализированная конструкция делает его простым в эксплуатации. Потребление ресурсов минимально — небольшой экземпляр Alertmanager обрабатывает тысячи активных оповещений, занимая всего несколько сотен мегабайт памяти. Он запускается за миллисекунды и практически не требует обслуживания.

Зрелое подавление событий и маршрутизация

Правила подавления Alertmanager являются полноценной частью системы. Вы можете подавлять предупреждения нижестоящего уровня, когда уже срабатывает критический алерт, предотвращая лавину алертов, которая может перегрузить команду on-call. Иерархическое дерево маршрутизации с флагами continue позволяет выполнять сложную доставку: отправлять уведомление в командный канал И одновременно эскалировать его в PagerDuty, используя разные стратегии группировки на каждом уровне.

Проверенная временем высокая доступность

Кластер высокой доступности на основе протокола Gossip стабильно работает уже много лет. Запуск трех реплик Alertmanager за балансировщиком нагрузки (или использование механизма Service Discovery в Kubernetes) обеспечивает надежную доставку уведомлений без общего хранилища. Протокол автоматически обрабатывает дедупликацию между экземплярами, что является самой сложной частью распределённого алертинга.

Уровни оповещений Grafana

Система оповещений Grafana значительно усовершенствовалась с момента своего непростого запуска в Grafana 8. К Grafana 11 и 12 она превратилась в полноценную платформу оповещений для производственной среды с возможностями, недоступными для Alertmanager.

Правила оповещения для нескольких источников данных

Это главное отличие Grafana Alerting. Вы можете создавать правила оповещений, которые запрашивают Loki для обнаружения всплесков ошибок в логах, CloudWatch для отслеживания использования ресурсов AWS, Elasticsearch для обнаружения ошибок приложений или базу данных PostgreSQL для получения бизнес-метрик — и всё это в рамках одной системы оповещений. Если ваш стек мониторинга включает в себя не только Prometheus, это устраняет необходимость в отдельных инструментах оповещения для каждого источника данных.

# Grafana alert rule provisioning example — alerting on Loki log errors
apiVersion: 1
groups:
  - orgId: 1
    name: application-errors
    folder: Production
    interval: 1m
    rules:
      - uid: loki-error-spike
        title: "High error rate in payment service"
        condition: C
        data:
          - refId: A\            datasourceUid: loki-prod
            model:
              expr: 'sum(rate({app="payment-service"} |= "ERROR" [5m]))'
          - refId: B
            datasourceUid: "__expr__"
            model:
              type: reduce
              expression: A
              reducer: last
          - refId: C
            datasourceUid: "__expr__"
            model:
              type: threshold
              expression: B
              conditions:
                - evaluator:
                    type: gt
                    params: [10]
        for: 5m
        labels:
          severity: warning
          team: payments

Alertmanager просто не может этого сделать. Alertmanager получает только предварительно оценённые алерты — у него нет понятия источников данных или выполнения запросов.

Единый пользовательский интерфейс для управления оповещениями

Grafana предоставляет единый интерфейс для создания правил алертов, их визуализации, управления политиками уведомлений, настройки контактных точек и управления silence. Для команд, где не каждый инженер уверенно работает с YAML-деревьями маршрутизации, визуальный редактор политик уведомлений значительно снижает порог входа. Вы можете увидеть состояние каждого правила алерта, историю его срабатываний и точный путь, по которому будет отправлено уведомление, — и всё это, не покидая браузер.

Нативная мультитенантность и RBAC

Организационная модель Grafana и управление доступом на основе ролей естественным образом распространяются и на систему оповещений. Разные команды могут управлять своими собственными правилами оповещений, контактными точками и политиками уведомлений в рамках своей организации или папки, не видя и не вмешиваясь в работу других команд. Для достижения этого с помощью автономного Alertmanager требуется либо запуск отдельных экземпляров для каждого клиента, либо использование многопользовательского Alertmanager от Mimir.

Отключение синхронизации и более гибкое планирование

В то время как Alertmanager поддерживает подавление (разовое временное отключение уведомлений), Grafana Alerting добавляет функцию отключения уведомлений по расписанию — повторяющиеся временные периоды, в течение которых уведомления отключаются. Это полезно для запланированных периодов технического обслуживания, оповещений только в рабочее время или подавления некритических оповещений в выходные дни. Для Alertmanager требуется использование внешних инструментов или ручное создание подавлений для повторяющихся периодов.

Grafana Cloud как управляемое решение

Для команд, которые хотят полностью отказаться от управления инфраструктурой алертинга, Grafana Cloud предоставляет полностью управляемый стек Grafana Alerting. Он включает HA, сохранение состояния и доставку уведомлений без каких-либо компонентов, размещённых самостоятельно. Стек алертинга Grafana Cloud также включает управляемый Mimir Alertmanager, поэтому вы можете использовать нативные для Prometheus правила алертинга, если предпочитаете эту модель, и при этом пользоваться управляемой инфраструктурой.

Когда использовать Prometheus Alertmanager

Alertmanager является правильным выбором, когда вашему окружению соответствуют следующие условия:

• Ваша система метрик изначально использует Prometheus. Если все ваши правила алертов являются выражениями PromQL, которые оцениваются Prometheus, Thanos Ruler или Mimir Ruler, Alertmanager является естественным выбором. Нет дополнительной ценности в маршрутизации этих алертов через Grafana.
• GitOps является обязательным требованием. Если каждое изменение инфраструктуры должно проходить через pull request и быть полностью декларативным, модель конфигурации Alertmanager в одном файле значительно проще в управлении, чем состояние Grafana, хранящееся в базе данных. Такие инструменты, как amtool, обеспечивают проверку конфигурации в CI-процессах.
• Вам нужна детальная маршрутизация с ингибированием. Сложные деревья маршрутизации с несколькими уровнями группировки, правилами ингибирования и флагами continue естественнее выражаются в YAML-формате Alertmanager. Логика маршрутизации остаётся стабильной и хорошо документированной уже много лет.
• Вы используете микросервисы с маршрутизацией по командам. Если каждая команда владеет своим поддеревом маршрутизации и логика маршрутизации сложная, иерархическая модель Alertmanager лучше масштабируется, чем конфигурация через UI. Команды могут владеть своей частью конфигурационного файла через CODEOWNERS в Git.
• Вы хотите минимальных операционных затрат. Alertmanager — это единый исполняемый файл с минимальными требованиями к ресурсам. Нет необходимости создавать резервные копии базы данных, запускать миграции и обновлять пользовательский интерфейс.

Когда использовать Grafana Alerting

Grafana Alerting является правильным выбором, когда применимы следующие условия:

• Вы создаёте алерты не только по метрикам Prometheus. Если вам нужны правила алертов на основе логов Loki, запросов Elasticsearch, метрик CloudWatch или запросов к базам данных, Grafana Alerting — единственный вариант, позволяющий нативно обрабатывать всё это. Альтернатива — запускать отдельные инструменты алертинга для каждого источника данных, что хуже.
• Ваша команда предпочитает конфигурацию, управляемую пользовательским интерфейсом. Не каждый инженер хочет редактировать YAML-деревья маршрутизации. Если ваша организация ценит визуальный интерфейс для управления алертами, контактными точками и политиками уведомлений, UI Grafana является большим преимуществом для продуктивности.
• Вы используете Grafana Cloud. Если вы уже работаете с Grafana Cloud, использование встроенного алертинга является наиболее простым вариантом. Вы получаете HA, управляемую доставку уведомлений и единый интерфейс без необходимости запускать дополнительную инфраструктуру.
• Многопользовательский режим является обязательным требованием. Если нескольким командам нужны изолированные конфигурации алертинга с RBAC, нативная модель доступа Grafana на основе организаций и папок значительно проще в настройке, чем запуск отдельных экземпляров Alertmanager для каждого тенанта.
• Вам нужны настройки времени отключения оповещений для повторяющихся периодов технического обслуживания. Если вашей команде регулярно необходимо отключать оповещения в запланированные периоды (периоды развертывания, часы пакетной обработки, отключение некритичных алертов в выходные дни), функция отключения оповещений в Grafana будет более эргономичной, чем создание и управление повторяющимися подавлениями в Alertmanager.

Совместное использование обоих методов: гибридный подход

На практике многие production-окружения запускают одновременно Alertmanager и Grafana Alerting. Это не обязательно ошибка — это может быть осознанным архитектурным решением при наличии чётких границ ответственности.

Распространённая гибридная архитектура

Наиболее распространенный вариант выглядит так:

• Prometheus Alertmanager обрабатывает все алерты на основе метрик. Правила PromQL оцениваются Prometheus или системой долговременного хранения с ruler (Thanos, Mimir). Alertmanager отвечает за маршрутизацию, группировку и уведомления для этих алертов.
• Grafana Alerting обрабатывает оповещения, не связанные с Prometheus: оповещения на основе логов из Loki, бизнес-метрики из источников данных SQL и правила корреляции между источниками данных.

Ключ к успешной работе без хаоса — установление четких правил владения:

# Ownership boundaries for hybrid alerting
#
# Prometheus Alertmanager owns:
#   - All PromQL-based alert rules
#   - Infrastructure alerts (node, kubelet, etcd, CoreDNS)
#   - Application SLO/SLI alerts based on metrics
#
# Grafana Alerting owns:
#   - Log-based alert rules (Loki, Elasticsearch)
#   - Business metric alerts (SQL datasources)
#   - Cross-datasource correlation rules
#   - Alerts for teams that prefer UI-driven management
#
# Shared:
#   - Contact points / receivers use the same Slack channels and PagerDuty services
#   - On-call rotations are managed externally (PagerDuty, Grafana OnCall)

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

Grafana как интерфейс просмотра Alertmanager

Даже если вы используете Alertmanager исключительно для маршрутизации и уведомлений, Grafana может выступать в качестве средства просмотра только для чтения. Grafana нативно поддерживает подключение к внешнему источнику данных Alertmanager, позволяя видеть срабатывающие алерты, активные подавления и группы алертов в UI Grafana. Это даёт операционную видимость Grafana без переноса логики алертинга в неё.

# Grafana datasource provisioning for external Alertmanager
apiVersion: 1
datasources:
  - name: Alertmanager
    type: alertmanager
    url: http://alertmanager.monitoring.svc:9093
    access: proxy
    jsonData:
      implementation: prometheus

Вопросы миграции

Если вы переходите с одной системы на другую, вот несколько практических моментов, которые следует учесть при планировании.

Миграция с Alertmanager на Grafana Alerting

• Преобразование правил. Ваши правила записи и алертов на основе PromQL, определённые в файлах правил Prometheus, необходимо заново создать как правила Grafana Alerting. Grafana предоставляет инструмент миграции, который может импортировать правила в формате Prometheus, но сложные выражения могут потребовать ручной корректировки.
• Перенос дерева маршрутизации. Иерархическое дерево маршрутизации Alertmanager соответствует политикам уведомлений Grafana, но семантика не идентична. Тщательно протестируйте маршрутизацию уведомлений — поведение флага continue и маршрутов по умолчанию может отличаться.
• Миграция правил подавления и ингибирования. Активные подавления являются временными и не требуют миграции. Правила ингибирования необходимо заново создать в формате Grafana. Повторяющиеся периоды технического обслуживания следует преобразовать в интервалы отключения.
• Сначала запустите системы параллельно. Самая безопасная стратегия миграции — в течение двух–четырёх недель держать обе системы запущенными параллельно, отправляя уведомления из обеих систем, а затем выполнить переключение, когда вы убедитесь в корректности настройки Grafana. Смиритесь с временным «шумом» от дублирующихся оповещений — это значительно дешевле, чем пропустить критически важный алерт во время миграции.

Миграция с Grafana Alerting на Alertmanager

• Ограничение источников данных. Вы можете перенести только алерты, основанные на источниках данных, совместимых с Prometheus. Алерты, которые запрашивают Loki, Elasticsearch или SQL-источники, не имеют эквивалента в Alertmanager — для них потребуется альтернативное решение.
• Экспорт правил. Экспортируйте правила алертов Grafana и преобразуйте их в файлы правил в формате Prometheus. API Grafana (GET /api/v1/provisioning/alert-rules) предоставляет структурированный вывод, который можно преобразовать с помощью скрипта.
• Сопоставление контактных точек. Сопоставьте контактные точки Grafana с получателями Alertmanager. Формат конфигурации отличается, но концепции эквивалентны.
• Потеря состояния. Alertmanager не переносит историю оценки алертов Grafana. Вы начинаете с чистого состояния. Запланируйте короткий период, в течение которого алерты могут сработать повторно, пока Prometheus оценивает правила, ранее управляемые Grafana.

Схема принятия решения

Если вам нужен быстрый путь к решению, используйте эту схему:

Start here:
│
├── Do you alert on non-Prometheus datasources (Loki, ES, SQL, CloudWatch)?
│   ├── YES → Grafana Alerting (at least for those datasources)
│   └── NO ↓
│
├── Is GitOps/declarative config a hard requirement?
│   ├── YES → Alertmanager
│   └── NO ↓
│
├── Do you need multi-tenancy with RBAC?
│   ├── YES → Grafana Alerting (or Mimir Alertmanager)
│   └── NO ↓
│
├── Are you on Grafana Cloud?
│   ├── YES → Grafana Alerting (path of least resistance)
│   └── NO ↓
│
└── Default → Alertmanager (simpler, lighter, well-proven)

Для многих команд оптимальным решением будет использовать обе системы: Alertmanager для нативного для Prometheus процесса работы с метриками, Grafana Alerting — для всего остального. Это допустимая архитектура, если границы ответственности задокументированы и команда on-call знает, где искать нужную информацию.

Часто задаваемые вопросы

В чём разница между Alertmanager и Grafana Alerting?

Prometheus Alertmanager — это автономный механизм маршрутизации уведомлений, который получает предварительно оценённые алерты от Prometheus и доставляет их таким получателям, как Slack, PagerDuty или email. Grafana Alerting — это интегрированная платформа алертинга, встроенная в Grafana, которая одновременно оценивает правила алертов и обрабатывает маршрутизацию уведомлений. Alertmanager полностью настраивается через YAML, тогда как Grafana Alerting предоставляет UI, API и provisioning через файлы. Принципиальное различие заключается в области ответственности: Alertmanager обрабатывает только этап маршрутизации и уведомлений, тогда как Grafana Alerting обрабатывает весь жизненный цикл — от оценки запросов до уведомления.

Может ли Grafana Alerting заменить Prometheus Alertmanager?

Да, для многих сценариев. Grafana Alerting может напрямую оценивать правила PromQL относительно источника данных Prometheus, поэтому отдельный экземпляр Alertmanager строго не требуется. Однако существуют сценарии, в которых Alertmanager остаётся лучшим выбором: окружения с активным использованием GitOps, команды, которым нужны зрелые правила ингибирования Alertmanager, или архитектуры, где оценка правил Prometheus выполняется внешним компонентом (Thanos Ruler, Mimir Ruler), а выделенный Alertmanager уже присутствует в процессе. Если вашим единственным источником данных является Prometheus и вы цените декларативную конфигурацию, Alertmanager по-прежнему проще и легче.

Grafana Alertmanager — это то же самое, что Prometheus Alertmanager?

Не совсем. Grafana Alerting использует форк кода Prometheus Alertmanager внутри своего механизма маршрутизации уведомлений, но это не один и тот же продукт. «Alertmanager» Grafana, который отображается в UI, является управляемым встроенным компонентом с другим интерфейсом конфигурации (политики уведомлений, контактные точки, интервалы отключения) по сравнению с standalone Prometheus Alertmanager (дерево маршрутизации, получатели, правила ингибирования в YAML). Grafana также может подключаться к внешнему Prometheus Alertmanager как к источнику данных, что добавляет путаницы.

Какие существуют лучшие альтернативы Prometheus Alertmanager?

Самая прямая альтернатива — Grafana Alerting, которая может получать и маршрутизировать алерты Prometheus, а также поддерживать другие источники данных. Кроме этого, Grafana OnCall для управления on-call и эскалациями, PagerDuty или Opsgenie как управляемые платформы реагирования на инциденты, Keep как open-source AIOps-платформа управления алертами и Mimir Alertmanager для мультитенантных окружений, работающих с Grafana Mimir.

Следует ли использовать алерты Prometheus или Grafana для мониторинга Kubernetes?

Конкретно для мониторинга Kubernetes kube-prometheus-stack (который включает Prometheus, Alertmanager и полный набор заранее созданных правил алертинга) остаётся отраслевым стандартом. Эти правила основаны на PromQL и предназначены для работы с Alertmanager. Если вы разворачиваете kube-prometheus-stack, использование Alertmanager для алертов на основе метрик является очевидным выбором. Добавьте Grafana Alerting сверху, если вам также нужны алерты по логам (через Loki) или по источникам данных, не связанным с метриками.

Итог

Дискуссия Alertmanager против Grafana Alerting на самом деле не о том, какой инструмент лучше, — она о том, какой инструмент подходит вашему операционному контексту. Alertmanager проще, легче и лучше подходит для GitOps. Grafana Alerting более универсальна, доступнее для команд, ориентированных на UI, и является единственным вариантом, если вам нужен алертинг по нескольким источникам данных. Запускать оба инструмента вполне допустимо, если границы ответственности чётко определены.

Худший исход — это не выбор «неправильного» инструмента. Худший исход — случайно запустить оба, с перекрывающимся покрытием, дублирующимися уведомлениями и отсутствием чёткой ответственности. Что бы вы ни выбрали, задокументируйте решение, определите границы ответственности и убедитесь, что ваша дежурная команда точно знает, куда обратиться, когда им нужно отключить оповещение в 3 часа ночи.