Інтеграція моніторингу з 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 та телекому середня економія на операційних витратах склала від 400 000 до 800 000 ₴ на рік на проект.
Архітектура інтеграції
Два основні шляхи доставити алерт у 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 дні.
