Метрики инфраструктуры полезны только тогда, когда по ним видно отклонение, а не просто график

Метрики инфраструктуры полезны только тогда, когда по ним видно отклонение, а не просто график

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

Для базового слоя обычно хватает: • загрузка CPU и steal time • память с учетом cache и swap • диски: latency, IOPS, queue depth • сеть: ошибки, retransmits, drops • сервисные метрики: RPS, p95/p99, коды ошибок. Если метрика не помогает локализовать причину, она не должна попадать на главный дашборд.

Визуализация должна отвечать на три вопроса: где узкое место, как быстро оно растет, есть ли корреляция между слоями. Полезно строить не только линии, но и связки: CPU против latency, очередь диска против времени ответа, ошибки сети против таймаута в приложении. Рекомендуется обратить внимание на метрику, которая меняется первой, а не громче всех.

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

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