Grafana 9.4 и Grafana OnCall: обновляем мониторинг-стек и уходим с PagerDuty на Telegram

В начале марта Grafana Labs выкатила 9.4, и у нас наконец сошлись звёзды: плановое обновление мониторинг-стека совпало с решением переехать с PagerDuty на Grafana OnCall для on-call нотификаций. Две задачи за один подход - это всегда подозрительно оптимистично, но в этот раз вышло примерно как задумывалось.

Grafana 9.4: что изменилось по делу

Unified alerting появился ещё в 8.x, но долго оставался в статусе «можно попробовать, но по умолчанию выключено». К 9.x он стал дефолтным, а в 9.4 получил несколько изменений, которые закрыли наши основные претензии.

Улучшенный routing в notification policies. Теперь можно строить более глубокую иерархию: корневая политика - group by cluster, дочерние - по severity, дальше ещё уровни по сервису. Раньше при сложной разветвлённой схеме routing-правила начинали конфликтовать, и нужно было либо упрощать, либо делать воркэраунды. В 9.4 это ведёт себя заметно предсказуемее.

State history и annotations. Алерты теперь пишут историю переходов состояний (firing -> resolved -> firing) в отдельное хранилище - и это подтягивается на панели как аннотации автоматически. Мелочь, но для разбора инцидентов экономит время: открыл дашборд, видишь метки на таймлайне где именно алерт срабатывал.

Provisioning через file-based config. Alerting rules, contact points и notification policies теперь полноценно раскатываются через YAML-файлы в /etc/grafana/provisioning/alerting/. Это то чего не хватало для GitOps-подхода: раньше provisioning для alerting был неполным и часть настроек приходилось делать руками через UI.

Обновление само по себе прошло без сюрпризов - у нас Grafana в Kubernetes через helm-чарт grafana/grafana, потребовалось поднять tag до 9.4.3 и прогнать helm upgrade. Единственный нюанс: если до обновления были включены legacy alerts параллельно с unified alerting (флаг unifiedAlerting.enabled: true при живых старых правилах), надо проверить что миграция прошла и старые правила видны в unified-формате. У нас на одном инстансе пара правил потерялась при апгрейде с 9.2 - пришлось восстановить из git.

Grafana OnCall: почему и зачем

PagerDuty работал. Претензий к функциональности особых не было, но два момента давили: цена при росте числа пользователей on-call и принципиальная зависимость от иностранного SaaS в 2023 году. Последнее для части клиентов уже не просто «неудобно» - в ряде случаев это требование.

Grafana OnCall существует в двух вариантах: облачный (grafana.com) и self-hosted через docker или kubernetes-оператор. Мы брали self-hosted, разворачивали в том же k8s-кластере что и Grafana.

Архитектура OnCall: отдельный сервис engine (Django-приложение), celery для фоновых задач, Redis и PostgreSQL. Интеграция с Grafana происходит через plugin - в Grafana 9.x plugin grafana-oncall-app устанавливается из каталога и настраивается через environment variables.

# helm values для grafana-oncall
engine:
  env:
    - name: BASE_URL
      value: "https://oncall.example.internal"
    - name: GRAFANA_API_URL
      value: "http://grafana:3000"
    - name: GRAFANA_TOKEN
      valueFrom:
        secretKeyRef:
          name: oncall-secrets
          key: grafana-token

Базовая схема: Grafana alertmanager -> OnCall -> Telegram.

Telegram вместо PagerDuty: конфиг и реальность

OnCall поддерживает Telegram как notification channel через bot API. Настройка: создаёшь бота через @BotFather, добавляешь его в нужные группы/каналы, в OnCall добавляешь Telegram как personal notification или channel notification.

Для дежурных нотификаций мы использовали личные уведомления через Telegram-аккаунты инженеров: каждый инженер привязывает свой Telegram через OnCall UI, дальше в escalation policy назначаешь его. Выглядит примерно так:

• Шаг 1 (0 мин) - notify on-call from schedule «Primary»
• Шаг 2 (5 мин) - notify on-call from schedule «Secondary»
• Шаг 3 (10 мин) - notify all users in team

Сообщение в Telegram приходит с кнопками: Acknowledge / Resolve / Silence. Это важно - без этого on-call через мессенджер превращается в одностороннее радио.

Что работает хорошо: базовый флоу ack/resolve, группировка алертов в тред, история переходов состояния прямо в Telegram-сообщении.

Что потеряли при переходе с PagerDuty

Честно - кое-что потеряли, и это стоит назвать прямо.

Телефонные звонки. PagerDuty умеет будить звонком, OnCall в self-hosted варианте - нет. Для критичных инцидентов ночью Telegram - слабее: его легче не услышать. Решение которое используем: настройка Telegram с максимальным приоритетом уведомлений и отдельная группа в телефоне для рабочего Telegram - некоторые инженеры держат громкость включённой. Не идеально.

Mobile app у PagerDuty был заметно зрелее: обновление статуса инцидента, timeline, связанные алерты - всё в одном месте. У OnCall мобильный клиент появился, но пока проще для простых сценариев.

On-call scheduling через API. В PagerDuty расписания и политики эскалации удобно управлялись через API с Terraform-провайдером. В OnCall это тоже есть, но документация по API тоньше, и пара нужных нам операций оказалась не полностью покрытой.

В целом переход прошёл нормально для нашего профиля нагрузки. Unified alerting в Grafana 9.4 - зрелый инструмент, не бета и не «используйте на свой страх и риск». Grafana OnCall как замена PagerDuty - работает, если не нужны голосовые звонки и сложный мобильный клиент. Для клиентов у которых мы ведём managed-инфраструктуру - переводим постепенно, не огульно: смотрим профиль on-call команды и критичность инцидентов.