Автоматизированные процессы реагирования на инциденты с помощью n8n и Prometheus

Это руководство поможет команде использовать n8n и Prometheus для автоматизации реагирования на некоторые инциденты.

1. Процесс реагирования на инциденты

Эффективное управление инцидентами предполагает структурированный подход, который можно улучшить с помощью автоматизации на каждом этапе:

Подготовка

• Документация: ведение runbook’ов и процедур реагирования
• Настройка мониторинга: настройте алерты Prometheus с соответствующими порогами.
• Готовность команды: убедитесь, что графики дежурств и пути эскалации четко определены.

Обнаружение и анализ

• Активация оповещений: Prometheus обнаруживает аномалии на основе предопределенных правил.
• Первоначальная оценка: автоматическая классификация по уровню критичности и влиянию.
• Контекстное обогащение: добавление релевантной системной информации в оповещения.

Восстановление

• Маршрутизация уведомлений: направление оповещений по соответствующим каналам (PagerDuty, Slack)
• Руководство по реагированию: ссылки на соответствующие руководства или документацию.
• Автоматическое устранение: запуск скриптов восстановления для известных проблем.

Действия после инцидента

• Документация: фиксация хронологии и деталей реагирования.
• Анализ: определение корневых причин и возможностей для предотвращения.
• Улучшение процесса: обновление правил мониторинга и рабочих процессов реагирования.

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

2. Создание процесса реагирования на инциденты с n8n + Prometheus

Давайте создадим практичный рабочий процесс, который будет разумно управлять оповещениями Prometheus, гарантируя, что критически важные проблемы будут отправляться с учетом критичности, рабочего времени,…

Обзор рабочего процесса

Наша цель — построить систему, которая:

• Получает оповещения от Prometheus/AlertManager
• Анализирует уровень критичности и рабочее время.
• Направляет критически важные алерты вне рабочего времени в PagerDuty для немедленного реагирования.
• Отправляет менее срочные или алерты в рабочее время в Slack/Discord.
• Автоматизирует разрешение инцидентов на основе предложений AI-агента.
• Lambda-функция выполняет ваши операции (можно кастомизировать для ECS, EKS и других).
• Документирует все инциденты в структурированном формате (Notion)

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

Настройка стека мониторинга

Перед построением нашего рабочего процесса n8n необходимо правильно настроить систему мониторинга:

1. Установить стек Prometheus

• Сервер Prometheus для сбора метрик
• Exporters для ваших конкретных сервисов
• AlertManager для обработки оповещений
• Grafana для визуализации

Для облегчения настройки стека я подготовил скрипты для развёртывания «Node Exporter — Prometheus — Alert Manager — Grafana Stack» по щелчку мыши. Вы можете посмотреть, скачать и развернуть самостоятельно.

2. Настройка правил алертов в Prometheus

Ниже приведен пример кода для активации оповещений.

groups:
- name: example
  rules:
  - alert: HighCPU
    expr: 100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle",job="exporters"}[5m])) * 100) > 10
    for: 1m
    labels:
      severity: critical
      service: node
    annotations:
      description: "CPU usage on {{ $labels.instance }} is {{ $value }}%"
  - alert: HighLatency
    expr: rate(http_request_duration_seconds_sum[5m]) / rate(http_request_duration_seconds_count[5m]) > 0.5
    for: 1m
    labels:
      severity: warning
      service: web
    annotations:
      description: "Response time on {{ $labels.instance }} is {{ $value }}s"

3. Настройка AlertManager для пересылки на n8n

route:
  receiver: 'n8n-webhook'
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 1m
  repeat_interval: 30m

receivers:
- name: 'n8n-webhook'
  webhook_configs:
  - url: '<http://your-n8n-instance:5678/webhook/prometheus>'
    send_resolved: true

Создание рабочего процесса n8n

Теперь давайте создадим наш рабочий процесс n8n для интеллектуальной обработки этих оповещений:

1. Создайте узел Webhook

• Это позволит получать оповещения от AlertManager.
• Настройте его на разбор JSON-данных.

Примечание: чтобы использовать «Production URL», необходимо перевести рабочий процесс в состояние «Active» (активный).

2. Добавьте узел Function для классификации оповещений

Чтобы проанализировать полезную нагрузку от Prometheus, мы попытаемся разобрать JSON. Также мы рассчитаем рабочее время и продолжительность инцидента, что поможет нам точнее оценить ситуацию.

Добавьте узел кода, введите следующий код JavaScript:

const alerts = items[0].json.body.alerts || [];
return alerts.map(alert => ({
  const startsAt = new Date(alert.startsAt);
  const endsAt = new Date(alert.endsAt);
  const hour = endsAt.getUTCHours();
  const isBusinessHours = hour >= 9 && hour < 17; // 9 AM–5 PM UTC
  const durationMinutes = (endsAt - startsAt) / 1000 / 60; // Duration in minutes
  json: {
    status: alert.status, // firing or resolved
    alertname: alert.labels.alertname, // e.g., HighCPU
    severity: alert.labels.severity, // e.g., critical
    instance: alert.labels.instance, // e.g., 47.129.163.27:9100
    service: alert.labels.service, // e.g., node
    description: alert.annotations.description, // e.g., CPU usage description
    startsAt: alert.startsAt, // e.g., 2025-05-25T06:40:29.682Z
    endsAt: alert.endsAt, // e.g., 2025-05-25T06:42:59.682Z
    fingerprint: alert.fingerprint, // e.g., 80e7d055dbb50b48
    isBusinessHours: isBusinessHours, // true if within 9 AM–5 PM UTC
    durationMinutes: durationMinutes // Duration in minutes
  }
}));

3. Добавьте узел Switch для маршрутизации.

Маршрутизация будет осуществляться на основе критичности и рабочего времени, будет три пути:

• Критический + вне рабочего дня → PagerDuty
• Критический + Рабочие часы → Discord (канал для срочных сообщений)
• Некритический → Discord (общий канал оповещений)

4. Настройте интеграцию с сервисами

Узел PagerDuty:

• Подключитесь к сервису PagerDuty
• Сопоставьте данные оповещения с полями инцидента
• Установите соответствующую критичность

Узел Discord:

• Создайте отформатированные сообщения с подробностями об оповещении.
• Включите ссылки на дашборды Grafana
• Добавьте ссылки на runbook’и, если они доступны.

5. Добавьте интеграцию с Notion для документации

• Создайте узел базы данных Notion
• Регистрируйте все инциденты с временными метками, уровнем серьёзности и деталями реагирования
• Добавляйте статус решения и последующие задачи

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

Оповещения среднего уровня отправляются в Discord, команда может проверить их позже.

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

Урегулировать инцидент

Предлагаемая подсказка(prompt) для ИИ-агента, которая обработает контекст для вас:

Analyze the following Prometheus alert to determine if it should be auto-resolved by restarting the EC2 instance to handle issues like high CPU usage, especially when the team is unavailable. The context is:

- Alert Name: {{ $node["Code"].json["alertname"] }}
- Severity: {{ $node["Code"].json["severity"] }}
- Duration: {{ $node["Code"].json.durationMinutes }} minutes
- Business Hours: {{ $node["Code"].json["isBusinessHours"] }} (true if 9 AM–5 PM UTC, false otherwise)
- Description: {{ $node["Code"].json["description"] }}

Extract the CPU usage (X%) from the description, formatted as: "On <instance> at <alertname>: CPU usage is X%, Memory available is Y%, Swap usage is Z%, Disk I/O is A s, Network received is B MB/s, Latency is C s".

Decide to auto-resolve (restart the EC2 instance) if:
1. CPU usage > 80% AND outside business hours (isBusinessHours is false).
2. CPU usage > 90% AND duration < 5 minutes.
3. Severity is "critical" AND outside business hours (isBusinessHours is false).

Return only the following JSON object, with no additional text, explanations, or markdown:
{
  "shouldAutoResolve": boolean,
  "reason": "Explanation of the reason why this action should or should not be auto-resolved, referencing CPU usage, duration, severity, and business hours if relevant."
}

- If shouldAutoResolve is true, a Lambda function will be triggered to restart the EC2 instance.
- If shouldAutoResolve is false, no restart will occur.
- Keep the reason concise and clear, referencing the specific criteria met or not met.
- If CPU usage cannot be extracted, assume 0% and include it in the reason.

Он будет следовать ожидаемому контексту и принимать решение о том, перезапускать сервис или нет:

3. Улучшение рабочего процесса

Вы можете улучшить рабочий процесс в соответствии со своими потребностями. Я порекомендую несколько подходов:

Этап уведомления

N8n поддерживает различные типы интеграций, такие как Slack, Telegram, Rocketchat и т.д. Вы можете интегрировать все, что вам нужно.

Этап анализа

Можно подключить ИИ-агента, LLM-chain или OpenLLM для оценки метрик и маршрутизации инцидентов.

Вы можете значительно улучшить рабочий процесс следующим образом:

• Реализуйте интеллектуальное подавление: агрегируя метрики из Prometheus Alertmanager, можно использовать узел ИИ в n8n, чтобы подавлять или эскалировать проблему для команды.
• Проверки внешних зависимостей: мы можем интегрироваться с некоторыми внешними сервисами, такими как DNS, Vercel, AWS и т. д., чтобы убедиться, что инцидент обработан корректно.

Этап логирования инцидентов

Вы можете интегрировать в хранилища, такие как GoogleSheet, MongoDB, SQL и т. д. Поддерживаются многие типы баз данных.

4. Примеры кодов и рабочего процесса

• Рабочий процесс реагирования на инциденты (json) — https://github.com/Bubobot-Team/automation-workflow-monitoring/blob/main/n8n/n8n___Incident_Response___1.json
• Развертывание Node Exporter — Prometheus — Alert Manager — Grafana Stack в режиме Click-Run: https://github.com/Bubobot-Team/monitoring-stack/tree/main/stacks/prometheus-stack