Многоуровневый алертинг: от warning до critical

«Хороший алертинг — это когда просыпаешься только когда действительно нужно»

#Проблема плоского алертинга

Плоский алертинг — все алерты одного уровня.

# ПЛОХО: все алерты critical
- alert: HighCPU
  severity: critical  # CPU 85%

- alert: ServiceDown
  severity: critical  # Сервис упал

- alert: DiskLow
  severity: critical  # Диск 80%

Проблемы:

Все алерты «критичные» — команда перестаёт реагировать
Нет эскалации — непонятно, что срочно
Alert fatigue — усталость от уведомлений

Решение: многоуровневая иерархия с разной срочностью реакции.

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

#Три уровня

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

#Примеры алертов по уровням

Critical:

ServiceDown — сервис полностью недоступен
HighErrorRate > 10% — критическая деградация
DatabaseDown — база данных не отвечает
PaymentFailed — платежи не проходят

Warning:

HighCPU > 80% — ресурс на исходе
HighMemory > 90% — память заканчивается
DiskLow > 85% — диск заполняется
HighLatency p95 > 1s — задержка выросла

Info:

ServerRebooted — сервер перезагрузился
DeploymentCompleted — деплой завершён
CertificateExpiring30Days — сертификат истекает через 30 дней

#Конфигурация многоуровневого алертинга

#Правила с уровнями

# alerting_rules.yml
groups:
  - name: application_alerts
    rules:
      # Critical
      - alert: ServiceDown
        expr: up{job="api"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Service {{ $labels.job }} is DOWN"
          description: "{{ $labels.instance }} не отвечает более 1 минуты"
          runbook_url: "https://wiki/runbooks/service-down"

      - alert: HighErrorRate
        expr: |
          sum by (service) (rate(http_requests_total{status=~"5.."}[5m]))
          /
          sum by (service) (rate(http_requests_total[5m]))
          > 0.10
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "High error rate on {{ $labels.service }}"
          description: "Error rate is {{ $value | humanizePercentage }}"

      # Warning
      - alert: HighCPU
        expr: |
          100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
          > 80
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "High CPU on {{ $labels.instance }}"
          description: "CPU usage is {{ $value | humanizePercentage }}"

      - alert: HighMemory
        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 }}"

      # Info
      - alert: ServerRebooted
        expr: changes(node_boot_time_seconds[5m]) > 0
        for: 0m
        labels:
          severity: info
        annotations:
          summary: "Server {{ $labels.instance }} was rebooted"

#Alertmanager: маршрутизация по уровням

#Конфигурация маршрутизации

# 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'
  pagerduty_url: 'https://events.pagerduty.com/v2/enqueue'

route:
  receiver: 'default-receiver'
  group_by: ['alertname', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  
  routes:
    # Critical → PagerDuty + Slack
    - match:
        severity: critical
      receiver: 'pagerduty-critical'
      continue: true  # Отправить и в Slack тоже
    
    # Warning → Slack
    - match:
        severity: warning
      receiver: 'slack-warnings'
    
    # Info → Email (без уведомлений)
    - match:
        severity: info
      receiver: 'email-info'
      group_wait: 5m
      group_interval: 1h

receivers:
  - name: 'default-receiver'
    email_configs:
      - to: 'alerts@example.com'

  - name: 'pagerduty-critical'
    pagerduty_configs:
      - service_key: 'your-pagerduty-service-key'
        severity: critical
        description: '{{ .CommonAnnotations.summary }}'

  - name: 'slack-warnings'
    slack_configs:
      - channel: '#alerts-warning'
        send_resolved: true
        title: '{{ .CommonAnnotations.summary }}'
        text: '{{ .CommonAnnotations.description }}'

  - name: 'email-info'
    email_configs:
      - to: 'info-alerts@example.com'

#Ключевые настройки

group_by:

group_by: ['alertname', 'severity']

Группирует алерты по имени и уровню. Вместо 10 отдельных алертов о высоком CPU — одно уведомление.

continue:

continue: true

Отправляет алерт в следующий маршрут тоже. Critical уйдёт и в PagerDuty, и в Slack.

group_wait:

group_wait: 30s  # Для critical
group_wait: 5m   # Для info

Ждёт перед отправкой первой группы. Для info — дольше, чтобы собрать больше контекста.

#Эскалация алертов

#Проблема

Алерт warning не реагируют — проблема становится critical.

#Решение: эскалация через время

route:
  routes:
    # Сначала warning в Slack
    - match:
        severity: warning
      receiver: 'slack-warnings'
      group_wait: 5m
      repeat_interval: 1h
      
      # Если не resolved через 2 часа → эскалация
      routes:
        - match:
            severity: warning
          receiver: 'pagerduty-escalated'
          group_wait: 1s
          repeat_interval: 30m
          matchers:
            - alertname =~ ".+"

#Эскалация через Recording Rules

Создайте метрику «возраст» алерта:

# Recording rule
- record: alert:pending_duration
  expr: time() - alert_start_time_seconds

Алерт на эскалацию:

- alert: WarningEscalatedToCritical
  expr: alert:pending_duration{severity="warning"} > 7200  # 2 часа
  labels:
    severity: critical
  annotations:
    summary: "Warning {{ $labels.alertname }} not resolved for 2 hours"

#Dependency-aware alerting

#Проблема

Упали 10 сервисов — 10 алертов. Но причина в одном: база данных.

#Решение: подавление по зависимости

# inhibit_rules в Alertmanager
inhibit_rules:
  # Если БД упала, подавить алерты сервисов
  - source_match:
      alertname: DatabaseDown
    target_match:
      alertname: ServiceDown
    equal: ['cluster']
  
  # Если critical, подавить warning той же системы
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'instance']

Как работает:

DatabaseDown срабатывает → source
ServiceDown на том же кластере → target
ServiceDown подавляется (не отправляется)

#Явные зависимости в аннотациях

- alert: ServiceDown
  expr: up{job="api"} == 0
  labels:
    severity: critical
    depends_on: 'database,cache'
  annotations:
    summary: "Service {{ $labels.job }} is DOWN"
    dependencies: "Check database and cache first"

#Silences: плановое подавление

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

Плановые работы (деплои, миграции)
Известные проблемы (ждём фикса)
Тестирование алертов

#Создание silence через UI

Alertmanager UI → Silences → New Silence
Fillters: alertname="HighCPU", instance="server1"
Duration: 2 часа
Created by: ваше имя
Comment: «Плановое обслуживание»

#Silence через API

curl -X POST http://alertmanager:9093/api/v2/silences \
  -H "Content-Type: application/json" \
  -d '{
    "matchers": [
      {"name": "alertname", "value": "HighCPU"},
      {"name": "instance", "value": "server1"}
    ],
    "startsAt": "2026-03-18T10:00:00Z",
    "endsAt": "2026-03-18T12:00:00Z",
    "createdBy": "admin",
    "comment": "Плановое обслуживание"
  }'

#Best practices многоуровневого алертинга

#1. Определите уровни явно

# Документация в README
## Severity Levels

- **critical**: Сервис недоступен. Реакция немедленно 24/7.
- **warning**: Проблема может стать критической. Реакция в течение часа.
- **info**: Информация для контекста. Реакция когда удобно.

#2. Используйте for для фильтрации

# Critical: быстро, но не слишком
for: 1m

# Warning: дольше, чтобы избежать ложных срабатываний
for: 15m

# Info: можно сразу
for: 0m

#3. Добавляйте runbook_url

annotations:
  runbook_url: "https://wiki/runbooks/high-cpu"

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

# Проверка синтаксиса
promtool check rules alerting_rules.yml

# Тестовое срабатывание (вручную создайте условие)

#5. Ревизия раз в квартал

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

#Мониторинг алертинга

#Метрики Alertmanager

# Количество отправленных уведомлений
alertmanager_notifications_total

# Ошибки отправки
alertmanager_notifications_failed_total

# Текущие активные алерты
alertmanager_alerts

# Длительность тишины
alertmanager_silences

#Алерты на сам алертинг

- alert: AlertmanagerDown
  expr: up{job="alertmanager"} == 0
  for: 1m
  labels:
    severity: critical

- alert: AlertmanagerNotificationsFailing
  expr: rate(alertmanager_notifications_failed_total[5m]) > 0.1
  for: 10m
  labels:
    severity: warning

Уровень

Когда

Реакция

Канал

critical

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

Немедленно (24/7)

PagerDuty, телефон

warning

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

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

Slack, email

info

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

Когда удобно

Email, лог