Статті

Система моніторингу з відправкою оповіщень про інциденти в Jira

Приймаючи рішення про створення системи моніторингу ІТ-інфраструктури, потрібно визначити завдання, які вона буде виконувати. Система моніторингу повинна контролювати процеси й додатки, якість виконання бізнес-процесів організації, генерувати звіти, виявляти та попереджувати інциденти інформаційної безпеки, при необхідності керувати конфігурацією інформаційної системи.

Для чого потрібен моніторинг


Моніторинг та оповіщення дозволяють інформаційній системі розповісти, коли вона зламалася, або ось-ось щось піде не так.

  • Аналіз тривалих трендів: Наскільки велика база даних і як швидко вона росте? Як змінюється щоденна кількість користувачів?
  • Порівняння швидкодії: Наскільки краще кешуються запити після появи додаткової ноди? Чи став повільніше працювати сайт в порівнянні з минулим тижнем?
  • Оповіщення: Щось зламалося і хтось повинен це полагодити. Або щось скоро зламається, і хтось повинен це перевірити.
  • Дашборди: інформаційні панелі повинні включати щось з «4 золотих сигналів» моніторингу - затримки (latency), трафік (traffic), помилки (errors) і величину навантаження (saturation).
  • Ретроспективний аналіз: Затримка обробки запиту збільшилася, а що ще трапилося приблизно в цей же час?

Найпростіше рішення - найвірніше


Моніторинг може ускладнитися настільки, що стане крихким, складним для змін і обслуговування. Вибираючи, що потрібно відстежувати, слід пам'ятати наступне:

  • Правила, які формують "інцидент", повинні бути простими, передбачуваними і надійними.
  • Конфігураціі для збору даних, які рідко виконуються (наприклад, менше ніж раз на квартал), повинні бути вилучені.
  • Метрики, які збираються, але не використовуються є кандидатами на видалення.

Завдяки рішенням від Atlassian® команди можуть швидко реагувати на інциденти і так само швидко надавати відмінні послуги підтримки клієнтам і співробітникам.

Сценарій формування запитів в Jira


Присутні два основних типи запиту Incident і Problem, формуються вони в такий спосіб:

  • Система моніторингу при спрацьовуванні правила збирає актуальну інформацію про інцидент.
  • Зібрана інформація відправляється POST запитом в плагін Alert Cаtcher.
  • Alert Cаtcher формує запит (тікет в Jira) та привласнює інциденту пріоритет згідно важливості.
  • Alert Catcher призначає виконавця відповідно до виставлених правил.
  • JIra на підставі отриманої інформації змінює статус об'єкта CMDB.
  • Якщо інцидент вирішується «сам по собі» система моніторингу відправляє PUT запит із зібраною актуальною інформацією.
  • Alert Catcher отримує PUT запит, оновлює інформацію в сформованому інциденту і закриває його.

Інцидент має такий робочий процес: To Do, In Progress, Freez, Done. Статус Freez використовується при «заморожуванні» інциденту на невизначений час, при цьому обов'язково заповнюється коментар чому інцидент перейшов в даний статус.

Проблема має стандартний робочий процес: To Do, In Progress, Done.


Готові поліпшити свій ITSM?


Шлях до здорового моніторингу та оповіщень повинен бути простий і зрозумілий. Основна увага приділяється симптомам проблеми, за якими виконуються моніторинг, причини служать допоміжним засобом для визначення проблеми.

Повідомлення через електронну пошту мають дуже обмежену користь і легко переростають в інформаційний шум. Замість цього краще використовувати панель моніторингу для керування всіми поточними IT-інцидентами і оповіщеннями. Прикладом такого рішення є плагін Alert Catcher для Jira, який дозволяє консолідувати оповіщення, що надходять від критично важливих систем (SIEM/EMS: McAfee, Zabbix, Paessler PRTG та ін.). Інформацію про всі інциденти, збої та сповіщення можна налаштувати на основі гнучких правил, при цьому ескалаціі створють запити в службу підтримки Jira Software або Jira Service Management (Service Desk).
ITSM