Alertmanager: кому и сколько раз уходят алерты

Alertmanager — служба, которая получает алерты от Prometheus и решает, кому, когда и сколько раз о них сообщить. Prometheus по правилу решает, что алерт горит (prometheus), и отправляет его в Alertmanager. Дальше Alertmanager:

1. собирает алерты в группы по меткам, чтобы одно событие давало одно уведомление, а не по одному на каждую машину;
2. по дереву маршрутов выбирает получателя;
3. пропускает алерты, которые заглушены тишиной или подавлены другим алертом;
4. отправляет уведомление — письмо, вебхук, сообщение в чат — и повторяет его, пока алерт горит.

Prometheus ──алерты──▶ Alertmanager :9093 ──уведомления──▶ получатели
 (правила)              группы, маршруты,                 (webhook,
                        тишина, подавление                 почта…)

В Ubuntu это пакет prometheus-alertmanager: служба с тем же именем, конфиг /etc/prometheus/alertmanager.yml, данные — тишины и журнал отправленного — в /var/lib/prometheus/alertmanager. Порт 9093 — веб-интерфейс и API, 9094 — связь узлов кластера. Утилита amtool — из того же пакета. На учебной машине пакет стоит, служба выключена, а конфиг из пакета — пример с почтой и PagerDuty: без сети он бесполезен, свой конфиг пишут заново.

Путь алерта

Куда Prometheus отправляет алерты — раздел alerting в prometheus.yml; в пакете это localhost:9093. Нашёл ли Prometheus Alertmanager:

$ curl -s localhost:9090/api/v1/alertmanagers | jq -c .data
{"activeAlertmanagers":[{"url":"http://localhost:9093/api/v2/alerts"}],
  "droppedAlertmanagers":[]}

Адрес отправки Prometheus собирает из scheme (по умолчанию http), адреса из targets, path_prefix (по умолчанию пусто) и /api/v2/alerts; полностью он виден в url ответа выше. Лишний path_prefix — например /alertmanager, скопированный с сервера за прокси, — даёт адрес, которого у Alertmanager нет (alertmanager).

Prometheus отправляет только алерты в состоянии firing и повторяет отправку, пока алерт горит; когда условие перестало выполняться, отправляет его ещё раз с временем окончания — Alertmanager считает алерт решённым. К меткам алерта Prometheus добавляет external_labels из своего конфига: в конфиге пакета это monitor: 'example', и у каждого алерта есть метка monitor="example".

Алерт в Alertmanager — это метки (по ним алерты различаются, группируются и выбирают маршрут), аннотации (текст: summary, description) и время начала и конца.

Группировка и интервалы

group_by перечисляет метки: алерты с одинаковыми значениями этих меток попадают в одну группу, группа — одно уведомление со списком алертов. На учебной машине три алерта InstanceDown для web01, web02 и web03:

Без group_by все алерты маршрута — одна группа; group_by: ['...'] — каждый алерт отдельно.

Пятьдесят уведомлений на одно событие — почти всегда группировка: в group_by метка, которая у каждого алерта своя (instance, pod, path), или '...'. Повторы того же уведомления каждые несколько минут — слишком короткий repeat_interval.

Маршруты

Маршруты — дерево. Корневой route принимает каждый алерт и обязан иметь receiver. Дочерние маршруты в routes проверяются сверху вниз; алерт уходит в первый, чьи matchers подошли, и спускается дальше, если у того есть свои routes. Не подошёл ни один — уведомление получает получатель родителя. continue: true у маршрута говорит «проверять и следующие»: так одно уведомление уходит нескольким получателям. Дочерний маршрут наследует group_by и интервалы родителя, если не задал свои; заданный group_by заменяет родительский целиком, метки не складываются.

Критичное — и дежурному, и команде:

route:
  receiver: team
  routes:
    - matchers: [severity="critical"]
      receiver: oncall
      continue: true
    - matchers: [team="web"]
      receiver: team-web

Без continue: true критичный алерт команды web ушёл бы только дежурному: проверка остановилась бы на первом подошедшем маршруте.

Условия в matchers — как селекторы promql: severity="critical", team!="db", severity=~"critical|page". Все условия списка должны выполниться. Старые формы match и match_re ещё читаются.

route:
  receiver: chat
  group_by: [alertname]
  routes:
    - matchers:
        - severity="critical"
      receiver: pager

amtool рисует дерево и отвечает, куда уйдёт алерт с заданными метками (флаг --config.file обязателен, см. alertmanager):

$ amtool config routes show \
    --config.file=/etc/prometheus/alertmanager.yml
Routing tree:
.
└── default-route  receiver: chat
    └── {severity="critical"}  receiver: pager

$ amtool config routes test \
    --config.file=/etc/prometheus/alertmanager.yml severity=critical
pager

Тишина и подавление

Тишина (silence) — временный запрет уведомлений для алертов, метки которых подходят под условия. Её ставит человек — amtool silence add или веб-интерфейс — с комментарием и сроком. Алерт под тишиной остаётся в списке со статусом suppressed, уведомлений по нему нет. Тишины хранятся в /var/lib/prometheus/alertmanager и переживают перезапуск.

Подавление (inhibition) — правило в конфиге: пока горит алерт- источник, алерты-цели с теми же значениями меток из equal не рассылаются. Машина недоступна — незачем отдельно сообщать, что на ней кончается диск:

inhibit_rules:
  - source_matchers: [alertname="NodeDown"]
    target_matchers: [severity="warning"]
    equal: [instance]

На учебной машине: тишина на alertname=DiskFull instance=web02 — уведомления о web02 нет, о web04 есть; NodeDown на web03 — DiskFull того же web03 в статусе suppressed.

amtool

amtool — Alertmanager из терминала: смотрит алерты, ставит и снимает тишины, проверяет конфиг и маршруты. Команды alert и silence идут в API Alertmanager. На учебной машине amtool по умолчанию ходит на http://localhost:9093; другой адрес — --alertmanager.url=… или строка в /etc/amtool/config.yml (для всех) либо ~/.config/amtool/config.yml (для себя):

alertmanager.url: http://localhost:9093

Алерты:

$ amtool alert
Alertname  Starts At                Summary     State
DiskFull   2026-10-22 04:44:53 UTC  мало места  active
DiskFull   2026-10-22 04:44:53 UTC              active

Summary — аннотация summary. Заглушённых тишиной и подавленных алертов в выводе amtool alert нет — их показывают -s (--silenced) и -i (--inhibited). amtool alert query instance=web01 отбирает по меткам, -o extended печатает все метки и аннотации, -s показывает заглушённые тишиной, -i — подавленные, -o json — всё в JSON для jq.

Тишины:

$ amtool silence add alertname=DiskFull instance=web01 \
    -d 30m -c 'замена диска'
6c91da38-1b58-4c6f-835e-3b504d18dd7b
$ amtool silence query
ID                                    Matchers                       …
6c91da38-1b58-4c6f-835e-3b504d18dd7b  alertname="DiskFull" instance=…

Вывод silence query здесь обрезан: дальше столбцы Ends At, Created By и Comment. Команда печатает ID новой тишины; снять её — amtool silence expire <ID>, ID всех тишин — amtool silence query -q. -d — срок (30m, 2h), -c — комментарий, без него тишина не ставится.

Пробный алерт без Prometheus — проверить маршрут и получателя:

amtool alert add alertname=Test severity=warning \
  --annotation=summary='проверка доставки'

• prometheus — правила, которые порождают алерты.
• promql — выражения правил и синтаксис условий на метки.
• node-exporter — метрики машины, по которым пишут правила.
• grafana — свои алерты и уведомления в Grafana.
• jq — разобрать amtool alert query -o json и тело вебхука.
• curl — API Alertmanager из терминала.
• systemctl — reload, restart, reset-failed.
• journalctl — журнал службы: ошибки конфига и доставки.