Как настроить алерты без усталости от уведомлений
Продвинутое3 минРедакция Innovialabs
Коротко
Будите человека только тогда, когда пользователи уже страдают или скоро начнут, и это требует действий; всё остальное отправляйте в тикеты или дашборды, а шумные алерты регулярно чистите.
Главное правило алертинга
Каждый алерт, который приходит дежурному, должен быть срочным, важным и требовать действия от человека. Если на уведомление можно не реагировать, это не алерт, а шум.
Alert fatigue (усталость от алертов) возникает, когда уведомлений так много, что люди перестают их читать. В итоге настоящий инцидент тонет среди ложных срабатываний.
Алерты по симптомам и по причинам
- Симптомы — то, что видит пользователь: растет доля ошибок, страницы грузятся медленно, заказы не проходят.
- Причины — внутренние состояния: высокая загрузка CPU, заканчивается память, перезапустился под.
| По симптомам | По причинам | |
|---|---|---|
| Что показывает | Пользователям плохо | Что-то может пойти не так |
| Ложные срабатывания | Мало | Много |
| Куда отправлять | Дежурному, срочно | В тикет или дашборд |
Будите людей по симптомам. Причинные алерты полезны как контекст для диагностики и как предупреждения, которые можно обработать в рабочее время. Исключение — причины, которые гарантированно приведут к сбою скоро, например диск заполнится за несколько часов.
Хорошая основа для симптомных алертов — ваши SLO и burn rate: алерт срабатывает, когда error budget расходуется слишком быстро.
Уровни критичности
Достаточно трех-четырех уровней с четкими правилами:
- Critical — пользователи затронуты сейчас. Звонок или push дежурному в любое время.
- Warning — скоро станет проблемой. Сообщение в рабочий канал, реакция в рабочие часы.
- Info — для истории и дашбордов. Никаких уведомлений.
Если команда не может объяснить, чем critical отличается от warning, уровни не работают.
Маршрутизация уведомлений
Типичная схема с Prometheus Alertmanager:
route:
receiver: telegram-team
group_by: ['alertname', 'service']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
routes:
- matchers:
- severity="critical"
receiver: oncall-pager
- Telegram или Slack — удобно для warning и общего контекста, но легко пропустить ночью.
- On-call инструменты (PagerDuty, Opsgenie, Grafana OnCall и аналоги) — для critical: расписание дежурств, эскалации, подтверждение получения.
- Каждый алерт должен иметь владельца — команду или сервис.
Дедупликация и группировка
Один сбой базы может породить сотни алертов от разных сервисов. Чтобы этого избежать:
- Группируйте алерты по сервису и типу.
- Используйте inhibition: если упал весь кластер, не нужно получать алерт по каждому поду.
- Добавляйте задержку
for:в правила, чтобы кратковременные всплески не будили людей. - Настраивайте разумный repeat_interval, чтобы не получать одно и то же каждые пять минут.
Регулярный разбор шумных алертов
Алертинг — не разовая настройка. Раз в неделю или раз в спринт смотрите:
- Какие алерты срабатывали чаще всего?
- На какие из них реально реагировали?
- Какие закрывались сами без действий?
Шумный алерт нужно исправить, понизить уровень или удалить. Каждый алерт должен иметь ссылку на runbook — короткую инструкцию, что проверить и что делать.