У вересні Broadcom (колишня CA) випустила нову версію 20.2 свого рішення DX Operations Intelligence (DX OI). На ринку цей продукт позиціонується як парасолькова система моніторингу. Система здатна отримувати та об'єднувати дані від систем моніторингу різних доменів (мережа, інфраструктура, додатки, бази даних) як CA, так і сторонніх виробників, у тому числі open source рішень (Zabbix, Prometheus та інших).

Основна функція DX OI - створення повноцінної ресурсно-сервісної моделі (РСМ) на основі конфігураційних одиниць (КЕ), що наповнюють інвентарну базу при інтеграції зі сторонніми системами. У DX OI реалізовані функції Machine Learning і Artificial Intelligence (ML і AI) над даними, що надходять у платформу, що дозволяє оцінити/спрогнозувати ймовірність відмови конкрентної КЕ і ступінь впливу відмови на бізнес-сервіс, в основі якого лежить конкретна КЕ. Крім того, DX OI є єдиною точкою збору подій моніторингу та, відповідно, інтеграції із системою Service Desk, що є незаперечною перевагою використання системи в єдиних центрах моніторингу черговими змінами організацій. У цій статті ми розповімо докладніше про функціонування системи та покажемо інтерфейси користувача та адміністратора.

Архітектура рішення DX OI

Платформа DX має мікросервісну архітектуру, встановлюється та працює під керуванням Kubernetes або OpenShift. На наступному малюнку наведено компоненти рішення, які можуть використовуватися як самостійні інструменти моніторингу або можуть бути замінені на вже наявні системи моніторингу з подібними функціями (на малюнку є приклади таких систем) і далі підключатися до парасольки DX OI. На схемі нижче:

• Моніторинг мобільних додатків у DX App Experience Analytics;
• Моніторинг продуктивності додатків у DX APM;
• Моніторинг інфраструктури у DX Infrastructure Manager;
• Моніторинг мережевих пристроїв у DX NetOps Manager.

Компоненти DX працюють під керуванням кластера Kubernetes і масштабуються простим запуском нових POD. Нижче є верхньорівнева схема рішення.

Адміністрування, масштабування та оновлення платформи DX виконується в адміністративній консолі. З однієї консолі можна керувати мультитенантною архітектурою, яка може охоплювати кількох підприємств або кількох бізнес-одиниць у рамках компанії. У цій моделі кожне підприємство може бути налаштоване як орендар зі своїм власним набором конфігурацій.

Консоль адміністрування — це веб-інструмент для управління операціями та системою, який надає адміністраторам узгоджений уніфікований інтерфейс для виконання завдань управління кластером моніторингу.

Нові тенанти для бізнес-одиниць чи підприємства у складі компанії розгортаються за лічені хвилини. Це дає перевагу, якщо ви хочете мати єдину систему моніторингу, але при цьому на рівні платформи (а не прав доступу) розмежувати об'єкти моніторингу між підрозділами.

Ресурсно-сервісні моделі та моніторинг бізнес-сервісів

DX OI має вбудовані механізми для створення сервісів та розробки класичних РСМ із завданням логіки впливу та ваги між компонентами сервісу. Також є механізми експорту РСМ із зовнішньої CMDB. На малюнку нижче вбудований редактор РСМ (зверніть увагу на ваги зв'язків).

DX OI дає цілісну картину ключових показників функціонування бізнес-послуг або ІТ-послуг із деталізацією, включаючи доступність сервісів та прогнозування ризиків відмови. Інструмент також може дати розуміння впливу проблеми продуктивності або зміни структури IT-компонентів (додатки чи інфраструктури) на бізнес-сервіс. На малюнку нижче інтерактивний дашборд, що відображає стан усіх сервісів.

Розглянемо подробиці з прикладу сервісу Digital Banking. За назвою сервісу переходимо в детальну РСМ сервісу. Бачимо, що статус сервісу Digital Banking залежить від стану інфраструктурних та транзакційних підсервісів із різними вагами. Робота з вагами та їх відображення – цікава перевага DX OI.

Топологія — важливий елемент оперативного моніторингу підприємства, що дозволяє операторам та інженерам аналізувати взаємозв'язки між компонентами, знаходити першопричину та вплив.

DX OI Topology Viewer - це сервіс, який використовує в роботі топологічні дані, що надходять від доменних систем моніторингу, які здійснюють збирання даних безпосередньо з об'єктів моніторингу. Інструмент призначений для пошуку в кількох шарах сховищ топології та відображення карти відносин, що залежить від контексту. Для розслідування проблем можна перейти до проблемного підсервісу Backend Banking та побачити топологію та проблемні компоненти. Також по кожному компоненту можна аналізувати аварійні повідомлення та метрики продуктивності.

При аналізі транзакційних компонентів Payments (користувацьких транзакцій) можемо відслідковувати значення бізнес-KPI, які також враховуються при розрахунку статусу доступності та здоров'я сервісу. Приклад бізнес-KPI наведений нижче:

Подієва аналітика (Alarm Analytics)

Алгоритмічне шумозаглушення за рахунок кластеризації аварій

Одна з ключових функцій DX OI під час обробки подій - кластеризація. Механізм працює над усіма оповіщеннями, що надходять до системи, щоб ідентифікувати шаблони на основі різних контекстів та об'єднувати їх у групи. Ці кластери є самонавчальними, їх потрібно конфігурувати вручну.

Таким чином, кластеризація дозволяє користувачам об'єднувати та групувати величезну кількість подій та аналізувати лише ті, які мають загальний контекст. Наприклад, набір подій, що становлять інцидент, що впливає на роботу додатків або центру обробки даних. Ситуації створюються з використанням алгоритмів кластеризації на основі машинного навчання, що використовують для аналізу тимчасову кореляцію, топологічний взаємозв'язок та обробку природної мови (native language). Нижче наведено приклади візуалізації кластерних груп повідомлень, так звані Situations Alarms, і Evidence Timeline, що відображають основні параметри угруповання та процес зменшення кількості шумових подій.

Аналіз кореневих проблем та кореляція аварій

У сучасному гібридному середовищі транзакція користувача може зачіпати кілька систем, які використовуються динамічно. В результаті може бути створено кілька попереджень з різних систем, але пов'язаних з однією проблемою або інцидентом. DX OI використовує запатентовані механізми для придушення надлишкових та дублюючих оповіщень та кореляції пов'язаних сповіщень для покращення виявлення критичних проблем та більш швидкого вирішення.

Розберемо приклад, коли у систему надходять численні аварійні повідомлення з різних об'єктів (КЕ), які у основі одного сервісу. У разі на доступність і працездатність сервісу система згенерує сервісну аварію (Service Alarm), вкаже і позначить ймовірну кореневу причину (проблемний КЕ і аварійне повідомлення КЕ), що сприяло зниженню продуктивності чи відмову сервісу. На малюнку нижче наведено візуалізацію аварійної ситуації для сервісу Webex.

DX OI дозволяє працювати з подіями за допомогою інтуїтивно зрозумілих дій у web-інтерфейсі системи. Користувачі можуть вручну призначати події на відповідального співробітника для усунення несправностей, скидати/підтверджувати оповіщення, створювати заявки або надсилати повідомлення електронною поштою, запускати автоматизовані сценарії для усунення аварійної ситуації (Remediation Workflow, трохи пізніше). Таким чином, DX OI дозволяє операторам чергових змін зосередитись на кореневому аварійному повідомленні, а також допомогти спростити процес сортування повідомлень на кластерні масиви.

Машинні алгоритми обробки метрик та аналіз даних щодо продуктивності

Машинне навчання дозволяє відстежувати, агрегувати та візуалізувати ключові показники продуктивності за будь-який конкретний період часу, що дає користувачеві наступні переваги:

• Виявлення вузьких місць та аномалій продуктивності;
• Порівняння кілька показників для тих самих пристроїв, інтерфейсів чи мереж;
• Порівняння однакових показників на кількох об'єктах;
• Порівняння різних показників по одному та декільком об'єктам;
• Порівняння багатовимірних метрик за кількома об'єктами.

Для аналізу метрик DX OI, що надходять до системи, використовує функції машинної аналітики із застосуванням математичних алгоритмів, що сприяє скороченню часу при налаштуванні статичних порогів і генерації попереджень при виникненні аномалій.

Результатом застосування математичних алгоритмів є побудова про ймовірнісних розподілів значення метрики (Rare, Probable, Center, Mean, Actual). На рисунках вище та нижче представлені імовірнісні розподіли.

На двох графіках вище відображено такі дані:

• Фактичні дані (Actual). Фактичні дані відображаються на графіку як суцільна чорна лінія (немає сигналів тривоги) або кольорова суцільна лінія (стан тривоги). Лінія розраховується з урахуванням фактичних даних для метрики. Порівнюючи фактичні дані та медіа значення, ви можете швидко побачити варіації метрики. Коли виникає подія, чорна лінія змінюється на кольорову суцільну лінію, що відповідає критичності події та відображає значки з відповідною критичністю над графіком. Наприклад, червоний колір для критичної аномалії, помаранчевий для значної аномалії та жовтий для незначної аномалії.
• Середнє значення показника (Mean value). Середнє значення або середнє значення показника показано на діаграмі сірої лінією. Середнє значення відображається, коли бракує історичних даних.
• Медіанний значення показника (Center value). Медіанна лінія є серединою діапазону та показана зеленою пунктирною лінією. Зони, найближчі цієї лінії, найбільш близькі до типових значень показника.
• Загальні дані (Common Value). Дані загальної зони відстежують найближчу до центральної лінії або норму для вашого показника та відображаються у вигляді темно-зеленої смуги. Аналітичні розрахунки поміщають загальну зону на один процент вище або нижче норми.
• Імовірнісні дані. Дані імовірнісної зони показані на графіку зеленою смугою. Система поміщає ймовірнісну зону на два відсотки вище або нижче за норму.
• Рідкісні дані. Дані про рідкісні зони показані на графіку у вигляді світло-зеленої смуги. Система містить зону з рідкісними значеннями метрики на три відсотки вище або нижче норми і сигналізує про поведінку показника за межами нормального діапазону при цьому система генерує так званий Anomaly Alert.

Аномалія — це вимір чи подія, несумісний із нормальними показниками метрики. Виявлення аномалій для виявлення проблем та розуміння тенденцій в інфраструктурі та додатках – ключова особливість DX OI. Виявлення аномалій дозволяє як розпізнавати незвичайну поведінку (наприклад, сервер, який відповідає повільніше, ніж зазвичай, або незвичайну мережну активність, викликану зломом), так і реагувати відповідним чином (заклад інциденту, запуск автоматичного сценарію Remediation).

Функція виявлення аномалій DX OI надає такі переваги:

• Не потрібно встановлювати граничні значення. DX OI самостійно зіставить дані та виявить аномалії.
• DX OI включає понад десять алгоритмів штучного інтелекту та машинного навчання, у тому числі EWMA (Exponentially-Weighted-Moving-Average) та KDE (Kernel Density Estimation). Ці алгоритми дозволяють виконувати швидкий аналіз причин і прогнозувати майбутні значення метрик.

Предиктивна аналітика та оповіщення про можливі відмови

Predictive Insights — функція, яка використовує можливості машинного навчання виявлення закономірностей і тенденцій. На основі цих тенденцій система прогнозує події, які можуть статися у майбутньому. Дані повідомлення вказують на необхідність прийняття дій до того, коли значення метрик вийдуть за межі нормальних значень, що вплине на критично важливі бізнес-сервіси. Predictive Insights зображені нижче.

А це візуалізація передиктивних попереджень для конкретної метрики.

Прогнозування завантаження обчислювальних потужностей із функцією завдання сценаріїв навантаження

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

Функція Capacity Analytics у DX OI дає такі переваги:

• Прогнозування потужностей у пікові сезони;
• Визначення моменту, коли будуть потрібні додаткові ресурси для забезпечення якісного функціонування сервісу;
• Закупівля додаткових ресурсів лише за необхідності;
• Ефективне управління інфраструктурою та мережами;
• Усунення зайвих витрат за електроенергію з допомогою виявлення недовикористовуваних ресурсів;
• Виконує оцінку навантаження на ресурси у разі запланованого збільшення потреб у сервісі або ресурсі.

На сторінці Capacity Analytics DX OI (рисунок нижче) є наступні віджети:

• Стан ємності ресурсу (Resource Capacity Status);
• Контрольовані групи/служби (Monitored Groups/Services);
• Великі споживачі ресурсів (Top Capacity Consumers).

Основна сторінка Capacity Analytics показує компоненти ресурсів, які надмірно завантажені та закінчуються ємністю. Ця сторінка допомагає адміністраторам платформи знаходити надмірно використовувані ресурси та допомагає їм змінювати розмір та оптимізувати ресурси. Стан ресурсів можна проаналізувати на основі колірних кодів та їх відповідних значень. Ресурси класифікуються залежно від ступеня їхньої перевантаженості на сторінці стану ємності ресурсів. Щоб переглянути список компонентів, які входять до вибраної категорії, можна клацнути на кожен із кольорів. Далі відобразиться теплова карта з усіма об'єктами та прогнозами на 12 місяців, що дозволяє виявити ресурси, які ось-ось будуть вичерпані.

Для кожної з метрик Capacity Analytics можна вказати фільтри, які DX Operational Intelligence використовує для складання прогнозів (рисунок нижче).

Доступні такі фільтри:

• Метричні. Метрика, яка використовуватиметься для прогнозу.
• Base on. Вибирає обсяг історичних даних, які будуть використані для побудови прогнозів на майбутнє. Це поле використовується для порівняння та аналізу тенденцій за останній місяць, тенденцій за останні 3 місяці, тенденцій за рік тощо.
• Зростання. Очікувана швидкість зростання робочого навантаження, яке хочете використовуватиме моделювання прогнозу потужності. Ці дані можна використовуватиме прогнозування зростання понад прогнозів. Наприклад, очікується, що використання ресурсу зросте ще на 40 відсотків через відкриття нового офісу.

Аналіз логів

Функція аналізу логів DX OI забезпечує:

• збір, агрегацію логів із різних джерел (у тому числі отриманих агентським та безагентським способами);
• парсинг та нормалізацію даних;
• аналіз на відповідність поставленим умовам та генерацію подій;
• кореляцію подій на основі логів, у тому числі з подіями, отриманими внаслідок моніторингу ІТ-інфраструктури;
• візуалізацію даних на основі аналізу у DX Dashboards;
• висновки про доступність сервісів на основі аналізу даних із логів.

Збір логів безагентним методом виконується системою Windows Event logs і Syslog. Агентним способом збираються текстові логі.

Функція автоматизованого вирішення аварійних ситуацій (Remediation)

Автоматизовані дії з виправлення аварійної ситуації (Remediation Workflow) дозволяють вирішити проблеми, що спричинили генерацію події в DX OI. Наприклад, проблема завантаження ЦП генерує аварійне повідомлення, процес виправлення (Remediation Workflow) вирішує проблему шляхом перезапуску сервера, де виникла проблема. Інтеграція між DX OI та системою автоматизації дозволяє запускати процеси виправлення з консолі подій у DX Operational Intelligence та відстежувати їх у консолі системи автоматизації.

Після інтеграції з системою автоматизації можна запускати автоматичні дії щодо виправлення будь-якої аварійної ситуації в консолі DX OI з контексту аварійного повідомлення. Ви можете переглянути рекомендовані дії разом із інформацією про відсотки достовірності (імовірність усунення ситуації шляхом виконання дії).

Спочатку, коли відсутня статистика за результатами виконання Remediation Workflow, механізм рекомендацій пропонує потенційні варіанти на основі пошуку, за ключовими словами, потім використовуються результати машинного навчання і механізм починає рекомендувати методику виправлення на основі евристики. Як тільки ви почнете оцінювати результати отриманих підказок, точність рекомендацій покращиться.

Приклад зворотного зв'язку від користувача: користувач вибирає запропоновану дію, що сподобалася або не сподобалася, а система враховує цей вибір при подальших рекомендаціях. Лайк/дизлайк:

Рекомендовані дії для конкретної тривоги засновані на комбінації зворотного зв'язку, яка визначає, чи є дія прийнятною. DX OI поставляється з готовою інтеграцією із системою автоматизації Automic Automation.

Інтеграція DX OI із сторонніми системами

Докладно зупинятися на інтеграції даних з нативних продуктів моніторингу Broadcom (DX NetOps, DX Infrastructure Management, DX Application Performance Management) ми не будемо. Натомість розглянемо як інтегруються дані зі сторонніх 3rd-party систем і розберемо приклад інтеграції з однією з найпопулярніших систем Zabbix.

Для інтеграції зі сторонніми системами використовується компонент DX Gateway. DX Gateway складається з 3 компонентів – On-Prem Gateway, RESTmon та Log Collector (Logstash). Ви можете встановити всі 3 компоненти або тільки той, який потрібен, змінивши загальний конфігураційний файл при установці DX Gateway. На малюнку нижче є архітектура DX Gateway.

Розглянемо призначення компонентів DX Gateway окремо.

On-Prem Gateway. Це інтерфейс, який збирає аварійні сигнали від платформи DX та відправляє події про аварії у сторонні системи. On-Prem Gateway діє як поллер, який періодично збирає дані про події з DX OI, використовуючи API запитів за протоколом HTTPS, потім надсилає попередження на сторонній сервер, інтегрований з платформою DX, використовуючи вебхуки.

DX Log Collector приймає syslog від мережевих пристроїв чи серверів і завантажує в OI. DX Log Collector дозволяє розділити програмне забезпечення, яке генерує повідомлення, систему, яка їх зберігає, та програмне забезпечення, яке повідомляє та аналізує їх. Кожне повідомлення позначається кодом об'єкта, що вказує тип програмного забезпечення, що генерує повідомлення, і призначається рівень критичності. У DX Dashboards це все потім можна побачити.

DX RESTmon інтегрується зі сторонніми продуктами/послугами через API REST і передає дані в OI. На малюнку нижче представлена ​​схема функціонування DX RESTmon на прикладі інтеграції із системами моніторингу Solarwinds та SCOM.

Ключові функції DX RESTmon:

• Підключення до будь-якого стороннього джерела даних для прийому даних:
  • PULL: підключення та вилучення даних із загальнодоступних REST API;
  • PUSH: потік даних у RESTmon через REST.
• Підтримка форматів JSON та XML;
• Прийом метрик, попереджень, груп, топології, інвентаризації та журналів;
• Готові конектори для різних інструментів/технологій, також можна розробити конектор до будь-якого джерела з відкритим API (список коробочних конекторів на малюнку нижче);
• Підтримка базової автентифікації (за замовчуванням) доступу до інтерфейсу Swagger і API;
• Підтримка HTTPS (за замовчуванням) для всіх вхідних та вихідних повідомлень;
• Підтримка вхідних та вихідних проксі;
• Потужні можливості синтаксичного аналізу тексту журналів, отриманих через REST;
• Налаштований синтаксичний аналіз за допомогою RESTmon, що забезпечує ефективний аналіз та візуалізацію журналів;
• Підтримка вилучення інформації про групи пристроїв з програм моніторингу та завантаження в OI для аналізу та візуалізації;
• Підтримка можливості зіставлення з регулярними виразами. Це може бути використане для синтаксичного аналізу та зіставлення повідомлень логів, отриманих через REST, а також для генерації або закриття подій на основі певних умов регулярного вираження.

Тепер розглянемо процес налаштування інтеграції DX OI із Zabbix через DX RESTmon. Коробна інтеграція забирає з Zabbix такі дані:

• інвентарні дані;
• топологія;
• проблеми;
• метрики.

Оскільки конектор для Zabbix доступний з коробки, все, що потрібно зробити для налаштування інтеграції – це оновити профайл, вказавши IP адресу API сервера Zabbix та обліковий запис, а потім завантажити профайл через web-інтерфейс Swagger. Приклад на наступних двох малюнках.

Після налаштування інтеграції, для даних, що надходять з Zabbix, будуть доступні аналітичні функції DX OI, описані вище, а саме: Alarm Analytics, Performance Analytics, Predictive Insights, Service Analytics і Remediation. Нижче наведено приклад аналізу метрик продуктивності по об'єктах, інтегрованих із Zabbix.

Висновок

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

Якщо ви хочете дізнатися більше про це рішення, залиште заявку на демонстрацію чи пілотний проект зручним для вас способом на нашому сайті.

Джерело: habr.com