Notification policies
Тема дорожной карты · Grafana
Политики уведомлений в Grafana Alerting формируют дерево маршрутизации, определяющее, какая точка доставки получает уведомление для сработавшего алерта на основе его меток. Корневая политика служит универсальным обработчиком, отправляющим все несопоставленные алерты в точку доставки по умолчанию, тогда как вложенные дочерние политики используют сопоставители меток (например, severity=critical или team=platform) для выборочной маршрутизации конкретных групп алертов в выделенные точки доставки — PagerDuty для критических и Slack для предупреждений. Каждый узел дерева политик также настраивает поведение группировки: метки Group by управляют тем, как Grafana Alerting объединяет несколько сработавших алертов в одно уведомление для снижения шума, а также задаёт тайминги Group wait, Group interval и Repeat interval, управляющие ритмом доставки уведомлений. Политики уведомлений в Grafana намеренно отделены от определений правил алертинга: это означает, что одна точка доставки и логика маршрутизации могут использоваться для многих правил алертинга, а дежурные инженеры могут корректировать маршрутизацию без изменения конфигурации самих правил. Страница Alerting > Notification policies в интерфейсе Grafana предоставляет древовидный вид всех политик и инструмент отладки View matches, показывающий, какая политика соответствует заданному набору меток алерта.
Как это работает
Notification policies (unified alerting с Grafana 9) позволяет определять alert rules с PromQL/LogQL/SQL-запросами + периодически оценивать + роутить к contact points. Rules в папках; папки наследуют notification policies. Notification channels: Slack, PagerDuty, OpsGenie, Telegram, email, webhook, MS Teams. Состояния алертов: Normal, Pending (условие выполнено, но ещё не дошло до "for"-длительности), Firing.
Когда применять
Grafana alerting — если хотите алерты, охватывающие несколько datasources (одно правило, комбинирующее Prometheus + Loki — полезно для SLO с errors + latency). Prometheus + Alertmanager напрямую — если хотите single PromQL/Alertmanager-стек. Выберите один и держитесь его; гонять оба создаёт путаницу дублирования правил.
Типичные ошибки
Ловушки Notification policies: алерты без "for:"-длительности (flapping); имена алертов без контекста (HighCPU — на чём? когда?); нет runbook-ссылки в annotations; все алерты в один Slack-канал (alert fatigue — роутьте по severity).