Налаштування правил алертингу в Grafana для автоматичних сповіщень

Ми стикаємося з цим постійно: коли алертів багато — черговий інженер перестає на них реагувати. 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 хвилин"

Другий — правильний поріг. 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 років. Ми гарантуємо зниження шуму алертів та чітку маршрутизацію сповіщень. Замовте налаштування алертингу під ключ — ми проведемо аудит, спроектуємо та реалізуємо систему сповіщень. Зв'яжіться з нами для оцінки вашого проекту.