Grafana: дашборд из запросов

Первый проход занимает минуты. В свежей Grafana добавляется источник данных: Configuration, Data sources, Prometheus, адрес http://prometheus:9090 — в docker-compose контейнеры ходят друг к другу по именам сервисов. Дальше New dashboard, Add visualization, выбор источника — открывается редактор панели: слева типы визуализации, ниже редактор запросов, в который вставляется выражение, отлаженное на 9090. Time series — рабочая лошадка мониторинга: линии по времени; Stat показывает одно текущее число крупно, Gauge добавляет к нему шкалу с порогами, Table удобен для табличных срезов вроде «топ маршрутов». Вверху справа живёт общее время дашборда: относительный диапазон вроде Last 1 hour применяется ко всем панелям сразу, и переключение на Last 24 hours перерисовывает всё окно без правки единого запроса. Там же включается автообновление с интервалами от секунд до минут; ставить его чаще скрейп-интервала бессмысленно — новых точек Prometheus всё равно не отдал, и это прямое следствие pull-модели из первого урока. Для разового вопроса без сохранения есть отдельный режим Explore: тот же редактор запросов без витрины — очередь между «проверил на 9090» и «сделал панель».

Три настройки дают девяносто процентов читаемости панели. Первая — легенда: у каждого ряда есть формат отображения, и шаблон в фигурных скобках подставляет значение лейбла; конструкция {{route}} заменит длинную строку серии на короткое имя маршрута из урока про лейблы. Вторая — единицы измерения: p99 возвращает доли секунды, и с единицей s Grafana сама покажет 340 ms вместо сырого 0.34; для долей есть percent, для памяти — bytes. Третья — пороги с цветом на Stat-панелях: зелёный до двух процентов ошибок, жёлтый до пяти, красный дальше — витрина начинает говорить сама. На этом месте ловится классика: панель p99 без юнита выглядит как подозрительно маленькое число, читатель решает, что это миллисекунды, — и половина команды принимает решения на неверной шкале. Юнит задаётся один раз при создании панели, и это дешевле, чем потом объяснять на планёрке, почему у всех числа разные.

Как только панелей становится больше трёх, появляется желание срезать всё сразу по маршруту или инстансу. Копировать дашборд на каждый вариант не нужно: в настройках создаётся переменная типа Query, источником значений служит запрос label_values(http_requests_total, route) — Grafana спросит у Prometheus все значения лейбла и превратит их в выпадающий список над дашбордом. В запросах панелей подставляется $route, и выбор значения перерисовывает все панели разом. Две детали обязательны. Первая: разрешив выбор нескольких значений, меняйте точное равенство на регулярку route=~"$route" — мультивыбор разворачивается в регулярное выражение с чередованием, и равенство перестаёт находить серии. Вторая: переменная — часть экспортируемого JSON дашборда, поэтому шаблон переживает пересоздание витрины и переезжает между стендами. Переменные превращают дашборд из личного файла в общий инструмент: один экран на команду, а срезы каждый выбирает себе сам.

Обещание из урока про встроенные метрики закрывается четырьмя панелями без единой собственной метрики. Скорость процессора: rate(process_cpu_seconds_total[5m]) — линия в ядрах; упор в лимит контейнера виден как прямая вдоль потолка графика. Резидентная память: process_resident_memory_bytes с единицей bytes — вечный рост при ровной куче повод заглянуть в профили, а не в настройки GC. Дескрипторы: process_open_fds — стабильный уровень норма, вечный подъём означает незакрытые файлы и соединения. Аптайм: time() - process_start_time_seconds — пила перезапусков, на которой плановый деплой отличается от ночных падений с одного взгляда. Типы визуализации расставьте по смыслу: четыре линии — Time series, аптайм — Stat с порогом «меньше часа — красный». Эти панели одинаковы для любого Go-сервиса, поэтому их удобно держать в шаблоне, с которого начинаются новые проекты.

Панель не умеет показывать деталей больше, чем есть в данных: при скрейпе раз в 30 секунд между точками всегда будет полминуты тишины, и ни одна настройка Grafana это не поправит. Второе ограничение — окно запроса: линия с rate по окну 5m на диапазоне сутки рисуется из сотен точек, каждая из которых уже сглажена, и всплеск пятиминутной давности на ней тонет; тот же запрос на диапазоне час показывает пик целиком. Отсюда рабочая пара: обзорная панель с окном час и суточным диапазоном — тренды и сравнение дней, и тревожная с окном 5m и диапазоном час — то, что открывается, когда обзорная кольнула. Диапазон при этом влияет и на стоимость: доля ошибок за месяц с окном в минуту — тяжёлый запрос, который Prometheus честно посчитает, но медленно; правило из двенадцатого урока про четыре скрейп-интервала в окне остаётся неизменным, а ширина окна выбирается под вопрос панели, а не под привычку.