Алертинг в Prometheus: когда что-то идёт не так

«Алерт без действия — это просто шум»

#Зачем нужен алертинг

Мониторинг без алертинга — как дымовая сигнализация, которая не звонит пожарным.

Цели алертинга:

Уведомить о проблеме до того, как её заметят пользователи
Объяснить что произошло и где
Направить к действию — что делать

Плохой алерт:

«CPU high on server-42»

Хороший алерт:

«High CPU (95%) on payment-api-server-42 for 10 minutes. Check recent deployments and autoscaling metrics. Runbook: https://wiki/...»

#Архитектура алертинга Prometheus

┌──────────────────────────────────────────────────────────────┐
│                      Prometheus                               │
│  ┌─────────────────────────────────────────────────────────┐ │
│  │  Alert Rules                                            │ │
│  │  (вычисление условий)                                   │ │
│  └─────────────────────────────────────────────────────────┘ │
│                           │                                   │
│                           ▼                                   │
│  ┌─────────────────────────────────────────────────────────┐ │
│  │  Alertmanager                                           │ │
│  │  (маршрутизация, группировка, подавление)               │ │
│  └─────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘
                           │
         ┌─────────────────┼─────────────────┐
         ▼                 ▼                 ▼
    ┌─────────┐      ┌─────────┐      ┌─────────┐
    │  Email  │      │  Slack  │      │PagerDuty│
    └─────────┘      └─────────┘      └─────────┘

Компоненты:

Prometheus — вычисляет правила алертинга, создаёт активные алерты
Alertmanager — отдельный сервис, который получает алерты от Prometheus и:
- Группирует похожие алерты
- Подавляет дубликаты (inhibition)
- Маршрутизирует по получателям (Slack, email, PagerDuty)
- Управляет тишиной (silences)

#Правила алертинга (Alerting Rules)

Правила определяются в YAML-файле и загружаются в Prometheus.

#Структура правила

groups:
  - name: application_alerts
    interval: 30s  # Как часто вычислять правила
    rules:
      - alert: HighErrorRate
        expr: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.05
        for: 5m
        labels:
          severity: critical
          team: backend
        annotations:
          summary: "High error rate detected"
          description: "Error rate is {{ $value | humanizePercentage }} on {{ $labels.instance }}"
          runbook_url: "https://wiki/runbooks/high-error-rate"

Поля:

alert — имя алерта (уникальное)
expr — PromQL выражение, которое возвращает 1 (алерт) или 0 (нет алерта)
for — как долго условие должно выполняться перед срабатыванием
labels — метки для категоризации и маршрутизации
annotations — человекочитаемое описание (поддерживает шаблонизацию)

#Вычисление условий

Prometheus вычисляет expr по расписанию (evaluation_interval или interval в группе).

Результат:

Если выражение возвращает вектор с элементами → алерт pending
Если условие выполняется for секунд → алерт firing
Если выражение возвращает пустой вектор → алерт resolved

#Практические примеры алертов

#Алерт на высокий error rate

- alert: HighErrorRate
  expr: |
    sum(rate(http_requests_total{status=~"5.."}[5m])) 
    / 
    sum(rate(http_requests_total[5m])) 
    > 0.05
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "High HTTP error rate"
    description: "Error rate is {{ $value | humanizePercentage }} over the last 5 minutes"

Почему так:

rate()[5m] — сглаживает кратковременные скачки
for: 5m — требует устойчивого превышения
sum() — агрегирует по всем инстансам (проблема системы, а не одного сервера)

#Алерт на высокую задержку

- alert: HighLatency
  expr: |
    histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) 
    > 0.5
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: "High latency detected"
    description: "95th percentile latency is {{ $value | humanizeDuration }}"

Почему так:

95-й перцентиль — не среднее, а реальный опыт большинства пользователей
for: 10m — более длительное окно, потому что задержка может колебаться

#Алерт на недоступность сервиса

- alert: ServiceDown
  expr: up == 0
  for: 1m
  labels:
    severity: critical
  annotations:
    summary: "Service {{ $labels.job }} is down"
    description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minute"

Почему так:

up == 0 — метрика автоматически добавляется Prometheus для всех targets
for: 1m — быстро, но не слишком (избегаем ложных срабатываний при перезапуске)

#Алерт на нехватку места на диске

- alert: DiskSpaceLow
  expr: |
    (node_disk_size_bytes - node_disk_free_bytes) / node_disk_size_bytes * 100 
    > 85
  for: 30m
  labels:
    severity: warning
  annotations:
    summary: "Disk space low on {{ $labels.instance }}"
    description: "Disk usage is {{ $value | humanizePercentage }} on {{ $labels.device }}"

Почему так:

for: 30m — диск заполняется медленно, не нужно реагировать на кратковременные скачки
85% — порог до того, как станет критично (90-95%)

#Алерт на предсказанное заполнение диска

- alert: DiskWillFillIn4Hours
  expr: |
    predict_linear(node_disk_free_bytes[24h], 4*3600) < 0
  for: 1h
  labels:
    severity: warning
  annotations:
    summary: "Disk will fill in 4 hours on {{ $labels.instance }}"
    description: "Based on 24h trend, disk {{ $labels.device }} will be full in 4 hours"

Почему так:

predict_linear() — предсказывает будущее значение на основе тренда
Проактивный алерт — даёт время на реакцию до проблемы

#Алерт на высокую загрузку памяти

- alert: HighMemoryUsage
  expr: |
    (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) 
    / 
    node_memory_MemTotal_bytes 
    * 100 
    > 90
  for: 15m
  labels:
    severity: warning
  annotations:
    summary: "High memory usage on {{ $labels.instance }}"
    description: "Memory usage is {{ $value | humanizePercentage }}"

#Alertmanager: конфигурация

Alertmanager настраивается отдельно от Prometheus.

#Базовая конфигурация (`alertmanager.yml`)

global:
  smtp_smarthost: 'smtp.example.com:587'
  smtp_from: 'alertmanager@example.com'
  slack_api_url: 'https://hooks.slack.com/services/XXX/YYY/ZZZ'

# Маршрутизация
route:
  receiver: 'default-receiver'
  group_by: ['alertname', 'severity']
  group_wait: 30s      # Ждём перед отправкой первой группы
  group_interval: 5m   # Ждём перед отправкой следующих алертов той же группы
  repeat_interval: 4h  # Повторяем, если алерт не resolved
  
  # Дочерние маршруты
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty-critical'
    - match:
        team: backend
      receiver: 'slack-backend'

# Получатели
receivers:
  - name: 'default-receiver'
    email_configs:
      - to: 'alerts@example.com'
  
  - name: 'pagerduty-critical'
    pagerduty_configs:
      - service_key: 'your-pagerduty-service-key'
  
  - name: 'slack-backend'
    slack_configs:
      - channel: '#backend-alerts'
        send_resolved: true

# Подавление (inhibition)
inhibit_rules:
  # Если критический алерт сработал, не отправлять warning той же системы
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'instance']

Ключевые концепции:

#Группировка (group_by)

Похожие алерты группируются в одно уведомление:

group_by: ['alertname', 'severity']

Вместо 10 отдельных уведомлений о 10 серверах с высоким CPU — одно: «10 серверов с высоким CPU».

#Подавление (inhibition)

Если сработал критический алерт, warning той же системы не отправляется:

inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'instance']

#Тишина (silences)

Через UI Alertmanager можно установить silence — временное подавление алертов.

Использование:

Плановые работы
Известные проблемы, над которыми работают
Тестирование

#Best practices алертинга

#1. Алерты должны быть действенными

Плохо:

«CPU high»

Хорошо:

«CPU > 90% на payment-api в течение 15 минут. Проверьте очередь задач и последние деплои. Runbook: https://wiki/...»

Правило: если на алерт нельзя отреагировать — не создавайте его.

#2. Избегайте шума

Проблема: alert fatigue — усталость от уведомлений. Люди перестают реагировать.

Решения:

Используйте for для фильтрации кратковременных скачков
Настраивайте разумные пороги
Подавляйте дубликаты через Alertmanager
Регулярно ревизуйте алерты

#3. Уровни серьёзности

Определите 2-3 уровня:

Уровень	Когда	Куда	Реакция
`critical`	Сервис недоступен или критически деградировал	PagerDuty, телефон	Немедленно
`warning`	Проблема, которая может стать критической	Slack, email	В течение часа
`info`	Информация для контекста	Email, лог	Когда удобно

#4. Документируйте в аннотациях

annotations:
  summary: "..."
  description: "..."
  runbook_url: "https://wiki/runbooks/..."
  dashboard_url: "https://grafana/d/..."

#5. Тестируйте алерты

Способы:

Вручную создайте условие (например, нагрузите CPU)
Используйте promtool check rules alerting.yml
Настройте тестовый маршрут в Alertmanager

#6. Ревизия алертов

Раз в квартал проверяйте:

Какие алерты срабатывали чаще всего?
Какие алерты никогда не срабатывали? (может, удалить?)
Какие алерты были ложными? (настроить пороги)

#Интеграция с Grafana Alerts

Grafana 8+ имеет свою систему алертинга (Unified Alerting).

Преимущества Grafana Alerts:

Визуальный редактор правил
Превью алертов на графике
Интеграция с дашбордами
Множество источников данных (не только Prometheus)

Когда использовать Grafana:

Алерты на основе дашбордов
Команды, которые уже работают в Grafana
Мульти-источник данных

Когда использовать Prometheus:

Классический стек Prometheus + Alertmanager
Сложные правила с PromQL
Централизованный алертинг для нескольких кластеров

#Отладка алертов

#Проверка правил в Prometheus UI

Откройте Prometheus (http://localhost:9090)
Перейдите в Alerts
Увидите список правил со статусом (pending, firing)

#Проверка через API

# Получить все алерты
curl http://localhost:9090/api/v1/rules

# Получить состояние алертов
curl http://localhost:9090/api/v1/alerts

#Тестирование PromQL

Проверьте выражение в Prometheus UI:

Должно возвращать непустой вектор при условии алерта
Должно возвращать пустой вектор в норме

┌──────────────────────────────────────────────────────────────┐ │ Prometheus │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Alert Rules │ │ │ │ (вычисление условий) │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Alertmanager │ │ │ │ (маршрутизация, группировка, подавление) │ │ │ └─────────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────┘ │ ┌─────────────────┼─────────────────┐ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ Email │ │ Slack │ │PagerDuty│ └─────────┘ └─────────┘ └─────────┘

Уровень

Когда

Куда

Реакция

critical

Сервис недоступен или критически деградировал

PagerDuty, телефон

Немедленно

warning

Проблема, которая может стать критической

Slack, email

В течение часа

info

Информация для контекста

Email, лог

Когда удобно

Алертинг в Prometheus: когда что-то идёт не так