Малодокументированные особливості IBM Tivoli Monitoring

Я займаюся впровадженням продуктів моніторингу від компанії IBM і мені стало цікаво, чого досяг open source в порівнянні з рішеннями від IBM у напрямку моніторингу заліза і програмного забезпечення. Для чого я став встановлювати найбільш популярні системи моніторингу з світу open source і читати документацію. Мене в основному цікавили архітектура рішень. В моє поле зору потрапили такі open source продукти: Zabbix, Nagios, NetXMS. Я вважав їх найбільш популярними і часто згадуються. Всі їх можна порівняти з IBM Tivoli Monitoring (ITM). ITM це ядро сервісів моніторингу від IBM. В результаті вирішив описати не документовану архітектуру ITM продукту, яка і є перевагою у великих інсталяціях.

Варто згадано, що ITM не єдиний продукт такого функціоналу у IBM на сьогоднішній день. Нещодавно з'явився продукт під назвою IBM Application Performance Management, але про його архітектуру в інший раз.

В увазі особливості ITM не рекомендується його використовувати для моніторингу великого числа мережевого обладнання. Бувають всякі незвичайні ситуації, але зазвичай для цього застосовують IBM Tivoli Network Manager.

Згадаю про zabbix. Я часто зустрічав у замовників і багато чув. Один раз мене замовник сильно вразив вимогами отримувати дані з агента кожні 10 секунд. Він же був сильно розчарований, що в ITM не можна створити тригери по середньому за період (якщо на спір, то можна накрутити милиць, але навіщо?). Він був знайомий з zabbix.

В zabbix (схожа ситуація і з NetXMS) тригери аналізують історичні дані. Це дуже круто, але у мене ніколи такої потрібні не виникало. Агент zabbix передає дані серверу (або через zabbix проксі). Дані зберігаються в базі даних. Після чого за ним відпрацьовують тригери, а потужна система макросів їм допомагає. Звідси з'являються вимоги до продуктивності заліза для виконання основного функціоналу.


В ITM свої особливості. Сервер ITM всі дані отримує виключно від агентів. Ніяких вбудованих протоколів SNMP і т. п. Сервер являє собою багатопотокове додаток з вбудованою базою даних. Особливість ITM в роботі тригерів (вони ж ситуації, але для дотримання загальної термінології буду назвати тригери). Тригери виконуються на агенті. В добавок ці тригери являють собою sql-запити з умовою. Сервер компілює тригери в бінарний sql-код і віддає агенту на виконання. Архітектура агента така, що він схожий на базу даних.

Всілякі метрики вже вбудовані в агент (відносно недавно додали можливість отримання даних від програм/скриптів) і описані як таблички в реляційній базі даних. Агент виконує sql запит згідно заданого інтервалу. Прошарок, яку дилетантськи назву «база даних», виконує необхідні запити до операційної системи(ОС) і кладе дані вигляді таблиці. Частота запитів до ОС не частіше 30 сек. Тобто дані в таблиці частіше 30 сек. не оновити. Зрозуміло, що агент може виконувати безліч одноманітних тригерів, що не сильно позначиться на завантаженні, оскільки знову-таки частіше 30 сек. дані він збирати не буде. Цікаво ще те, що агент не буде турбувати сервер до тих пір, поки виконується їм sql запит повертає 0 рядків. Як тільки sql запит повернув кілька рядків, всі ці рядки підуть на сервер (умова тригера настав). Сервер у свою чергу, покладе дані в тимчасову таблицю до моменту, поки з нею не пройдеться окремий потік, який перевірить на додаткові умови і згенерує подію в системі. Передбачаючи питання як же агент обробляє події, наприклад логи? Там з цим все нормально, такі дані агент відразу відправляє на сервер в активному режимі.

Звідси висновок. База даних сервера ITM не містить історію, тільки оперативні дані. Тригери виконуються на стороні агента який візьме на себе частину навантаження.

Так само розглядаючи open source я відразу задавався питанням реалізації відмовостійкості. Я не побачив того, чого хотілося б. Оскільки ITM дозволяє реалізувати hot-stanby (гаряче резервування), то хотілося б що-небудь на зразок такого в open source. В ITM це реалізовано досить просто. Два сервери, які реплікують свої бази від активного до пасивного. У налаштуваннях агента вказані обидва сервера. Агенти перемикаються між двома серверами автоматично.


Збір історії в ITM реалізується тими ж тригерами, тільки в системі вони помічені як історичні та налаштовуються окремо. Згідно налаштування історії сервер віддає агенту історичні sql запити на виконання, тільки вони без умови (зразок select * from table). Результатом цих sql є всі дані у таблицях агента. Ці дані складаються в файл. Агент періодично віддає історичні дані спеціальним warehouse proxy агенту, який в свою чергу кладе їх в спеціальну базу даних, яку зазвичай називають Warehouse. Якщо агент втратить зв'язок з сервером або з проксі агентом, то нічого страшного крім зростання файлу історії не статися. Агент віддасть історію проксі як тільки зможе. ITM-сервер на базі warehouse доступу не має, і отже робити тригери поверх історії не вийти.


Мені подобатися open source і доступні рішення мають свої переваги і недоліки. Є якесь почуття, що вибір архітектури був обумовлений де спочатку рішення застосовувалося. Ось ядро ITM народилося в надрах іншої компанії мабуть десь на початку 90-х. Припускаю в ті часи пам'яті було мало, процесора слабкі за сучасними мірками. З цього шукалися складні рішення економії ресурсів.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.