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

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

У стабильной системы всегда есть две зоны контроля: метрики, которые смотрят на состояние узлов, и события, которые показывают деградацию цепочки. Если алерт строится только на CPU или памяти, он чаще сообщает о шуме, чем о проблеме. Сигнал нужен там, где сбой уже влияет на SLA: задержка очереди, рост ошибок, провал по таймаутам, расхождение между входящим и обработанным потоком.

Оптимизируем пороговые значения по поведению системы, а не по интуиции. Для этого:
— отделяем краткий пик от устойчивого отклонения;
— ставим окна агрегации, чтобы не ловить дрожание;
— связываем алерт с конкретным действием: рестарт, переключение, ручная проверка;
— убираем дубли, иначе оператор перестаёт видеть важное.

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

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