WMB虎の巻: 第9回「WMBトラブル・シューティング 」

最終回である今回は、WMBのトラブル・シューティングについてご紹介します。

1. 問題状況の確認

WebSphere Mesage Broker(以下WMB)の構成時やアプリケーション開発時、メッセージの処理中にエラーが発生した場合にどこを確認するか、またどのようにデバッグするか、といった問題判別の概要についてご案内します。

確認項目として

  • エラーメッセージは出力されていないか?
  • 処理されたメッセージが予期したとおりになっているか?
  • メッセージがフロー内の意図した経路をたどっているか?

などがあります。

この章では問題が起きたときに、解決の糸口になることが期待されるログやトレース当の資料や、作成したアプリケーションのデバッグのために提供されているツールについてご案内いたします。

なお、問題判別についてはマニュアルにも記載があります。以下のWMBマニュアルもあわせてご参照ください。


2. WMBのログ

製品が問題なく稼動しているかどうか確認するため、問題が起きた際にどんな問題がどのような原因で起きたかを確認するために、ログを確認することがあります。

WMBでは通常使うログには製品独自のロギングの機能はなく、OSのロギング機能に依存します。Windowsでは製品を導入するだけで、特に設定を行なわなくてもアプリケーションログに記録されます。
LinuxおよびUnixシステムではログメッセージはsyslogサブシステムに送られるため、あらかじめsyslogデーモンを稼動させておく必要があります。

2.1 syslogの設定 (LinuxおよびUnixシステムのみ)

WMBは、オペレーティング・システム上で syslog コマンドを呼び出しますが、出力宛先用に定義されたフィルターに対応するメッセージだけが表示されます。 すべての WMBのログメッセージを記録するには、レベル info 以上のメッセージに対して user ファシリティーにフィルターを作成します。 syslog.conf ファイル内に以下の行を加えてください。

user.info /var/log/user.log

設定しましたらsyslogデーモンを再始動させてください。
InfoCenterの"Linux および UNIX システム: syslog デーモンの構成"の項目も合わせてご確認ください。

2.2 Windows環境でのログの確認

既にご案内しましたようにWindows環境ではイベントビューアのアプリケーションログに記録されます。"ソース"の箇所にFixpackレベルまで含めたバージョン情報がでます。イベントの箇所に出ている4桁の数字がBIPメッセージの数字4桁の箇所に相当します。

例) Windows環境イベント ビューアのアプリケーションログに記録されているWMBのメッセージ。
例) Windows環境イベント ビューアのアプリケーションログに記録されているWMBのメッセージ。

2.3 WMBメッセージの確認

syslog,またはアプリケーションログ内のメッセージを確認します。メッセージに関する説明は、WMBのInfoCenter"診断メッセージ"をご確認ください。

BIPメッセージの番号は、以下のようにカテゴリ分けされています。

BIP0000-0999: ツールキット
BIP01000-01999: ブローカー・アーカイブ
BIP1000-1999: 構成
BIP2000-2999: ブローカー
BIP3000-3999: 組み込みノード
BIP4000-4999: 組み込みノード
BIP5000-5999: パーサー
BIP6000-6999: WebSphere MQ パーサー
BIP7000-7999: パブリッシュ・サブスクライブ
BIP8000-8999: コマンド
BIP9000-9999: z/OS

2.4 Java関係のログ

WMBでは内部的にJavaを使用しています。この内部的に使用しているJavaが記録するログがあります。Windowsではconsole.txtというファイルが作成されています。Unixではstdoutとstderrの2つのファイルがあります。
出力ディレクトリは、以下の通りです。

【Windowsの場合】
%MQSI_WORKPATH%\components\<Broker_Name>\<EG_uuid>
(デフォルトだとC:\Documents and Settings\All Users\Application Data\IBM\MQSI\components\<Broker_Name>\<EG_uuid>)

【Unixの場合】
/var/mqsi/components/<Broker_name>/<EG_uuid>

参考)
EG_uuidは、実行グループに紐付けられているIDのことです。WMBでは実行グループを作成する時に名前をつけますが、内部では自動的に割り振られたUUIDで管理されています。WMBv7であればブローカーが稼動している状態でmqsilistコマンドにブローカー名と"-d 2"のオプションを与えることで実行グループ名とUUIDの関係を確認することができます。

例)ブローカー"MBK1"の実行グループの一覧を詳細に出力させる。

$ mqsilist MBK1 -d 2
-----------------------------------
BIP1286I: ブローカー 'MBK1' の実行グループ 'default' が実行中です。

実行中のメッセージ・フローの数: '1'。
プロセス ID: '1310894'
UUID: '6f3aca77-2d01-0000-0080-eec626c76a20'
簡略説明: ''
詳細説明: ''

-----------------------------------

2.5 abendファイル

WMBのプロセスが異常終了してしまった場合、abendファイルが作成されることがあります。出力ディレクトリは、以下の通りです。

【Windowsの場合】
%MQSI_WORKPATH%\common\errors

(デフォルトだとC:\Documents and Settings\All Users\Application Data\IBM\MQSI\Common\errors)

【Unixの場合】
/var/mqsi/common/errors

ファイル名は

(DataFlowEngine以外) <Broker_name>.<component_name>.<PID>.<threadID>.abend
(DataFlowEngine) <Broker_name>.<EG_UUID>.<PID>.<threadID>.abend

abendファイル内には異常終了の原因となったシグナル番号やエラー番号、スタック情報やプロセスに設定されている環境変数等が記載されます。一般的に、このファイルはサポートセンターに送付し、障害解析のために利用されます。

2.6 サービス・トレース

製品の動作が仕様を満たしていないことが疑われるときや、異常終了といった問題を調べるために、WMBではサービストレースというものがあります。サービストレースは製品そのもののデバッグを行なうためのものなので、後述するユーザーが作成したアプリケーションをデバッグするときには使いません。通常、サービストレースはサポートセンターから取得を依頼されたときに取得してください。

以下に取得例を示しますが、通常サポートセンターがサービストレースの取得を依頼するときは、取得手順の指示がありますので基本的にはサポートセンターの指示に従って取ってください。

例)ブローカー"MBK1"の実行グループ"default"で、40MBのサービストレースを取得する

mqsichangetrace MBK1 -t -e -l debug -m safe -c 40000 -r

問題を再現させたらトレースを停止します。

例)ブローカー"MBK1"の実行グループ"default"にしかけたサービストレースを停止する

mqsichangetrace MBK1 -t -e -l none

トレースを停止したらファイルへの書き出しを行ないます。

例) ブローカー"MBK1"の実行グループ"default"で取得したトレースをtrace.xmlというファイルに書き出す

mqsireadlog MBK1 -t -e default -f -o trace.xml

ファイルに書き出されたトレースはxmlフォーマットになっています。xmlフォーマットのトレースをトレース形式のフォーマットに変更します。

例) trace.xmlファイルをトレースフォーマットであるtrace.logに変更する。

mqsiformatlog -i trace.xml -o trace.log

サービス・トレースについてはInfoCenterの"サービス・トレース"の項目をご確認ください。またサービストレースはMBエクスプローラからでも停開始が可能ですが、MBエクスプローラからではトレースサイズの変更ができないため、サポートセンターから取得を依頼されるときはコマンドでの取得になることがほとんどです。コマンドでの取得を依頼されたときはその指示に従ってください。


3. アプリケーションのデバッグ

WMBではメッセージフローやメッセージセットを開発していくうえで、便利なデバッガーがいくつか提供されています。メッセージフローやメッセージセット開発においてデバッグが必要な場面に遭遇した時は、以下に紹介するデバッガーを用いて問題を解消していくことができます。

3.1 トレースノード

トレースノードとは、メッセージフロー内に配置するIBMプリミティブ・ノードの1つで、トレースノードをメッセージ・フローに追加することで、ファイル、ユーザー・トレース、またはシステム・ログにデバッグ・メッセージを書き込むことができ、またメッセージ・フローがいくつかのデータを処理した後にそれらのメッセージを確認することができます。

例)トレースノードのアイコン
例)トレースノードのアイコン

トレースノードを組み込むと、そのノードを通過した時点でのメッセージやtimestampといった情報を出力させることができるので、その時点での処理されたメッセージが意図したとおりのものになっているかどうか確認することができます。

例)テキストファイルに書き出したトレースノードの出力
例)テキストファイルに書き出したトレースノードの出力

トレースノードでは、メッセージの処理において起きたエラーの情報としてBIPメッセージの番号と引数を出力させることもできます。

v6.1ではトレースノードを含めたメッセージフローを配置させるとトレースを取得し続けますが、v7.0ではmqsichangetraceコマンドでトレースノードの機能を動的にOn/Off切り替えることができます。メッセージ・フローをテストし、その動作が適正であることを確認したら、トレースノードをメッセージ・フローから除去するか、またはオフに切り替えます。トレースノードについてはInfoCenterのTrace ノードの項目も合わせてご確認ください。

3.2 ユーザー・トレース

ユーザー・トレースは、アプリケーションをデバッグするときに使用し、デプロイされたメッセージフローをトレースできます。メッセージの処理中にエラーが発生すると、例外がユーザー・トレースに書き込まれます。エラーがメッセージ・フロー内にキャッチされない場合は、システム・ログにも書き込まれます。ユーザー・トレース内の各エントリーには、接頭部に「BIP」が付いています。インフォメーション・センターで BIP メッセージを検索できます。

ユーザートレースのOn/OffはMBエクスプーラー(v6.1ではブローカー・ツールキット) から実行できます。標準、もしくはデバッグを選ぶとトレースが開始されます。

例)MBエクスプローラーからユーザートレースの停/開始の選択
例)MBエクスプローラーからユーザートレースの停/開始の選択

トレースを停止したら、トレースログのファイルへの書き出し、フォーマットを行います。 トレースログのファイルへの書き出し、フォーマットの手順はサービストレースと同じですが、一部オプションが異なるので注意が必要です。

例) ブローカーMBK1の実行グループdefaultで取得したユーザートレースのファイルへの書き出し方法。出力ファイル名はdebug.xml

mqsireadlog MBK1 -u -e default -o debug.xml

ファイルに書き出されたトレースはxmlフォーマットになっています。このままでもかまいませんが、トレースフォーマットに変更する際にはサービストレースのフォーマットでも用いたmqsiformatlogコマンドを用います。

例) mqsireadlogコマンドでファイルに書き出したdebug.xmlファイルをフォーマットする。出力ファイル名はdebug.txt

mqsiformatlog -i debug.xml -o debug.txt

3.3 フローデバッグ

ステップバイステップでメッセージが処理されていく様子を確認する必要がある場合はフローデバッグの機能があります。このフローデバッグの機能を使うとメッセージフロー内に設定したかくブレイクポイントごとのメッセージの様子をリアルタイムに確認することができ、各ノードごと、またESQL内ではESQL1行ごとの処理を見ていくこともできます。

フローデバッグを行うためには、予め実行グループにデバッグ用のポートを空けておく必要があります。MBエクスプローラーからデバッグしたいメッセージフローが配置されている実行グループを右クリックして、プロパティ画面を開きます。"拡張済み"を選択すると一番上に"フロー・デバッグ・ポート"がありますので、そこにあけさせる適当なポート番号を入れてください。OKボタンを押すと実行グループが自動的に再起動されます。

実行グループが再起動しましたら、ブローカーツールキットから実行グループを選択して右クリックして"デバッガーを起動する"を選択して開始します。メッセージフローにデバッグポイントを設定した上でメッセージを流すと、ツールキットがデバッグパースペクティブに切り替わります。


4. WMB問題解決の方法ヒント

WMBでの問題解決になりえる方法についてまとめてあります。

4.1 マニュアルやその他関連資料を読む

問題解決に限りませんが、正しい設定や機能の理解を深めるためにもマニュアルは必要です。製品にもドキュメンテーション・パッケージが含まれておりますので、お手持ちのPCに導入して参照することもできますが、外部WebでもWMB V7インフォメーション・センターとしてマニュアルを公開しております。左ナビの先頭にあるWebSphere Message Brokerタイトルをクリックすると、WMBで提供されているマニュアル一覧が表示されますので、そこから読みたいマニュアルを選択していきます。

4.2 サポート・センターに問い合わせる

正規のWMBのライセンスをお持ちであり、かつメンテナンス契約(ソフトウェア・サブスクリプション&サポートといいます)がその時点で有効なものをお持ちであるお客様は、MQについてのテクニカルQAや障害に関する問い合わせや報告をIBMのサポート・センターに対して行うことができます。(古いバージョンでは、製品としてのサポートが切れている場合もあるのでご注意ください。)お問い合わせにはサポートIDが必要です。WMBの問い合わせ先は、WebSphereブランド製品の窓口になります。

電話での窓口対応は、障害報告かつその緊急度が最高のものでない限り、通常の業務時間内に限られますが、Webでの問い合わせ(現在サービス・リクエストと呼ばれるインターフェースが用意されています)は24時間使用可能です。

パスポート・アドバンテージ(PA)の契約をお持ちであれば、製品のサポートを受けることができます。製品サポートへのお問い合わせ方法ついては、お電話もしくはWeb上からお問い合わせいただくサービス・リクエスト(SR)というものがございます。SRについては以下のリンクをご覧ください。

サービス・リクエスト(SR)

4.3 WMB研修に出る

日本アイ・ビー・エム人財ソリューション株式会社でWMBの研修コースを用意しています。(有料) WMBの設定やプログラミングの基本を一から学習したい場合にお奨めです。

4.4 WMBのサポートWebで調べる

4.4.1 WMBサポートWeb(US)の検索方法

無料で利用できる問題解決の方法としては、WebでのWMBナレッジ・ベースの検索があります。

日本語での"ソフトウェア技術検索メニュー"もありますが、無料で最もWMBでの問題解決の可能性の高い方法は、WMBの開発元のハーズレー(イギリス)で提供している、"WMBのサポートWeb"を検索することです。掲載されている情報は全て英語ではありますが、世界中から集まってくるWMBの障害に対する修正報告や、開発元からのヒント&チップスがここに集められてきますので、一番早く問題が解決する可能性があります。

英語で検索するのに慣れていない方は、まずはWMBでのBIPメッセージ番号やバージョン、プラットフォームの名前(RHEL, AIX, HP-UX等)、使用しているノード名やESQLの関数名など検索結果を絞り込めるようなキーワードを指定してみましょう。

ご自分の問題に当てはまる文書をTechnote(技術文書)に見つけた場合、Resolving the problem(問題の解決策)の項目に、問題の回避策や、正しい設定方法が書かれている場合があります。

また、問題に対する修正が既に出ている場合もあります。タイトルの最初に7桁の番号(APAR番号といいます)が書かれているものは問題に対する修正の番号です。Fixes are availableと書いてある場合には、問題に対するFixがFixPackの中に組み込まれていることを示します。FixPackとは開発元が出している障害ご自分のバージョンに対するFixのリンクをクリックすると、そこからダウンロード・サイトにたどり着くことができます。

FixPackのダウンロードサイトなど、サポートサイトの中で、以下のようなIBM IDとパスワードの入力を要求されることがありますが、この登録は無料で行うことができます。registerのリンクをクリックします。

4.4.2 サポートWeb(US)からFixPackの入手

問題を最小にするためにあらかじめ製品を導入する際にその時点で提供されている最新のFixPackを入手するのもサポートWeb経由で可能です。FixPackというのは累積パッチのことで、MQでは四半期に一回程度の周期で新しいFixPackがリリースされます。最初にMQを導入する際、あるいはテスト環境でMQに起因すると思われる障害が発生した場合にはその時点でリリースされている最新のFixPackを適用することをお勧めします。現状で適用を推奨しているFixPackのリストが"Recommended fixes"という名前でサポートWebに用意されています。

4.4.3 MQ障害時に集めるべきデータ(MustGather)

障害に際して収集する必要のあるデータの内容についてはこの8章で述べていますが、MQの場合プラットフォームが多岐に渡り、UNIXやLinux、Windowsといったプラットフォーム以外のものもあります。プラットフォームのOSの特性によってデータの場所や収集の手段が異なる場合がよくあります。そういった場合に役に立つのがMustGatherです。MustGatherは障害解析に必要なデータ収集のことをいいます。さきほどのサポートWebの検索画面で、MustGatherと入力してください。いろいろなシチュエーションでのMustGatherがリストされます。ただ100以上ありますので、まずは"MustGather: Read first for WebSphere Message Broker"を見てください。各プラットフォームのいろいろなシチュエーション毎のMustGatherのリンクが用意されています。


5. まとめ

以上9回にわたって、導入と構成、アプリケーションの設計、運用監視など、WMB虎の巻として連載してきました。いかがだったでしょうか。
WMBは今後も、効率的なソリューションを検討できるシステム連携基盤として、皆様にご提供できる製品となっています。
当記事が、皆様のWMB構築プロジェクトの参考にしていただけますと幸いです。
9回にわたってお付き合いいただき、ありがとうございました。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=659385
ArticleTitle=WMB虎の巻: 第9回「WMBトラブル・シューティング 」
publish-date=05192011