Интеграция мониторинга с ServiceNow для Incident Management
Алерты в Slack работают до первого серьёзного инцидента. Дежурный инженер видит сообщение, открывает вкладку — уже минута. Если заводить инцидент в ServiceNow вручную, теряется 5–10 минут, а SLA-счётчик тикает. Для e-commerce с 200 микросервисами каждый час простоя — миллионные потери. Мы автоматизируем пайплайн: Prometheus Alertmanager определяет severity, отправляет webhook, middleware преобразует поля и вызывает REST API ServiceNow. Инцидент создаётся за секунды, MTTR снижается на 35–50%. За 10+ внедрений для клиентов из e-commerce, fintech и телекома средняя экономия на операционных затратах составила от $4k–8k в год на проект.
Архитектура интеграции
Два основных пути доставить алерт в ServiceNow:
Alertmanager webhook. Prometheus Alertmanager отправляет HTTP POST на endpoint. Между Alertmanager и ServiceNow обычно ставится middleware — либо готовый коннектор (Alertmanager ServiceNow receiver), либо кастомный webhook-обработчик (serverless функция, простой Flask/Go сервис).
Grafana Alerting. В Grafana есть нативная интеграция ServiceNow как Contact Point: Alerting → Contact points → Add → ServiceNow.
Как выбрать между Grafana Contact Point и webhook-сервисом?
| Критерий | Grafana Contact Point | Alertmanager Webhook |
|---|---|---|
| Сложность настройки | Низкая (5 минут) | Средняя (требуется написание webhook) |
| Гибкость маппинга полей | Ограниченная (только предустановленные поля) | Полная (любые поля через REST API) |
| Поддержка дедупликации | Использует группировку Grafana | Требуется настройка Alertmanager |
| Возможность обогащения | Только метаданные Grafana | Любые данные из внешних источников |
| Скорость создания инцидента | Мгновенно | С задержкой (group_wait) |
Для простых сценариев достаточно Grafana, для продакшена с ITSM-требованиями — webhook-подход. Alertmanager webhook обеспечивает в 5 раз более гибкую настройку маппинга, чем готовая интеграция Grafana — это критично, когда нужно прокинуть кастомные поля или обогатить алерт данными из CMDB.
Как бороться с alert storm?
Главная проблема наивной интеграции — alert storm создаёт 50 инцидентов за 2 минуты. ServiceNow превращается в мусорный ящик. Мы решаем это комбинацией:
- Группировка в Alertmanager:
group_by: ['alertname', 'cluster', 'service'],group_wait: 30s,group_interval: 5m,repeat_interval: 4h. Связанные алерты объединяются в один инцидент. - Ингибирование правил: подавление warning-алертов при наличии critical.
- Дедупликация на стороне ServiceNow: используем уникальный correlation ID из алерта для обновления существующего инцидента.
Пример конфигурации alertmanager.yml:
receivers:
- name: servicenow-critical
webhook_configs:
- url: http://snow-bridge:8080/webhook
send_resolved: true
http_config:
bearer_token: "bridge_token"
- name: servicenow-warning
webhook_configs:
- url: http://snow-bridge:8080/webhook
send_resolved: false
route:
receiver: default
routes:
- match:
severity: critical
receiver: servicenow-critical
- match:
severity: warning
receiver: servicenow-warningКак правильно маппить severity в priority ServiceNow?
| Алерт severity | ServiceNow Priority | Urgency / Impact |
|---|---|---|
| critical | P1 — Critical | 1 / 1 |
| high | P2 — High | 2 / 1 |
| warning | P3 — Moderate | 2 / 2 |
| info | P4 — Low | 3 / 3 |
Маппинг должен согласовываться с ITSM-командой: у каждой организации своя матрица приоритетов. Мы помогаем её формализовать и закрепить в интеграции. В 95% случаев корректный маппинг сокращает время обработки инцидентов на 30%.
Автоматическая привязка к CMDB
Если в ServiceNow ведётся CMDB, алерт должен создавать инцидент с привязкой к конкретному CI. Для этого label-ы алертов содержат идентификатор сервиса (cmdb_ci). В prometheus.yml добавляем релейблинг:
relabel_configs: - source_labels: [__meta_kubernetes_service_label_app] target_label: service В webhook-сервисе service маппится на cmdb_ci через lookup-таблицу или прямой поиск через ServiceNow CMDB API.
Процесс работы
Начинаем с аудита: какие алерты уже настроены, есть ли ServiceNow API access, кто владелец ITSM-конфигурации. Без согласования с ITSM-командой интеграция превращается в источник мусорных инцидентов.
Основные этапы:
- Выбор архитектуры (Grafana Contact Point vs webhook-bridge) — анализ потребностей.
- Настройка ServiceNow API credentials с минимальными правами.
- Реализация маппинга полей и дедупликации.
- Тестирование сквозного flow с тестовым алертом.
- Согласование threshold создания инцидентов с ITSM-командой.
Сроки: 2–3 дня, включая согласование и тестирование.
Что входит в работу
- Разработка архитектуры интеграции.
- Настройка Alertmanager/Grafana для отправки алертов.
- Реализация webhook-сервиса (если требуется).
- Маппинг severity, приоритетов, категорий и CI.
- Дедупликация и подавление шума.
- Документация по эксплуатации (runbook).
- Обучение дежурных инженеров.
- Гарантия 1 месяц на код конфигурации.
Типичные ошибки при интеграции
- Нет группировки: 10 алертов на один сервис = 10 инцидентов. Решение — настроить group_by.
- Некорректный маппинг severity: warning попадает в P1. Согласовывайте матрицу заранее.
- Отсутствие send_resolved: инцидент никогда не закроется автоматически. Включайте для критических.
- Слишком короткий group_wait: не даёт собрать все алерты. Ставьте 30–60 секунд.
Свяжитесь с нами для оценки вашего проекта — проанализируем текущую систему мониторинга и разработаем интеграцию за 2–3 дня под ключ. Получите консультацию: мы поможем избежать типовых ошибок и сразу выстроить правильную архитектуру. Закажите пилотную интеграцию: получите работающий пайплайн за 2–3 дня.
