Философия панели: одна панель — один вопрос¶

Прежде чем погружаться в кнопки, метрики и трансформации, давайте остановимся и зададим себе один принципиальный вопрос: зачем мы создаём панель?

Ответ прост: чтобы получить ответ на вопрос.

Аналогия с термометром¶

Представьте термометр за окном. Вы смотрите на него и мгновенно получаете ответ: «на улице +22». Это отличная панель: один показатель, одна задача, чёткий ответ. А теперь представьте, что на том же термометре есть шкала влажности, атмосферного давления и скорости ветра. И ещё отдельная шкала «вероятности дождя». И ещё график температуры за последний месяц. Всё это на одном циферблате. Вопрос: с какой вероятностью вы мгновенно ответите на вопрос «какая сейчас влажность»?

Примерно с такой же. Перегруженная панель не отвечает ни на один вопрос. Она — мазня из цифр и линий, и пользователь вынужден расшифровывать её каждый раз заново. Именно поэтому правило звучит так: одна панель — один вопрос.

Как формулировать вопрос¶

Хороший вопрос для панели формулируется в одном из форматов:

Тип вопроса	Пример	Тип панели
Каково значение сейчас?	«Какая температура CPU на сервере db01?»	Stat, Gauge
Как значение менялось за период?	«Как менялась температура CPU за последние 24 часа?»	Time series
Каков топ-N по показателю?	«Какие запросы медленнее всех за последний час?»	Table, Bar chart
Каково распределение?	«Сколько запросов выполняется до 10 мс, до 100 мс, до 1 секунды, дольше?»	Histogram, Heatmap
Каково состояние в конкретный момент времени?	«Какие серверы были в состоянии CRITICAL 15 августа в 03:14?»	State timeline
Где находится проблема?	«На каких континентах больше всего ошибок?»	Geomap
Какие события произошли?	«Какие ошибки логировались в момент падения сервера?»	Logs

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

Почему не надо делать одну гигантскую панель¶

Частая ошибка новичков: запихнуть все метрики в одну огромную Time series панель. Вот так, например:

rate(http_requests_total{...}[5m]),
rate(grpc_requests_total{...}[5m]),
node_cpu_seconds_total{...},
container_memory_usage_bytes{...},
go_goroutines{...},
postgresql_rows_inserted_total{...}

Всё на одном графике. 6 легенд, каждая со своим масштабом. У одного запроса значения в диапазоне 0–100, у другого — 10 000–50 000. Оба «ужимаются» в один Y-axis, и в итоге визуально всё выглядит как пучок плоских линий. Информативность — ноль.

Лучше: одна панель для HTTP requests, одна для gRPC, одна для PostgreSQL inserts. Три панели. Каждая — с одним вопросом и читаемым масштабом.

Технических затрат на разделение практически нет: на бэкенде всё равно выполняется N запросов, а не один, даже если они в одной панели. Так почему бы не сделать это читаемо?

Принципы хорошей панели¶

Читатель понимает суть за 3 секунды, даже если видит дашборд впервые. Взглянул — и уже понял, про что панель.
Заголовок панели — часть ответа. Не «Метрика node_cpu», а «Нагрузка CPU — средняя по всем серверам». Заголовок направляет читателя.
Единицы измерения видны. Не заставляйте читателя гадать, в чём измеряется значение: процентах, миллисекундах, запросах в секунду. Настройте Field Configuration (гл. 4 этой части).
Цвета несут смысл. Красный — плохо, зелёный — хорошо. Без пояснений. Если метрика то зелёная, то фиолетовая просто так — это визуальный шум, а не информация.

Когда нарушать правило¶

Есть исключение: связанные метрики, которые всегда смотрят вместе. Например:

rate(http_requests_total{status="2xx"}[5m]) и rate(http_requests_total{status="5xx"}[5m]). Если вы хотите показать долю ошибок, то естественно показать оба ряда на одном графике — зелёные успешные и красные ошибочные запросы под ними.
node_network_receive_bytes_total и node_network_transmit_bytes_total — входящий и исходящий трафик. Часто смотрят вместе: один над осью X, другой под осью (как в классическом сетевом мониторинге).

Правило: две метрики на одной панели допустимы, если у них одинаковый масштаб и они логически связаны (два аспекта одного явления). Три — допустимы в исключительных случаях. Четыре и более — почти всегда ошибка.

Далее: Интерфейс редактирования