Мониторинг и алертинг ломаются не в графиках, а в правилах срабатывания

Мониторинг и алертинг ломаются не в графиках, а в правилах срабатывания

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

Базовый набор для инфраструктуры выглядит скучно, зато работает:
— доступность сервисов и health-check’и;
— задержки, ошибки, насыщение ресурсов;
— очереди, ретраи, таймауты;
— дисковое пространство, память, load average;
— зависимость между сервисами, а не только их локальное состояние.

Ключевая ошибка — алертить по симптомам без контекста. Один высокий CPU ничего не значит, если это краткий пик. Одна ошибка в логах тоже не повод будить дежурного. Полезнее строить правила на комбинации признаков, держать пороги с гистерезисом и разделять severity: info, warning, critical. И да, алерт без runbook — это просто уведомление с плохим характером.

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

Начинайте не с дашбордов, а с вопроса: какое отклонение мы хотим поймать, кто реагирует и что он делает дальше. Без этого алертинг быстро превращается в фоновый шум, а потом продакшен, как обычно, напоминает о себе сам.