Grafana 10.4: новый интерфейс алертов и работа с Loki без боли

Grafana 10.4 вышла в середине марта, и мы планово прошлись по клиентским стекам на этой неделе. Не экстренное обновление - планово, в рамках managed-сопровождения. Но после апгрейда несколько вещей в работе с алертами изменились достаточно заметно, чтобы написать об этом отдельно.

Основное, что нас интересовало: новый интерфейс Alertmanager-маршрутизации и то, насколько изменилась ситуация с Loki. Расскажем по порядку.

Alerting UI: наконец можно не лезть в YAML

Это главное изменение релиза с точки зрения ежедневной работы. В Grafana Alertmanager маршрутизация уведомлений - кто получает какой алерт, по каким каналам, с какими условиями матчинга - исторически жила в YAML-конфиге. Редактировать её через UI было технически возможно, но интерфейс был таким, что большинство предпочитало не рисковать и правили файл напрямую.

В 10.4 раздел «Notification policies» переработан. Теперь это полноценный визуальный редактор дерева маршрутизации: добавить политику, задать матчеры по лейблам, привязать contact point, выставить timing - всё это делается кликами, и результат сразу видно в виде дерева. YAML под капотом никуда не делся, но смотреть на него больше не обязательно.

На практике это меняет одну конкретную операцию, которая случается нередко: добавить нового получателя уведомлений или изменить маршрут для конкретного окружения. Раньше это требовало либо доступа к файлу конфига и понимания структуры Alertmanager YAML, либо звонка тому, кто этот конфиг помнит. Теперь - понятный интерфейс, который не требует знания синтаксиса.

Из нюансов: если вы генерировали Alertmanager-конфиг через Ansible или Terraform и храните его в репозитории - стоит проверить, что ручные изменения через UI не перетирают следующим прогоном автоматики. Это не баг 10.4, это вопрос архитектуры, но после обновления он стал актуальнее именно потому, что через UI теперь хочется что-то менять.

Новые типы панелей: XY Chart и Canvas-обновления

В 10.4 появился XY Chart как стабильный тип панели - раньше он был за feature toggle. Это панель для произвольных scatter-графиков: ось X - не обязательно время, можно задать любое числовое поле. Для Prometheus-метрик это бывает полезно, когда хочешь посмотреть корреляцию двух метрик - например, latency в зависимости от RPS - не по временным срезам, а как облако точек.

Честно говоря, в повседневном мониторинге мы этот тип используем редко. Но для разового анализа инцидента или емкостного планирования XY Chart удобнее, чем собирать то же самое в отдельном инструменте.

Canvas получил несколько улучшений в работе с фигурами и привязками - если вы строите схемы инфраструктуры прямо в Grafana, это заметно. Мы такой подход используем у пары клиентов, где нужен живой статусный дашборд для NOC - там Canvas действительно закрывает задачу.

Loki: упрощённый query builder

Работа с Loki через Grafana исторически имела один неприятный момент: LogQL - язык специфический, и query builder в Grafana до последнего времени помогал слабо. Логично написанный запрос легко получить из документации, но чуть отойти от шаблона - и начинается редактирование в сыром режиме.

В 10.4 query builder для Loki доработан. Основное улучшение - лучшая работа с label-фильтрами и парсерами: выбор парсера (logfmt, json, pattern) теперь влияет на то, какие поля предлагаются в автодополнении дальше по запросу. Звучит как мелочь, но на практике это снижает количество попыток при составлении нетривиального запроса.

Проверили на клиентском стеке с Loki 2.9: работает ожидаемо. Для базовых фильтраций - без изменений. Для запросов с | logfmt | label_format - заметно лучше.

Обновление: как прошло

Обновляли стандартно - через Helm-чарт на k8s-окружениях, через пакет там, где Grafana живёт на VM. Grafana 10.4 требует обновления схемы базы данных при первом запуске - это штатное поведение, но стоит убедиться, что есть свежий бэкап перед апгрейдом.

Никаких неожиданностей с дашбордами не было: панели, которые работали на 10.3, работают на 10.4 без изменений. Один клиентский стек использовал ряд deprecated-опций в provisioning-конфигах - Grafana их приняла с предупреждениями в логах, но не сломала. Разберём на ближайшем обслуживании.

Отдельно проверили алерты: существующие правила и contact points перенеслись без изменений. Это важно, потому что alerting - то место, где проблемы после апгрейда неприятнее всего: тихо сломавшийся алерт обнаруживается в самый неподходящий момент.

Где сейчас

Клиентские стеки обновлены. Новый интерфейс маршрутизации уже показали нескольким командам - реакция позитивная именно потому, что это убирает зависимость от «человека, который знает YAML». Для тех, кто поддерживает мониторинг в небольшой команде без выделенного SRE, это конкретная разгрузка.

По Loki-части - продолжаем наблюдать. Запросы стали писаться проще, но до уровня, когда неподготовленный человек может сам разобраться в нетривиальном LogQL без нашей помощи, ещё далеко - это вопрос не столько инструмента, сколько самого языка.