Для чого потрібен моніторинг
Моніторинг та оповіщення дозволяють інформаційній системі розповісти, коли вона зламалася, або ось-ось щось піде не так.
- Аналіз тривалих трендів: Наскільки велика база даних і як швидко вона росте? Як змінюється щоденна кількість користувачів?
- Порівняння швидкодії: Наскільки краще кешуються запити після появи додаткової ноди? Чи став повільніше працювати сайт в порівнянні з минулим тижнем?
- Оповіщення: Щось зламалося і хтось повинен це полагодити. Або щось скоро зламається, і хтось повинен це перевірити.
- Дашборди: інформаційні панелі повинні включати щось з «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).