Сравнение систем мониторинга
В данном разделе будет проведено сравнение системы мониторинга IBM Tivoli Monitoring с другими решениями в области мониторинга.
В настоящее время в Санкт-Петербургском ИВЦ для мониторинга SAP-систем используется Nagios. Это программа мониторинга компьютерных систем и сетей с открытым кодом. Предназначена для наблюдения, контроля состояния вычислительных узлов и служб, оповещает администратора в том случае, если какие-то из служб прекращают (или возобновляют) свою работу.
Nagios первоначально была создана под именем Netsaint, разработана Этаном Галстадом. Он же поддерживает и развивает систему сегодня, совместно с командой разработчиков, которые занимаются как официальными, так и неофициальными плагинами (программными модулями) для расширения возможностей системы мониторинга.
К достоинствам Nagios можно отнести:
- большое количество плагинов, расширяющих базовый функционал;
- лицензию GNU;
- использование циклической базы данных RRD, по данным которой строятся графики;
- использование демона (программы, работающей в фоновом режиме без прямого общения с пользователем) cron –планировщика задач в UNIX-подобных операционных системах – для периодического выполнения заданий в определённое время.
Недостатками же являются:
- слишком большой интервал между проверками и замерами параметров;
- перезапуск системы после изменения файла конфигурации (~10-15 минут);
- RRD усредняет данные, поэтому невозможно сказать, каково было точное значение параметров, например, месяц назад (т.е. нет возможности просмотра истории изменений количественных характеристик.).
- отсутствие возможности просматривать внутренние сбои системы (например, когда закончились диалоговые или фоновые процессы).
Основными аналогами в мониторинге удаленных систем являются следующие решения: Zabbix, Cacti, Ganglia, Munin.
Zabbix – свободная система мониторинга и отслеживания статусов разнообразных сервисов компьютерной сети, серверов и сетевого оборудования, написанная Алексеем Владышевым.
Достоинства Zabbix:
- Zabbix агенты являются чрезвычайно эффективными из-за использования родных системных вызовов для сбора информации о статистике;
- вся конфигурация хранится в базе, управляется через web-интерфейс;
- разграничение доступа к данным и конфигурации;
- с серверов собираются не результаты проверок, а количественные характеристики работы, которые анализируются на стороне сервера;
- время хранения данных ограничено лишь дисковым пространством;
- возможность создавать карты сетей;
Недостатки:
- веб-интерфейс требует веб-сервер (например, Apache);
- все данные истории хранятся в базе, что неэффективно и ограничивает масштабируемость;
- нет возможности просматривать внутренние сбои системы (например, когда закончились диалоговые или фоновые процессы).
Ganglia — масштабируемая распределенная система мониторинга кластеров параллельных и распределенных вычислений и облачных систем с иерархической структурой. Позволяет наблюдать статистику и историю (загруженность процессоров, сети) вычислений в реальном времени для каждой из наблюдаемых машин.
На каждой машине запускается демон gmond, который собирает системную информацию (скорость процессора, использование памяти и т.д.) и посылает ее на определенную машину. Машина, получающая информацию, может отображать ее, а также передавать некоторую обобщенную форму данных вверх по иерархии. Именно благодаря этой иерархической схеме Ganglia так хорошо масштабируется. Накладные расходы, связанные с работой gmond, очень малы, поэтому этот код можно запускать на всех машинах кластера без ущерба для производительности.
К недостаткам можно отнести отсутствие оповещений в аварийных ситуациях и управления доступом к системе.
Cacti — открытая система мониторинга с Web-интерфейсом, позволяющее пользователю опрашивать сервисы через заданные интервалы времени. Cacti собирает статистические данные за определённые временные интервалы и позволяет отобразить их в графическом виде.
Преимущественно используются стандартные шаблоны для отображения статистики по загрузке процессора, выделению оперативной памяти, количеству запущенных процессов, использованию входящего/исходящего трафика. Cacti может быть расширена за счёт скриптов или исполняемых программ.
Недостатком является отсутствие отслеживания внутренних сбоев.
Munin – система мониторинга приложений, которая представляет получаемые данные в графиках через Web-интерфейс. Основной акцент сделан на создание плагинов, число которых насчитывает уже свыше 500. Используя Munin, можно контролировать производительность компьютеров, сети, приложений.
Для работы с данными используется RRDtool. Munin имеет архитектуру владелец/узел, при которой все узлы опрашиваются через равные промежутки времени. Получаемая информация хранится в файлах RRD.
Сравнительная таблица систем мониторинга (Табл.2) наглядно показывает общую картину. Несмотря на все достоинства, вышеупомянутые системы мониторинга не могут в той или иной мере предоставить тот набор функций, который обеспечивает IBM Tivoli Monitoring.
Отслеживание внутренних сбоев | Просмотр истории изменения количественных характеристик | Оповещения | Метод хранения данных | Управление доступом | Карты сети | |
Nagios | Нет | Нет | Да | RRDtool, SQL | Да | Да |
Zabbix | Нет | Да | Да | Oracle Database, MySQL, DB2 | Да | Да |
Cacti | Нет | Да | Да | RRDtool, MySQL | Да | Через плагин |
Ganglia | Нет | Нет | Да | RRDtool | Нет | Да |
Munin | Нет | Нет | Да | RRDtool | Нет | Нет |
Tivoli Monitoring | Да | Да | Да | MySQL, Oracle Database, DB2 | Да | Да |
Таблица 2 - Сравнительная таблица систем мониторинга
Система имеет готовые методы системного администрирования, реализованные в виде заранее определенных пороговых значений, проверочных процедур и рекомендованных мер автоматической коррекции, что устраняет необходимость проведения обширных исследований и ручной настройки конфигурации решения.
TEP предоставляет масштабируемый, интуитивно понятный графический интерфейс пользователя, в котором наглядно отображаются собираемые данные.
Система предъявляет минимальные требования к объему оперативной памяти и дисковому пространству. В минимальной конфигурации можно установить все компоненты на один сервер с 1 ГБ оперативной памяти и 20 ГБ свободного пространства на диске.
Tivoli Monitoring предоставляет возможность отслеживать внутренние сбои системы, такие как:
- блокировка пользователя на объектах SAP (например, таблицах);
- ситуации, когда закончились фоновые или диалоговые процессы в SAP;
- неотработавшие фоновые задания в SAP;
- заполненность табличных пространств в БД;
- ошибки в БД посредством мониторинга ее журнала.
С учетом широкого применения в Санкт-Петербургском ИВЦ системы SAP и БД, отслеживание внутренних сбоев становится ключевым фактором в выборе IBM Tivoli Monitoring, т.к. даже минутные отказы системы могут привести к большим финансовым потерям ОАО «РЖД».
Анализ табл.2 показывает явные преимущества Tivoli Monitoring по сравнению с другими системами мониторинга. Данная система мониторинга обеспечивает мощную базу для контроля распределенных ресурсов предприятия и своевременного оповещения о критических ситуациях наравне с относительно малыми требованиями к конфигурации сервера.