Alertmanager: алерты которые не бесят

Если вы когда-нибудь просыпались в три ночи от очередного уведомления о том, что CPU загружен на 80% — добро пожаловать в клуб. Alertmanager, компонент экосистемы Prometheus, создан именно для того, чтобы превратить хаотичный поток алертов в управляемую, осмысленную систему уведомлений. В этой статье разберём, как настроить его так, чтобы дежурный инженер получал только то, что действительно требует внимания.

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

Ключевые возможности:

• Группировка — объединяет похожие алерты в одно уведомление
• Ингибирование — подавляет второстепенные алерты, если сработал критичный
• Сайленсы — временное отключение алертов на период обслуживания
• Маршрутизация — разные алерты идут в разные каналы

Установим Alertmanager на Ubuntu/Debian:

wget https://github.com/prometheus/alertmanager/releases/download/v0.27.0/alertmanager-0.27.0.linux-amd64.tar.gz
tar xzf alertmanager-0.27.0.linux-amd64.tar.gz
sudo mv alertmanager-0.27.0.linux-amd64/alertmanager /usr/local/bin/
sudo mv alertmanager-0.27.0.linux-amd64/amtool /usr/local/bin/

Базовый конфиг alertmanager.yml:

global:
  resolve_timeout: 5m
  slack_api_url: 'https://hooks.slack.com/services/YOUR/WEBHOOK/URL'

route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'slack-notifications'
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty-critical'
      continue: true

receivers:
  - name: 'slack-notifications'
    slack_configs:
      - channel: '#alerts'
        title: '{{ .GroupLabels.alertname }}'
        text: '{{ range .Alerts }}{{ .Annotations.description }}
{{ end }}'

  - name: 'pagerduty-critical'
    pagerduty_configs:
      - routing_key: 'YOUR_PAGERDUTY_KEY'

Самая болезненная проблема — alert storm, когда падает один сервис и генерирует десятки уведомлений. Параметр group_by позволяет объединять алерты по меткам.

Пример: если упал целый кластер, вы получите одно сообщение вместо уведомления по каждой ноде:

route:
  group_by: ['cluster', 'alertname']
  group_wait: 30s      # ждём 30 секунд перед первой отправкой
  group_interval: 5m   # интервал для новых алертов в группе
  repeat_interval: 3h  # повтор если не resolved

group_wait — критически важный параметр. За эти 30 секунд Alertmanager собирает все алерты одной группы и отправляет их пачкой.

Если упал весь датацентр, алерты о недоступности отдельных сервисов — шум. Ингибирование решает это:

inhibit_rules:
  - source_match:
      severity: 'critical'
      alertname: 'DatacenterDown'
    target_match:
      severity: 'warning'
    equal: ['datacenter']

Пока активен алерт DatacenterDown с severity=critical, все warning-алерты для того же датацентра будут подавлены.

Перед деплоем или техработами создайте сайленс через amtool:

amtool silence add 
  alertname="HighMemoryUsage" 
  --comment="Плановое обслуживание серверов" 
  --duration=2h 
  --alertmanager.url=http://localhost:9093

Или через веб-интерфейс на порту 9093 — там всё интуитивно понятно.

Alertmanager не волшебная таблетка, но правильно настроенная маршрутизация и группировка способны сократить alert fatigue в разы. Начните с простого: настройте group_by по alertname и cluster, добавьте базовое ингибирование для критических алертов — и дежурные инженеры скажут вам спасибо.