Расскажи про градацию алертов в мониторинге

Градация алертов в мониторинге: от тихого свиста до сирены

В DevOps-практике эффективная система алертинга — это не просто «шумовая пушка», а тонко настроенный механизм коммуникации между системами и людьми. Градация (северити, критичность) алертов — это систематизация их важности, которая напрямую определяет приоритет реакции команды, каналы уведомления и потенциальное воздействие на бизнес. Без четкой градации наступает alert fatigue (усталость от алертов), когда важные сигналы тонут в потоке информационного шума, а команда теряет бдительность.

Основные уровни градации (Severity Levels)

Как правило, используется 3-5 уровней критичности. Я предпочитаю классическую четырехуровневую модель, согласующуюся со многими ITSM-практиками (например, приоритизацией инцидентов):

1. Critical (Критический / P1)
2. High (Высокий / P2)
3. Medium (Средний / P3)
4. Low (Низкий / P4 / Info)

1. Critical (P1) — «Код красный»

Это алерты, требующие немедленных действий, часто в нерабочее время. Они сигнализируют о полной или значительной недоступности сервиса, потере данных, критической уязвимости безопасности или нарушениях ключевых бизнес-процессов.

• Примеры: недоступность основного приложения (5xx ошибки > 5%), отказ всех инстансов БД, сбой дата-центра.
• Реакция: Немедленная эскалация на on-call инженера через громкие каналы (звонок, SMS, громкий пуш), сбор war room, запуск процедур по устранению инцидента.
• В инструментах (Prometheus + Alertmanager):

  # alertmanager.yml
  routes:
    - receiver: 'critical-pager'
      group_wait: 10s
      group_interval: 5m
      repeat_interval: 1h
      matchers:
        - severity = "critical"
  

2. High (P2) — «Серьезная деградация»

Проблема существенно влияет на работу, но система не полностью недоступна. Требует срочного вмешательства в рабочее время, но не обязательно среди ночи.

• Примеры: высокая латентность (>95 перцентиль), частичная деградация функционала, сбой одного из нескольких регионов, быстро растущее потребление памяти, предупреждения от систем безопасности.
• Реакция: Уведомление в чат-каналы команд (Slack, Telegram, MS Teams) с требованием реакции, эскалация на ответственных в течение часа. Часто запускает процесс расследования.
• В Prometheus:

  # prometheus_rules.yml
  - alert: HighRequestLatency
    expr: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) > 0.5
    for: 3m
    labels:
      severity: high
      service: api-gateway
    annotations:
      summary: "Высокая латентность API-гейтвея"
      description: "P95 latency для {{ $labels.job }} составляет {{ $value }}s."
  

3. Medium (P3) — «Требует внимания»

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

• Примеры: повышенный уровень ошибок 4xx (проблемы клиентов), медленный рост дискового пространства, неоптимальная конфигурация, предупреждения от CI/CD пайплайнов.
• Реакция: Уведомление в тихие каналы (например, тихий Slack-канал, email, тикет в Jira). Обрабатывается в рамках рабочего дня или спринта.

4. Low / Warning / Info (P4) — «Информационный сигнал»

Чисто информационные сообщения, не требующие действий. Их цель — дать контекст для диагностики, протоколировать изменения или сообщить о восстановлении.

• Примеры: успешное развертывание, автоматическое восстановление системы после алерта, низкий уровень утилизации ресурсов, информационные события от инфраструктуры.
• Реакция: Только логирование. Часто такие алерты используются для ауторемедиации (система сама исправила проблему и сообщает об этом).

Ключевые принципы настройки градации

• Ориентация на бизнес-воздействие (Business Impact): Критичность алерта должна определяться не технической метрикой самой по себе (например, CPU load = 5), а тем, как эта метрика влияет на пользователей и доходы. SLA/SLO сервиса — главный ориентир.
• Избегание дублирования: Одна и та же корневая проблема не должна генерировать сотни одинаковых алертов (используйте group_by в Alertmanager).
• Автоматическое восстановление и задержка (for): Настройте for в правилах Prometheus, чтобы отфильтровать кратковременные всплески. Алгоритмы, основанные на машинном обучении (например, Nexthink), могут помочь отличить аномалию от фонового шума.
• Обзор и рефакторинг: Правила алертинга должны регулярно пересматриваться. Алерт, на который никогда не реагируют, либо понижают в степени, либо удаляют. Используйте Симпсоны алертов (The Four Golden Signals: Latency, Traffic, Errors, Saturation) как фундамент.

Практический пример стека: Prometheus + Alertmanager + Grafana

# Пример структуры конфига Alertmanager для маршрутизации по северити
route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 12h
  receiver: 'default-slack'

  # Вложенные маршруты для разных уровней
  routes:
    - matchers:
        - severity =~ "critical|high"
      receiver: 'oncall-pagerduty'
      group_wait: 10s
      repeat_interval: 30m
      routes:
        - matchers:
            - severity = "critical"
          receiver: 'critical-sms' # Отдельный приемник для P1

    - matchers:
        - severity =~ "warning|medium"
      receiver: 'team-email'
      repeat_interval: 6h

    - matchers:
        - severity = "info"
      receiver: 'log-only'
      repeat_interval: 1h

Итог: Правильная градация алертов превращает мониторинг из источника хаоса в стратегическую систему раннего оповещения. Она защищает команду от выгорания, экономит время и, что самое важное, фокусирует ресурсы на решении проблем, которые действительно угрожают стабильности и бизнесу. Это динамичный процесс, который требует постоянной коммуникации между DevOps-(SRE)-командой и бизнес-заказчиками.