Как строить дашборды в системе мониторинга: какие графики нужны в первую очередь

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

Первый экран должен показывать масштаб проблемы и направление поиска. Сначала инженер проверяет состояние сервисов, затем сопоставляет ошибки с трафиком, смотрит задержку, оценивает ресурсы и переходит к зависимостям. Детальные показатели по endpoint, pod, дискам и отдельным узлам лучше вынести на связанные диагностические панели.

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

Какие графики нужны на дашборде в первую очередь

Минимальный набор показателей для первого экрана

Базовый дашборд должен содержать ограниченное число панелей. Каждая панель отвечает на конкретный вопрос и подсказывает следующий шаг инженеру.

Для доступности подходят статусы up и down, результат синтетических проверок, состояние health-check и число доступных экземпляров. Для нагрузки используют количество запросов, сообщений, соединений или операций за единицу времени. Ошибки показывают в абсолютных значениях и как долю общего трафика. Задержку лучше разделять по квантилям, а ресурсные панели дополнять очередями, throttling и другими признаками насыщения.

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

Порядок чтения дашборда во время инцидента

1. Подтвердить факт сбоя. Проверить доступность сервиса, health-check и число затронутых экземпляров. Один сбой проверки еще не доказывает массовую проблему.
2. Определить время начала и масштаб. Найти момент первого отклонения и сравнить зоны, кластеры, окружения и экземпляры. Так локальная проблема отделяется от системной.
3. Сопоставить трафик и ошибки. Рост ошибок при обычном трафике указывает на внутреннюю деградацию. Резкое падение трафика с малым числом ошибок может означать недоступность входного слоя.
4. Проверить задержку. Сравнить p50, p95 и p99 с обычным уровнем. Среднее значение может скрыть редкие медленные запросы, которые затрагивают значительную часть пользователей.
5. Перейти к ресурсам и зависимостям. Проверить CPU, память, диски, сеть, очереди, лимиты контейнеров, базу данных и внешние API. После этого инженер выбирает диагностическую панель, логи, трассировку или эскалацию.

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

От задачи к макету: что должен помогать решить дашборд

Перед выбором графиков зафиксируйте четыре параметра: кто читает панель, какой объект наблюдается, какой период нужен для анализа и какое действие следует после отклонения. Назначение полезно сформулировать одним предложением: «быстро определить, затронут ли веб-сервис и на каком уровне искать причину».

Кто будет использовать дашборд

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

Какие решения должен поддерживать каждый блок

Для каждой панели запишите вопрос и действие. Например:

• Статус сервисов: подтвердить или опровергнуть недоступность.
• График ошибок: определить время начала, класс ошибки и затронутую операцию.
• График задержки: проверить деградацию пользовательского пути и выбрать нужный endpoint.
• Таблица экземпляров: найти pod, хост или процесс с отклонением.
• Панель релизов: сопоставить изменение показателей с деплоем или изменением конфигурации.
• Ссылка на диагностику: перейти к логам, трассировке или панели зависимости.

График без интерпретации и следующего шага можно удалить с обзорного экрана. Название панели должно объяснять объект, показатель и период: «p95 времени ответа API, 5 минут» читается быстрее, чем «Latency».

Обзорный дашборд: базовые графики для оценки состояния системы

Обзорный экран показывает состояние системы за короткое время. В большинстве инцидентов достаточно 6-12 панелей, если они согласованы по времени, цветам, единицам и фильтрам. Полную карту метрик лучше хранить на сервисных и инфраструктурных дашбордах.

Доступность и текущее состояние сервисов

В верхней строке разместите текущие статусы критичных сервисов. Подойдут Stat-панели и таблица, где явно видны значения «работает», «ошибка», «нет данных». Для нескольких зон или экземпляров таблица полезнее крупного общего числа: она сразу показывает, где возникло отклонение.

На отдельном временном ряду отобразите успешность проверок за последний час. Синтетический health-check должен проверять пользовательский путь, если локальная проверка процесса не отражает доступность приложения. Например, проверка HTTP-порта может быть успешной при недоступной базе данных, а проверка бизнес-операции покажет реальную деградацию.

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

Трафик и фактическая нагрузка

Трафик показывает объем работы, который система получает. Для веб-сервиса это RPS и число активных соединений, для очереди - число сообщений и скорость поступления, для базы данных - операции чтения и записи, для хранилища - запросы и объем переданных данных.

Сравнивайте текущий поток с обычным диапазоном. Если API обычно получает 1500 RPS, а в момент инцидента поток упал до 40 RPS, небольшое количество ошибок не доказывает исправность сервиса. Если поток вырос в три раза, рост задержки может быть следствием нагрузки, а не нового дефекта.

Разрез по сервису, endpoint, очереди или экземпляру добавляйте тогда, когда он сокращает поиск источника. Десятки линий на одной панели затрудняют чтение. Для обзорного уровня лучше показать общий поток и 3-5 наиболее значимых категорий, а детали оставить для панели сервиса.

Ошибки и доля неуспешных операций

Показывайте число ошибок вместе с их долей от общего количества операций. Базовая формула выглядит так: errors / total requests * 100. Абсолютное число 100 ошибок за минуту имеет разный смысл при 1000 и при 1 000 000 запросов.

Разделяйте HTTP-коды 4xx и 5xx, ошибки бизнес-операций, тайм-ауты, отказы зависимостей и исключения приложения. Клиентские ошибки могут расти из-за неверных запросов пользователей, а 5xx чаще требуют проверки серверной части. Единый показатель «errors» скрывает это различие.

Панель должна показывать базовый трафик рядом с ошибками. Низкое число ошибок при резком падении входящих запросов может маскировать отказ балансировщика, DNS, ingress или API gateway. Для критичного SLI добавьте текущую долю успешных операций и порог, связанный с SLO.

Задержка и распределение времени ответа

Доступный сервис может отвечать слишком медленно. На обзорном экране разместите временной ряд задержки с p50, p95 и p99, если система собирает histogram или summary. p50 показывает типичный запрос, p95 помогает увидеть деградацию у значительной доли пользователей, p99 показывает длинный хвост.

Среднее значение удобно для общего контроля, но его недостаточно для неоднородных запросов. Например, p50 может оставаться около 80 миллисекунд, а p99 вырасти до 2 секунд. Пользовательский эффект уже заметен, хотя средняя задержка выглядит приемлемо.

Для API добавляйте разрезы по endpoint и типу операции. Для фоновых задач показывайте длительность выполнения и возраст самого старого задания. Для базы данных полезны latency запросов, время ожидания блокировок и длительность операций записи.

Насыщение ресурсов и узкие места

Насыщение показывает, какой ресурс ограничивает дальнейшую работу системы. Набор зависит от архитектуры:

• CPU: утилизация, load average, throttling контейнеров и время ожидания CPU.
• Память: занятое пространство, доступная память, swap, OOM-события и давление на память.
• Диски: свободное место, IOPS, throughput, latency и длина очереди операций.
• Сеть: входящий и исходящий трафик, ошибки интерфейсов, retransmit и заполнение каналов.
• Контейнеры: фактическое потребление, requests, limits, рестарты и состояние pod.
• Очереди: длина очереди, скорость поступления, скорость обработки и возраст сообщений.

Высокая загрузка CPU сама по себе не всегда означает сбой. Если очередь не растет, задержка стабильна, а запас пропускной способности достаточен, показатель может отражать штатную нагрузку. Рост очереди, throttling, увеличение latency и ошибки дают более сильное подтверждение насыщения.

Зависимости и внешние компоненты

Для каждой критичной зависимости выведите доступность, ошибки, latency и показатель насыщения. Для базы данных это число соединений, время ожидания пула и задержка запросов. Для очереди - заполнение, скорость обработки и возраст сообщений. Для хранилища - свободное место, latency и состояние операций.

Не добавляйте все известные зависимости подряд. В обзор попадают компоненты, отказ которых действительно влияет на рассматриваемый сервис. Если приложение обращается к пяти внешним API, а критичны только два, остальные лучше оставить на сервисной панели.

Цвет статуса должен иметь единый смысл на всех дашбордах. Зеленый означает норму, желтый - состояние, требующее наблюдения или действия по процессу, красный - нарушение согласованного порога. Серый используйте для отсутствующих данных, а не для нулевой нагрузки.

Дашборды для диагностики: от симптома к причине

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

Панель конкретного сервиса

Сервисная панель собирает показатели одного приложения или функционального блока. В ней нужны:

• входящие запросы и фоновые операции;
• успешные и неуспешные операции по типам;
• p50, p95 и p99 по endpoint или маршрутам;
• число активных экземпляров, рестарты и готовность;
• длина очередей и возраст заданий;
• состояние базы данных, очередей, API и других критичных зависимостей.

Добавьте переменные для окружения, региона, кластера, namespace, pod и экземпляра. Фильтр должен менять все связанные панели одновременно. Если выбранный объект отсутствует, интерфейс должен явно показать «нет данных», а не скрыть проблему пустыми графиками.

Для Nginx полезны RPS, активные соединения, время ответа и ошибки по кодам. Практический пример такой панели и настройки алертов разобран в руководстве по дашборду Nginx в Grafana.

Панель инфраструктурного уровня

Инфраструктурный дашборд помогает двигаться по слоям системы:

• Узлы и виртуальные машины: CPU, память, load average, сеть, файловые системы.
• Контейнеры и Kubernetes: состояние pod, рестарты, requests, limits, throttling, доступные ресурсы и события размещения.
• Сеть: ошибки интерфейсов, потеря пакетов, retransmit, latency и пропускная способность.
• Диски и хранилища: свободное место, I/O latency, очередь операций, ошибки и состояние пула.

Среднее значение по кластеру может скрыть один перегруженный узел. В таблице сортируйте объекты по отклонению: высокий p99, большое число рестартов, заполнение диска или длина очереди должны подниматься вверх. Для кластерных систем полезную схему размещения Prometheus и Grafana с отдельными панелями для HA и Ceph описывает руководство по мониторингу кластеров серверов.

Панель расследования инцидента

Для конкретного инцидента создайте узкое представление с коротким временным окном и выбранным объектом. На нем оставляют только показатели, которые помогают подтвердить или опровергнуть текущую гипотезу.

Минимальный состав:

• время начала отклонения и выбранный интервал до и после события;
• затронутый сервис, endpoint, экземпляр, pod или узел;
• ошибки, трафик и задержка на одной временной шкале;
• релизы, изменения конфигурации и переключения трафика;
• состояние зависимости, которая может объяснить симптом;
• переходы к логам и трассировке.

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

Как группировать графики по сервисам и уровням инфраструктуры

Структура дашбордов должна соответствовать архитектуре и цепочке зависимостей. Названия команд или организационных подразделений не помогают найти место отказа, если инженер мыслит категориями API, контейнера, узла, сети и хранилища.

Группировка по сервисам и пользовательским операциям

Разделяйте frontend, API, фоновые задачи, базы данных, очереди и хранилища. Внутри сервиса используйте одинаковый порядок:

1. входящий трафик и количество операций;
2. успешные и неуспешные результаты;
3. задержка и распределение времени ответа;
4. активные экземпляры и очереди;
5. критичные зависимости.

Пользовательский путь полезнее технического списка метрик. Например, для оформления заказа отдельными категориями могут быть создание заказа, резервирование товара, оплата и отправка уведомления. Если общий RPS стабилен, а ошибки оплаты растут, инженер сразу видит область воздействия.

Не размещайте на одной строке показатели несвязанных сервисов без общей цели. Панель «все API» подходит для сравнения состояния, а панель конкретного заказа должна содержать только компоненты, участвующие в этом потоке.

Группировка по уровням инфраструктуры

Используйте последовательность «сервис - контейнер или процесс - узел - сеть - хранилище». Для каждого слоя зафиксируйте собственные сигналы и связь с верхним уровнем.

Указывайте окружение, регион, кластер, namespace и единицы измерения в названии или легенде. Метрики с одинаковым названием могут описывать разные уровни: CPU процесса, контейнера и узла нельзя сравнивать без явного контекста.

Группировка по типам инцидентов

Диагностические представления удобно строить вокруг повторяющихся сценариев:

• Недоступность: health-check, успешность проб, количество доступных экземпляров, ingress и критичные зависимости.
• Ошибки: коды ответов, исключения, тайм-ауты, ошибки конкретных операций и релизы.
• Задержка: p95, p99, heatmap, длина очереди, время блокировок и задержка зависимостей.
• Нехватка ресурсов: утилизация, лимиты, throttling, очереди, рестарты и число доступных экземпляров.
• Проблемы хранилища: свободное место, latency, IOPS, ошибки операций, состояние пула и дисков.

Один тип инцидента может затрагивать несколько уровней. Рост задержки API проверяют вместе с очередью контейнера, latency базы данных и I/O узла. Такое сопоставление сокращает число ложных гипотез.

Как выбрать тип графика для каждой метрики

Визуализация должна соответствовать вопросу к данным. Временной ряд показывает изменение и взаимосвязь, Stat отражает текущее состояние, таблица сравнивает объекты, а heatmap раскрывает распределение значений.

Временной ряд для динамики и поиска корреляций

Временные ряды используйте для трафика, ошибок, задержки, CPU, памяти, дисков и сети. Они помогают определить момент начала проблемы, ее продолжительность и связь с релизом или изменением нагрузки.

Связанные показатели размещайте с одинаковым временным диапазоном. Например, RPS, долю 5xx и p95 ответа удобно читать рядом. Накладывать десятки линий на одну ось не следует: при необходимости разделите график по сервису или используйте таблицу с выбором объекта.

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

Stat и таблица для текущего состояния

Stat-панель подходит для одного актуального значения: доступность, доля ошибок за 5 минут, SLO, число проблемных объектов или свободное место. Укажите период расчета прямо в названии: «5xx за 5 минут» и «свободное место сейчас» отвечают на разные вопросы.

Таблица удобна для сравнения хостов, pod, экземпляров, endpoint и дисков. Добавьте сортировку по проблемному показателю и ограничьте число строк на обзорном экране. Таблица из 200 объектов полезна для диагностики, но мешает оперативной оценке состояния.

Любое число должно иметь единицу и условие интерпретации. Значение 75 без подписи может означать проценты, секунды, гигабайты или количество объектов.

Гистограмма и heatmap для распределений

Гистограмма показывает, как значения распределены по интервалам. Heatmap помогает увидеть изменение распределения во времени. Эти панели подходят для задержки HTTP-запросов, размера ответов, длительности фоновых задач и времени операций с базой данных.

Средняя задержка 100 миллисекунд может скрывать небольшой сегмент запросов длительностью 5 секунд. На heatmap такой хвост заметен по верхним интервалам. При чтении панели подпишите ось времени, диапазоны значений и единицу измерения, иначе различия между 100 миллисекундами и 100 секундами легко пропустить.

Для histogram-метрик проверьте интервалы bucket. Слишком крупные интервалы скрывают пики, слишком мелкие создают шум и увеличивают объем данных. Набор bucket должен отражать реальные требования SLO, например 100, 300, 500, 1000 и 3000 миллисекунд для пользовательского API.

Когда gauge, pie chart и декоративные элементы мешают

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

Pie chart не подходит для временных рядов и большого количества категорий. Коды ответов проще сравнивать в таблице или на stacked-графике с небольшим числом категорий. Круговую диаграмму можно оставить для компактного состава трафика, если категорий не больше 4-5 и их доли меняются медленно.

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

Пороговые значения, алерты и контекст времени

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

Пороги и базовая линия

SLI измеряет фактическое качество сервиса, например долю успешных запросов или p95 задержки. SLO задает целевое значение. Если SLO доступности равен 99,9% за 30 дней, допустимый бюджет недоступности составляет примерно 43,2 минуты. Алерт должен учитывать этот бюджет и текущую скорость его расходования.

Для задержки порог выбирайте по пользовательскому сценарию. Для ресурсов смотрите на сочетание утилизации и последствий: CPU 80% без очереди может быть нормой, а CPU 60% вместе с растущим throttling и p99 уже требует проверки.

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

Практическая схема выбора порогов, алертов и baseline описана в материале о мониторинге производительности автоматических систем. На дашборде при этом оставляйте только те пороги, которые помогают принять решение во время инцидента.

Временные окна и агрегация

Короткое окно в 15-30 минут подходит для текущего инцидента. Часовой диапазон помогает связать отклонение с релизом, переключением трафика или изменением нагрузки. Просмотр за 24 часа и 7 дней нужен для тренда, повторяющихся пиков и оценки базового уровня.

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

Сглаживание применяйте осторожно. Оно помогает увидеть тренд, но может скрыть кратковременный отказ, всплеск latency или заполнение очереди. Для одной метрики можно показать исходный ряд и отдельную линию среднего, если различие между ними понятно из легенды.

Аннотации релизов и изменений

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

Аннотация должна содержать короткое имя изменения, окружение и идентификатор релиза. Не перегружайте график всеми событиями CI/CD: оставляйте изменения, способные повлиять на выбранный сервис.

Отметка релиза рядом с ростом ошибок формирует гипотезу, но не подтверждает причину. Проверьте версии экземпляров, логи, трассировку и поведение сервиса после отката или исправления.

Практический шаблон дашборда для Grafana и Prometheus

Grafana позволяет собрать обзор из временных рядов, Stat, таблиц и ссылок на связанные панели. Prometheus обычно предоставляет метрики через exporters и instrumentation, поэтому точные имена рядов зависят от приложения, версии exporter и выбранных labels.

Рекомендуемый порядок рядов на обзорном экране

1. Сводный статус: доступность критичных сервисов, область воздействия, число активных алертов.
2. Доступность и ошибки: успешность health-check, доля 5xx, тайм-ауты и ошибки бизнес-операций.
3. Трафик: RPS, соединения, сообщения, операции чтения и записи.
4. Задержка: p50, p95, p99 и распределение для ключевого пользовательского пути.
5. Зависимости: состояние базы данных, очереди, API и хранилища.
6. Насыщение: CPU, память, диски, сеть, лимиты контейнеров и очереди.
7. Проблемные объекты: таблица экземпляров, pod, узлов или дисков с сортировкой по отклонению.

В первой строке не размещайте все возможные ресурсы. Для серверной инфраструктуры достаточно показать проблемные узлы и переход к детальной панели. Для Kubernetes добавьте число готовых pod, рестарты, доступные ресурсы и признаки вытеснения.

Пример временного ряда для скорости запросов может выглядеть так:

sum(rate(http_requests_total[5m]))

Пример расчета p95 для histogram-метрики:

histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

Эти выражения показывают принцип, а не готовую конфигурацию для любого проекта. Проверьте тип метрики, labels и единицы измерения перед публикацией панели.

Переменные и переходы к деталям

Для фильтрации используйте переменные окружения, кластера, namespace, сервиса, хоста и экземпляра. Значения должны быть согласованы с labels в Prometheus. Переменная, которая возвращает пустой результат или смешивает production и staging, снижает доверие к дашборду.

Настройте drill-down с сохранением выбранного времени и объекта. Переход из панели API должен открывать сервисный дашборд с тем же endpoint или экземпляром. Переход из строки хоста должен вести на инфраструктурную панель узла, а не на общий список серверов.

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

Для тестового стенда с Prometheus и Grafana можно использовать облачную инфраструктуру с VDS, базами данных и Kubernetes, например Timeweb Cloud. Среду для проверки следует отделять от production и не подключать к ней реальные секреты.

Единые правила именования и единицы измерения

Зафиксируйте шаблон названия панели: [Сервис] Показатель, разрез, период. Примеры: «API p95 latency по endpoint, 5 минут», «Node свободное место, сейчас», «Queue возраст старого сообщения, 1 минута».

Отделяйте типы значений:

• rate: запросы, события или операции в секунду;
• count: количество объектов, ошибок или сообщений;
• percentage: доля в процентах;
• bytes: объем памяти, диска или трафика;
• duration: миллисекунды или секунды;
• ratio: безразмерное отношение, которое нужно пояснить.

Цвета, названия окружений и формат времени должны совпадать на всех панелях. Для duration не смешивайте секунды и миллисекунды. Для диска явно укажите, показывается свободное или занятое место.

Зафиксируйте источник данных, период расчета, фильтры и условие тревоги в описании панели. Названия метрик и доступные измерения зависят от exporters, instrumentation и архитектуры, поэтому готовый JSON дашборда всегда проверяйте на конкретной системе.

Проверка дашборда на реальном сценарии инцидента

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

Проверка на сценарии «ошибки выросли»

Создайте или выберите инцидент с ростом 5xx, ошибками бизнес-операции или тайм-аутами. Инженер должен увидеть:

• точное время начала роста;
• затронутый сервис и endpoint;
• изменение входящего трафика;
• динамику p95 и p99;
• экземпляры или pod с максимальным числом ошибок;
• состояние базы данных, очереди и других зависимостей;
• переход к логам и трассировке.

Проверьте, что один фильтр не оставляет часть панелей без выбранного объекта. Сравните поведение проблемного и исправного экземпляра. Если после этого причина остается неясной, дашборд выполнил роль навигатора, а расследование продолжится по логам и трассировкам.

Перегрузку метриками, высокую кардинальность, шумные алерты и разрыв между метриками, логами и трассировками разбирает чек-лист типовых ошибок систем мониторинга. Его полезно применять после проверки первого рабочего сценария.

Проверка на сценарии «ресурс исчерпывается»

Для CPU проверьте утилизацию, load average, throttling, очередь задач, latency и ошибки сервиса. Для памяти сопоставьте потребление, лимит, swap, OOM-события и рестарты. Высокое значение ресурса должно иметь видимое последствие или понятный риск.

Для дисков и хранилищ добавьте свободное место, I/O latency, очередь операций, ошибки записи и состояние пула. Для контейнеров сравните фактическое потребление с requests и limits. Для Kubernetes проверьте число готовых pod, рестарты и доступность ресурсов на узлах.

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

Чек-лист готовности дашборда

• Назначение дашборда сформулировано одним предложением.
• Первый экран читается без устного пояснения автора.
• На первом экране видны доступность, трафик, ошибки, задержка и насыщение.
• Критичные зависимости имеют собственные статусы и ключевые показатели.
• Каждая метрика содержит единицу измерения и период расчета.
• Пороги связаны с SLI, SLO, пользовательским эффектом или риском исчерпания ресурса.
• Короткое и длинное временные окна дают разные, но согласованные ответы.
• Панели не дублируют друг друга и не скрывают важные пики.
• Фильтры по окружению, кластеру, сервису и экземпляру работают корректно.
• Переходы ведут к сервисным и инфраструктурным дашбордам с сохранением времени и объекта.
• На графиках видны релизы, конфигурационные изменения и другие значимые события.
• Серый статус обозначает отсутствие данных, а не нормальное нулевое значение.
• Дашборд проверен на росте ошибок, увеличении задержки, нехватке дискового места, отказе зависимости и падении трафика.
• Метрики, логи и трассировки доступны в едином сценарии поиска причины.

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

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