Сбор метрик начинается не с дашборда, а с ответа на вопрос: какой слой системы мы наблюдаем. Обычно достаточно разделить данные на 4 группы: загрузка ресурсов, сеть, ошибки приложений, доступность сервисов. Если смешать их в один график, сигнал тонет в шуме, а локальный сбой выглядит как общая деградация.
Дальше важна дискретность. Частый сбор нужен для коротких пиков, но для емкости и трендов достаточно более редкого интервала. Анализ показал, что избыточная частота без нормальной агрегации лишь раздувает хранилище и усложняет поиск аномалий. Рекомендуется сразу определить, какие метрики хранятся как сырые, а какие — как усредненные или по квантилям.
Визуализация должна отвечать на три вопроса: где проблема, как давно она началась, затрагивает ли она весь контур или один узел. Для этого полезны:
— график по времени для тренда;
— heatmap для распределения по хостам;
— отдельные панели по CPU, памяти, I/O и ошибкам;
— пороги, которые не маскируют краткие всплески.
Если на дашборде нет корреляции между ростом задержек, ошибками и нагрузкой, метрики собраны формально. Рассмотрим архитектурный срез по данному узлу: сначала базовые ресурсы, затем сетевой слой, потом прикладные показатели. Такой порядок снижает риск ложных выводов и ускоряет разбор инцидента.
Прокси-инфра
@proxy_infra_desk_arb
Метрики инфраструктуры бесполезны, если их собирают без границ и нормальной визуализации
Этот пост опубликован в Telegram-канале Прокси-инфра. Подписаться можно по ссылке: @proxy_infra_desk_arb.