Уявіть: вночі падає прод-сервіс, Alertmanager шле алерт у PagerDuty, а черговий інженер вручну створює тікет у Jira Service Management. Поки він шукає шаблон, заповнює severity та призначає SLA, проходять хвилини — кожен алерт перетворюється на десятки повідомлень. Ми зіткнулися з цією проблемою при обслуговуванні інфраструктури з 200+ мікросервісами у клієнта в fintech-секторі. Результат автоматизації: час реакції скоротився на 60%, а операційні витрати на інциденти — вдвічі за рахунок усунення рутини. За 5+ років роботи з ITSM та моніторингом (понад 30 впроваджень) ми виробили оптимальні схеми інтеграції. Наша команда — сертифіковані інженери з досвідом управління інцидентами DevOps з 2018 року.
Досвід підказує: універсального рішення немає — підбирати метод потрібно під конкретний стек і вимоги до гнучкості. Нижче — порівняння підходів за ключовими параметрами.
| Метод | Гнучкість | Складність налаштування | Дедуплікація | Двостороння синхронізація | Час впровадження |
|---|---|---|---|---|---|
| Alertmanager webhook | Висока | Середня | Налаштовувана | Часткова (resolve) | 2-3 дні |
| Grafana OnCall | Середня | Низька | Вбудована | Повна | 1-2 дні |
| Grafana Alerting → JSM | Низька | Низька | Базова | Немає | 1 день |
Як працює webhook-інтеграція Alertmanager з JSM?
Найгнучкіший шлях — webhook-отримувач у Alertmanager, який викликає Jira REST API (документація Atlassian). Інтеграція Prometheus з JSM через Alertmanager дозволяє контролювати кожне поле інциденту. Налаштування складається з таких кроків:
- Налаштуйте конфігурацію Alertmanager з receiver, що вказує на ваш webhook-сервіс.
- Створіть webhook-сервіс, який отримує алерти та через Jira REST API створює issue.
- Налаштуйте JSM для прийому інцидентів з автоматичним призначенням та SLA.
Приклад конфігурації Alertmanager:
---
# alertmanager.yml
receivers:
- name: jira-incidents
webhook_configs:
- url: http://jsm-bridge:8080/alert
send_resolved: true
http_config:
bearer_token_file: /etc/alertmanager/jsm_token
route:
group_by: ['alertname', 'namespace', 'service']
group_wait: 30s
group_interval: 5m
repeat_interval: 6h
routes:
- match:
severity: critical
receiver: jira-incidents
- match:
severity: warning
receiver: jira-incidents
continue: false
Код webhook-сервісу (Node.js)
const express = require('express');
const axios = require('axios');
const app = express();
app.use(express.json());
app.post('/alert', async (req, res) => {
const { alerts } = req.body;
for (const alert of alerts) {
const existing = await jira.search(`project = INFRA AND status != Done AND labels = "alert:${alert.labels.alertname}"`);
if (existing.length === 0) {
await jira.createIssue({
summary: alert.annotations.description,
issueType: 'Incident',
priority: alert.severity === 'critical' ? 'Highest' : 'High',
labels: [`alert:${alert.labels.alertname}`]
});
} else {
await jira.addComment(existing[0].id, 'Повторний алерт');
}
}
res.send('ok');
});
app.listen(8080);Що робити з дедуплікацією алертів?
Без дедуплікації один збій генерує десятки тікетів. Два рівні захисту:
На рівні Alertmanager: group_by: ['alertname','namespace','service'] об'єднує пов'язані алерти в один webhook. group_wait: 30s збирає повторні спрацювання до першого виклику.
На рівні webhook-сервісу: перед створенням issue сервіс виконує JQL-запит: project = INFRA AND issuetype = Incident AND status != Done AND labels = "alert:HighCPU" AND labels = "host:prod-01". Якщо тікет знайдений — додається коментар, новий не створюється. Так одна подія = один інцидент.
Нативна інтеграція через Grafana OnCall
Якщо стек включає Grafana OnCall, JSM-конектор налаштовується за годину. OnCall підтримує створення JSM-інциденту при активації ескалації, автоматичне закриття при resolve та двосторонню синхронізацію статусів. Це простіше, ніж кастомний webhook, але гнучкість нижча: не можна кастомізувати маппінг полів під складні сценарії. Grafana OnCall впроваджується на 50% швидше, ніж вебхук, але поступається в гнучкості.
Пряма інтеграція Grafana Alerting (Grafana Alerting Jira connector)
В останніх версіях Grafana з'явився Contact Point типу Jira. Налаштування: Jira URL, username, API token, project, issue type, summary. Обмеження — немає умовного створення (тільки з routing rules) і кастомних полів.
Налаштування JSM для інцидентів з моніторингу
У JSM для ефективного SLA моніторингу інцидентів необхідно:
- Service Project з SLA-політиками та чергою чергових.
- Request Type «Monitoring Alert» з полями: severity, affected_service, alert_link.
- Automation Rules для автоматичного призначення черговому (через on-call ротацію JSM) та переходу статусів залежно від priority.
Приклад Automation Rule: при створенні issue з типом запиту «Monitoring Alert» і пріорітетом Critical — призначити черговому через on-call ротацію та перевести в статус «In Progress».
Вибір методу залежить від потреб: webhook підходить для повної кастомізації, Grafana OnCall — для швидкого впровадження, прямий конектор — для простих сценаріїв.
Порівняння методів впровадження
| Метод | Швидкість впровадження | Гнучкість |
|---|---|---|
| Webhook-сервіс | 2-3 дні | Висока |
| Grafana OnCall | 1-2 дні | Середня |
| Прямий конектор | 1 день | Низька |
Що входить в роботу
Впровадження автоматизації під ключ включає:
- Аудит поточної схеми моніторингу та ITSM-процесів.
- Вибір методу інтеграції з обґрунтуванням.
- Налаштування webhook/конектора з дедуплікацією та маппінгом полів.
- Тестування повного циклу: від алерту до закриття тікета.
- Документацію конфігурації та інструкції для чергових інженерів.
- Пост-релізну підтримку протягом 2 тижнів.
Процес роботи та терміни
Починаємо з узгодження: проект, issue type, кастомні поля, SLA-політики. Це займає 1 день. Технічна реалізація — від 1 до 2 днів, включаючи деплой і тестування. Терміни — від 2 до 3 днів. Вартість розраховується індивідуально, залежить від складності скоупу. Оцінимо ваш проект — напишіть нам.
Чому це вигідно?
Автоматизація створення інцидентів з моніторингу економить до 10 годин на тиждень черговому інженеру та знижує MTTR на 50% (реальні цифри з одного з впроваджень). Середня економія бюджету на інциденти становить 40% після впровадження — це до 5000 доларів на місяць при типових витратах. Вартість самого впровадження — від 2000 доларів. Гарантуємо якість: всі конфігурації ми тестуємо на тестовому стенді перед деплоєм у прод.
Щоб уникнути ручного створення тікетів, зв'яжіться з нами для впровадження автоматизації. Замовте інтеграцію вже сьогодні за 2-3 дні — ваші алерти перетворюватимуться на інциденти без затримок.
