この章では、Sun Java System Application Server 8.2 Enterprise Edition Platform Edition のトラブルシューティングに使用できるツール、手法、および情報源について説明します。問題の評価および調査のためのガイドラインも提供します。
アプリケーションの配備、配備解除、再配備を行なったり、異なるサーバー設定を試したりしていくうちに、サーバーが混乱状態または不安定状態になることがあります。そのような場合は、よりどころとなる有効な設定が、前に保存されていると役立ちます。これ自体は問題解決策ではありませんが、まず第一に問題を回避するための方法です。
Application Server の asadmin コマンドには、指定したドメインをバックアップする backup-domain オプションがあります。このオプションを使用して、サーバー設定の定期的な「スナップショット」を取ってください。その後、必要な場合には、restore-domain オプションを使用して 1 つ以上のドメインを正常に機能する既知の状態に復元します。
asadmin backup-domain および restore-domain オプションの詳細な使用手順については、『Application Server 管理ガイド』を参照してください。ただし、この『トラブルシューティングガイド』の目的の範囲内で、サーバー設定のバックアップおよび復元手順の概要を次に示します。
Application Server を起動します。
install_dir/bin/asadmin start-domain domain_name |
ドメインを停止します。
install_dir/bin/asadmin stop-domain domain_name |
ドメインをバックアップします。
install_dir/bin/asadmin backup-domain domain_name |
デフォルトでは、バックアップしたディレクトリは install_dir/backups ディレクトリに保存されます。
Application Server の設定またはドメイン、あるいはその両方に必要な変更を加えます。
必要に応じて、サーバーやドメインの設定を、前記手順 3 で保存した状態に復元します。
install_dir/bin/asadmin restore-domain --filename backup_file domain_name |
一般に、J2EE アプリケーションサーバーは、複雑で高度に洗練されたオペレーティング環境に配備されます。Sun Java System Application Server は、Java、Java サーブレット、XML、JSP、JDBC データソース、EJB テクノロジなど、幅広いテクノロジに対応しています。Application Server と関連するほかの製品およびツールは、LDAP、Web Server、Sun Java System Message Queue、配備および移行ツールなどです。多数の本質的に異なるコンポーネントが関係する複雑な問題を理解および診断するには、十分な知識と注意深い診断プロセスが必要です。
次に示す情報のいずれかまたはすべてを収集すれば、問題を分類して解決策を探すことが容易になります。システム情報の収集には、Solaris の pkginfo や showrev、Linux の rpm など、オペレーティングシステムのユーティリティーが役立ちます。
オペレーティングシステムとインストールされている製品の正確なバージョン番号を確認します。
パッチが適用されているかどうか調べます。適用されている場合は、製品およびオペレーティングシステムのパッチ番号を指定します。
システムの構成を調べます。
システムが備えるシステムリソース (メモリー、ディスク、スワップ空間など) について調べます。
インストールされているアプリケーションサーバー、Web サーバー、およびディレクトリサーバーの数を調べます。
Web サーバーと Application Server との接続方法について調べます。それらは同じマシン上にありますか ?
Application Server とディレクトリサーバーとの接続方法について調べます。
アプリケーションサーバーがクラスタ化されているかどうか調べます。
アップグレードが行われたかどうか調べます。すでに行われている場合は、ソースバージョンとターゲットバージョンを確認します。
移行が行われたかどうか調べます。すでに行われている場合は、ソースバージョンとターゲットバージョンを確認します。
新しいアプリケーションが配備されたかどうか調べます。
SSL に対応しているかどうか調べます。
HADB および使用しているバックエンドデータベースのバージョンを確認します。
データベースのアクセスに使用している JDBC ドライバを特定します。
使用している JDK のバージョンを確認します。
JVM のヒープ、スタック、およびガベージコレクション関連のパラメータの設定値を確認します。
JVM オプションを確認します。
インストールで使用されているサードパーティーのテクノロジについて調べます。
相互運用コンポーネントのバージョンが、リリースノートに記載された互換表に適合しているかどうか調べます。
これらの情報を収集したあと、次の作業を行います。
Web サーバーのエラーおよびアクセスログのデータを収集します (Web サーバーインスタンスによって異なる)。
Application Server のスタックトレースを収集します。特定の問題に関連するログの最新セットが稼働するように注意してください。これにより、何ギガバイトもの無関係なログ情報を走査することを避けることができます。
その問題を解決するためにすでに実行した可能性のある手順を含め、問題の最初の出現時に発生したイベントのシーケンスを調べます。
問題を特定し、何が間違っているかについて予備的な仮説を立てると、調査を行う準備が整います。
この節では、次のトピックについて説明します。
もっとも明白な解決法が見過ごされている場合も少なくありません。したがって、最初の手順はシステム設定を確認することです。最新のシステム要件と依存関係については、『Sun Java System Application Server 8.2 リリースノート』を参照してください。
メッセージには通常、試行されたアクション、アクションの結果、さらに場合によっては障害や失敗の原因に関する情報が含まれています。
ログファイルに含まれている一般的なメッセージエントリの種類は、次のとおりです。
エラー – これらのメッセージは、状態が「失敗」と報告される要因となる重大な失敗を示します。エラーメッセージには、通常、発生した問題の性質および原因についての詳細な情報が示されます。
警告 – これらのメッセージは重大でない失敗を示します。警告メッセージには、通常、失敗の原因および性質についての情報が含まれ、考えられる救済策も示されます。
情報 – これらのメッセージは、各タスクが正常に完了したことを示します。
アプリケーションの続行を妨げる問題には、通常、エラーメッセージが伴います。
何が間違っているか、およびそれを修正することが可能な場合、何を行う必要があるかについて、メッセージの内容がきわめて明白な場合もあります。たとえば、asadmin start-domain コマンドを使用してドメインを起動する場合、ドメインが起動済みになったあとに不注意で同じコマンドを再度実行すると、次のメッセージが表示されます。
userD:\\Sun\\studio5_se\\appserver8\\bin\>asadmin start-domain Domain already started : domain1 Domain domain1 Started.
この場合、メッセージに示される明白なガイダンスに従って、問題を無視することができます。
問題または解決法についての全般的な情報のみを表示するエラーメッセージや、複数の可能性を提示するエラーメッセージもあります。次に例を示します。
[16/Jun/2003:22:20:50] SEVERE ( 2204): WEB0200: Configuration error in web module [JAXBProjectStudio] (while initializing virtual server [server1]) com.iplanet.ias.config.ConfigException: Failed to load deployment descriptor for: JAXBProjectStudio cause: java.io.FileNotFoundException:
この場合は、問題が明確でないか、複数の点で間違いが存在する可能性があります。さまざまな可能性とともに、おそらく多くの解決策を検討することが必要になる可能性があります。時間や費用のかかる解決法が提案された場合、実際に何かを行う前に、その解決法で成功するという確信を得るための手順を踏んでください。
問題の解決に役立たず、ガイダンスもほとんど示されないエラーメッセージもあります。次に例を示します。
[23/Jun/2003:16:50:45] WARNING ( 1972): for host 127.0.0.1 trying to GET /SupplierServiceClient1/ SupplierServiceClient1_SOAP.html, send-file reports: HTTP4144: error sending D:/Sun/studio5_se/appserver8 /domains/domain1/server1/applications/j2ee-modules/SupplierServiceClient1_1/SupplierServiceClient1_SOAP.html (Overlapped I/O operation is in progress.) status=1:5
この場合、対策を取るための情報はほとんどありません。何か行う前に、エラーの原因となった正確な状況と現れた症状を把握することはきわめて重要です。
Application Server のすべてのエラーメッセージの説明については、次の場所にある『Sun Java System Application Server Error Message Reference』を参照してください。
多数の Application Server サブシステムでログファイルが作成され、イベントがそれらのファイルに記録されます。これらのログファイルの主な目的は、トラブルシューティング情報を提供することです。
記録されたメッセージから、メッセージテキストに加えて次の情報を得ることができます。
イベントの日時
イベントのログレベル — Application Server によって指定されたログレベル ID または名前
プロセス識別子 (PID) — Application Server プロセスの PID
(オプション) 仮想サーバー識別子 (VSID) — メッセージの生成元 VSID
メッセージ識別子 (MID) — サブシステムと 4 桁の整数
メッセージデータ
Application Server の各問題分野に関連する固有のログについては、このマニュアルの関連する章を参照してください。
Application Server の 管理 GUI では、さまざまなログレベルを設定できます (FINEST、FINER、FINE、CONFIG、INFO、WARNING、SEVERE、ALERT、および FATAL)。ログレベルを FINEST に設定するとすべてのメッセージが記録され、ログレベルを FATAL に設定すると重大なエラーメッセージのみが出力されます。
詳細なログレベル (FINEST、FINER、FINE) では、ある特定のイベントのログ情報が大量に生成されるため、一見すると、実際には存在しなくてもエラー条件が存在するように見えることがあります。
デフォルトレベルの INFO より重大でないログレベル (FINEST、FINER、FINE、および CONFIG) のすべてのメッセージには、デバッグに関連する情報が含まれているので、特定して有効にする必要があります。これを行う手順については、『Sun Java System Application Server 管理ガイド』を参照してください。
Application Server には、標準の JDK ログレベルに加えて、Application Server ログファイル (server.log) との関係を直観的に把握でき、Solaris と緊密に統合するように考案されたログレベルが追加されています。ログレベル ALERT および FATAL は Application Server に固有なログレベルで、JDK1.4 のログ API には実装されていません。
Microsoft Windows オペレーティング環境で使用されるイベントログ機構については、キーワード「イベントログ」で Windows ヘルプシステムを索引検索してください。Windows server.log ファイルにログを送信する場合、ログレベル INFO、WARNING、SEVERE、ALERT、または FATAL のメッセージのみが Windows イベントログに記録されます。
管理 GUI は次の 2 つのログオプションを提供します。
オプション 1 — stdout (System.out.print) コンテンツをイベントログに記録する
オプション 2 — stderr (System.err.print) コンテンツをイベントログに記録する
これらのオプションを設定すると、stdout と stderr のメッセージが server.log ファイルに出力されます。イベントログは、Solaris では syslog デーモン、Microsoft Windows ではイベントログです。
前記のオプションを設定しないと、次のように動作します。
stdout または stderr に書き込まれる (つまり、System.out または System.err を使用する) すべての情報が、ログに表示されない。
JDK ロガーで記録されたメッセージがログに表示される。
stdout または stderr に書き込まれるメッセージは INFO レベルとして表示されるが、メッセージ ID は付かない。
アプリケーションクライアントコンテナ (ACC) には、ローカルファイルにのみ出力可能な独自のログサービスがあります。通常、ACC は、Application Server とは別のホスト上の独自のプロセスで実行されます。ログインフラストラクチャーとログファイルは ACC 固有のものです。ACC の設定は、sun-acc.xml ファイルに格納されています。詳しくは、『Sun Java System Application Server Developer's Guide』を参照してください。
ここでは、Application Server 8.2 のスレッドダンプを取得する方法について説明します。デフォルトでは、サーバーからコアファイルがダンプされ、server.xml ファイルにある -Xrs java-option フラグに従って再起動が行われます。
UNIX でサーバースレッドダンプを取得する方法は次のとおりです。
影響を受けるサーバーインスタンスの server.xml ファイルに -Xrs java-option フラグが含まれていないことを確認します。含まれている場合は、-Xrs java-option フラグを削除します。
オプションが変更されている場合は、サーバーインスタンスを再起動します。
ps コマンドを使用して、アプリケーションサーバーが稼働している java プロセスまたは appservDAS プロセス、あるいはその両方を特定します。
アプリケーションサーバーインスタンスで次のコマンドを実行します。
kill -3 pid |
この kill コマンドで、スレッドダンプがサーバーインスタンスの server.log ファイルにリダイレクトされます。
Windows でサーバースレッドダンプを取得する方法は次のとおりです。
サーバーインスタンスの server.xml ファイルに -Xrs java-option フラグが含まれていないことを確認します。含まれている場合は、-Xrs java-option フラグを削除します。
オプションが変更された場合は、Application Server を再起動します。
「Application Server」ウィンドウで ctrl-brk を入力します。スレッドダンプがインスタンスの server.log ファイルにリダイレクトされます。
最初にこの『トラブルシューティングガイド』に目を通して、その問題が扱われているかどうか確認することをお勧めします。扱われているなら、適切な解決法を選択します。多くの解決法では、詳細な説明や例については、Application Server のマニュアルセット内のほかのマニュアルを参照するように指示されています。
トラブルシューティングする製品の該当バージョンの『リリースノート』を読むことから始めます。
この Application Server 製品リリースのマニュアルは、次の場所から入手できます。
http://docs.sun.com/db/coll/ApplicationServer81
Application Server のマニュアルの詳細については、「Application Server のマニュアルセット」を参照してください。
ナレッジベースは、製品の問題に関する記事を集めたもので、トラブルシューティングに役立つ情報が含まれています。ナレッジベースを利用するには、次の手順に従います。
SunSolve Online に移動します。
「SunSolve Collections」で「Search Collections」リンクをクリックします。
検索するコレクションのチェックボックスを選択します。
「次へ」をクリックします。
検索基準を入力します。
「検索」をクリックします。
オンラインフォーラム内で直接検索するか、ログインおよび登録してメッセージを投稿できるようにします。Application Server のオンラインフォーラムは、次の場所にあります。http://swforum.sun.com/jive/index.jsp?cat=7
必要な場合は、これまでに取得した情報を手元に用意して、テクニカルサポート http://www.sun.com/service/contacting までお問い合わせください。