Как настроить группировку, дедупликацию и маршрутизацию алертов в Alertmanager, чтобы дежурный получал одно осмысленное уведомление вместо лавины отдельных алертов?

Короткий ответ

В конфигурации route задаются group_by (какие labels объединяют похожие алерты в одно уведомление), group_wait (сколько ждать перед первой отправкой группы, чтобы собрать связанные алерты), group_interval (пауза между обновлениями той же группы) и repeat_interval (как часто повторять уведомление, если проблема не решена); маршрутизация по receiver определяет, куда (Slack/PagerDuty/email) и для каких severity/team отправлять.

Как это работает подробнее

если одновременно срабатывает 20 алертов с одинаковым service и severity (например, все поды одного сервиса стали недоступны после сбоя узла), Alertmanager группирует их в одно уведомление согласно group_by: [service, alertname], а не отправляет 20 отдельных сообщений. group_wait даёт небольшую задержку (например, 30 секунд) перед первой отправкой, чтобы успеть собрать все связанные алерты, возникшие практически одновременно, в одну группу.

Пример кода

config.yamlКопировать

route:
  group_by: ["service", "alertname"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: "slack-default"
  routes:
    - matchers: ["severity=critical"]
      receiver: "pagerduty"
      repeat_interval: 15m
inhibit_rules:
  - source_matchers: ["alertname=ServiceDown"]
    target_matchers: ["alertname=HighLatency"]
    equal: ["service"]

Что использовать на практике

• Практика. дерево route позволяет направлять критичные production-алерты в PagerDuty с коротким repeat_interval (например, 15 минут, чтобы не забыть про нерешённую проблему), а некритичные/информационные — в Slack-канал с более длинным интервалом или вовсе без повтора. Отдельно inhibit_rules позволяют подавить менее важный алерт, если уже активен более важный, логически его перекрывающий (например, не слать алерт "высокая latency сервиса", если уже активен алерт "сервис полностью недоступен").
• Практика. При падении сервиса одновременно сработают ServiceDown и HighLatency для того же service; благодаря inhibit_rules дежурный получит только критичный ServiceDown через PagerDuty, а шумный производный HighLatency будет подавлен — это проверяется по вкладке /#/alerts в Alertmanager, где HighLatency будет отмечен как Inhibited.

Подводные камни

• Частые ошибки. группировать слишком широко (group_by: [], то есть по всем лейблам сразу), из-за чего каждый уникальный набор лейблов создаёт отдельную группу и эффект группировки пропадает; группировать слишком узко (group_by: [alertname] без service), из-за чего алерты от совершенно разных сервисов схлопываются в одно нечитаемое уведомление; не настраивать inhibit_rules, получая одновременно и общий алерт о недоступности сервиса, и десятки производных алертов о каждом отдельном симптоме этой недоступности.