Настройка Grafana Alerting Rules для автоматических уведомлений

Мы сталкиваемся с этим постоянно: когда алертов много — дежурный инженер перестаёт на них реагировать. Alert fatigue — это не метафора. Реальная ситуация: 300 firing алертов в Slack-канале, из которых 280 — хронический flapping одного NodeMemoryPressure на нагруженной ноде, который «всегда так». В итоге критический алерт о падении базы данных тонет в этом шуме. Наш опыт показывает: правильная настройка алертинга экономит до 70% времени дежурной смены и избавляет от ночных ложных вызовов.

Unified Alerting vs Legacy

Начиная с Grafana 9 и новее, классический подход с Alertmanager-правилами в Prometheus и нотификациями через Grafana разделён — теперь есть Grafana Unified Alerting, который умеет управлять алертами из нескольких datasource (Prometheus, Loki, InfluxDB) в одном интерфейсе. Это удобно, но создаёт путаницу: если в проекте уже настроен Alertmanager с маршрутами, inhibit rules и silences — дублировать логику в Grafana Alerting не нужно.

Правило простое: если Prometheus Alertmanager уже является центром маршрутизации — используем Grafana только для визуализации алертов, правила пишем в PrometheusRule CRD (для Kubernetes) или в prometheus.yml. Если Grafana — единственная точка входа и нет отдельного Alertmanager — тогда Grafana Unified Alerting с contact points.

Как проектируем правила без flapping

Flapping — алерт постоянно переходит из firing в resolved и обратно. Лечится двумя способами.

Первый — параметр for в правиле. for: 5m означает: условие должно быть истинным непрерывно 5 минут, только потом отправляем уведомление. Для CPU-алертов это критично: spike на 10 секунд не должен будить инженера ночью.

groups:
  - name: node.alerts
    rules:
      - alert: NodeCPUHighUsage
        expr: |
          ( 1 - avg by (instance) ( rate(node_cpu_seconds_total{mode="idle"}[5m]) ) ) > 0.85
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "CPU > 85% на {{ $labels.instance }} в течение 10 минут"
          runbook_url: "https://wiki.example.com/runbooks/node-cpu"

Второй — правильный порог. 85% CPU — warning, 95% — critical. Не надо один алерт на 80% с severity=critical. Нужна градация, чтобы дежурный понимал: warning можно посмотреть утром, critical — звоним прямо сейчас.

Почему flapping опасен?

Flapping забивает каналы уведомлений, снижает внимание дежурного и маскирует реальные инциденты. При частых переключениях статуса инженер перестаёт доверять алертам, что приводит к пропуску критических событий. Параметр for — единственный способ отсечь шум без потери чувствительности.

Как настроить inhibit rules в Alertmanager?

В Alertmanager настраиваем inhibit rules: если NodeDown firing — все алерты с этой ноды (pod, service, container) подавляются. Иначе за одной упавшей нодой следует лавина из 50 дочерних алертов.

---
inhibit_rules:
  - source_match:
      alertname: NodeDown
    target_match_re:
      alertname: "Pod.*|Container.*|Service.*"
    equal:
      - instance

Маршрутизация: критические алерты идут в PagerDuty с escalation policy, warning — в Slack-канал #alerts-warning, info — в отдельный low-priority канал. Дежурный видит только то, что требует немедленного действия.

Contact points в Grafana Unified Alerting

Если используем Grafana Alerting, contact points настраиваем через provisioning, а не через UI:

# /etc/grafana/provisioning/alerting/contact-points.yaml
apiVersion: 1
contactPoints:
  - orgId: 1
    name: pagerduty-critical
    receivers:
      - uid: pd-critical-uid
        type: pagerduty
        settings:
          integrationKey: "${PAGERDUTY_INTEGRATION_KEY}"
          severity: critical

Секреты — через переменные окружения, не хардкод в файл. Grafana читает их при старте.

Сравнение Grafana Unified Alerting и Prometheus Alertmanager

Evaluation groups и их влияние на производительность

Все алертные правила объединяем в группы с evaluationInterval. Дефолт — 1 минута. Для критической инфраструктуры можно поставить 30 секунд, но это увеличивает нагрузку на Prometheus/Grafana. Для 99% правил минута — нормальный интервал. Быстрее нужно только для SLA-критичных сервисов с жёстким RTO.

Как создать правило алерта в Unified Alerting (пошагово)

1. Перейти в раздел Alerting → Alert rules
2. Нажать New alert rule
3. Выбрать datasource (Prometheus, Loki)
4. Написать выражение, задать for и severity
5. Настроить аннотации (summary, description, runbook_url)
6. Выбрать contact point
7. Сохранить

Что входит в работу по настройке алертинга

• Аудит текущих алертов и источников данных
• Проектирование правил с группировкой и порогами
• Настройка contact points (Slack, PagerDuty, Telegram)
• Создание inhibit rules и маршрутизации
• Документация runbook'ов с автоматическими ссылками
• Обучение дежурной смены работе с алертами
• Пост-релизная поддержка в течение 2 недель

Сроки

Аудит существующих алертов и разработка правильной структуры занимает больше времени, чем сама настройка. Типичный проект: 2–4 дня — инвентаризация и проектирование правил, 1–2 дня — реализация и тестирование, 1 день — документация runbook'ов с ссылками из аннотаций алертов.

Специалисты нашей команды имеют сертификаты Kubernetes и опыт работы с инфраструктурой от 5 лет. Мы гарантируем снижение шума алертов и чёткую маршрутизацию уведомлений. Закажите настройку алертинга под ключ — мы проведём аудит, спроектируем и реализуем систему уведомлений. Свяжитесь с нами для оценки вашего проекта.