<b>Мониторинг и алертинг ломаются не в графиках, а в правилах реакции</b>

<b>Мониторинг и алертинг ломаются не в графиках, а в правилах реакции</b>

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

Рабочая схема простая:
— метрики для нагрузки и доступности;
— логи для контекста;
— трассировка для цепочек запросов;
— алерты только на то, что требует действия.
Всё остальное — дашборды. Дашборд не должен будить on-call, как бы ему ни хотелось быть важным.

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

Полезная привычка — регулярно чистить алерты, на которые никто не реагировал, и проверять, что каждый инцидент оставляет после себя новый rule или дашборд. Мониторинг должен быть проактивным, а не реактивным.

—
Рядом по жанру: @smartlink_tactics_arb