Метрики инфраструктуры бесполезны, если их нельзя связать с отказом за 5 минут

Метрики инфраструктуры бесполезны, если их нельзя связать с отказом за 5 минут

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

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

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

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

Практика простая: сначала определите, какие отклонения вы хотите ловить, затем стройте графики и алерты под эти отклонения, а не наоборот.