Алерты, которые будят не зря
Алерт, на который никто не реагирует, хуже отсутствия алерта: он приучает игнорировать и настоящие.
Усталость от алертов — главная угроза
Канал, куда сыплется по сто уведомлений в день, никто не читает. Когда придёт настоящее — его пропустят вместе с остальными. Поэтому золотое правило: каждое срабатывание требует действия. Если действие — «посмотрел и закрыл», алерт надо чинить или удалять.
Симптомы, а не причины
Алертить стоит на то, что видит пользователь, а не на внутренние причины:
| Симптом (алертим) | Причина (смотрим при разборе) |
|---|---|
| Доля 5xx выше 1% | Упавший под, полный диск |
| p95 задержки выше 500 мс | Медленный запрос, GC, нагрузка |
| Очередь растёт и не разгребается | Мёртвый воркер |
Причинных состояний тысячи, и большинство не влияет на пользователей: один из трёх подов перезапустился — система работает, будить человека не за чем. Симптомных метрик — единицы, и каждая означает реальную боль.
Две очереди: будить и не будить
- page — деградация для пользователей прямо сейчас: будим дежурного;
- ticket — требует внимания на днях: диск заполнится через неделю, сертификат истекает через 20 дней.
Смешивание очередей и рождает усталость: «диск 80%» в три ночи — верный способ узнать про отключенные уведомления.
Гигиена
- Порог с длительностью:
for: 5mотсекает секундные всплески; - Группировка: упавшая нода = один алерт про ноду, а не пятьдесят про каждый под (Alertmanager группирует);
- Silence на время работ: деплой и учения не должны звонить;
- Runbook в аннотации: ссылка «что делать» экономит дежурному первые — самые дорогие — десять минут.
Проверка качества
Раз в месяц посмотрите последние 20 срабатываний: сколько привело к действию? Меньше половины — алерты дрессируют команду их игнорировать.