Общая архитектура Omegamon

Для профессиональной работы с WebSphere MQ рекомендуется использовать средства мониторинга. Несмотря на высокую надежность WebSphere MQ сообщения могут застревать в очередях по разным причинам, прежде всего из-за нештатных ситуаций для программ обработчиков, пиковых перегрузок потоков данных, нестабильности работы корпоративной информационной сети (КИС). Рассмотрим систему Omegamon фирмы IBM (ранее Candle Corp., USA) для мониторинга WebSphere MQ. Согласно аналитическим отчетам группы Gartner компания Candle является бесспорным лидером среди компаний по обслуживанию инфраструктуры WebSphere MQ.

Основными компонентами системы Omegamon, представленными на рис.14.1, являются:

Рис. 14.1.  Структурная схема Omegamon.

• Candle Management Server (CMS) - сервер сбора информации от агентов;
• Candle Net Portal Server (CNP) - сервер отображения результатов, оповещения пользователей и настройки мониторинга КИС со своими клиентами;
• CNP Client (desktop and browser options) - рабочая станция администратора Omegamon;
• Candle Management Workstation (CMW) – специальная рабочая станция администратора Omegamon (для особо-тонких настроек и анализа);
• Контролируемые системы – компьютеры КИС, на которых работают агенты Omegamon.

Агенты Omegamon работают на контролируемых системах (Managed Systems) как первоклассные шпионы: они незаметны с точки зрения использования CPU и оперативны при мониторинге с точки зрения времени доставки своих донесений в центр. Они осуществляют контроль работы программного обеспечения (ПО) и имеют агентов для всех типов поддерживаемых операционных систем, сетевого программного обеспечения, баз данных (DB-2, ORACLE, SQL server и др.), WebSphere MQ, WebSphere Application Server, Enterprise Resource Planning (ERP) систем таких как SAP и др.ПО, для которого нет специализированных агентов и мониторинг осуществляется за счет универсального агента Universal Agent. Не работоспособность аппаратного обеспечения фиксируется автоматически как побочный результат неправильного функционирования программного обеспечения.

Агенты Omegamon фиксируют критическую ситуацию и обеспечивают реакцию (ACTION) менее чем за 1 секунду. Все определяется тем интервалом мониторинга, который задается экспертом на основе своих интуитивных знаний. В качестве ACTION при определении ситуаций можно использовать различные типы действий: посылка почтовых и sms-сообщений специалистам сопровождения, посылка информации в другие системы, выполнение системных команд и т.д. Количество объектов мониторинга (компьютеров КИС) может достигать несколько сотен и на каждом объекте может быть несколько сотен контролируемых параметров. Количество платформ (типов операционных систем), на которых работают агенты, превышает 30, начиная от OS/390,…,OS/400, далее различные UNIX платформы (HP_UX, AIX, Solaris …) и заканчивая Windows. На одном сервере может работать несколько агентов, например, для мониторинга WebSphere MQ (MQSeries), WebSphere Application Server, DB-2 и HP_UNIX одновременно. Именно эффективность агентов Omegamon, созданных профессионалами, позволила Candle стать лидером среди компаний по мониторингу WebSphere MQ и других программных продуктов.

Сервера CMS и CNP-servers могут работать на одном выделенном сервере, как правило, на базе операционной системы Windows. Настройка ситуаций (situations) и механизмов логического вывода (policy) производится на рабочем компьютере администратора через CNP-client. Для только что созданной ситуации вы нажимаете кнопку Apply и моментально видите отображение ACTION через CNP-client, через почту и т.д.

Настройка Omegamon для WebSphere MQ

При установке WebSphere MQ Monitoring Agent осуществляется настройка конфигурационного файла mq.cfg, пример структуры которого приведен ниже.

SET   GROUP   NAME (GROUP1) -
               DEFAULT(YES) -
               COMMAND (YES) -
               MSGACCESS(DELETE) -
               EVENTS(REMOVE)
SET MANAGER NAME(QM1)
SET AGENT NAME(SERVER_MAIN)
SET QUEUE NAME(*) MGRNAME(QM1)
SET CHANNEL NAME(*) MGRNAME(QM1)
PERFORM STARTMON SAMPINT(300)
  HISTORY(YES)

В этом файле задаются опции для мониторинга. Обязательным параметром при задании опций является имя менеджера MANAGER NAME, в данном случае QM1. Другими важными и полезными опциями являются:

• Опция MSGACCESS(NONE | DESC | RETRY | DATA | DELETE) задает режимы работы с сообщениями и функциями и, в частности, опция DELETE позволяет удалять сообщения и использовать все функции работы с сообщениями;
• QUEUE NAME и CHANNEL NAME позволяют задать имена очередей и каналов для мониторинга (* указывает, что мониторятся все объекты данного менеджера);
• Имя агента AGENT NAME (8 символов) необходимо задать, если мониторятся менеджеры с одинаковыми именами MANAGER NAME на разных серверах;
• Опция PERFORM STARTMON SAMPINT(300) HISTORY(YES) указывает, что осуществляется сбор статистических данных с помощью Historical Data Collection c заданным интервалом мониторинга (при большом числе объектов рекомендуется не менее 60 сек).

Если возникла необходимость поменять опции, то после их изменения следует перестартовать агента для мониторинга. Опции для мониторинга подробно изложены в [27].

После установки агентов можно через CNP consol настраивать мониторинг и наблюдать все сервера с установленными агентами. Основным этапом настройки агентов Omegamon для работы с WebSphere MQ является создание ситуаций (situation). Omegamon позволяет за считанные минуты ввести и отладить правила мониторинга внештатных ситуаций для объектов КИС. Правило (situation) записывается как знания специалистов в виде так называемых продукций или, иначе говоря, условий ЕСЛИ …. ТО …...

На рис.14.2, рис.14.3 приведен вид интерфейса для создания ситуаций и показана ситуация, определяющая критическое количество сообщений в очередях WebSphere MQ.

Рис. 14.2.  Интерфейс Omegamon для представления ситуаций (часть 1).

Рис. 14.3.  Интерфейс Omegamon для представления ситуаций (часть 2).

Кроме мониторинга очередей наиболее типичными ситуациями для мониторинга объектов WebSphere MQ являются: мониторинг состояния каналов (останов, binding, retrying), мониторинг состояния менеджера очередей, мониторинг канала на предмет записи значений message count (только одно условие channel name = <имя канала>).

Дополнительным вариантом настройки агентов Omegamon для работы с WebSphere MQ может быть создание политики (Policy), которая служит для выполнения действий (ACTION) при срабатывании нескольких ситуаций одновременно, например, при мониторинге ситуаций на разных серверах, при подключении разных ситуаций в разное время и т.д.. Создание Policy осуществляется в CNP client (меню Edit => Workflow Editor) в графическом режиме. На рис.14.4 показан пример создания Policy для случая, когда требуется в NT кластере определить, что оба менеджера очередей остановлены, выдать предупреждение командой net send и попытаться запустить один из менеджеров командой strmqm.

Рис. 14.4.  Пример создания Policy

В 90-х годах весьма популярны были экспертные системы (ЭС), под которыми понимаются программы, использующие знания специалистов (экспертов) о некоторой конкретной узко специализированной предметной области и которая в пределах этой области способна принимать решения на уровне эксперта-профессионала [28]. Исходя из этого определения можно сказать, что Omegamon – яркий представитель современных экспертных мультиагентных динамических систем, работающих в реальном времени. Логический вывод в такой ЭС реализован при помощи механизма policy, обеспечивающего построение цепочек логического вывода на основе situations.

Настройка рабочих областей и многопользовательской работы

Рассмотрим некоторые дополнительные особенности работы с Omegamon для WebSphere MQ и в первую очередь настройку рабочих областей (WorkSpace) для создания необходимых пользовательских окон (View) и отображения наиболее важной динамической информации за последние 1 – 2 часа. Как уже упоминалось, по умолчанию Omegamon имеет достаточно информативные настройки рабочих областей, но настройка пользовательских взглядов (custom workspace views) дает дополнительные удобства.

Допустим желательно иметь окно с графиком прохождения сообщений через канал QM1_QM2.ch. Определим пользовательский взгляд с помощью следующих шагов.

• Выбираем вершину, для которой определяем пользовательский взгляд, и сохраняем в меню File новое рабочее пространство кнопкой Save WorkSpace As, например, с именем MyWorkSpace
• Выбираем кнопку с вариантом отображения WorkSpace – блокнот, таблица, график, гистограмма и т.д. и перемещаем её на наше MyWorkSpace по технологии drag and drop.

• Правой кнопкой мыши открываем свойства MyWorkSpace и нажимаем кнопку Click here to assign a querry и вызываем QuerryEditor.

  Среди множества запросов (Querry) выбираем подходящий или создаем новый и модифицируем его, например,

  Begin (Channel Name EQ ‘QM1_QM2.ch’
   and Origin Name EQ $NODE$ and
   Message Count GT 0 ) End
  

  Нажав кнопку OK, присваиваем созданный запрос нашему рабочему пространству MyWorkSpace.

• Возвращаемся в свойства WorkSpace, задаем при необходимости фильтры, стиль оформления, название и нажимаем OK.

Пользовательский взгляд готов и отображает динамику сообщений по каналу QM1_QM2.ch, например так, как показано на рисунке рис.14.5.

Рис. 14.5.  Динамика сообщений по каналу QM1_QM2.ch

В меню View/Refresh Every можно выставить интервал съема значений: 30сек, 60сек, 5мин, 15мин, 60мин и по требованию. После этого можно наблюдать динамику прохождения сообщений. Можно установить всевозможные взгляды для отображения динамических изменений. В любой момент когда будет вызван экран CNP client эти взгляды покажут реальную динамическую картину о потоках в системе, например, как это показано на рис.14.6.

При работе нескольких администраторов с CNP важно чтобы каждый администратор видел только свои группы серверов для мониторинга, имел необходимые права и мог настроить необходимые окна для просмотра.

Рассмотрим методику настройки для некоторого администратора с именем mq_admin прав доступа через CNP-клиент к мониторингу подведомственных ему серверов CASH1, CASH2. Для этого в меню Edit Navigator View встаем на вершине дерева Enterprise, нажимаем кнопку Create Child Item, вводим Name, например, CASH_VIEW и переносим из окна Available Managed Systems в окно Assigned сервера для мониторинга, как показано на рис.14.7.

Далее в меню Edit вызываем окно Administer users и нажимаем кнопку Create New User и создаем пользователя cash_admin. Для этого пользователя в окне Navigator Views назначаем View = CASH_VIEW (рис.14.8). В разделе Permission этому пользователю предоставляем необходимые права. Как правило, это все права кроме User Administration, которые предоставляются главному Администратору Omegamon.

Теперь осталось проверить, чтобы в Candle Management Server в Configuration помечен флажок Security Validate User. При инсталляции этот флажок не помечен и вводиться default user = sysadmin без пароля. Пометив этот флажок и перегрузив CMS (stop and start Services), мы предоставляем пользователю mq_admin возможность загрузки клиентского окна CNP с login = mq_admin и с его сетевым паролем. И ни какому другому пользователю вход с именем mq_admin и соответствующие права не доступны в CNP Omegamon. Просто и эффективно. Более подробно эта методика описана в [29].

Рис. 14.6.  Динамическая картина потоков в системе

Рис. 14.7.  Создание взгляда Meridian (часть 1)

Рис. 14.8.  Создание взгляда Meridian (часть 2)

Работа с накоплением статистической информации

Как отмечалось ранее, пользовательские взгляды View или так называемые ShortStory предоставляют динамическую информацию за последние 1 – 2 часа. Omegamon предоставляет возможность накапливать статистическую информацию за месяцы и годы при помощи Warehouse Proxy агента и Microsoft SQL server на CMS. Этот механизм называют History Data Collection [30] или LongStory. Общая последовательность действий следующая.

• На SQL server создается база данных, например, CandleWarehouse.
• На сервере CMS создается data source с именем Candle Data Warehouse при помощи ODBC Administrator для доступа к базе данных CandleWarehouse пользователю Candle c паролем Candle
• Инсталируется Warehouse Proxy агент на CMS сервере.
• Осуществляется настройка History Collection Configuration через CMW или CNP client (меню Edit => History Configuration) и нажимается кнопка Start Collection. Пример настройки параметров приведен на рис.14.9.
• Осуществляется анализ накапливаемой информации на SQL server и разработка различных видов отображения информации. Например, на основе Microsoft Access можно получить различные графики и гистограммы потоков информации (message count) на различных серверах, например, как показано на рис.14.10.

Накопление статистической информации через History Data Collection осуществляется с минимальным интервалом 5 минут. Это сделано специально, чтобы не переполнять базу данных SQL сервера. Иногда может понадобиться детальный анализ, например, с интервалом мониторинга 5 сек и записью значений в лог файлы. Это можно сделать с помощью ситуаций. Полученную информацию в дальнейшем можно будет использовать для анализа, построения графиков, презентаций и т.д.

Рис. 14.9.  Настройка History Collection Configuration

Рис. 14.10.  Графики на основе History Data Collection

Среди дополнительных особенностей Omegamon нельзя не отметить службу eDelivery, позволяющую в любой момент получить приобретенное и обновленное программное обеспечение Omegamon через Интернет. Это особенно важно в связи с появлением новых версий программного обеспечения и документации, приобретением новых агентов. На рис.14.11 показан интерфес для выбора и загрузки необходимого программного обеспечения Omegamon для WebSphere MQ через Интернет.

Рис. 14.11.  Интерфейс для загрузки программного обеспечения через eDelivery

Важной особенностью системы Omegamon является возможность создания порталов для мониторинга. Суть создания порталов такова. Имеется несколько систем мониторинга в КИС, например, мониторинг сетевых ресурсов, мониторинг антивирусной защиты и мониторинг WebSphere MQ. Портал для мониторинга будет включать указанные системы мониторинга как подсистемы за счет получения информации через своего универсального агента (Universal Agent), установленного на системы мониторинга. Универсальному агенту через SNMP протокол передаются совокупности измеряемых параметров от каждой из систем мониторинга и портал для мониторинга будет работать по тем же принципам, что и описанная система Omegamon.

В заключение cледует подчеркнуть, что основанная на знаниях система мониторинга Omegamon это весьма эффективная система управления вычислительными ресурсами в целом и WebSphere MQ в частности, надежный и незаменимый помощник в поисках решений по оперативному устранению критических и трудных для диагностирования ситуаций, при анализе информационных потоков, анализе производительности и настройке КИС.