Алертинг без усталости за 8 минут

Алерт это просьба к человеку срочно что-то сделать. Если алерт не требует действия, это не алерт, а шум. Шум приводит к усталости: дежурный привыкает, что «оно само пройдёт», и пропускает настоящий пожар.

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

groups:
  - name: api
    rules:
      - alert: ApiHighErrorRate
        expr: |
          sum(rate(http_requests_total{job="api",status=~"5.."}[5m]))
            / sum(rate(http_requests_total{job="api"}[5m])) > 0.05
        for: 10m
        labels:
          severity: page
        annotations:
          summary: "API отдаёт больше 5% ошибок"
          description: "Доля 5xx {{ $value | humanizePercentage }} последние 10 минут"
          runbook_url: "https://wiki.example.ru/runbooks/api-errors"

• expr: условие. Пока оно истинно, алерт в состоянии pending.
• for: сколько условие должно держаться, чтобы алерт стал firing. Защищает от разовых всплесков, но задерживает обнаружение.
• keep_firing_for: держать алерт активным ещё какое-то время после исчезновения условия, чтобы он не мигал.
• labels.severity: куда и как срочно отправлять.
• annotations: что случилось и что делать, обязательно ссылка на раннбук.

Alertmanager

Prometheus только вычисляет правила и отправляет алерты. Что с ними делать, решает Alertmanager:

• Маршрутизация: дерево route по меткам: severity="page" в систему дежурств и звонок, severity="ticket" в трекер, команда billing в свой канал.
• Группировка (group_by: [alertname, service]): 50 упавших подов дают одно уведомление, а не 50. group_wait (по умолчанию 30 с) ждёт, пока соберётся группа, group_interval (5 мин) задаёт паузу перед сообщением об изменениях в группе, repeat_interval (4 ч) повторяет напоминание о неразрешённом.
• Подавление (inhibit_rules): если горит «дата-центр недоступен», не слать сотню алертов о сервисах в нём.
• Тишина (silences): временно заглушить алерты на время плановых работ.
• HA: несколько экземпляров Alertmanager обмениваются состоянием и не дублируют уведомления.

Симптомы, а не причины

Будите людей по симптомам, которые чувствует пользователь: доля ошибок, задержка, недоступность снаружи, нарушение SLO. Причины (CPU 90%, мало свободной памяти, перезапуск одного пода) показывайте на дашбордах или как тикеты в рабочее время. CPU 95% при нормальных ошибках и задержке не повод звонить ночью. А ошибки 30% при CPU 20% это пожар, который алерт по причинам пропустит.

Исключения: причины, которые точно скоро станут симптомом и требуют действия заранее. Например, диск кончится через 4 часа или сертификат истекает через 14 дней.

Уровни

• Page: срочно, днём и ночью. Только то, что требует действия человека прямо сейчас.
• Ticket: нужно сделать в рабочее время.
• Info: на дашборд, никого не уведомлять.

Алерты по SLO и burn rate

Простой порог «ошибок больше 1%» либо шумит, либо опаздывает. Подход из SRE workbook: алертить по скорости расходования бюджета ошибок (burn rate). Burn rate 1 значит, что бюджет кончится ровно к концу окна SLO; burn rate 10 в десять раз быстрее.

Рекомендуемая схема для SLO на 30 дней (multiwindow, multi-burn-rate):

Тяжесть	Длинное окно	Короткое окно	Burn rate	Сколько бюджета сгорит
page	1 час	5 минут	14.4	2%
page	6 часов	30 минут	6	5%
ticket	3 дня	6 часов	1	10%

Длинное окно даёт значимость, короткое быстро гасит алерт, когда проблема ушла. Для SLO 99.9% burn rate 14.4 означает долю ошибок 14.4 × 0.1% = 1.44%.

(
  sum(rate(http_requests_total{job="api",status=~"5.."}[1h])) / sum(rate(http_requests_total{job="api"}[1h])) > (14.4 * 0.001)
and
  sum(rate(http_requests_total{job="api",status=~"5.."}[5m])) / sum(rate(http_requests_total{job="api"}[5m])) > (14.4 * 0.001)
)

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

• Раз в неделю или на передаче смены разбирать: какие алерты сработали, на какие было действие, какие повторяются.
• Каждый неактивируемый алерт удалить, превратить в тикет или поднять порог.
• Мигающие алерты лечить for, keep_firing_for и окнами, а не тишиной на месяц.
• Ориентир из книги Google SRE: не больше двух инцидентов за 12-часовую смену, иначе дежурный не успевает разбираться качественно.
• У каждого алерта владелец, раннбук и понятный текст: что сломалось, где, насколько плохо.

Не забыть

• Мониторинг мониторинга: алерт, если Prometheus или Alertmanager недоступны (watchdog: всегда горящий алерт, отсутствие которого означает поломку цепочки).
• Алерт на пропажу данных (absent), иначе сервис может «исчезнуть» молча.
• Тестирование правил: promtool test rules в CI.

Частые ошибки

• Алерт на CPU 80% ночью.
• Нет for: алерт мигает от каждого всплеска.
• Сотни алертов без группировки при падении одного кластера.
• Алерт без раннбука и без понятного текста.
• Тишина на месяц вместо исправления правила.

Что спросят на собесе

• Чем алерт по симптомам лучше алерта по причинам.
• Зачем for в правиле и чем он вреден.
• Группировка, подавление и тишина в Alertmanager.
• Что такое burn rate и multiwindow-алерты.
• Как вы боролись с усталостью от алертов.