Привет, Хабрахабр!
Сегодня я расскажу вам об одном из продуктов IBM для мониторинга серверов и приложений. Всегда пристально следил за публикациями по теме мониторинга и по моим ощущениям в последнее время их резко поубавилось. Ну что же, попробую хоть как-то восполнить этот досадный пробел.
Почему именно ITM (IBM Tivoli Monitoring) спросите вы, просто так сложилось, что уже на протяжении нескольких лет я занимаюсь внедрением и настройкой этого продукта и хочу поделиться своими впечатлениями о работе с ним.
![](https://habrastorage.org/r/w1560/storage2/37c/305/98b/37c30598b4b5dec3176ad7094f84e885.png)
Если вам интересно познакомиться с ITM или просто хочется увидеть, что же скрывается за этим таинственным окном, то прошу под хабракат.
Начнем знакомство с архитектуры системы.
Инженеры из IBM не стали изобретать велосипед и пошли проверенным путем.
Архитектура IBM Tivoli Monitoring
![](https://habrastorage.org/r/w1560/storage2/c38/b0d/012/c38b0d012258ce862ede0349489ba833.png)
Не хочу загружать читателей лишними подробностями, поэтому обрисую все крупными мазками. Имеется основной сервер мониторинга TEMS (Tivoli Enterprise Monitoring Server), портальный сервер TEPS (Tivoli Enterprise Portal Server), агенты мониторинга и база данных (DB2, MSSQL, Oracle или встроенная Derby) в которой хранится вся информация.
В работе системы все функционирует как швейцарские часы, по крайней мере, на моей практике не было ни одного случая, чтобы сданная в промышленную эксплуатацию система подводила (может быть, заказчики что-то скрывают?). Агенты собирают информацию и передают ее на сервер мониторинга, затем на сервере мониторинга эта информация анализируется, и при превышении порогов срабатывают ситуации. Пользователю вся эта красота доступна посредством клиента к портальному серверу, который именуется TEP (Tivoli Enterprise Portal) и доступен в десктопной и браузерной версиях.
Интерфейс Tivoli Enterprise Portal
![](https://habrastorage.org/r/w1560/storage2/449/ef8/f2e/449ef8f2ea98fa30102e5efad2eece50.png)
В целом об архитектуре я скажу следующее:
— Хорошая масштабируемость, надежность и удобство распространения/управления агентами из центра
— Обновление системы в некоторых случаях может вывести из себя даже самого спокойного и умиротворенного человека
Далее я хотел бы познакомить вас с основными возможностями ITM.
Совсем не трудно догадаться, что это основная функция любой системы мониторинга. За сбор информации, как я уже говорил, отвечают агенты. В большинстве своем они устанавливаются на сервер, который нужно мониторить, однако, есть агенты собирающие параметры удаленно. Перечислять в статье список агентов я не буду – ознакомиться с ним можно на сайте IBM и, поверьте, их очень много. Ну а для особо изощренных заказчиков всегда можно разработать уникального агента, который будет покрывать любые потребности, для этого существует Agent Builder.
Управляемые системы и агенты
![](https://habrastorage.org/r/w1560/storage2/f5e/8ea/bd0/f5e8eabd0f7c296b59de7e67b3bcf69a.png)
После того как параметры поступают в TEMS, их значения сравниваются с пороговыми и при превышении порога срабатывают ситуации. Разумеется, все пороги можно менять по вашему усмотрению и создавать новые ситуации.
Активные ситуации
![](https://habrastorage.org/r/w1560/storage2/eaa/8d1/fb3/eaa8d1fb312d8563d3ec70b0e15ccb40.png)
Все это хорошо и при появлении проблем администраторы смогут оперативно решить их, а ведь иногда возникновения проблемы можно и вовсе избежать. Для целей предиктивного анализа в ITM используется TPA (Tivoli Performance Analyser). Предчувствую, что у большинства читателей возникнут некоторые сомнения по поводу его работоспособности, я перед знакомством c TPA тоже был настроен скептически и полагал, что все будет работать, мягко говоря, не так как это обещает производитель. Но скажу вам — он работает, да, нужен большой объем информации для анализа, т.е. на данных за неделю точного прогноза не построить, но в целом у меня сложилось положительное впечатление о TPA.
Обозначу основные моменты по реализации функции мониторинга:
— Большое количество агентов мониторинга и возможность разработки собственных агентов. Вместе с агентами поставляется достаточно объемный набор заранее настроенных ситуаций
— Не буду углубляться в подробности, но при установке некоторых агентов приходится перезагружать программную часть TEMS/TEPS, что не может не огорчать
Очень полезная функция ведь все мы знаем, как руководство любит отчетность.
Историческая информация собирается в БД Warehouse, а затем на основе этой информации строятся всевозможные отчеты. Усреднением и очисткой исторических данных занимается Summarization & Pruning агент. В качестве движка отчетности выступает Cognos, работа с отчетами осуществляется через Tivoli Integrated Portal – это единый портал для управления всеми продуктами линейки Tivoli, по крайней мере, так он позиционируется. Так же историческая информация используется для предиктивного анализа, о котором я упомянул в предыдущем разделе.
Конфигурация сбора исторической информации
![](https://habrastorage.org/r/w1560/storage2/56f/a25/1d5/56fa251d50512d1e8975e71dd195a111.png)
К сбору исторической информации у меня никаких претензий нет, все работает так, как и должно работать.
Интегрироваться можно с обширным количеством продуктов. Это могут быть системы мониторинга, системы обработки событийной информации, в общем-то, любые системы которые, так или иначе, служат для работы с ситуациями, событиями или параметрами мониторинга. Логическим продолжением для работы с ситуациями является их передача в систему обработки событийной информации. В линейке Tivoli – это Netcool/OMNIbus.
Система обработки событийной информации
![](https://habrastorage.org/r/w1560/storage2/8f8/e35/6e2/8f8e356e2ea5395fa8e539ba70c3d71d.png)
Дальше уже возможна интеграция с системами Service Desk и системами контроля качества предоставления сервисов, например, TBSM (Tivoli Business Service Manager) – на хабре есть небольшая статья.
Насчет интеграции могу сказать следующее:
— Большое количество поддерживаемых систем «из коробки» и при желании ITM интегрируется практически с любым продуктом
— Долго думал над минусами. Да, не всегда интеграция проходит гладко, но в целом не могу выделить существенных недостатков.
Ну что же, на этой оптимистичной ноте я буду закругляться.
Я постарался как можно более лаконично и объективно описать систему. Чтобы не утомлять читателей большим количеством технических подробностей, я описал работу в общих чертах и за кадром остался огромный пласт интересных решений, о которых, возможно, напишу в следующих статьях. И в завершении я хочу подвести итог – это мое видение того, что из себя на данный момент представляет ITM.
— Система мониторинга огромного количества разнородных компонентов информационной инфраструктуры
— Подходит для мониторинга как небольшой, так и огромной инфраструктуры
— Содержит все необходимое для создания отчетов любой сложности
— Без проблем интегрируется с большинством систем
— Не самое дешевое и достаточно требовательное к ресурсам ПО
Сегодня я расскажу вам об одном из продуктов IBM для мониторинга серверов и приложений. Всегда пристально следил за публикациями по теме мониторинга и по моим ощущениям в последнее время их резко поубавилось. Ну что же, попробую хоть как-то восполнить этот досадный пробел.
Почему именно ITM (IBM Tivoli Monitoring) спросите вы, просто так сложилось, что уже на протяжении нескольких лет я занимаюсь внедрением и настройкой этого продукта и хочу поделиться своими впечатлениями о работе с ним.
![](https://habrastorage.org/storage2/37c/305/98b/37c30598b4b5dec3176ad7094f84e885.png)
Если вам интересно познакомиться с ITM или просто хочется увидеть, что же скрывается за этим таинственным окном, то прошу под хабракат.
Начнем знакомство с архитектуры системы.
Архитектура.
Инженеры из IBM не стали изобретать велосипед и пошли проверенным путем.
Архитектура IBM Tivoli Monitoring
![](https://habrastorage.org/storage2/c38/b0d/012/c38b0d012258ce862ede0349489ba833.png)
Не хочу загружать читателей лишними подробностями, поэтому обрисую все крупными мазками. Имеется основной сервер мониторинга TEMS (Tivoli Enterprise Monitoring Server), портальный сервер TEPS (Tivoli Enterprise Portal Server), агенты мониторинга и база данных (DB2, MSSQL, Oracle или встроенная Derby) в которой хранится вся информация.
В работе системы все функционирует как швейцарские часы, по крайней мере, на моей практике не было ни одного случая, чтобы сданная в промышленную эксплуатацию система подводила (может быть, заказчики что-то скрывают?). Агенты собирают информацию и передают ее на сервер мониторинга, затем на сервере мониторинга эта информация анализируется, и при превышении порогов срабатывают ситуации. Пользователю вся эта красота доступна посредством клиента к портальному серверу, который именуется TEP (Tivoli Enterprise Portal) и доступен в десктопной и браузерной версиях.
Интерфейс Tivoli Enterprise Portal
![](https://habrastorage.org/storage2/449/ef8/f2e/449ef8f2ea98fa30102e5efad2eece50.png)
В целом об архитектуре я скажу следующее:
— Хорошая масштабируемость, надежность и удобство распространения/управления агентами из центра
— Обновление системы в некоторых случаях может вывести из себя даже самого спокойного и умиротворенного человека
Далее я хотел бы познакомить вас с основными возможностями ITM.
Мониторинг параметров серверов и приложений.
Совсем не трудно догадаться, что это основная функция любой системы мониторинга. За сбор информации, как я уже говорил, отвечают агенты. В большинстве своем они устанавливаются на сервер, который нужно мониторить, однако, есть агенты собирающие параметры удаленно. Перечислять в статье список агентов я не буду – ознакомиться с ним можно на сайте IBM и, поверьте, их очень много. Ну а для особо изощренных заказчиков всегда можно разработать уникального агента, который будет покрывать любые потребности, для этого существует Agent Builder.
Управляемые системы и агенты
![](https://habrastorage.org/storage2/f5e/8ea/bd0/f5e8eabd0f7c296b59de7e67b3bcf69a.png)
После того как параметры поступают в TEMS, их значения сравниваются с пороговыми и при превышении порога срабатывают ситуации. Разумеется, все пороги можно менять по вашему усмотрению и создавать новые ситуации.
Активные ситуации
![](https://habrastorage.org/storage2/eaa/8d1/fb3/eaa8d1fb312d8563d3ec70b0e15ccb40.png)
Все это хорошо и при появлении проблем администраторы смогут оперативно решить их, а ведь иногда возникновения проблемы можно и вовсе избежать. Для целей предиктивного анализа в ITM используется TPA (Tivoli Performance Analyser). Предчувствую, что у большинства читателей возникнут некоторые сомнения по поводу его работоспособности, я перед знакомством c TPA тоже был настроен скептически и полагал, что все будет работать, мягко говоря, не так как это обещает производитель. Но скажу вам — он работает, да, нужен большой объем информации для анализа, т.е. на данных за неделю точного прогноза не построить, но в целом у меня сложилось положительное впечатление о TPA.
Обозначу основные моменты по реализации функции мониторинга:
— Большое количество агентов мониторинга и возможность разработки собственных агентов. Вместе с агентами поставляется достаточно объемный набор заранее настроенных ситуаций
— Не буду углубляться в подробности, но при установке некоторых агентов приходится перезагружать программную часть TEMS/TEPS, что не может не огорчать
Сбор исторической информации.
Очень полезная функция ведь все мы знаем, как руководство любит отчетность.
Историческая информация собирается в БД Warehouse, а затем на основе этой информации строятся всевозможные отчеты. Усреднением и очисткой исторических данных занимается Summarization & Pruning агент. В качестве движка отчетности выступает Cognos, работа с отчетами осуществляется через Tivoli Integrated Portal – это единый портал для управления всеми продуктами линейки Tivoli, по крайней мере, так он позиционируется. Так же историческая информация используется для предиктивного анализа, о котором я упомянул в предыдущем разделе.
Конфигурация сбора исторической информации
![](https://habrastorage.org/storage2/56f/a25/1d5/56fa251d50512d1e8975e71dd195a111.png)
К сбору исторической информации у меня никаких претензий нет, все работает так, как и должно работать.
Интеграция.
Интегрироваться можно с обширным количеством продуктов. Это могут быть системы мониторинга, системы обработки событийной информации, в общем-то, любые системы которые, так или иначе, служат для работы с ситуациями, событиями или параметрами мониторинга. Логическим продолжением для работы с ситуациями является их передача в систему обработки событийной информации. В линейке Tivoli – это Netcool/OMNIbus.
Система обработки событийной информации
![](https://habrastorage.org/storage2/8f8/e35/6e2/8f8e356e2ea5395fa8e539ba70c3d71d.png)
Дальше уже возможна интеграция с системами Service Desk и системами контроля качества предоставления сервисов, например, TBSM (Tivoli Business Service Manager) – на хабре есть небольшая статья.
Насчет интеграции могу сказать следующее:
— Большое количество поддерживаемых систем «из коробки» и при желании ITM интегрируется практически с любым продуктом
— Долго думал над минусами. Да, не всегда интеграция проходит гладко, но в целом не могу выделить существенных недостатков.
Ну что же, на этой оптимистичной ноте я буду закругляться.
Заключение.
Я постарался как можно более лаконично и объективно описать систему. Чтобы не утомлять читателей большим количеством технических подробностей, я описал работу в общих чертах и за кадром остался огромный пласт интересных решений, о которых, возможно, напишу в следующих статьях. И в завершении я хочу подвести итог – это мое видение того, что из себя на данный момент представляет ITM.
— Система мониторинга огромного количества разнородных компонентов информационной инфраструктуры
— Подходит для мониторинга как небольшой, так и огромной инфраструктуры
— Содержит все необходимое для создания отчетов любой сложности
— Без проблем интегрируется с большинством систем
— Не самое дешевое и достаточно требовательное к ресурсам ПО