В этой лекции обсуждаются следующие темы:
Базовая информация, предоставляемая WebSphere MQ
Разрешение известных проблем
Общие проблемы при построении инфраструктуры
Общие проблемы при использовании инфраструктуры
Сбор сведений для обращения в службу поддержки
12.1. Базовая информация, предоставляемая MQ
Приведенные ниже источники информации помогут устранить проблемы с WebSphere MQ следующего рода:
неудачное завершение управляющей команды WebSphere MQ;
неудачное завершение операции WebSphere MQ Explorer;
неудачное завершение программы-примера WebSphere MQ;
невозможность подключения приложения к WebSphere MQ;
невозможность отправки или получения сообщений приложением;
невозможность взаимодействия между менеджерами очередей;
неудачное завершение попыток программного выполнения различных действий над WebSphere MQ.
12.1.1. Сообщения AMQXXXX
Сообщения, отображаемые администратору инфраструктуры WebSphere MQ в ответ на выполняемые им действия, а также при различных событиях, помечаются идентификаторами вида AMQXXXX.
К их числу относятся сообщения об успешном и неудачном завершении действий, выполняемых в WebSphere MQ Explorer, а также управляющих команд WebSphere MQ и команд MQSC. Также выводятся сведения о работе менеджера очередей, которые заносятся в его журнал ошибок.
Идентификаторы этих сообщений состоят из подстроки AMQ и четырех цифр; допустимы идентификаторы из диапазона AMQ4000–AMQ9999.
Для любого сообщения WebSphere MQ можно получить дополнительную информацию (более подробное разъяснение обстоятельств генерации сообщения и рекомендуемые ответные действия).
Методы получения дополнительной информации следующие:
поиск идентификатора сообщения в руководстве WebSphere MQ Messages, GC34-6601;
исполнение команды mqrc с идентификатором сообщения в качестве параметра на машине с WebSphere MQ, например:mqrc AMQ4002
12.1.2. Коды причины
При неудачном или неполном завершении любого программного действия над WebSphere MQ приложению возвращается код, называемый кодом причины ( reason code ).
Этот код идентифицирует причину неудачного или неполного завершения действия, что позволяет предусмотреть эти обстоятельства при разработке приложения и отреагировать на них должным образом. Например, если приложение, ожидающее поступления сообщений в очередь в течение нескольких секунд, так и не дождется прибытия сообщений, оно должно получить код этого события.
Если некоторое действие завершается неудачей неожиданно для приложения, при диагностике прежде всего следует изучить код причины.
Коды причины представляют собой четырехзначные десятичные числа, которым соответствуют описательные имена. Вывести значение кода и описание, соответствующее коду, можно при помощи команды mqrc.
Параметром этой команды является десятичное значение кода, либо его шестнадцатеричное представление, предваренное знаками 0x, либо имя кода. В ответ на ввод одного из представлений кода команда возвращает остальные представления.
Подробнее об отдельных кодах причины см. в руководстве WebSphere MQ Messages, GC34-6601.
Получение кодов причин при использовании MQI и объектно-ориентированных API
Коды причин возвращаются непосредственно в ответ на действия над менеджерами очередей, выполняемые при помощи MQI API и других API, основанных на объектной модели WebSphere MQ. Описание кодов причин, возвращаемых при вызове функций MQI, приведено в WebSphere MQ Application Programming Reference, SC34-6596.
Получение кодов причины при использовании стандартных API, таких как JMS
При использовании стандартных API, например JMS, коды причины WebSphere MQ не описаны в стандартах на данные API. Однако код причины WebSphere MQ может содержаться в стандартном описании сбоя, предоставляемом приложению. Например, при использовании JMS API для взаимодействия с WebSphere MQ в описании Java-исключений могут содержаться коды причины WebSphere MQ.
12.1.3. Журналы ошибок менеджеров очередей
Журнал ошибок менеджера очередей - основной источник информации о работе менеджера очередей.
Если кода причины или сообщения AMQXXXX недостаточно, чтобы понять причины неудачного завершения программной операции или попытки административного действия, следует изучить журналы ошибок менеджера очередей. Впрочем, эти журналы содержат сведения не только о сбоях.
Журналы ошибок менеджера очередей предоставляют весьма полезную информацию о том, как он функционирует. Администраторам WebSphere MQ рекомендуется регулярно изучать журналы менеджеров очередей, подобно тому как системным администраторам рекомендуется анализировать журналы ОС.
12.1.4. Системные журналы ошибок WebSphere MQ
Некоторые операции по взаимодействию с инфраструктурой WebSphere MQ не сводятся к взаимодействию с отдельными менеджерами очередей. Например, когда попытка приложения подключиться к менеджеру очередей в режиме клиента оканчивается неудачей, с точки зрения этого приложения информация об этом сбое не связана с менеджером очередей.
Эта информация записывается в системном журнале ошибок WebSphere MQ, который рекомендуется анализировать наряду с журналами отдельных менеджеров очередей при диагностике проблем с клиентскими подключениями к менеджерам очередей.
Журналы ведутся как клиентами, так и серверами WebSphere MQ.
12.1.5. Расположение журналов ошибок
Журналы ошибок располагаются в следующих каталогах.
В Windows:журналы ошибок менеджеров очередей: C:\Program Files\IBM\WebSphere MQ\Qmgrs\Имя_менеджера_очередей\errors
системные журналы ошибок WebSphere MQ: C:\Program Files\IBM\WebSphere MQ\errors
системные журналы ошибок при установке только клиента WebSphere MQ: c:\Program Files\IBM\WebSphere MQ Client\errors
системные журналы ошибок менеджеров очередей: C:\Program Files\IBM\WebSphere MQ\Qmgrs\@SYSTEM\errors
В UNIX:журналы ошибок менеджеров очередей: /var/mqm/qmgrs/Имя_менеджера_очередей/errors
системные журналы ошибок WebSphere MQ: /var/mqm/errors
системные журналы ошибок менеджеров очередей: /var/mqm/qmgrs/@SYSTEM/errors
В iSeries:журналы ошибок менеджеров очередей: /QIBM/UserData/mqm/Имя_менеджера_очередей/errors
системные журналы ошибок WebSphere MQ: /QIBM/UserData/mqm/errors
системные журналы ошибок менеджеров очередей: /QIBM/UserData/mqm/SYSTEM/errors
Подробнее об этих журналах см. в разделе 5.3.15.
12.1.6. Технология FFST
При возникновении в менеджере очередей WebSphere MQ неожиданных событий, которые могут повлиять на его работоспособность, генерируется отчет FFST (firstfailure support technology).
Часть сведений из отчета FFST опытный администратор WebSphere MQ может прочитать непосредственно, остальная информация описывает состояние внутренних механизмов WebSphere MQ на момент сбоя. Эти сведения весьма полезны представителям службы IBM Service для диагностики сбоев WebSphere MQ.
Желательно хранить FFST-файлы в течение некоторого времени, поскольку полный набор таких файлов существенно облегчит диагностику неполадок представителям службы IBM Service. FFST-файлы создаются незадолго до проявления первых симптомов проблемы, и потому они могут быть полезны при анализе ее причин. FFST-отчеты генерируются не только при сбоях WebSphere MQ, но и при других неожиданных событиях. Регулярно проверяйте наличие FFST-файлов.
12.1.7. Документация по WebSphere MQ
В документации по WebSphere MQ содержится справочная информация об администрировании WebSphere MQ и разработке приложений, использующих инфраструктуру WebSphere MQ.
Обзор содержимого документации см. ниже в разделе "Публикации на смежные темы", а также в руководстве WebSphere MQ Bibliography and Glossary, SC34-6603.
Документация по WebSphere MQ V6.0 также доступна в виде библиотеки Information Center, поддерживающей удобный поиск (поставляется на носителе с WebSphere MQ), см. также Web-страницу: http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp
12.2. Устранение известных неполадок
WebSphere MQ - устоявшийся программный продукт с солидным контингентом пользователей. Весьма вероятно, что проблемы, с которыми вы столкнулись при построении инфраструктуры WebSphere MQ или при попытке выполнения административных действий либо программных операций, уже возникали у других пользователей.
Возможно, эта проблема устраняется модификацией WebSphere MQ посредством APAR, изменением конфигурации инфраструктуры WebSphere MQ либо кода использующего ее приложения, а также путем изменений других аппаратных и программных компонентов инфраструктуры.
12.2.1. Сайт поддержки WebSphere MQ
Вся информация IBM по технической поддержке WebSphere MQ доступна через центральный Web-сайт: http://www.ibm.com/software/integration/wmq/support/
На этом сайте имеется документация по WebSphere MQ, база с поисковым интерфейсом, содержащая информацию о всех ранее устраненных неполадках в WebSphere MQ, также возможна загрузка пакетов SupportPacs для WebSphere MQ и исправлений для WebSphere MQ.
12.2.2. Установка исправлений и обновлений
IBM регулярно выпускает пакеты исправлений для WebSphere MQ. Важно постоянно устанавливать эти пакеты на всех экземплярах WebSphere MQ в составе инфраструктуры WebSphere MQ.
Регулярная установка исправлений даже при отсутствии соответствующих проблем защищает инфраструктуру WebSphere MQ от сбоев из-за возникновения известных неполадок.
Примечание. Любые изменения инфраструктуры и приложений, а также исправления, рекомендуется сначала испытывать в тестовой среде и лишь потом развертывать в производственной среде. То же верно для исправлений WebSphere MQ.
Подробнее о доступных обновлениях и исправлениях для WebSphere MQ см. на Web-странице технической поддержки WebSphere MQ.
Перед установкой исправления изучите его документ readme. В нем содержится описание проблемы, которое оно устраняет, а также история неполадок, которые устраняются исправлениями, ранее выпущенными для данной версии WebSphere MQ.
В readme также могут содержаться дополнения к документации WebSphere MQ и особые сведения, которые могут касаться работы WebSphere MQ в вашей среде.
Примечание. Определить текущую версию WebSphere MQ и состояние установленных исправлений в Windows и UNIX можно при помощи управляющей команды dspmqver. Команда возвращает информацию вида Version.Release.Modification.Fixpack. На iSeries для той же цели используют команду CALL QMQM/DSPMQVER.
12.2.3. "Молнии"
При выпуске каждого обновления или важного промежуточного исправления, дополняющего пакет исправлений, всем пользователям, зарегистрированным на сайте технической поддержки IBM, рассылаются уведомления-"молнии" (flashes). Каждому администратору WebSphere MQ рекомендуется подписаться на эти уведомления. Для этого зарегистрируйтесь на сайте технической поддержки IBM и добавьте WebSphere MQ в список продуктов на своей персональной странице.
12.2.4. Поиск APAR и Technote
Среди прочего доступна база знаний с решениями распространенных проблем, советами и инструкциями. Документ этой базы называется "technote" (техническая записка).
Поисковый интерфейс на сайте поддержки WebSphere MQ обеспечивает поиск в базах APAR и Technotes.
12.2.5. Дополнительные источники информации
В Интернете доступно множество источников сведений о WebSphere MQ, включая группы новостей, форумы и даже специализированные Web-сайты.
На Web-сайте IBM developerWorks $$\text{\textregistered}$$ можно найти ссылки на множество подобных ресурсов, подробнее см. на Web-странице: http://www.ibm.com/developerworks/websphere/community
12.2.6. Модуль Healthcheck для WebSphere MQ Explorer
Подключаемый модуль Healthcheck для WebSphere MQ Explorer расширяет возможности WebSphere MQ Explorer. Этот модуль анализирует конфигурацию всех менеджеров очередей, подключенных к WebSphere MQ Explorer, в поисках потенциальных проблем.
Модуль WebSphere MQ Explorer Healthcheck поставляется в составе пакета SupportPac MH01, доступного по адресу http://www.ibm.com/support/docview.wss?rs=171uid=swg24010096
12.3. Общие проблемы при построении инфраструктуры
В этом разделе приводятся действия по диагностике и разрешению проблем, возникающих при наладке взаимодействия менеджеров очередей.
12.3.1. Устранение неполадок распределенных каналов сообщений
Для диагностики проблем с взаимодействием менеджеров очередей через объявленные вручную каналы рекомендуется выполнить следующие действия.
Проверьте, соответствуют ли имена объектов-каналов на обоих концах соединения; учтите, что имена каналов чувствительны к регистру.
Убедитесь, что на обоих концах соединения в менеджере очередей нет записей состояния STOPPED для данных каналов. Такая запись свидетельствует о том, что канал отключен. Чтобы включить канал, запустите его соответствующей командой, отданной объектам канала в менеджерах очередей, содержащих записи состояния STOPPED. Для просмотра всех записей состояния канала в WebSphere MQ Explorer щелкните канал правой кнопкой и выберите команду Status\Current Status.
Убедитесь в совместимости типов объекта MCA отправителя, извлекающего сообщения из транспортной очереди, и MCA получателя, доставляющего сообщения в очереди менеджера-адресата (см. раздел 7.4.10).
Проследите, чтобы в атрибуте "имя подключения" ( CONNAME ) объекта канала MCA, используемого для соединения, был указан IP-адрес или хост-имя машины, на которой работает менеджер очередей, с которым нужно наладить взаимодействие. Проверьте связь с этой машиной при помощи команды ОС ping (с обоих концов соединения, для любого канала из пары).
Убедитесь, что в атрибуте "имя подключения" ( CONNAME ) объекта канала MCA, используемого для соединения, указан порт, соответствующий порту слушателя менеджера очередей, с которым нужно наладить взаимодействие. Проверьте связь с этой машиной при помощи команды ОС ping (с обоих концов соединения, для любого канала из пары).
Выполните команду WebSphere MQ ping для проверки связи через канал. Если эта проверка окончится неудачей, проверьте журналы ошибок обоих менеджеров очередей.
Убедитесь, что в атрибуте "транспортная очередь" ( XMITQ ) объекта канала, определяющего MCA отправителя, указано имя объекта локальной очереди, объявленного в том же менеджере очередей (учтите, что имена объектов чувствительны к регистру).
Убедитесь, что атрибут USAGE этого объекта локальной очереди определяет эту очередь как транспортную (имеет значение XMITQ ).
Попытайтесь запустить канал вручную.
Если канал не запускается, проверьте журналы ошибок обоих менеджеров очередей.
Проверьте, существует ли очередь недоставленных сообщений в менеджере очередей, в котором работает MCA получателя. Если в транспортной очереди накапливаются постоянные сообщения, которые не могут быть переданы получателю из-за ошибок доставки, то в отсутствие очереди недоставленных сообщений канал переходит в состояние RETRYING, а затем – в состояние STOPPED.
Проверьте, не указана ли одна и та же транспортная очередь у двух объектов канала в данном менеджере очередей.
Если для данных каналов есть запись о статусе, проверьте, не содержит ли ее атрибут "неоднозначное состояние" ( INDOUBT ) значение YES.
12.3.2. Устранение неполадок инициации каналов сообщений
Для диагностики проблем с инициацией распределенных каналов сообщений рекомендуется выполнить следующие действия (предварительно убедитесь, что наладить связь через эти каналы вручную удается).
Убедитесь, что атрибут "управление триггером" ( TRIGGER ) задан для объекта локальной очереди, использующейся в качестве транспортной очереди, из того же менеджера очередей, что используется объектом канала отправителя. В данном случае этот объект представляет транспортную очередь.
Проследите, чтобы атрибуту "тип триггера" ( TRIGTYPE ) транспортной очереди было присвоено значение FIRST или DEPTH.
Если триггер срабатывает на определенную длину очереди ( DEPTH ), убедитесь, что значение TRIGDPTH настроено соответствующим образом.
Убедитесь, что атрибуты "данные триггера" ( TRIGDATA ) и "процесс" ( PROCESS ) транспортной очереди содержат имя объекта канала отправителя (имена объектов чувствительны к регистру).
Проследите, чтобы атрибуту "очередь инициации" ( INITQ ) транспортной очереди было присвоено значение SYSTEM.CHANNEL.INITQ.Примечание. Допускается использование собственных очередей инициации, но инициатор каналов для них нужно запускать вручную.
Убедитесь, что инициатор каналов в менеджере очередей активен. В WebSphere MQ V6.0 для этого используется команда MQSC DISPLAY QMSTATUS CHINIT, альтернативный вариант – щелкнуть правой кнопкой менеджер очередей в WebSphere MQ Explorer и выбрать Status.
Проверьте, правильно ли установлен атрибут "интервал отключения" ( DISCINT ) объекта канала отправителя.
Вручную запустите канал, чтобы передать все сообщения из транспортной очереди удаленному менеджеру очередей.
Дождитесь истечения интервала отключения канала либо остановите его вручную, установив целевой статус ( STATUS ) канала в INACTIVE.
Добавьте сообщение в очередь удаленного менеджера очередей. В результате сообщение будет добавлено в транспортную очередь, и менеджер очередей автоматически запустит канал.
12.3.3. Устранение неполадок кластерных каналов сообщений
Ниже рассказывается о разрешении проблем, возникающих при добавлении менеджера очередей к кластеру (см. раздел 8.3.3), удалении менеджера очередей из кластера (см. раздел 8.3.4). В частности, освещается устранение неполадок кластерных каналов сообщений. Чаще всего они возникают из-за неверной настройки атрибутов объектов кластерных sender- и receiver-каналов.
Общий симптом таких проблем — наличие строк следующего вида в выводе команд DISPLAY CLUSQMGR либо в папке Clusters, отображаемой WebSphere MQ Explorer.
SYSTEM.TEMPQMGR.имя_хоста(порт)
Обычно они возникают из-за проблем с подключением к кластеру либо повторным подключением с помощью команды REFRESH CLUSTER с параметром REPOS(YES).
Примечание. Обычно изменения вручную объявленного объекта кластерного sender -канала, используемого для связи с полным репозиторием, не действуют после ввода соответствующего менеджера очередей в кластер. Атрибуты этого объекта переопределяются значениями параметров автоматически создаваемого объекта кластерного sender-канала на основе объекта кластерного receiver-канала, объявленного в менеджере очередей, обслуживающего полный репозиторий.
Важная особенность кластера менеджеров очередей заключается в том, что каждый менеджер в его составе должен взаимодействовать с другими через подключение, имя которого указано в объекте кластерного receiver-канала, объявленного в этом менеджере очередей кластера.
Чтобы изменить имя этого подключения, удалите менеджер очередей из всех кластеров, в которые он входит, используя объект кластерного receiver-канала, внесите изменения и верните менеджер очередей в кластер. Не рекомендуется изменять имя объекта кластерного receiver-канала, пока этот объект опубликован в кластере.
Для кластерных каналов верно многое из того, что сказано о распределенных sender-каналах. Всегда начинайте с проверки каналов между менеджерами очередей полных репозиториев кластера. Далее проверьте каналы между менеджерами очередей частичных и полных репозиториев кластера. Лишь убедившись в работоспособности этих каналов, переходите к проверке каналов между менеджерами очередей частичных репозиториев.
Для каждой пары менеджеров очередей кластера проверьте следующее:
для менеджера очередей с полным репозиторием проверьте, что атрибуты "репозиторий" ( REPOS ) или "список имен репозиториев" ( REPOSNL ) объекта менеджера очередей содержат верные имена кластера или объекта списка имен ( namelist ). Имена этих объектов чувствительны к регистру. Если используется список имен, проверьте наличие имени кластера в его атрибуте "имена" ( NAMES );
убедитесь, что у обоих менеджеров очередей имеется активный слушатель;
проверьте, содержат ли атрибуты "кластер" ( CLUSTER ) или "список имен кластеров" ( CLUSNL ) объектов кластерных sender- и receiver-каналов верные имена кластера и объекта списка имен. Если используется список имен, проверьте наличие имени кластера в его атрибуте "имена" ( NAMES );
исполните MQSC-команду DISPLAY CLUSQMGR(*) на обоих менеджерах очередей. Убедитесь, что в выводе команды отсутствуют строки вида SYSTEM.TEMPQMGR.имя_хоста(порт). Их наличие свидетельствует о неудаче добавления менеджера очередей к кластеру по одной из двух причин.Сбой кластерного sender-канала, объявленного вручную. Эти неполадки препятствуют подключению к менеджеру очередей, обслуживающему полный репозиторий. Убедитесь, что имя объекта кластерного sender-канала соответствует имени объекта кластерного receiver-канала, объявленного в менеджере очередей, обслуживающем полный репозиторий. Проверьте, пригодно ли заданное хост-имя, IP-адрес и порт для связи с менеджером очередей, обслуживающим полный репозиторий.Примечание. Конкретный экземпляр полного репозитория, с которым осуществляется связь, не имеет значения. Имя подключения, а также имя канала должно соответствовать аналогичным параметрам менеджера очередей, обслуживающего полный репозиторий, в противном случае запустить канал не удастся.
Сбой кластерного receiver-канала. Эти неполадки препятствуют подключению менеджера очередей, обслуживающего полный репозиторий. Проверьте имя подключения, заданного для объекта кластерного receiver-канала. Рекомендуется сбросить атрибуты CLUSTER и CLUSNL (записав в них пустую строку) до внесения любых изменений в имя подключения;
убедитесь в доступности хост-имени и IP-адреса, заданного в атрибуте "имя подключения" ( CONNAME ) объекта кластерного receiver-канала в обоих менеджерах очередей. Для проверки связи можно использовать команду ОС ping. Проверьте также порты слушателей менеджеров очередей;
проверьте журналы ошибок обоих менеджеров очередей;
выполните команду MQSC DISPLAY CHSTATUS(*) над обоими менеджерами очередей. Попробуйте найти каналы, у которых статус отличается от RUNNING (например, каналы в состоянии RETRYING ), а также каналы, атрибут состояния INDOUBT у которых равен "YES" ;
если пара менеджеров очередей обслуживают частичные репозитории, они могут иметь доступ к менеджерам, обслуживающим полные репозитории кластера, и не иметь доступа друг к другу. Чтобы открыть доступ к удаленному частичному репозиторию, следует объявить на нем объект локальной очереди. Чтобы опубликовать этот объект в кластере, запишите имя кластера в его атрибут "кластер" ( CLUSTER ). Добавьте сообщение в эту очередь, используя программу-пример amqsput, подключившись к локальному частичному репозиторию. Если эта операция завершилась успешно, команда DISPLAY CLUSQMGR(*), отданная на локальном частичном репозитории, отображает сведения об удаленном частичном репозитории.
12.4. Общие проблемы с доступом к инфраструктуре
В этом разделе рассказывается о диагностике и разрешении проблем, возникающих при обращении к инфраструктуре WebSphere MQ.
12.4.1. Устранение сбоев подключения к менеджеру очередей
Диагностику неполадок, связанных с подключением приложений к менеджерам очередей, рекомендуется выполнять следующим образом.
Убедитесь, что менеджер очередей работает, например так:с помощью команды dspmq (в Windows и UNIX) либо WebSphere MQ Explorer;
с помощью команды WRKMQM (в iSeries).
Изучите код возврата операции подключения.
В случае клиентских приложений убедитесь, что у целевого менеджера очередей работает слушатель. Убедитесь в том, что для менеджера очередей указан верный транспорт (обычно TCP) и имя подключения. Если используется таблица CCDT, проверьте, верно ли указан путь к ней. Для JMS-приложений его указывают в объекте connection factory в каталоге, к которому обращаются через JNDI. Этот каталог должен быть доступен приложению.
Для клиентских приложений проверьте, соответствует ли имя используемого канала имени канала серверного подключения из менеджера очередей; также проверьте, включено ли автоопределение канала (channel auto-definition, CHAD) для этого менеджера очередей. В любом случае имена каналов должны совпадать (учтите: имена каналов чувствительны к регистру).
Проверьте правильность (вплоть до регистра) имени менеджера очередей, указанного приложением. Для клиентских приложений, подключающихся с использованием CCDT, проверьте правильность значения атрибута "имя менеджера очередей" ( QMNAME ) объекта клиентского подключения, объявленного в менеджере очередей, создавшем CCDT.
Изучите системные журналы ошибок WebSphere MQ.
Проанализируйте журналы ошибок менеджера очередей, чтобы определить, в каком компоненте возникают сбои.
Проверьте наличие у учетной записи пользователя, под которой приложение пытается подключиться к менеджеру очередей, соответствующих полномочий.
Примечание. Для клиентских приложений рекомендуется определять атрибут "идентификатор пользователя MCA" ( MCAUSER ) для объекта канала серверного подключения. В результате приложение будет подключаться с использованием этого имени пользователя независимо от того, под каким именем оно работает на локальной системе. В итоге приложение всегда будет пользоваться в отношении менеджера очередей полномочиями, назначенными этому идентификатору пользователя.
12.4.2. Устранение неполадок отправки сообщений
Диагностику неполадок, не позволяющих открывать очереди и размещать в них сообщения, рекомендуется выполнять следующим образом.
Изучите код возврата операций открытия очереди и размещения сообщений.
Проверьте правильность имен объекта очереди и (необязательно) менеджера очередей, указанных приложением, открывающим очередь (учтите, что имена объектов чувствительны к регистру).
Убедитесь, что целевая очередь доступна менеджеру очередей, существует необходимая транспортная очередь и объявлен локальный объект удаленной очереди.
Если целевая очередь обслуживается менеджером очередей в составе кластера, убедитесь, что ее объект опубликован в кластере удаленным менеджером очередей, а также в наличии у обоих менеджеров очередей связи с полным репозиторием кластера.
Проверьте правильность параметров, с которыми приложение открывает очередь, в частности убедитесь, что очередь открывается для вывода.
С помощью табл. 6.1 определите объект, применяемый для проверки полномочий в комбинации с именем менеджера очередей, указанным приложением. Убедитесь, что учетная запись, под которой приложение пытается подключиться, обладает полномочиями для добавления сообщений в нужную очередь. Чтобы определить контекст приложения, можно вывести сведения о подключении к менеджеру очередей, пока подключение существует, например командой DISPLAY CONN(*) ALL.
Проверьте параметры добавляемого сообщения, в частности указана ли точка синхронизации ( syncpoint ), определяющая включение добавления сообщения в единицу работы. Если точка синхронизации указана, проверьте, зафиксирована ли единица работы.
Проверьте, что во всех очередях на пути к очереди назначения разрешен вывод.
Убедитесь, что значения атрибутов "максимальная длина сообщений" ( MAXMSGL ) локальной очереди и всех транспортных очередей, а также менеджера очередей достаточно велики.
Изучите журналы ошибок менеджера очередей, к которому подключено приложение.
12.4.3. Устранение неполадок извлечения сообщений
Диагностику неполадок, не позволяющих открывать очереди и получать из них сообщения, рекомендуется выполнять следующим образом.
Изучите код возврата операций открытия очереди и извлечения сообщений.
Убедитесь, что в менеджере очередей, к которому подключено сообщение, существует подходящий объект локальной очереди или модельной очереди.
Проверьте правильность имени объекта, указанного приложением, открывающим очередь (учтите, что имена объектов чувствительны к регистру).
Проверьте правильность параметров, с которыми приложение открывает очередь. В частности, очередь должна открываться для ввода, ввода с монопольным доступом или для просмотра. С помощью табл. 6.1 определите объект, применяемый для проверки полномочий в комбинации с именем менеджера очередей, указанным приложением. Убедитесь, что учетная запись, под которой приложение пытается подключиться, обладает полномочиями для извлечения сообщений из нужной очереди. Чтобы определить контекст приложения, можно вывести сведения о подключении к менеджеру очередей, пока подключение существует, например командой DISPLAY CONN(*) ALL.
Проверьте правильность параметров получения сообщений, в частности указана ли точка синхронизации, определяющая включение извлечения сообщения в единицу работы. Если точка синхронизации указана, проверьте, зафиксирована ли единица работы.
Убедитесь, что буфер, предоставляемый приложением, достаточно велик для приема сообщения (если только параметры извлечения не допускают прием усеченных сообщений).Примечание. Если извлечение оканчивается неудачей из-за недостаточной емкости буфера, приложению возвращается размер сообщения. После этого приложение может повторить операцию, выделив буфер большего размера.
Проверьте, имеются ли сообщения в очереди, не получают ли их другие приложения, а также соответствуют ли параметры поиска искомым сообщениям.Примечание. Если полю version в структуре, содержащей параметры извлечения сообщений, не присвоено значение 2 или 3, а параметры поиска не определены, идентификатор сообщения и корреляционный идентификатор, которые передаются операции get, необходимо сбрасывать после извлечения каждого сообщения.
Убедитесь, что отправка требуемых сообщений в очередь зафиксирована. Возможные причины возникновения незафиксированных сообщений: приложение не зафиксировало единицу работы после размещения сообщения под управлением точки синхронизации; канал связи с менеджером очередей находится в состоянии INDOUBT ; другое приложение получило сообщение под управлением точки синхронизации, но не зафиксировало единицу работы.Примечание. Проверить наличие незафиксированных сообщений в очереди можно при помощи команды MQSC DISPLAY QSTATUS либо щелкнув правой кнопкой очередь в WebSphere MQ Explorer и выбрав Status.
Изучите журналы ошибок менеджера очередей, к которому подключено приложение.
12.4.4. Устранение общих неполадок триггеров
Существует ряд правил для триггеров, исполнение которых необходимо для генерации триггерных сообщений в очереди инициации при поступлении сообщений в очередь, для которой происходит инициация. Подробнее см. в разделе "Starting WebSphere MQ applications using triggers" руководства WebSphere MQ Application Programming Reference, SC34-6596.
12.4.5. Поиск сообщений, отправленных в инфраструктуру
Менеджеры очередей поддерживают механизм под названием трассировка ( traceroute ), позволяющий тестировать маршруты, пролегающие сквозь инфраструктуру менеджеров очередей WebSphere MQ V6.0, которые возвращают трассировочную информацию приложению trace-route.
Trace-route использует функции отчетов об активности, поддерживаемые менеджерами очередей WebSphere MQ V6.0. Эта функция заключается в генерации компонентами менеджера очередей, такими как MCA, отчетов об активности при выполнении любых действий над сообщениями.
Подробнее о trace-route и отчетах об активности см. в разделе "Message monitoring" руководства Monitoring WebSphere MQ, SC34-6593.
Общие методы поиска сообщений
Поиск сообщений в инфраструктуре взаимосвязанных менеджеров очередей рекомендуется выполнять следующим образом.
Учтите, что непостоянные сообщения могут быть потеряны. Это бывает при перезапуске менеджеров очередей, отсутствии очередей недоставленных сообщений, из-за слишком большого размера сообщений, а также при сбоях сетевых каналов связи, по которым передаются такие сообщения.
Убедитесь, что у всех менеджеров очередей настроены очереди недоставленных сообщений. Проверьте эти очереди, просмотрев их.
Проверьте наличие в маршруте каналов с состоянием, отличным от RUNNING, либо с неопределенным состоянием (неактивных каналов).
Просмотрите транспортную очередь менеджера очередей, к которому приложение было подключено в момент генерации сообщения, затем проверьте следующие транспортные очереди на потенциальном маршруте приложения (в случае кластера менеджеров очередей – SYSTEM.CLUSTER.TRANSMIT.QUEUE ).
Убедитесь, что для всех менеджеров очередей, транспортных очередей, каналов и целевых очередей назначения указана достаточно большая максимальная длина сообщения (особенно если размер сообщения больше 4 Мб).
Проверьте наличие незафиксированных сообщений во всех транспортных очередях и целевой очереди. Если таковые обнаружатся, проверьте, нет ли каналов в состоянии INDOUBT и приложений с незафиксированными единицами работы, содержащими операции получения данных сообщений.
Маршрутизация сообщений по инфраструктуре
Сообщения могут следовать по инфраструктуре (или взаимосвязанным инфраструктурам) сложным маршрутом. Разрешение имен очередей выполняется независимо для каждого менеджера очередей, в результате этой операции определяется следующий этап маршрута к точке назначения сообщения.
Первый менеджер очередей (к нему подключено приложение, отправившее сообщение) выполняет разрешение имени очереди по именам объекта и объекта менеджера очередей, заданным во время открытия очереди для размещения в ней сообщений.
Для следующих на маршруте сообщения менеджеров разрешение имен очередей выполняется на основе имени очереди, а также имени менеджера очередей, полученного предыдущим менеджером в результате разрешения имен. Эта информация передается по каналу в заголовке транспортной очереди. Агент канала-приемника (MCA) открывает нужную очередь, ориентируясь на сведения из этого заголовка, аналогично тому, как это делают приложения.
Для разрешения имен очередей все менеджеры используют объекты очередей, расположенных в этом менеджере, такие как локальные очереди, назначенных с помощью атрибутов транспортными, объекты псевдонимов очередей и удаленных очередей. Объекты удаленных очередей выполняют три отдельные задачи в разрешении имен: локальное описание удаленных очередей, псевдонимы менеджеров очередей и псевдонимы очередей ответов.
На разрешение имен очередей также влияет членство в кластере менеджеров очередей, поскольку менеджеры, входящие в кластер, сообща используют объекты очередей. Это также обеспечивает балансировку нагрузки в кластере по обслуживанию очередей.
12.5. Сбор сведений для обращения в сервисную службу
Если компоненты WebSphere MQ работают не так, как описано в документации, во время выполнения административных действий генерируются сообщения AMQXXXX и коды причин, указывающие на возникновение неполадок, а журналы менеджера очередей и системные журналы WebSphere MQ содержат сообщения об ошибках, возможно, вам придется обратиться в службу IBM Service.
Причиной этих неполадок могут быть проблемы, возникшие при построении инфраструктуры WebSphere MQ, разработке приложений для доступа к этой инфраструктуре, а также сбои, выявленные в ходе тестирования или эксплуатации приложения.
В этих случаях необходимо тщательно задокументировать сбой, чтобы представители службы IBM Service смогли успешно устранить его.
12.5.1. Составление описания проблемы
Наличие технического описания, включающего сводку симптомов неполадки, снижает шансы неверной интерпретации собранных сведений. После обращения в службу IBM Service вам, возможно, придется работать с разными специалистами.
Поэтому описание проблемы должно содержать максимально полную картину ее внешних проявлений. В него следует включить техническое описание симптомов, а также действий, ведущих к их проявлению.
Представить четкое техническое описание проблемы для специалистов из вашей компании и службы IBM Service поможет Problem Management Record, PMR. Сводку PMR, подготовленную в электронном виде, можно передать представителям IBM, при этом вам не придется устно объяснять суть проблемы.
Подать PMR в электронном виде можно на сайте: http://www.ibm.com/software/support/probsub.html
После подачи сведений о проблеме PMR становится основным источником сведений о ней. Представители IBM Service заносят в PMR результаты всех выполненных ими анализов.
12.5.2. Описание окружения
Подробно опишите окружение, в котором возникла проблема. Непременно включите следующую информацию:
аппаратную платформу всех используемых компьютеров;
ОС на всех используемых машинах, включая установленные обновления;
номер версии WebSphere MQ;
сведения о всех установленных обновлениях и исправлениях WebSphere MQ.
12.5.3. Описание использования WebSphere MQ
Чрезвычайно полезной информацией является контекст, в котором возникает наблюдаемая проблема. Максимально подробно опишите, какие действия над программой и в каких обстоятельствах вызывают неполадки. Чем подробнее будут предоставленные сведения, тем эффективнее будет диагностика проблемы. Примерное содержание описания приводится ниже.
Сколько машин, менеджеров очередей и приложений содержится в инфраструктуре?
Подключаются ли приложения к менеджерам очередей напрямую (через связывание) либо через клиентские подключения? В последнем случае идентичны ли платформа и ОС, на которых работают приложения и менеджер очередей?
На каком языке программирования написаны приложения?
Используют ли приложения MQI API непосредственно, через API, соответствующий объектной модели WebSphere MQ, либо через стандартный API, такой как JMS?
Работают ли приложения непосредственно в ОС либо в сервере приложений или другой исполняющей среде?
Каковы задачи приложения или административных действий, вызвавших неполадки? Включите в их описание максимум технической информации, включая перечень вызовов MQI, команд MQSC и управляющих команд WebSphere MQ.
12.5.4. Подготовка описания сбоя для отправки в IBM Service
Перечень документов, которые необходимо подготовить для описания возникших неполадок, см. в технической записке (Technote) "MustGather: Read first for all Web Sphere MQ v5.3, v5.3.1, and v6.0 products", доступной по адресу http://www.ibm.com/support/docview.wss?rs=171uid=swg21177923
12.5.5. Воспроизведение неполадок
Возникновение неполадок может быть связано с попытками выполнения определенных действий. В этом случае можно попробовать повторить эти действия, чтобы воспроизвести неполадки.
Если удается воспроизвести проблему в упрощенной инфраструктуре WebSphere MQ, состоящей из одного или нескольких менеджеров очередей, желательно предоставить IBM Service соответствующие сведения.
Впрочем, воспроизвести аномальные сбои в производственной среде, а также выяснить их причины порой бывает сложно, поскольку такие эксперименты негативно отразятся на ее работе. В итоге воспроизвести наблюдаемые неполадки в рабочей среде удается не всегда.
В подобных случаях весьма удобно иметь тестовую лабораторию, максимально похожую на производственную среду, поскольку в ней можно смоделировать возникновение неполадок.
В FFST и журналах ошибок WebSphere MQ можно найти подробные сведения о неполадках. Данные, зарегистрированные в этих источниках в момент возникновения неполадок, значительно расширяют возможности представителей IBM Service по диагностике и устранению сбоев в случаях, когда воспроизвести их не удается.
12.5.6. Трассировка WebSphere MQ
Инфраструктура WebSphere MQ и работа с ней могут быть довольно сложными и специализированными под конкретные бизнес-требования. Моделирование неполадок на машинах IBM не всегда эффективно, поскольку они не настроены под особенности использования WebSphere MQ в конкретной компании.
Трассировка - мощная функция WebSphere MQ, позволяющая регистрировать все внутренние операции WebSphere MQ в файлах журналов, которые можно отправить в IBM Service для анализа.
Это позволит IBM Service тщательно проанализировать проблему без использования машины клиента и внесения изменений в его среду.
Трассировку можно запускать и останавливать, не прерывая работы менеджеров очередей.
Если удается воспроизвести неполадки в тестовой среде, следует запустить трассировку перед выполнением действий, ведущих к возникновению проблемы, а затем остановить трассировку. Полученные трассировочные данные вместе с FFST, журналами ошибок менеджеров очередей и системными журналами ошибок WebSphere MQ, полученными на машинах, где возникают сбои, следует передать для анализа в службу технической поддержки IBM.
Трассировка всех действий WebSphere MQ снижает производительность инфраструктуры WebSphere MQ, поэтому желательно использовать трассировку во время моделирования сбоев в тестовой среде, а не в производственной. Если такая возможность недоступна и воспроизвести неполадки можно лишь в производственной среде, возможно, в ней же придется активировать и трассировку.
Если установить, какое действие вызывает неполадки, не удается, трассировка работы WebSphere MQ во время их возникновения поможет представителям IBM Service в диагностике.
Трассировка в Windows
На платформе Windows запустить трассировку всех действий WebSphere MQ можно следующей командой:
strmqtrc -t detail -t all
Останавливает трассировку команда
endmqtrc
В WebSphere MQ V6.0 трассировочные файлы хранятся в каталоге C:\Program Files\IBM\WebSphere MQ\Trace, в WebSphere MQ V5.3 - в каталоге C:\Program Files\IBM\WebSphere MQ\Errors.
О настройке максимального размера трассировочных файлов см. в разделе "Problem determination" руководства WebSphere MQ Application Programming Guide, SC34-6595.
Трассировка в UNIX
На платформе UNIX запустить трассировку всех действий WebSphere MQ можно следующей командой:
strmqtrc -e -t detail -t all
Трассировку отдельного менеджера очередей запускают командой вида
strmqtrc -m имя_менеджера_очередей -t detail -t all
Примечание. При возникновении сбоев во время запуска менеджеров очередей или подключении приложения к менеджеру очередей используйте параметр -e, а не указывайте отдельный менеджер очередей.
Трассировочные файлы создаются в каталоге /var/mqm/trace.
Чтобы содержимое этих файлов было понятно людям, его необходимо отформатировать. Для этого перейдите в каталог с трассировочными файлами и выполните команду
dspmqtrc *.TRC
О настройке размера трассировочных файлов см. в разделе "Problem determination" руководства WebSphere MQ Application Programming Guide, SC34-6595.
Трассировка WebSphere MQ для AIX 5L V5.3
WebSphere MQ для AIX 5L V5.3 использует поддержку трассировки ОС AIX 5L. Эти функции доступны и в WebSphere MQ для AIX 5L V6.0, но рекомендуется использовать вышеописанные функции трассировки WebSphere MQ.
Настройка трассировки WebSphere MQ выполняется так:
MQS_TRACE_OPTIONS=4194303
export MQS_TRACE_OPTIONS
Запустите трассировку, используя трассировочный файл без перезаписи с максимальным размером 50 Мб:
trace -a -j30D,30E -o wmq_trace.trc -s -L 52428800
Примечание. О параметрах команды trace см. в руководстве AIX 5L.
Остановить трассировку можно следующей командой:
trcstop
Отформатировать отдельный трассировочный файл можно так:
trcrpt -t /usr/mqm/lib/amqtrc.fmt wmq_trace.unf > wmq_trace.fmt
Трассировка в iSeries
На платформе iSeries запустить трассировку всех действий WebSphere MQ можно следующей командой:
TRCMQM TRCEARLY(*YES) SET(*ON) TRCLEVEL(*DETAIL) MAXSTG(8)
Трассировку отдельного менеджера очередей запускают командой вида
TRCMQM SET(*ON) TRCLEVEL(*DETAIL) MAXSTG(8) MQMNAME(ИМЯ_МЕНЕДЖЕРА)
Остановить трассировку можно следующей командой:
TRCMQM SET(*END)
Трассировочные файлы создаются в каталоге /QIBM/UserData/mqm/trace/ файловой системы IFS (integrated file system).
Чтобы содержимое этих файлов было понятно людям, его необходимо отформатировать. Для этого в оболочке QShell перейдите в каталог с трассировочными файлами и выполните команду
dspmqtrc *.TRC
О настройке максимального размера трассировочных файлов см. в разделе "Analyzing problems" руководства WebSphere MQ для iSeries V6.0 System Administration Guide, SC34-6586.
z/OS
О поддержке трассировки в WebSphere MQ для платформы z/OS см. в руководстве WebSphere MQ для z/OS V6.0 Problem Determination Guide, GC34-6600.
