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

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

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

Базовый набор:
— health-check на сервисы и зависимости
— метрики ресурсов: CPU, RAM, диск, сеть
— latency, error rate, saturation
— логи с корреляцией по request_id
— алерты на отсутствие данных, а не только на плохие значения

Главная ошибка — слать уведомления на всё подряд. Шум быстро убивает доверие к системе: инженеры начинают игнорировать алерты, а потом внезапно «красный» становится фоном. Нормальный алертинг — это пороги, дедупликация, группировка и понятный runbook рядом с уведомлением.

Отдельно проверьте, кто получает сигнал и что он должен сделать. Если у алерта нет владельца, SLA реакции и сценария эскалации, он полезен только в отчёте для совещания. Код работает, но есть нюансы.

Мониторинг должен быть проактивным, а не реактивным: сначала ловим деградацию, потом ищем причину, а не наоборот.