Система активного моніторингу мережі, з відображенням показників у реальному часі



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

Ключові слова: Клієнт-серверна архітектура, моніторинг, SignalR, реактивне відображення

Activenetwork system monitoring with indicators display in real time

Vovk Yevgeniy Andriyovych (Student "ACTS" NTUU "KPI")

Mart Bohdan Anatoliyovych (Postgraduate "ACTS" NTUU "KPI")

Kyiv, Ukraine

During the development of the monitoring and management of IT infrastructure raises task to timely alert administrator on changes of the state of target and about criticalsituations of the system in real time. Study describes main mechanisms oftimely delivery of data to the web interface. We consider a distributed monitoring system based on the agent approach, which optimizes network traffic usage by sending information to the central server not continuously, but only when it is needed to the user, or when the internal buffer is full. Agent uses different modes, for regular collection of metrics of target machine, preserving information in a local buffer and packet sending and real-time model, which foresees more frequent surveys, and immediate delivery of allchanges. To ensure timely and reliable data sending we are using Enterprise service buss technology, and Web sockets library.

Keywords: REAL TIME, SIGNAL-R, MONITORING, CLIENT SEVER ARCHITECTURE

Вступ

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

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

Для управління корпоративними ІТ-інфраструктурами використовуються універсальні фірмові або розроблені власні, адаптовані під потреби підприємства, системи управління ІТ-інфраструктурою (СУІ) [2]. СУІ повинні виконувати такі функції: відстеження основних показників функціонування обладнання; відстеження стану запущених процесів та сервісів; агрегація даних моніторингу; збереження історії зміни параметрів до БД; відображення інформації про зміни параметрів роботи ІТ-інфраструктури у вигляді часових діаграм та графіків із можливостями масштабування та вибору часових проміжків; аналіз та оцінка станів параметрів; інформування відповідальних осіб при перевищенні якимось значенням певного порогу; автоматичне формування реакції на зміни станів параметрів із метою забезпечення певного рівня сервісу; відправка команд віддаленого управління на підконтрольне обладнання. Проте в будь-якому разі стійкість ІТ-інфраструктури і всієї організації залежить від своєчасного отримання показників із кожної робочої станції, наприклад для сервера баз даних, на якому активно йде запис; одним із найважливіших факторів є вільне місце на накопичувачі, і в години найактивнішого використання оператор повинен отримувати поточні показники в реальному часі.

Розроблено модуль оповіщення в реальному часі для СУІ. СУІ базується на клієнт-серверній архітектурі з використанням шини даних (ESB – enterprise service bus) і бази даних для накопичення та зберігання інформації [3]. Основні компоненти СУІ: серверний компонент, що включає базу даних, сервіс для збереження інформації, веб-подання для управління системою; шина даних; агенти.

У базі даних можна виділити ключові таблиці (рис 1).

Таблиця ОММТуpes містить опис типів об’єктів моніторингу, таких як обладнання, сервіси, сервери. Кожний ОММТуpe містить від 1 до N параметрів/метрик (OMMParameters). У таблиці ОММs містяться конкретні сутності об’єктів моніторингу. Історія зміни метрик зберігається в таблиці з композитним ключем (за рахунок чого досягається фізичне сортування рядків БД за об’єктом, типом метрики та датою) OMMParameterValues.

Рисунок 1. ER-Діаграма сутностей моніторингу

Таблиця агентів указує на межу розподілу об’єктів моніторингу між агентами, окрім того, кожен ОМУ містить посилання на його агент, це дозволяє визначати потрібний ОМУ, коли приходить пакет даних з агенту, та визначати відповідний агент по ОМУ з користувацького інтерфейсу.

Серверний компонент розмежований на дві частини, сервіс, як служба ОС «Windows» отримує дані моніторингу з шини даних та зберігає їх до бази даних. Завдякиви користанню шини даних є можливість прозоро розподілити сервіси на різних фізичних машинах, і вся робота з балансування пакетів лягає на сервісну шину [3]. Оскільки шина даних являє собою чергу, яка накопичує пакети з даними моніторингу від усіх агентів, – проблемою такого опрацювання даних є забезпечення синхронізації операцій вставки та оновлення даних, – цю проблему вирішено використанням засобу синхронізації потоків на рівні бази даних завдяки застосуванню службової процедури «sp_getapplock», що дозволяє блокувати одночасну зміну данихіз розподілених у просторі екземплярів сервісу.

Компонент веб-подання для управління ІТ-інфраструктурою. Даний компонент відповідає за взаємодію з оператором і реалізує відображення даних моніторингу та інтерфейс управління агентами.

Модуль міжкомпонентної взаємодії відповідає таким вимогам:

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

З урахуванням вищеперерахованих пунктів було вирішено використовувати шину даних Apache ActiveMQ – через найвищий показник швидкості та легкості впровадження.

Важливим компонентом загальної архітектури є агент [2]. Даний компонент реалізовано за принципом тонкого клієнта, що вміє виконувати команди, надіслані з сервера, та план моніторингу, що включає в себе набір об’єктів моніторингу машини, на якій знаходиться агент, та відправку даних на сервер через вказаний у налаштуваннях інтервал часу. Також агент можна запускати як сервіс чи як звичайний процес.

На агенті реалізовано механізм виконання команд, що отримують або певну кількість параметрів, або жодного, і повертають результат увигляді JSON-об’єкта. Цей механізм уніфікований і розширюваний, оскільки кількість зареєстрованих команд у системі є динамічно змінюваною величиною, що дає можливість додавати нові функції без зміни всієї системи. Його було спроектовано для виконання віддалених команд, наданих адміністратором, але універсальність даного механізму дозволила використовувати функції для здійснення активного моніторингу, і вважати повернений об’єкт поточним станом відповідного компоненту машини, на яку інстальовано агент. У агенті виділяють такі групи команд:

1) реального часу, такі як запуск та відключення механізму оповіщення;

2) для роботи з файловою системою створення / видалення файлів;

3) для роботи з процесами запуску / завершення;

4) моніторингу – здійснюють активний моніторинг різних показників;

системна – заміна та отримання конфігурації агенту.

При штатній роботі агент здійснює активний моніторинг, періодично опитуючи команди/функції, згідно з «планом моніторингу», який конфігурується адміністратором; зберігає результати в локальну базу даних, і дані, що змінилися з моменту останнього відправлення, через задані в конфігурації інтервали часу надсилає на сервер із допомогою сервісної шини (рис. 2).

Рисунок 2. Відправлення даних моніторингу

У разі, якщо адміністраторові потрібно віддалено виконати будь-яку з доступних команд, необхідно, використовуючи веб-подання, вибрати агент і команду, після чого система оповістить агент через шину даних, агент виконає команду і поверне результат її виконання (рис. 3).

Рисунок 3. Виконання команди

У разі, коли стан системи чи її компонентів динамічно змінюється, адміністраторові необхідно бачити поточні зміни в реальному часі.

При використанні вищезгаданих механізмів, з урахуванням того, що агент відсилає інформацію не відразу, а поміщаючи її впевний буфер (із метою оптимізації мережевого трафіку), адміністратор зможе бачити інформацію про поточний об’єкт із затримками в розмірі періоду відправки даних моніторингу. Окрім того, йому буде необхідно здійснювати повторний запит до бази даних (рис. 4), що створить додаткові затримки, оскільки веб-інтерфейс базується на протоколі HTTP, який після повернення даних на бік клієнта розриває з’єднання. Для динамічного оповіщення веб-клієнтів прийнято використовувати технології WebSocket, Server Sent Events, Forever Frame та Ajaxlong polling. Це дозволяє оповіщувати адміністратора з мінімальними затрата мичасу. Також необхідно реалізувати на агентському боці механізм, який відсилатиме дані частіше, коли користувач переглядає даний об’єкт.

Рисунок 4. Отримання даних моніторингу

Однією з найпопулярніших наявних бібліотек для роботи з оповіщенням веб-клієнтів є SignalR. Самостійна реалізація користувачем аналогічного алгоритму має ряд мінусів:

  • Розробка модуля, який буде кращим чи принаймні аналогічним, – завдання ресурсозатратне.
  • Проблемою є реалізація логіки визначення інтерфейсу підключення, оскільки SignalR із доступного набору алгоритмів підтримує найшвидший, що підтримується серверною та клієнтською ОС, а також браузером.
  • Розширення поточного компоненту можливе завдяки незалежності реалізації бібліотеки SignalR від інших компонентів.

Із врахуванням вищенаведених пунктів було вирішено інтегрувати SignalR як бібліотеку для роботи з оповіщеннями в реальному часі. Розглянемо її роботу. В ній виділяються три ключові компоненти: Hub, ядро SignalR, клієнтські JavaScript-обробники повідомлень (перший і останній необхідно визначити користувачеві, а ядро надає як серверний, так і клієнтський функціонал).

Hub являє собою клас мови C#, що надає набір базових подій, таких як підключення клієнта, додавання поточного ідентифікатора підключення до колекції наявних підключень та вибору поточного типу взаємодії з результуючим клієнтом залежно від підтримки способів комунікації, розсилку групових повідомлень, дана бібліотека підтримує створення так званої групи, що містить у собі список підключень. Відключення поточного користувача (видалення поточного connectionId зі списку клієнтів), повторного підключення поточного користувача: обробка події, яка виникає, коли відключений користувач спробує повторно підключитись.

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

  • WebSocket
  • ServerSent Events
  • ForeverFrame
  • Ajax long polling

Веб-сокети – найбільш нова та оптимізована технологія, що базується на створенні повнодуплексного зв’язку над HTTP-з’єднанням, проте є обмеження версії ПЗ і ОС: веб-сокети можна використовувати лише при версії серверної ОС більшій чи рівній за WindowsServer 2012 та встановленій на платформі .Net, версія якого є більшою або рівною 4,5. За відсутності можливості встановити з’єднання через веб-сокети, бібліотека SignalR намагається встановити з’єднання з використанням ServerSent Events, що є обгорткою над механізмом, що реалізує JS API і надає серверу можливість відправляти події у вигляді DOM-об’єктів. Наступний спосіб комунікації (ForeverFrame) використовується лише в Internet Explorer, де обмін повідомленнями реалізовано через створення прихованого Iframe-компоненту, в результаті чого ігноруються тайм-аути щодо відключення поточного користувача і життєвий циклпоточного з’єднання завершується закриттям сторінки. Ajax long polling є реалізацією для старих версій браузерів та реалізує найпростіший спосіб опитування сервера, а саме: відправляє HTTP Get-запит, після чого сервер очікує появи події, адресованої клієнту, та відправляє дані.

Основою роботи SignalRє можливість опрацьовувати події, згенеровані сервером на боці клієнта. Даний механізм працює таким чином: JavaScript-бібліотека SignalR знає про спосіб з’єднання з сервером та працює з ним, програмістові залишається лише визначити свої обробники кожної конкретно взятої події на боці клієнта, які динамічно змінюватимуть вміст сторінки залежно від отриманих даних.

На боці сервера знаходиться Hub, що інкапсулює логіку підключення/відключення та оповіщення оператора в реальному часі.

Рисунок 5. Оповіщення в реальному часі

При переході на сторінку сутностей конкретного об’єкта моніторингу веб-переглядач повідомляє про це Hub, який усвою чергу через сервісну шину передає агенту команду на виконання, а саме відправлення даних моніторингу в реальному часі, за вказаними параметрами генеруються відповідні команди моніторингу (рис. 5). Варто зазначити, що інтеграція механізму реального часу є ресурсозатратною операцією, через що важливо перевіряти необхідність використання даного оповіщення, яка присутня лише у разі, коли користувач переглядає той чи інший параметр, звідки витікає, що після того, як користувач залишив поточну сторінку чи перейшов на іншу ОМУ, пакети з даними моніторингу відправляти не потрібно. З огляду на вищесказане було введено такі обмеження:

  1. Агент відправляє інформацію моніторингу покомандно залежно від типу ОМУ;

  2. На сервері реалізовано групи користувачів, кожній «групі» відповідає один, конкретний, об’єкт моніторингу, під час підписки на отримання даних моніторингу в реальному часі користувач додається до групи, щоб однією відправкою даних оповіщати користувачів, які переглядають поточну інформацію.

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

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

Перелік посилань

  1. Ролик А.И. Концепция управления корпоративной ИТ-инфраструктурой / А.И. Ролик // Вісник НТУУ «КПІ»: Інформатика, управління та обчислювальна техніка. – К.: «ВЕК+», 2012. – № 56. –С. 31–55.

  2. Ролик А.И. Система управления корпоративной информационно-телекоммуникационной инфраструктурой на основе агентского подхода / А.И. Ролик, А.В. Волошин, Д.А. Галушко, П.Ф.Можаровский, А.А. Покотило // Вісник НТУУ «КПІ»: Інформатика, управління та обчислювальна техніка. – К.: «ВЕК+», 2010. – № 52. – С. 39–52.

  3. Ролік О.І., Автоматизована система моніторингу та управління критичними системами/ О.І.Ролік, д.т.н.; Б.А. Март, М.Д. Литвиненко, Є.А. Вовк // ХII міжнароднанаук.-техн. конф. «АВІА-2015», 28–29 квітня 2015 р.. – К.: НАУ. – 2015. – С. 6.86–6.90.

  4. Что такое Long-Polling, WebSockets, SSE и Comet [Електронний ресурс]. – Режим доступу: https://myrusakov.ru/long\-polling\-websockets\-sse\-and\-comet.html (дата звернення 10.05.2016). – Что такоеLong-Polling, WebSockets, SSE и Comet.

  5. SignalR TransportsExplained [Електронний ресурс]. – Режим доступу: http://kevgriffin.com/signalr\-transports\-explained/ (дата звернення 10.05.2016). – SignalR TransportsExplained.

  6. Understanding andHandling Connection Lifetime Events in SignalR [Електронний ресурс]. – Режимдоступу: http://www.asp.net/signalr/overview/guide\-to\-the\-api/handling\-connection\-lifetime\-events (дата звернення 10.05.2016). – SignalR TransportsExplained Understanding and Handling Connection Lifetime Events in SignalR.
May 23, 2016