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

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

Практический минимум для узла:
— CPU, load average, steal time
— память: used, cache, swap in/out
— диск: latency, queue depth, свободное место
— сеть: errors, drops, retransmits, RTT
— сервисные метрики: latency, error rate, saturation

Далее важна визуализация. Графики должны отвечать на вопрос «это норма или деградация?», а не просто показывать историю. Рекомендуется строить панели по уровням: общая картина кластера, затем узел, затем конкретный сервис. На одном экране полезно держать корреляции: рост задержки вместе с очередью диска или падение QPS вместе с ростом ошибок.

Отдельно проверьте агрегацию: среднее значение часто скрывает пики. Для эксплуатации лучше работают p95/p99, rate of change и окна по нескольким интервалам. Данные подтверждают следующую корреляцию: если метрика есть, но не связана с алертом или разбором инцидента, она быстро теряет ценность.

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