Grafana Alerting: настраиваем оповещения для микросервисов — от PromQL до notification policies

Мониторинг без алертинга — это просто красивые графики. Grafana Alerting превращает PromQL-запросы в автоматические оповещения нужной команде в нужный канал. Разбираем полный путь: от alert rule до маршрутизации по severity и борьбы с alert fatigue.

Grafana Alerting vs legacy alerting

До Grafana 9 алерты привязывались к панелям дашборда. Unified Alerting работает иначе:

• Alert rules отделены от дашбордов — живут в отдельном разделе.
• Multi-datasource — одно правило комбинирует Prometheus, Loki, PostgreSQL.
• Notification policies — гибкая маршрутизация вместо жёсткой привязки «алерт → канал».
• Совместимость с Alertmanager — встроенный или внешний.

Legacy alerting отключён по умолчанию с Grafana 11.

Alert rules: PromQL-условия и timing

Alert rule: запрос (PromQL), условие срабатывания, тайминги. Пример — высокий error rate:

groups:
  - name: microservices
    interval: 30s
    rules:
      - uid: high-error-rate
        title: "High Error Rate"
        condition: C
        data:
          - refId: A
            model:
              expr: |
                sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
                /
                sum(rate(http_requests_total[5m])) by (service)
          - refId: C
            model:
              type: threshold
              conditions:
                - evaluator:
                    type: gt
                    params: [0.05]
        for: 2m
        labels:
          severity: critical
          team: backend
        annotations:
          summary: "Error rate {{ $labels.service }} > 5%"

Ключевые параметры:

• evaluation interval (30s) — частота проверки условия.
• for / pending (2m) — сколько условие должно быть true перед firing. Защита от спайков.
• labels — метки для маршрутизации (severity, team).

Полезные PromQL-паттерны:

# Latency p99 выше SLO
histogram_quantile(0.99, rate(http_duration_seconds_bucket[5m])) > 0.5

# Pod рестартится >3 раз за 10 минут
increase(kube_pod_container_status_restarts_total[10m]) > 3

# Диск заполнится через 4 часа
predict_linear(node_filesystem_avail_bytes[1h], 4*3600) < 0

# Сервис не отвечает
up{job="api-server"} == 0

Contact points: Telegram, Slack, PagerDuty

Contact point — куда уходит уведомление. Настройка через provisioning:

contactPoints:
  - name: backend-telegram
    receivers:
      - type: telegram
        settings:
          bottoken: "${TG_BOT_TOKEN}"
          chatid: "-1001234567890"
          parse_mode: HTML
          message: |
            {{ if eq .Status "firing" }}🔥{{ else }}✅{{ end }}
            {{ .CommonLabels.alertname }}
            {{ range .Alerts }}
            Service: {{ .Labels.service }}
            {{ .Annotations.summary }}
            {{ end }}

  - name: oncall-pagerduty
    receivers:
      - type: pagerduty
        settings:
          integrationKey: "${PD_KEY}"
          severity: "{{ .CommonLabels.severity }}"

Шаблоны используют Go template syntax с доступом к .Labels, .Annotations, .Status.

Notification policies и routing tree

Notification policy — дерево маршрутизации алертов по меткам:

policies:
  - receiver: default-email
    group_by: ['alertname', 'service']
    group_wait: 30s
    group_interval: 5m
    repeat_interval: 4h
    routes:
      - receiver: oncall-pagerduty
        matchers:
          - severity = critical
        mute_time_intervals:
          - maintenance-window

      - receiver: backend-telegram
        matchers:
          - team = backend
          - severity =~ "warning|critical"
        group_by: ['service']

      - receiver: frontend-slack
        matchers:
          - team = frontend

Логика:

• Алерт проходит дерево сверху вниз, попадает в первый подходящий route.
• continue: true — отправить в несколько каналов.
• group_by — вместо 50 алертов придёт одно сообщение с перечислением.
• repeat_interval — частота повторов, пока алерт не resolved.

Silences, mute timings и борьба с шумом

Mute timings — расписание подавления (maintenance windows):

muteTimes:
  - name: maintenance-window
    time_intervals:
      - weekdays: ['saturday', 'sunday']
        times:
          - start_time: '02:00'
            end_time: '06:00'
        location: Europe/Moscow

Silences — ручное подавление через UI/API на время инцидента.

Best practices:

• Каждый алерт — с runbook URL: что делать при срабатывании.
• for: 2m+ для всех кроме критических down-алертов.
• Разделяйте severity: critical (PagerDuty, будит ночью), warning (мессенджер в рабочее время), info (только дашборд).
• Группируйте по сервису — 20 алертов = один инцидент.
• Ревьюйте: если алерт игнорируется >50% — удалите или поднимите порог.

Ключ к успеху — не количество алертов, а их качество: каждое уведомление должно требовать действия.