Прямой ответ
Полезный дашборд отвечает на вопросы, а не показывает графики: у него есть структура чтения (сверху — «здоров ли сервис» за три секунды, ниже — детализация «что именно»), каждый график имеет смысловую подпись и единицы, а алерты привязаны к симптомам, влияющим на пользователей, а не к каждому чиху CPU. Рабочий минимум на сервис — один «сервисный» дашборд из четырёх зон: RED-панели (rate/errors/duration из метрик приложения), ресурсы (CPU/память/диск/сеть хоста), зависимости (БД, кеш, внешние API), бизнес-метрики (заказы, платежи). Плюс два свойства «взрослости»: переменные (выбор сервиса/окружения без клонирования дашбордов) и аннотации деплоев (всплеск ошибок совпал с релизом — видно сразу, без детективных раскопок).
Структура: три секунды на главный ответ
Верхняя зона — stat/ gauge-панели с главным: доступность (доля 2xx за 5 минут), p95 латентности, текущий RPS, число активных алертов — взгляд дежурного заканчивается здесь. Второй ряд — RED-графики во времени: sum(rate(http_requests_total[5m])) by (status_class), histogram_quantile(0.95, ...) с пороговой линией SLA, error-rate в процентах (не абсолютных числах — 50 ошибок при 10 RPS и при 1000 RPS — разные события). Третья зона — ресурсы хоста/контейнера (CPU с ядрами-ориентиром, память с available, диск с прогнозом заполнения, сеть), четвёртая — зависимости: латентность и ошибки запросов к БД/внешним API, размер пула соединений, hit-rate кеша. Правило порядка: чем выше панель, тем короче путь от неё к решению («сервис нездоров → что: ошибки или латентность → где: путь/зависимость»); дашборд, где всё одного размера вперемешку, не читается в инцидент.
PromQL: четыре запроса, которые надо знать
База, покрывающая большинство панелей: rate — rate(metric_total[5m]) (скорость роста counter'а; окно 4× интервала scrape минимум); доля ошибок — sum(rate(...{status=~"5.."}[5m])) / sum(rate(...[5m])) (ratio, а не два графика рядом — глаз плохо сравнивает масштабы); квантили — histogram_quantile(0.95, sum(rate(..._bucket[5m])) by (le)) (сумма по le обязательна; by (le, path) — квантили по путям); прогноз заполнения диска — predict_linear(node_filesystem_avail_bytes[6h], 24*3600) (линейная экстраполяция — «диск кончится через N часов» вместо паники при 90%). Полезные привычки: avg without (instance) при нескольких инстансах (или by (instance) когда ищем разбалансировку); increase() для «сколько за период» в отчётах; absent() — алерт «метрика пропала» (пропавшая метрика — упавший scrape — событие не менее важное, чем плохие значения).
Переменные, аннотации, организация
Переменные (Dashboard settings → Variables): $service (query-переменная из значений лейбла), $env, $instance — один дашборд на все сервисы/окружения вместо десятка копий (копии расходятся и врут); repeat-панели по переменной — ряд однотипных графиков на каждый инстанс автоматически. Аннотации: источник из CI (событие деплоя с тегом релиза в Prometheus pushgateway/annotations API или Grafana-аннотации из webhook) — вертикальные линии релизов на графиках превращают «ошибки выросли в 14:03» и «деплой в 14:00» в очевидную связь; без аннотаций каждая деградация — расследование «а что менялось?». Организация: дашборды как код (JSON в git, provisioning-каталог Grafana — подход IaC переносится и сюда); папки по командам/сервисам; «дашборд-библиотека» панели-шаблонов для типовых сервисов. Именование панелей — утверждениями («Доля 5xx» с порогом), не «График 3».
Алерты: симптомы, пороги, тишина
Зрелая алертинг-модель: алертим на симптомы (error-rate > 1% пять минут, p95 > SLA десять минут, диск кончится через 6 часов, очередь растёт при живом поступлении) — не на причины (CPU 70% — не инцидент, а факт; CPU-алерты — источник усталости и игнора). Практика порогов: for: 5m (устойчивость к всплескам), warning/critical раздельно (warning — в рабочий чат, critical — будит дежурного: oncall-процесс), алерт «метрика отсутствует» (absent()) — обязательный спутник каждого важного алерта. Борьба с alert fatigue: ревизия раз в квартал (каждый алерт, на который не реагировали, — удаляется или поднимается порог), группировка (Alertmanager group_by — одна страница вместо двадцати при массовом сбое), inhibit-правила (упавший хост глушит алерты его сервисов). Каждый алерт — с runbook-ссылкой в аннотации: «что делать» известно в момент пейджа, а не ищется в вики.
Практический сценарий: дашборд нового сервиса за час
Сервис только что получил метрики; собираем дашборд по шаблону. Клон — базовый «сервисный» дашборд из библиотеки (переменная $service уже есть): RED-ряд подтянулся автоматически по имени метрик (конвенция именования из инструментирования окупается здесь — запросы переносимы). Добавляем специфичное: панель глубины очереди задач с пороговой линией, панель внешнего API (латентность/ошибки по лейблу), бизнес-счётчик заказов. Аннотации — webhook из CI-воркфлоу деплоя (Actions шлёт событие с тегом). Алерты — три штуки на старте: error-rate, p95, «метрика пропала»; всё остальное добавится по инцидентам (каждый постмортем рождает панель или алерт — эволюция, а не проектирование «всего сразу»). Дашборд — JSON в репозиторий, provisioning подхватывает на всех окружениях. Итог: через неделю дашборд открывают ежедневно не потому что «надо», а потому что он отвечает на реальные вопросы команды.
FAQ
Grafana или встроенный UI Prometheus? Prometheus UI — для ad-hoc PromQL и отладки правил; Grafana — для дашбордов, алертинга с маршрутизацией и доступом команды. В проде — оба по ролям.
Как не утонуть в готовых дашбордах (grafana.com)? Готовые дашборды node-exporter/PostgreSQL — отличная база для ресурсного слоя; сервисный слой (RED, бизнес-метрики) — только свой, потому что только вы знаете вопросы своей команды. Импортированный дашборд, который никто не читает, — шум.
Сколько хранить метрики? Локально в Prometheus — недели-месяцы (диск против разрешения); долгосрок — remote-write в VictoriaMetrics/Thanos/Mimir. Практический критерий: сравнивать «месяц к месяцу» нужно — значит нужен долгосрок; иначе локального хранения достаточно.
Нужны ли дашборды в офисе на телевизоре? «Стена графиков» полезна как фоновая осведомлённость (большой красный график заметят все), но принимать решения по телевизору нельзя — для инцидента дашборд открывается на ноутбуке с drill-down. Телевизор — индикатор, не инструмент.
Источники: документация Grafana и PromQL, Grafana alerting — ссылки в шапке.