Дашборд, который читают: правила хорошей панели

MAATRIX

Открываете Grafana — и видите тридцать графиков одинакового размера, среди которых нужно на глаз выцепить тот, где что-то пошло не так. Через пару недель команда перестаёт туда заходить вообще и узнаёт об инцидентах из тикетов пользователей. Дашборд технически работает — метрики собираются, панели рисуются, — но он никому не помогает быстро ответить на вопрос «всё ли в порядке». Ниже — конкретные правила, по которым можно отличить панель, которую реально читают, от панели, которая просто существует.

Симптом: дашборд есть, но им не пользуются

Первый признак плохого дашборда — не отсутствие данных, а отсутствие привычки на него смотреть. Обычно это выглядит так: во время инцидента дежурный инженер идёт не в Grafana, а сразу в логи или в top/htop на сервере, потому что там быстрее найти причину, чем на панели с двадцатью пятью одинаковыми по важности графиками. Дашборд превращается в артефакт, который показывают на демо «смотрите, у нас есть мониторинг», но который не участвует в реальной работе.

Причина почти всегда одна: дашборд спроектирован от метрик, а не от вопросов. Кто-то подключил экспортёр, увидел список из полусотни доступных метрик и вывел их все на панель, потому что «раз метрика есть — почему бы не показать». В результате важные и второстепенные показатели визуально равны: график свободной памяти на диске занимает столько же места и привлекает столько же внимания, как график количества ошибок 5xx на продакшене. Мозг не может за три секунды понять, куда смотреть — приходится сканировать всё подряд.

Полезный тест: покажите свою главную панель человеку, который видит её впервые, дайте три секунды и спросите — «всё в порядке или нет?». Если он не может ответить уверенно — панель не выполняет свою основную функцию, независимо от того, сколько на ней полезных данных технически присутствует.

Иерархия важности: что на первом экране, а что — по клику

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

Практическая реализация в Grafana — верхний ряд из 3-5 крупных stat-панелей или gauge-панелей с самыми важными агрегированными показателями:

• общий процент успешных запросов (или error rate) по всем сервисам;
• p95/p99 задержки на ключевом эндпоинте;
• количество активных алертов/инцидентов;
• доступность (uptime) за последние 24 часа;
• загрузка самого нагруженного узла кластера.

Всё, что нужно для расследования конкретной проблемы — разбивка по хостам, графики CPU/memory/disk по каждой ноде, детальные тайм-серии по отдельным эндпоинтам — уезжает ниже, в свёрнутые по умолчанию row-панели (Repeat row + collapsed: true в JSON модели дашборда) или на отдельные дашборды, куда переходят по ссылке из верхнего ряда. Это не значит, что детальные данные не нужны — они критичны для расследования. Но расследование начинается ПОСЛЕ того, как верхний уровень сказал «что-то не так», а не до этого.

Хороший ориентир — принцип «сначала сигнал, потом причина»: верхний экран отвечает на вопрос «есть проблема?», второй уровень — «где именно?», третий — «почему?». Смешивать все три уровня на одном экране без визуальной иерархии — типичная причина того, почему дашборд не читают.

Контекст: зелёный/жёлтый/красный вместо голого числа

Число «47» само по себе ничего не говорит. Это 47 мс задержки (отлично) или 47% error rate (катастрофа) — зависит от метрики, но даже зная метрику, дежурный инженер в 3 часа ночи не должен вспоминать, какое значение считается нормальным для конкретно этого сервиса. Эту работу должна делать сама панель.

В Grafana это решается через Thresholds в настройках панели: задаёте границы (например, base: green, 80: yellow, 95: red для загрузки диска в процентах) — и число само меняет цвет фона или заливку gauge-индикатора в зависимости от того, в какую зону оно попало. Дежурному не нужно ничего вспоминать — красный цвет уже говорит «сюда смотреть в первую очередь».

Пример настройки thresholds для панели с загрузкой CPU:

"fieldConfig": {
  "defaults": {
    "thresholds": {
      "mode": "absolute",
      "steps": [
        { "color": "green", "value": null },
        { "color": "yellow", "value": 70 },
        { "color": "red", "value": 90 }
      ]
    },
    "unit": "percent"
  }
}

Те же пороги стоит продублировать в правилах алертинга (Grafana Alerting или Prometheus Alertmanager) — тогда цвет на панели и повод получить уведомление в Telegram совпадают, а не живут отдельной жизнью. О том, как подобрать пороги так, чтобы алерты не сыпались по пустякам, у нас есть отдельный разбор — алерты, которые не бесят: как выставить пороги.

Контекст можно давать не только цветом. Полезные приёмы:

• показывать рядом с текущим значением динамику за предыдущий период (+12% к вчера);
• рисовать на графике горизонтальную линию нормального диапазона или SLA-порога (annotation в Grafana);
• использовать sparkline внутри stat-панели, чтобы видеть тренд, а не только точку.

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

Согласованность визуального языка между панелями

Четвёртое правило — одинаковые вещи должны выглядеть одинаково на разных панелях. Если на Overview-дашборде красный означает «критично», а на дашборде capacity planning тот же красный цвет используется просто для одной из линий графика без отношения к серьёзности — при переключении между панелями мозг тратит время на то, чтобы заново понять, что означает цвет именно здесь. Это лишняя когнитивная нагрузка, которую легко убрать один раз на уровне соглашений команды.

Что стоит зафиксировать письменно (даже в одном абзаце в README репозитория с дашбордами) и соблюдать во всех панелях:

• Цветовая семантика. Красный — всегда критично/недоступно, жёлтый — всегда предупреждение/деградация, зелёный — всегда норма. Не использовать красный для «просто заметного» значения на одной панели, если на соседней он означает «всё сломано».
• Масштаб времени по умолчанию. Если Overview открывается с диапазоном «последние 6 часов», а соседний дашборд — с «последние 30 дней», сравнение состояний превращается в лишнюю работу. В Grafana это настраивается через time_options и refresh в JSON модели дашборда или через сохранённый дефолт при экспорте.
• Единицы измерения и округление. Если один дашборд показывает память в мегабайтах, а другой — в процентах от общего объёма, приходится пересчитывать в уме на ходу.
• Расположение общих элементов. Строка с фильтрами по хосту/сервису (template variables в Grafana) — всегда сверху, в одном и том же порядке полей.

Согласованность особенно важна, если в компании несколько инструментов одновременно — например, Zabbix для инфраструктуры и Grafana с Prometheus для приложений. В таком случае стоит явно решить, какой цвет что означает в обеих системах, а не полагаться на дефолты каждого инструмента. Если ещё выбираете стек для сбора метрик — сравнение подходов есть в статье про установку Grafana и Prometheus на Ubuntu 24.04.

Плохой пример: стена из тридцати одинаковых графиков

Возьмём типичный дашборд, который наследуется от старого Zabbix- или Cacti-подхода «выведи все доступные метрики» и просто переносится в Grafana почти без изменений. Структура такого дашборда обычно выглядит так: 4 колонки по 6-8 рядов, в каждой ячейке — таймсерия одинакового небольшого размера (примерно 300×200 пикселей), подписи мелким шрифтом, без единого цветового индикатора состояния — просто линии графиков разного цвета по умолчанию (Grafana раскрашивает серии автоматически, эти цвета не несут смысла «хорошо/плохо»).

Что здесь не так:

1. Нет иерархии — CPU, память, диск, сеть, количество открытых файловых дескрипторов, температура процессора выведены одним весом. Чтобы понять «всё ли в порядке», нужно визуально пробежаться по всем тридцати графикам — на это уходит время, которого нет во время инцидента.
2. Нет контекста — линия графика показывает форму (растёт/падает), но не говорит, где граница нормы. Нужно помнить наизусть, что «диск в 85% - это ещё терпимо, а 95% — уже пора действовать», для каждой из тридцати метрик отдельно.
3. Всё на одном экране — совмещены вопросы «есть ли инцидент сейчас» (нужно для дежурного) и «сколько ресурсов понадобится через полгода» (нужно для капасити-планирования раз в квартал). Эти два вопроса требуют разных дашбордов и разной частоты просмотра.
4. Нет согласованности — половина графиков в процентах, половина — в абсолютных числах (МБ, штуки), масштаб времени у части панелей переопределён вручную и отличается от дефолта дашборда.

Как эта же панель могла бы выглядеть при переработке под три описанных выше правила:

• Верхний ряд (крупно, всегда видно): 4 stat-панели с цветовыми порогами — «Error rate по всем сервисам», «p95 latency», «Активные алерты», «Доступность за 24ч».
• Второй ряд (видно сразу, но компактнее): таблица «сервис → статус» с цветовой заливкой ячеек (зелёный/жёлтый/красный) по каждому из 5-10 сервисов — одна строка на сервис, без графиков.
• Свёрнутые row-панели ниже: по одной на каждый сервис, раскрываются по клику, содержат детальные графики CPU/memory/disk/network именно для этого сервиса — но только когда таблица выше показала, что там жёлтый или красный статус.
• Capacity planning — отдельный дашборд, не смешанный с оперативным.

Итоговое число панелей на первом экране падает с тридцати до пяти-шести, но полезность для дежурного инженера растёт, потому что вопрос «где смотреть» решается за секунду, а не за минуту сканирования.

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

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

Практически это можно делать так:

• на ретро после инцидента спрашивать: «какую метрику вы искали в первую очередь, и была ли она на дашборде видна сразу или пришлось её искать?»;
• раз в квартал проводить короткий опрос дежурных: «какие три вопроса вы задаёте дашборду чаще всего?» — и сверять список с тем, что реально вынесено на верхний уровень;
• удалять графики, которые никто не может вспомнить, когда в последний раз смотрел — если метрика висит на панели полгода и ни разу не помогла в расследовании, она, вероятно, занимает чужое место;
• при добавлении новой метрики сразу спрашивать «на какой вопрос она отвечает и кто на неё смотрит» — если ответа нет, метрика уезжает в детальный дашборд, а не на Overview.

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

Частые вопросы