第3回　トラブルシューティング①

はじめに

現在のWebシステム開発・運用で踏まえるべき新しい技術的な取り組みについて、日立Cosminexus（コズミネクサス）の製品群を題材として取り上げながら解説する本連載、前回は、Java VMによるメモリ管理を中心に解説しました。

第3回の今回は、トラブルシューティングについて取り上げます。トラブルシューティングの流れからトラブルの切り分け方法までを説明します。なお、次回も引き続いてトラブルシューティングの実際について解説する予定です。

Webアプリシステムのトラブルはわかりにくい

Webアプリケーションシステムでのトラブルは、「⁠ログインできない」「⁠応答が返ってこない」「⁠処理が遅い」「⁠結果がおかしい」といった、業務に支障を来してユーザに直接影響が及ぶレベルから、ユーザには気づきにくいものの稼働管理により検知されるものまでさまざまです。またトラブルの発生個所はWebサーバやJ2EEサーバ、DBサーバ、Java VM、OSなど多岐にわたり、どこで障害が起きているのかを把握しにくいのがWebアプリにおけるトラブルシューティングの難しさです。そのため、トラブルの発生個所を正確に把握し、適切な処置を施すことが、何よりも肝要となります。

Cosminexusでは、管理サーバのManagement Serverと運用管理エージェントがシステムの稼働状況を監視することで、プロセスダウン、ハングアップ、スローダウンを早期に検知し、自律的にサーバを再起動させ、システムの停止時間を最小にします（図1⁠）⁠。

また、処理性能を極力落とさずに詳細なログを取得できるしくみを備えているため、トラブル個所の特定や障害復旧における運用管理者の負担を大きく軽減でき、Webアプリにおけるトラブルシューティング効率化を支援します。さらに、日立の統合システム運用管理JP1と連携することで、運用管理者へ詳細な障害情報を伝達することも可能です。

なお、本記事ではシステムにおける何らかの不具合（問題）の発生を「トラブル⁠」⁠、システムのトラブルのために、先に挙げた例のような業務に支障を来す状態を「障害」として考えます。主なトラブルとしては、プロセスダウン、ハングアップ、スローダウン、タイムアウト、OutOfMemoryが挙げられます。トラブルの原因は、アプリケーションのエラーやJava VMでのメモリ不足、OSの異常終了、DBサーバの無応答などが考えられます（図2⁠）⁠。

トラブルシュートの流れ

Cosminexusの場合を例にして、トラブルシューティングの流れを見ていきます。

障害が発生した場合には、原因究明よりも障害復旧を優先させます。しかし、原因究明のための解析情報を確保する必要があるため、障害発生後は速やかに障害解析情報を収集する必要があります。

なお、原因究明に際しては、ユーザモジュール、製品モジュールのどちら側で発生した問題であるかといったように、障害原因をある程度切り分けてから該当開発元への調査依頼を行います。

トラブル発生時の対処

ユーザから運用管理者に対してトラブルにより業務に支障が生じたと報告があった場合や、ユーザからの報告はなくても稼働管理においてManagement Serverで異常を検知した場合は、ユーザ側で発生している現象やメッセージからトラブルを識別します。

これを一次判別と呼びます。Cosminexusでは別プロセスでManagement Serverが稼働しているため、詳細な監視が可能という特長があります（図3⁠）⁠。

運用管理者が出力されたメッセージに従って対処できる場合は、対策して復旧します。対処できない場合やエラーメッセージが出力されない場合は、障害解析情報を収集します。障害解析情報の収集は、障害からの復旧前に実施します。これは、復旧後では情報が消えてしまうケースがあるからです。その後、システムの回復作業を実行し、SE/SIerに連絡します。

SE/SIerは、運用管理者が取得した障害解析情報をもとに、問題がユーザプログラムか製品モジュールのどちらにあるかを切り分けます。ユーザプログラムの問題であれば対処し、製品モジュールの場合は製品開発元が調査を行います。

障害解析情報の採取

障害解析情報には、トレースやメッセージなど運用時に適宜出力される「稼働情報」と、スレッドダンプやメモリダンプなど障害時を示す「障害情報」の2種類があります。これらを採取・収集するには、プロパティやツールの設定など事前準備が必要ですので、システムの運用開始前に用意しておきます。

採取する障害情報の種類は、使用しているシステムの情報（メモリ容量やCPUなどハードウェア情報、OSのバージョンおよびパッチの適用状況、Javaのバージョンなど⁠）⁠、スレッドダンプ、メモリダンプです。

Cosminexusでは、これらの障害解析情報はコマンドにより一括で収集できます。さらにManagement Serverを利用していれば、情報の採取・収集からシステム回復作業までを自動化でき、トラブルを検知するとManagement Serverが障害検知コマンドを自動実行します。コマンド自体はUNIXのシェルスクリプトまたはWindowsのバッチプログラムであるため、システムや運用の状況に合わせてカスタマイズができます。

代表的なトラブル

Webアプリのシステムにおけるトラブルの代表的なものには、次の5種類があります。

① J2EEプロセスダウン
② J2EEプロセスハングアップ
③ J2EEプロセススローダウン
④ タイムアウト
⑤ OutOfMemory障害

今回は①のJ2EEプロセスダウンにおけるCosminexusでの調査の流れを詳述し、②～⑤については次回で解説します。

J2EEプロセスダウンの調査

J2EEプロセスダウンが発生した場合は、プロセスのどこのモジュールで発生したのかを特定することがポイントになります。まずCosminexusの「エラーリポートファイル」を解析します。エラーリポートファイルにはネイティブの情報が出力されるため、メモリダンプを解析する前に状況を把握して原因を特定できる場合があります。これで特定できなければ、OSのメモリダンプを調査します。メモリダンプとは、UNIXではcoreファイル、Windowsではワトソンログとユーザダンプです（図4⁠）⁠。

エラーリポートファイルでの確認点

エラーリポートファイルでは、次の3点を確認します。

① Java VM以外の異常終了かどうか
② シグナルが発生したライブラリはどれか
③ 発生したシグナルの種別

異常終了個所がJava VMか否かは、リポートの「Anunexpected exception...」の行の末尾で判別します。ここに「outside the VM」とあればJavaVM以外、「⁠by HotSpot Virtual Machine」であればJava VMでの異常発生です。Java VMが異常終了した場合はVMのサポートに問い合わせるか、最新のパッチを探すなどしましょう。

どのライブラリでシグナルが発生したかは「Library=」の行で確認し、発生したシグナルの種別は「Unexpected Signal:」の行で判断します。シグナル種別から、ダウンしたライブラリ自体に問題があるか、呼び出し先のライブラリに問題があるかが判断できます（図5⁠）⁠。

メモリダンプの解析

エラーリポートファイルの結果から、呼び出し先のライブラリを調査する必要があると判明した場合は、メモリダンプを解析します。なお、メモリダンプの取得は、UNIXとWindowsの場合で手順が異なります。UNIX系ではcoreダンプ、Windowsではワトソンログおよびユーザダンプを取得して解析を行います。

・UNIXの場合

まずcoreファイルを開き、バックトレースを出力します。

異常終了した個所はシグナルハンドラがコールされた直後にあるので、上から順にバックトレースを見ていきます。

・Windowsの場合

Windowsでは、まずワトソンログ（drwtsn32.log）を調べます。スレッドのステートダンプで「フォールト->」が表示されているスレッドを確認し、そのスタックバックトレースで出力される「*** ERROR」の個所がダウンした関数名です。

ワトソンログで詳細がわからない場合は、ユーザダンプを使用します。そのためには、Microsoftが配布しているwindbg.exeの入手が必要です。ユーザダンプを開くとビューが開くので、「⁠~* kb」と入力して全スレッドのバックトレースを出力します。これを解析して異常終了個所を発見します。

異常終了個所は「*** ERROR」に表示されたライブラリで、異常個所はそれ以後に表示されるバックトレースの最初の行に記されています。

次回予告

本連載の次回ではトラブルシューティングの後編として、J2EEプロセスハングアップ、J2EEプロセススローダウン、タイムアウト、OutOfMemory障害のそれぞれについて、調査手順を解説します。