Настройка 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.
