Grafana 9.1: переезжаем на unified alerting и разбираемся с routing tree

Grafana 9.1 вышла в августе, и у неё есть одно изменение, которое нельзя проигнорировать: unified alerting теперь включён по умолчанию для новых инсталляций, а legacy alerting официально устарел. Для тех, кто поднимал Grafana год-два назад и настроил алертинг «как было», это означает один неприятный вопрос: когда мигрировать и насколько это больно.

У нас таких инсталляций несколько. Взяли одну клиентскую - мониторинг микросервисного приложения, Grafana 8.x, около тридцати alert rules, три notification channel-а (Telegram, email, PagerDuty) - и прошли через миграцию от начала до конца.

Что вообще изменилось

Legacy alerting в Grafana - это alert rules, привязанные к конкретным панелям дашборда. Правило живёт внутри JSON дашборда, уведомление уходит в notification channel. Просто, понятно, но ограниченно: правила разбросаны по дашбордам, нет нормальной группировки, нет silences на уровне всего стека, маршрутизация - только «отправить всё в этот channel».

Unified alerting - это отдельная система поверх Grafana, архитектурно ближе к Prometheus Alertmanager. Правила живут в отдельном разделе и не привязаны к дашбордам. Появляется contact points вместо notification channels, routing tree для маршрутизации по лейблам, silences, notification groups. Под капотом - Alertmanager, встроенный в Grafana, с его логикой group_by, group_wait, repeat_interval.

Звучит как улучшение - и по большей части так и есть. Но переезд с legacy на unified не автоматический: Grafana предлагает кнопку «migrate», которая переносит правила, но результат надо проверять руками.

Как проходил переезд

Первое, что сделали - сняли экспорт legacy rules через Grafana API и положили в git. Не потому что не доверяем миграции, а потому что хочется понимать, что было до и что стало после.

Запустили встроенный мигратор. Он перенёс все тридцать правил в unified alerting folder, создал contact points из notification channels и набросал базовый routing tree. На этом «автоматическая» часть закончилась.

Проблема первая - лейблы и маршрутизация. Legacy alerting не знает про лейблы в том смысле, в котором их понимает Alertmanager. Мигратор создаёт одно дефолтное правило в routing tree, которое отправляет всё в один contact point. Если нужна раздельная маршрутизация - «критические в PagerDuty, остальное в Telegram» - это надо настраивать заново. Логику пришлось восстанавливать из голов и старых Wiki-страниц, потому что в legacy она была зашита неявно: «этот channel получает только эти rules» через ручной выбор в UI.

Проблема вторая - условия срабатывания. Часть legacy rules использовала условия типа «значение > threshold последние X минут». В unified alerting это выражается через query с временным окном и reduce-функцией. Мигратор переносит запросы, но не всегда корректно интерпретирует «последние X минут» - получается либо другой диапазон, либо другая агрегация. Пришлось пройтись по каждому правилу и сверить логику с оригиналом.

Проблема третья - notification groups. Unified alerting группирует уведомления по лейблам (group_by в routing tree). По умолчанию - по grafana_folder и alertname. Если не настроить явно, можно получить шторм из тридцати отдельных уведомлений там, где раньше было одно письмо со списком. Первый тест на staging именно так и выглядел: PagerDuty получил тридцать инцидентов одновременно.

Что настроили в routing tree

Структура routing tree получилась несложная:

• Корневой маршрут - contact point Telegram, group_by по alertname, repeat_interval 4h.
• Ветка по лейблу severity=critical - contact point PagerDuty, group_wait 30s, repeat_interval 1h.
• Ветка по лейблу team=infra - contact point отдельный Telegram-канал инфраструктурной команды.

Лейблы severity и team добавили к правилам вручную - legacy rules их не имели. Это отдельная работа, которую мигратор не делает: нужно пройтись по каждому правилу и проставить осмысленные лейблы, исходя из того, что этот алерт означает для бизнеса.

Silences наконец работают нормально

Одна из причин, почему unified alerting стоит переезда - silences. В legacy alerting silence можно было поставить только на конкретный alert rule в конкретном дашборде, через UI. В unified alerting silence настраивается через matcher по лейблам: например, заглушить всё с team=infra на два часа в окно планового обслуживания. Это реально удобно, особенно когда плановые работы затрагивают несколько сервисов сразу.

Где есть шероховатости

Grafana Alertmanager - это не полный Prometheus Alertmanager. Часть возможностей, которые есть в standalone Alertmanager (например, inhibit_rules для подавления дочерних алертов при срабатывании родительского), либо реализована частично, либо работает иначе. Мы не используем сложные inhibitions, поэтому критичного не задело, но кто переезжает со зрелого Alertmanager-стека - стоит проверить заранее.

Интерфейс routing tree в Grafana UI тоже пока сыроват: редактировать удобнее через YAML-конфиг (Grafana позволяет задать его через provisioning), чем кликать по вложенным блокам в браузере.

Итог

На весь переезд ушло примерно полтора рабочих дня: час на автоматическую миграцию и отладку на staging, остальное - ручная расстановка лейблов, настройка routing tree и проверка условий срабатывания правил. Не катастрофа, но и не «нажал кнопку и всё само».

Клиентский мониторинг ведём в рамках managed-сопровождения. Переезд остальных инсталляций с Grafana 8.x поставили в план на следующие недели - пока legacy alerting ещё работает, но ждать до последнего момента не хочется.