Метрики состояния инфраструктуры: что собирать, чтобы не смотреть в пустой график

Метрики состояния инфраструктуры: что собирать, чтобы не смотреть в пустой график

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

Минимальный набор для узла: CPU, память, диск, сеть, latency прикладного запроса, ошибки, saturation очередей. Для сервисов добавляют p95/p99, rate ошибок, timeouts, retransmits и размер пулов соединений. Анализ показал, что именно корреляция между слоями дает ответ, где начинается проблема.

При визуализации важны не цвета, а контекст:
• baseline для нормального режима;
• пороги предупреждения и отказа;
• агрегация по роли узла, а не только по хосту;
• одинаковые интервалы сбора и одинаковая шкала на сравниваемых графиках.

Частая ошибка — смешивать симптомы и причины на одном экране. График загрузки CPU полезен, но без очередей, I/O wait и latency он не объясняет, почему растет время ответа. Рекомендуется обратить внимание на метрику, которая первой уходит от baseline, а не на ту, которая выглядит наиболее драматично.

Если дашборд не отвечает на вопрос «что сломалось первым», его нужно упрощать. Хорошая визуализация не показывает все, она быстро ведет к узкому месту.