Мониторинг без шума: как не утонуть в алертах и не пропустить падение

Стабильность инфраструктуры ломается не в момент инцидента, а когда алерты перестают отличаться от фона. Если сигналов слишком много, их перестают читать; если слишком мало, инцидент замечают по жалобам. Поэтому базовая задача — не «собирать всё», а отбирать события, которые действительно меняют состояние системы.

Рабочая схема обычно выглядит так:
— метрики на уровне сервиса: ошибки, latency, timeout, saturation;
— системные метрики: CPU, RAM, диск, сеть, очередь;
— бизнес-сигналы: провал авторизации, резкое падение транзакций, аномалии в конверсии;
— логи и трассировка — не как паника, а как второй слой диагностики.

Оптимизируем пороговые значения. Статичный threshold без контекста почти всегда даёт мусор: ночной трафик, batch-процессы и краткие пики будут срабатывать как авария. Лучше строить алерты на отклонении от нормы, на длительности аномалии и на подтверждении через несколько независимых сигналов. Один сработавший датчик — это гипотеза, три — уже повод открывать инцидент.

Отдельно стоит разделять уровни реакции: warning для деградации, critical для остановки, informational для трендов. Если в одном канале смешаны «упал сервис» и «подрос latency», операторы быстро привыкают игнорировать всё. Развертывание прошло в штатном режиме только тогда, когда после него не прибавилось ложных срабатываний.

Вывод простой: хороший алертинг не шумит, а экономит внимание. Настраивайте его так, будто читать его будет человек в перегруженную смену — и только тогда система начнёт работать как инструмент, а не как генератор тревог.