Мониторинг и алертинг: как не утонуть в шуме и не пропустить реальную аварию

Мониторинг и алертинг: как не утонуть в шуме и не пропустить реальную аварию

Мониторинг полезен только тогда, когда отвечает на два вопроса: что сломалось и почему это важно. Если алерт не ведет к действию, это не сигнал, а фон. Код работает, но есть нюансы: метрики, логи и трассировки должны быть связаны, иначе расследование превращается в ручной квест.

Базовый набор правил простой:
— алертим на симптомы для пользователя, а не на внутреннюю «красоту» системы;
— разделяем warning и critical, не смешиваем все в один канал;
— у каждого алерта есть владелец, порог и ожидаемое действие;
— если событие повторяется и ничего не меняется, это не инцидент, это шум.

Хорошая практика — строить алерты от SLO и деградации сервиса: рост ошибок, задержки, недоступность зависимых компонентов. Отдельно проверяйте «тихие» отказы: очередь стоит, бэкапы не идут, диск почти заполнен, но сервис еще отвечает. Именно такие вещи потом и всплывают в самый неудобный момент.

Еще одна типовая ошибка — алертить по каждой метрике без контекста. Мониторинг должен быть проактивным, а не реактивным. Если инженер первым делом открывает графики, а не понимает причину из уведомления, система алертинга требует пересборки.

Сначала определите, какой инцидент вы хотите поймать, и только потом настраивайте пороги, маршрутизацию и эскалацию.