Grafana 7.2: library panels и трансформации без ETL

Grafana 7.2 вышла в середине сентября без особого шума, но с несколькими изменениями, которые давно ждали. Главное - library panels: механизм переиспользования панелей между дашбордами без копипасты. Мы сразу посмотрели на это в контексте нашей мониторинговой инфраструктуры, где одни и те же панели CPU, RAM и network throughput живут на десятке дашбордов в слегка различающихся вариациях. Картина была не очень.

Проблема, которую решают library panels

До 7.2 типичная ситуация выглядела так: есть панель CPU usage с настроенными thresholds, легендой, правильными единицами измерения и выверенным запросом. Чтобы добавить её на новый дашборд, делается JSON copy-paste через Export/Import или вручную через edit-mode. Через месяц кто-то правит threshold на одном дашборде, забывает обновить остальные, и начинается расхождение. У нас на одном из клиентских проектов было двенадцать дашбордов с панелью CPU usage в восьми вариациях - часть из них уже не соответствовала актуальному запросу к Prometheus, просто потому что синхронизировать руками никто не следил.

Library panels решают это прямолинейно: создаёшь панель один раз, сохраняешь как library panel, используешь ссылку на неё в любом количестве дашбордов. Изменение в одном месте - обновляется везде.

Создание через UI: открываешь нужную панель, в контекстном меню появился пункт «More... -> Create library panel». Задаёшь имя и папку. После этого панель доступна для добавления через «Add panel -> Add a panel from the panel library». В JSON дашборда она выглядит как "libraryPanel": {"uid": "...", "name": "..."} вместо встроенного определения.

На практике мы за день привели двенадцать дашбордов к одной library panel для CPU usage. Правка query - один раз, threshold - один раз. Расхождения ушли. Единственное что нужно держать в голове: если кто-то на конкретном дашборде хочет переопределить порог для специфического сервиса - library panel не позволяет переопределять отдельные поля без unlink. Unlink делает копию обратно в дашборд. Это осознанное архитектурное решение, но в первый момент немного удивляет.

Трансформации: джойн нескольких datasource без ETL

Второе изменение - переработанный transformations engine. В 7.0 он появился как preview, в 7.2 стал значительно шире по возможностям и стабильнее в поведении.

Конкретный кейс, который нас заинтересовал: панель, которая показывает метрику latency из Prometheus и рядом - бизнес-метрику из PostgreSQL (количество заказов в очереди). Раньше это решалось одним из двух способов:

Первый - писать exporter, который тащит данные из PostgreSQL в Prometheus. Работает, но это ETL-пайплайн ради одной панели мониторинга.

Второй - делать два отдельных панели рядом и надеяться что пользователь сам сопоставит временные ряды глазами.

Теперь трансформация Join by field (time) в Grafana позволяет объединить два datasource прямо в панели:

• добавляешь два query: один к Prometheus, второй к PostgreSQL через grafana-postgresql-datasource
• в блоке Transformations добавляешь Join by field с полем Time
• на выходе одна таблица с обоими временными рядами, которую можно отобразить в Time series с двумя осями

Это не замена нормальному ETL для сложной аналитики - запросы выполняются в реальном времени, join происходит на стороне браузера, масштабировать это на миллионы точек не получится. Но для операционного дашборда, где нужно видеть «а не упала ли у нас пропускная способность очереди как раз когда latency выросла» - вполне достаточно. Мы убрали один промежуточный exporter, который писали именно для этого сценария.

Аннотации: фильтрация по дашборду

Третья фича - менее впечатляющая, но практически полезная. В 7.2 улучшили управление аннотациями: теперь аннотации можно фильтровать по тегам не только глобально, но и в контексте конкретного дашборда.

У нас аннотации используются для маркировки деплоев: CI пишет в Grafana через API при каждом деплое в production. Раньше на дашбордах лезли аннотации всех проектов сразу, что при активном деплое превращалось в лес вертикальных линий. Теперь можно настроить фильтрацию по тегу project:myapp на конкретном дашборде - и видишь только свои деплои. Звучит как мелочь, но когда мониторишь десяток проектов с одного места - ощутимо.

Что пока не идеально

Library panels в 7.2 не поддерживают версионирование. Если обновить library panel и что-то сломалось - rollback только через ручное редактирование или восстановление из snapshot дашборда. В production-мониторинге это создаёт определённый риск: изменение одной library panel разойдётся по всем двенадцати дашбордам без возможности быстро откатить только часть. Пока наш подход - тестировать изменения панели на отдельном dev-дашборде перед обновлением.

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

В целом 7.2 делает Grafana менее похожей на инструмент, где каждый дашборд - изолированный остров. Library panels это не революция, но закрывают конкретную дыру в рабочем процессе. Для проектов на managed-сопровождении обновление уже раскатали, library panels для типовых системных метрик вынесли в отдельную папку в Grafana.