Алерты: правила и Alertmanager

Зачем алерты

Дашборд из прошлого урока полезен, когда на него смотрят. Но в три ночи на него никто не смотрит, а сервис может лежать. Алерт это автоматическое оповещение: система сама замечает проблему по метрикам и будит дежурного. Без алертов наблюдаемость пассивна, с алертами она реагирует.

Правило алерта

Алерт — условие на метрику, которое держится какое-то время. В Prometheus правила пишут на PromQL из урока про метрики:

- alert: HighErrorRate
  expr: >
    sum(rate(http_requests_total{status=~"5.."}[5m]))
    / sum(rate(http_requests_total[5m])) > 0.05
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Доля 5xx выше 5% пять минут"

expr — условие, for — «держится столько времени». for: 5m важен: он отсекает короткие всплески. Без него алерт сработал бы на секундный скачок и зря разбудил человека. Когда условие держится 5 минут, проблема реальна.

Alertmanager: что делать с алертом

Prometheus решает, что алерт сработал, а Alertmanager решает, что с ним делать: кому отправить, как, когда. Он берёт на себя три вещи.

• Маршрутизация. Разные алерты разным адресатам: критичные в пейджер дежурного, мелкие в чат команды.
• Группировка. Десять подов упали одновременно, и приходит одно сводное оповещение, а не десять.
• Подавление и тишина. На время плановых работ алерты глушат (silence), чтобы не будить зря.

Prometheus (правило сработало) → Alertmanager → Slack / PagerDuty / email

Борьба с шумом

Главный враг алертинга — шум. Если алертов слишком много и часть из них ложные, дежурный перестаёт на них реагировать (alert fatigue), и важный алерт тонет. Поэтому алертов делают мало и по делу:

• алертить на симптомы, а не на каждую причину: «пользователи получают ошибки» важнее, чем «у одного пода высокий CPU»;
• ставить осмысленный for, чтобы не ловить всплески;
• каждый алерт должен быть actionable: пришёл, значит надо что-то сделать. Если на алерт ничего не делают, его убирают.

Хороший набор алертов часто строят вокруг тех же золотых сигналов и SLO из следующего урока.

Что важно запомнить

Алерт превращает метрику в оповещение: правило — PromQL-условие с for, которое отсекает короткие всплески. Это переводит наблюдаемость из пассивной в реагирующую.

Alertmanager решает судьбу сработавшего алерта: маршрутизация по адресатам, группировка похожих, тишина на время работ.

Алертов держат мало и по делу: на симптомы, с осмысленным for, каждый actionable. Иначе шум приводит к усталости и пропуску важного.

В следующем уроке разберём SLI, SLO и error budget: как измерять надёжность.