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

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

Сбор метрик без модели системы обычно превращается в шум. Сначала фиксируют, какие слои надо наблюдать: хост, сеть, диск, сервис, очередь, внешний зависимый контур. Для каждого слоя нужен свой набор сигналов: загрузка CPU, память, latency, error rate, saturation, доступность.

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

Если этого нет, график красивый, но расследовать по нему нечего. Анализ показал, что на практике чаще всего ломается не сбор, а семантика: разные команды по-разному считают одно и то же событие, а потом сравнивают несопоставимые ряды 📈

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

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

Хорошая панель не заменяет наблюдаемость, но быстро показывает, где искать причину. Если метрика не помогает сократить путь до RCA, ее место не в дашборде, а в архиве.