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

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

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

Анализ показал, что визуализация ценна только тогда, когда у каждой метрики есть контекст: базовая линия, пороги и связь с другими слоями. Один рост latency малоинформативен, если не видно, что в тот же момент выросли retransmits, CPU softirq или очередь на апстриме. Поэтому дашборд должен отвечать на три вопроса: где узкое место, как долго оно длится и кого оно затрагивает.

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

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