Мониторинг ломается не из-за графиков, а из-за плохих сигналов и лишнего шума

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

Базовый набор алертов: • доступность сервиса • рост latency • ошибки на уровне приложения и сети • заполнение диска, памяти, inode • отказ резервного копирования. Для каждого сигнала нужен порог, окно оценки и понятный маршрут эскалации. Иначе получаем классический продакшен: шум есть, реакции нет.

Не алертите на каждый всплеск. Грубые пороги без сглаживания дают лавину ложных срабатываний, а слишком длинные окна скрывают реальные проблемы. Разделяйте alerting и dashboarding: первое — для реакции, второе — для анализа. Мониторинг должен быть проактивным, а не реактивным.

Проверяйте алерты как код: версия в репозитории, ревью правил, тестовые срабатывания, понятные названия и owner для каждого сигнала. Без этого через пару месяцев система превращается в музей старых тревог, где никто уже не знает, зачем пищит половина датчиков. Дальше всё просто: меньше шума, больше сигналов, на которые действительно можно опереться.