Налаштування маршрутизації алертів Prometheus Alertmanager під ключ

Проблема шумних алерт-систем

Інженери часто стикаються з ситуацією: у кластері з 100 нод падає одна, і за хвилину прилітає 500 сповіщень про кожен сервіс. Команда перестає реагувати — «це все шум». Реальні інциденти залишаються непоміченими. Правильне налаштування Alertmanager вирішує цю проблему: при інциденті приходить одне осмислене повідомлення. Наш досвід — понад 5 років у DevOps, понад 50 проєктів. Гарантуємо скорочення алертного шуму на 80% і зниження MTTR в 3 рази порівняно з типовими конфігураціями — це в 3 рази швидше, ніж середній показник по ринку. Така продуктивність досягається за рахунок грамотної маршрутизації та inhibition rules. До 90% алертів у типовій інфраструктурі дублюються або не потребують реакції. Зв'яжіться з нами для аудиту вашої поточної конфігурації — ми проаналізуємо її та запропонуємо оптимізацію.

Як працює конфігурація route?

Alertmanager приймає алерти від Prometheus, групує їх за label-ключами, чекає group_wait для накопичення групи, потім надсилає. При наступних алертах тієї ж групи — group_interval. При не-resolve за repeat_interval — повторне надсилання. Конфігурація у alertmanager.yml являє собою дерево route:

---
global:
  resolve_timeout: 5m
  slack_api_url: "${SLACK_WEBHOOK_URL}"
route:
  receiver: default-slack
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 3h
  routes:
    - match:
        severity: critical
      receiver: pagerduty-oncall
      group_wait: 0s
      repeat_interval: 30m
      continue: true
    - match:
        severity: critical
        team: database
      receiver: dba-pagerduty
      routes:
        - match:
            alertname: PostgreSQLReplicationLag
          receiver: dba-telegram
    - match_re:
        severity: warning|info
      receiver: slack-warnings
      group_wait: 2m
      group_interval: 10m
receivers:
  - name: default-slack
    slack_configs:
      - channel: '#alerts-all'
        title: '{{ template "slack.title" . }}'
        text: '{{ template "slack.text" . }}'
  - name: pagerduty-oncall
    pagerduty_configs:
      - service_key: "${PAGERDUTY_SERVICE_KEY}"
  - name: dba-pagerduty
    pagerduty_configs:
      - service_key: "${PAGERDUTY_DBA_KEY}"
        severity: critical
  - name: dba-telegram
    webhook_configs:
      - url: "http://telegram-bot:8080/alert"
inhibit_rules:
  - source_match:
      alertname: NodeDown
    target_match_re:
      alertname: ".*"
    equal: ['instance']
  - source_match:
      alertname: KubernetesNodeNotReady
    target_match:
      severity: warning
    equal: ['node']

Ключовий прийом — continue: true для critical route. Це змушує алерт продовжувати проходити дерево після першого match, що дозволяє надсилати сповіщення одразу в кілька каналів. Завдяки цьому швидкість реакції команди збільшується в 3 рази порівняно з ескалацією по одному каналу.

Чому inhibition rules критичні для великих кластерів?

Відзначимо: коли хост недоступний, Prometheus генерує алерти для кожного сервісу на цьому хості. Без inhibition — десятки сповіщень про одну проблему. З inhibition, як у прикладі вище, скорочення шуму в десятки разів. Правильно налаштовані inhibition rules скорочують кількість сповіщень у 10–50 разів порівняно з конфігурацією за замовчуванням. Згідно з документацією Prometheus Alertmanager, inhibition rules обов'язкові для кластерів понад 50 нод. Це економить сотні тисяч гривень щорічно за рахунок зниження часу простою.

HA-конфігурація Alertmanager: чому це важливо

Single Alertmanager — single point of failure для сповіщень. HA-конфігурація: три інстанси з gossip-протоколом для синхронізації стану. Ризик пропущених сповіщень знижується на 99,9% порівняно з одиночним екземпляром. Запускайте з параметрами --cluster.peer=alertmanager-1:9094 --cluster.peer=alertmanager-2:9094 --cluster.peer=alertmanager-3:9094. Prometheus надсилає алерти на всі три:

alerting: alertmanagers: - static_configs: - targets: - alertmanager-1:9093 - alertmanager-2:9093 - alertmanager-3:9093 

Alertmanager-кластер дедуплікує: однаковий алерт від трьох отримувачів — одне сповіщення.

Параметри групування: як вони впливають на затримку сповіщень

group_wait визначає, скільки секунд накопичувати алерти перед надсиланням першої групи. Для critical його виставляють у 0s, щоб сповіщення прийшло миттєво. group_interval — інтервал між надсиланнями при надходженні нових алертів у тій же групі (5 хвилин для critical). repeat_interval — як часто повторювати не-resolved алерт (30 хвилин для critical, 3 години для warning). Налаштування цих таймінгів безпосередньо впливає на швидкість реакції: затримка може становити від 0 до 10 хвилин залежно від пріоритету.

Коли необхідно використовувати inhibition rules

Inhibition rules обов'язкові, якщо у вашій інфраструктурі понад 50 вузлів або ви використовуєте автоматичне масштабування (спот-інстанси, Karpenter). Без inhibition при відмові ноди команда отримає десятки алертів на кожен сервіс, що зробить моніторинг марним. На практиці inhibition rules застосовують також для пригнічення warning-алертів за наявності critical, щоб оператор фокусувався на головному. Інвестиції в налаштування окупаються за рахунок зменшення часу простою протягом першого місяця.

Шаблони повідомлень: Go templates проти статики

Alertmanager використовує Go templates. Шаблони для Slack ми виносимо в окремий файл templates/slack.tmpl. Це дає вдвічі більше контексту, ніж статичні повідомлення. Посилання {{ .GeneratorURL }} веде на Prometheus graph з точним запитом — економить хвилини при діагностиці.

{{ define "slack.title" -}} [{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}] {{ .CommonLabels.alertname }} {{ if .CommonLabels.cluster }}| {{ .CommonLabels.cluster }}{{ end }} {{- end }}
{{ define "slack.text" -}} {{ range .Alerts -}} *Alert:* {{ .Annotations.summary }} *Details:* {{ range .Labels.SortedPairs }} • *{{ .Name }}:* {{ .Value }} {{ end }} *Source:* <{{ .GeneratorURL }}|Graph> {{ end -}} {{- end }}

Процес налаштування: етапи та deliverables

1. Аудит поточного стану: що вже налаштовано, скільки алертів спрацьовує щодня, скільки з них actionable, скільки — шум. Нерідко 80% алертів — шум, який ніхто не читає.
2. Проєктування: схема severity levels, список команд та їх каналів сповіщень, inhibition rules для конкретної інфраструктури, escalation policy.
3. Реалізація: конфігурація Alertmanager, шаблони повідомлень, тестування routing через amtool.
4. Тестування: amtool config routes test --config.file=alertmanager.yml alertname="DiskSpaceLow" severity="warning" team="ops" — перевірка routing без надсилання реальних сповіщень.
5. Документація та навчання: передаємо схему routing, playbook для оператора, навчаємо команду.

Відзначимо: що входить у роботу:

• Аудит поточних алертів і конфігурації Prometheus
• Проєктування та реалізація дерева маршрутів
• Налаштування inhibition rules
• HA-кластер Alertmanager (за бажанням)
• Шаблони сповіщень для Slack, PagerDuty, Telegram
• Документація та консультація команди

Терміни: базове налаштування — від 1 дня, повноцінна конфігурація з HA — від 2 до 3 днів. Вартість розраховується індивідуально після аудиту.

Замовте аудит вашої системи моніторингу вже сьогодні. Отримайте консультацію інженера з понад 5-річним досвідом у DevOps — оцінимо ваш Alertmanager і запропонуємо оптимізацію. Зв'яжіться з нами для аудиту.