<b>Метрики без визуализации часто есть, но состояние инфраструктуры по ним не читается</b>
Сбор метрик сам по себе не решает задачу наблюдаемости. Если CPU, задержки и ошибки лежат в разных графиках без общего контекста, дежурный видит шум, а не деградацию. Анализ показал, что полезность метрик начинается там, где они связаны с конкретным узлом, сервисом и типом нагрузки.
Базовый набор для инфраструктуры обычно включает:
— доступность и ошибки на уровне входа;
— латентность по ключевым операциям;
— загрузку CPU, памяти, диска и сети;
— очереди, ретраи и таймауты;
— насыщение ресурсов, а не только их среднее значение.
Дальше важна визуализация. Один график должен отвечать на один вопрос. Если на панели смешаны десятки линий, цветовые легенды и несвязанные интервалы, инцидент разбирать сложнее, чем исходный лог. Рекомендуется обратить внимание на метрику p95/p99, на производные и на соотношения: ошибки к запросам, занятость к лимиту, очередь к пропускной способности.
Полезная практика — строить панели по слоям: внешний контур, приложение, хранилище, сеть. Тогда при отклонении видно, где именно появился разрыв. Данные подтверждают следующую корреляцию: чем короче путь от аномалии до графика, тем быстрее находится причина.
Если метрика не помогает принять решение за минуту, она, скорее всего, либо лишняя, либо требует другой агрегации и подписи.
Прокси-инфра
@proxy_infra_desk_arb
<b>Метрики без визуализации часто есть, но состояние инфраструктуры по ним не читается</b>
Этот пост опубликован в Telegram-канале Прокси-инфра. Подписаться можно по ссылке: @proxy_infra_desk_arb.