障害発生時は、出力されたエラーメッセージや障害の状況などを確認し、 原因を解析してください。
情報採取に関する機能は [ 1.1. 情報採取 ] で説明しています。また、 [ 2. 障害解析 ]では、よくある障害の状況やログ情報などの観点から障害について説明しています。
障害が特定できたら、復旧作業を行ってください。 ドメインの復旧作業に関しては、 [ 高度な管理と運用サイクルガイド > 1. バックアップ/リストア ] を参照してください。
[ 高度な管理と運用サイクルガイド > 4. 監視 ] には、異常終了の状態別に対処方法を記載しています。
ドメインプロセスの異常等により復旧が行えない場合は、 [ 1.2. ドメインの強制停止 ] を参照してドメインプロセスを強制停止してください。
WebOTXでは、 [ 1.1.1. 診断サービス ]として自動に情報収集する機能を提供しています。 診断サービスで採取できない情報や、手動で情報を取得する場合は [ 1.1.2. 手動で情報採取する場合は ] を参照して採取してください。
JavaVMのスレッドダンプは、診断サービスを利用しなくても個別に採取することができます。 [ 1.1.3. JavaVMのスレッドダンプ取得 ] を参照してください。
WebOTXでは、アプリケーションサーバに障害が起きたときに、 障害解析に必要な情報を収集する機能を「診断サービス」として提供しています。 アプリケーションサーバのログや、OSの種類やバージョン、 JVMのスレッドダンプなど様々な情報を収集することができます。
障害発生時は、この機能を利用して情報収集を行い、障害解析を行ってください。
診断サービスの機能詳細については、 [ 製品構成と提供機能 > 3. 提供機能 > 3.7. 運用管理 > 3.7.9. 診断サービス ] を参照してください。
診断サービスの設定項目と実行方法については、 [ ドメイン構築・基本設定ガイド > 10. 診断サービス ] を参照してください。
既定値では採取されない情報もあります。必要に応じて設定変更して採取してください。
ここでは、各モジュール単位に採取すべき情報について説明します。 診断サービスを利用せずに診断サービスと同等の情報採取をする場合は、 [ ドメイン構築・基本設定ガイド > 10. 診断サービス > 10.1. 診断サービスの設定 ] を参照して必要な情報採取を行ってください。
以下、各モジュール単位に採取すべき情報について説明します。
障害が発生した場合、採取すべき全ての情報について説明します。
UNIX版におけるcoreファイルの出力先は以下のようになります。
| サービス名 | プロセス名 | 出力場所 | 備考 |
|---|---|---|---|
| 運用管理エージェント | java (agent) | ${INSTANCE_ROOT}/config | |
| Webサーバ | httpd | ${INSTANCE_ROOT}/ | |
| ObjectBrokerサービス | oad | ${INSTANCE_ROOT}/config | |
| namesv | ${INSTANCE_ROOT}/config | ||
| cnamesv | ${INSTANCE_ROOT}/config | Enterpriseのみ | |
| java (oadj) | ${INSTANCE_ROOT}/config | ||
| ospprxy | ${INSTANCE_ROOT}/config | Enterpriseのみ | |
| JMSサービス | java (jms) | ${INSTANCE_ROOT}/config | |
| Transactionサービス | rcssv | ${INSTANCE_ROOT}/config |
|
| TPシステム | iioplsn | ${INSTANCE_ROOT}/logs/tpsystem |
|
| ajplsn | ${INSTANCE_ROOT}/logs/tpsystem |
|
|
| tpmonitor | ${INSTANCE_ROOT}/logs/tpsystem |
|
|
|
${INSTANCE_ROOT}/logs/tpsystem |
|
|
| TPモニタ制御サービス | oltpad | ${INSTANCE_ROOT}/logs/tpsystem |
|
WebOTXで障害を検出した場合は、イベントログ（UNIXの場合はsyslog）に障害情報を出力します。 障害が起きた場合は、まずイベントログを調査して下さい。
サーバアプリケーションが異常終了した場合は、アプリケーションログを確認して下さい。
WebOTXサーバを構成するプロセス群の起動、停止情報はhistory.actというファイルに格納されています。 何らかのプロセス障害、例えばWebOTXの起動に失敗したり、アプリケーショングループの停止に失敗した場合は、history.actを確認して下さい。
イベントログ（UNIXの場合はsyslog）への出力形式は以下の通りです。
ソースが「WebOTX_ASMonitor <TPシステム名>」または「WebOTX AS」となります。
OTXMで始まるメッセージを出力します。 フォーマットは次のようになります。
OTXM:<TPシステム名>(※1):<プロセスグループ名>(※1):<プロセスID>(※1): <種類>(※2):<メッセージ詳細>※1：省略されることがあります。 また、サーバAP以外の障害ではプロセスグループ名以外の名前が表示されることがあります。
また、WebOTX_Agentで始まるメッセージを出力します。 フォーマットは次のようになります。
WebOTX_Agent: <ロガーの種類> <メッセージ詳細>「TPSxx-yyyyy」と出力されるメッセージは、xxの部分で該当コンポーネントを特定することができます。 xxとコンポーネントの対応は以下の通りです。
サーバアプリケーションで障害が発生した場合、アプリケーションログを確認してください。
${INSTANCE_ROOT}/logs/tpsystem/<アプリケーショングループ名>/<プロセスグループ名>/<プロセスグループ名>.<プロセスID>.log
history.actファイルの所在は以下の通りです。
${INSTANCE_ROOT}/logs/tpsystem/history.act
historyは既定値では10世代まで出力されます。ファイル名は次のようになります。
history.act, history.act.1, history.act.2 ・・・
サーバで発生した障害はWindowsのイベントログ、UNIXのsyslogとWebOTX サーバのトレースファイルに出力されます。 イベントログの参照などの操作に関しては、Windows のマニュアルを参照してください。 障害の詳しい情報を採取したい場合は、トレースログを取得することにより詳細なデータを取得することができます。 トレースログはログファイルに出力されます。
プロセスグループからトレース用APIを呼び出すと、同じファイルに出力されます。
プロセスグループのトレース出力に関する設定は、統合運用管理ツールで指定します。
アプリケーションログの例を以下に示し、その見方を説明します。
:
2010/04/12 11:59:35.821|1442|001: Ok. Found keyword.
2010/04/12 11:59:35.821|1442|001: Invoking. IP=[10.20.11.2] IF=[IDL:Calc:1.0] OP=[Add] ←(6)
2010/04/12 11:59:35.821|1442|001: *** Call process_message().
2010/04/12 11:59:35.821|1442|001: StatelessLoc::preinvoke() in.
2010/04/12 11:59:35.821|1442|001: StatelessApartment::getServant() in.
(1) (2) (3) (4) (5)
Windows OS で C++アプリケーションで障害が発生した場合、障害解析にワトソンログが必要となる場合があります。例外時にワトソンログを出力させるには、統合運用管理ツールからTPシステムの[例外ハンドル]タブを選択し、「WebOTXで例外処理を行う」のチェックを外してTPシステムを再起動してください。
ただし、この設定を変更すると以下の影響があるため注意が必要です。また、OSの設定でワトソンログを採取する設定になっていない場合はコマンドプロンプトで 「drwtsn32 -i」を実行してください。 「-i」を指定すると、必要な変更がレジストリに対して行われます。
TPモニタのログ出力の設定方法は次の通りです。
--運用管理コマンドの場合--
以下のコマンドを実行してドメインを再起動します。
otxadmin> set tpsystem.collectTpmonitorTrace=true otxadmin> set tpsystem.tpmonitorTraceSize=100000
（collectTpmonitorTrace は true で採取有り、false で採取無しで、既定値はfalse）
（tpmonitorTraceSize は ログの最大行数で、既定値は100,000）
--統合運用管理ツールの場合--
以下の属性を設定してドメインを再起動します。
ドメイン再起動後、以下のログが出力されます。
${INSTANCE_ROOT}/logs/tpsystem/tpmonitor.trc
TPAのログ出力の設定方法は次の通りです。
--運用管理コマンドの場合--
以下のコマンドを実行してドメインを再起動します。
otxadmin> set tpsystem.collectTpaTrace=true otxadmin> set tpsystem.tpaTraceSize=100000
（collectTpaTrace は true で採取有り、false で採取無しで、既定値はfalse）
（tpaTraceSize は ログの最大行数で、既定値は100,000）
--統合運用管理ツールの場合--
以下の属性を設定してドメインを再起動します。
ドメイン再起動後、以下のログが出力されます。
${INSTANCE_ROOT}/logs/tpsystem/oltpad.trc
IIOPリスナは二つのトレースファイルから構成されます。 一つは通信管理部分。 もう一つは振り分け部分になります。
--運用管理コマンドの場合--
以下のコマンドを実行してTPシステムを再起動します。
otxadmin> set tpsystem.IIOPListener.collectIiopManagementLog=true otxadmin> set tpsystem.IIOPListener.iiopManagementLogSize=10240
（collectIiopManagementLog は true で採取有り、false で採取無しで、既定値はfalse）
（iiopManagementLogSize は ログファイルの最大サイズで、既定値は10,240KB）
--統合運用管理ツールの場合--
以下の属性を設定してTPシステムを再起動します。
TPシステム再起動後、以下のログが出力されます。
${INSTANCE_ROOT}/logs/tpsystem/iiopbase.log
--運用管理コマンドの場合--
以下のコマンドを実行してTPシステムを再起動します。
otxadmin> set tpsystem.IIOPListener.collectIiopControlLog=true otxadmin> set tpsystem.IIOPListener.iiopControlLogSize=32
（collectIiopControlLog は true で採取有り、false で採取無しで、既定値はfalse）
（iiopControlLogSize は ログファイルの最大サイズで、既定値は32KB）
--統合運用管理ツールの場合--
以下の属性を設定してTPシステムを再起動します。
TPシステム再起動後、以下のログが出力されます。
${INSTANCE_ROOT}/logs/tpsystem/<システム名>_IIOPLsn.log
どちらのトレースも詳細な通信ログを採取するため、性能劣化が発生します。トレースの採取が終わりましたら、設定は元に戻してください。
AJPリスナは二つのトレースファイルから構成されます。 一つは通信管理部分。 もう一つは振り分け部分になります。
--運用管理コマンドの場合--
以下のコマンドを実行してTPシステムを再起動します。
otxadmin> set tpsystem.AJPListener.collectAjpManagementLog=true otxadmin> set tpsystem.AJPListener.ajpManagementLogSize=10240
（collectAjpManagementLog は true で採取有り、false で採取無しで、既定値はfalse）
（ajpManagementLogSize は ログファイルの最大サイズで、既定値は10,240KB）
--統合運用管理ツールの場合--
以下の属性を設定してTPシステムを再起動します。
TPシステム再起動後、以下のログが出力されます。
${INSTANCE_ROOT}/logs/tpsystem/ajpbase.log
--運用管理コマンドの場合--
以下のコマンドを実行してTPシステムを再起動します。
otxadmin> set tpsystem.AJPListener.collectAjpControlLog=true otxadmin> set tpsystem.AJPListener.ajpControlLogSize=32
（collectAjpControlLog は true で採取有り、false で採取無しで、既定値はfalse）
（ajpControlLogSize は ログファイルの最大サイズで、既定値は32KB）
--統合運用管理ツールの場合--
以下の属性を設定してTPシステムを再起動します。
TPシステム再起動後、以下のログが出力されます。
${INSTANCE_ROOT}/logs/tpsystem/<システム名>_AJPLsn.log
どちらのトレースも詳細な通信ログを採取するため、性能劣化が発生します。トレースの採取が終わりましたら、設定は元に戻してください。
${INSTANCE_ROOT}/config/tpsystsem/olf.sg
をnotepadかviなどのエディタで開いてください。
トレース採取の有無、トレースファイル名、ファイルサイズを設定できます
トレースを採取する場合は、該当TPシステムのカタログディレクトリにあるvdserver.pedファイルに、以下の行を追加します。
ARGS -OltpTplibTrace F=<filename>,<line>
（filename はトレースファイル名（フルパス）で、採取時は必ず指定する）
（line は行数で、採取時は必ず指定する）
トレースを採取する場合は、該当TPシステムのカタログディレクトリにあるwosystpp.pedファイルに、以下の行を追加します。
ARGS -OltpTplibTrace F=<filename>,<line>
（filename はトレースファイル名（フルパス）で、採取時は必ず指定する）
（line は行数で、採取時は必ず指定する）
OLF/TP Adapter の詳細については、 [ WebOTX OLF/TP Adapter > 運用ガイド ] を参照してください。
${OrbRoot}/scripts/に格納されたツールを使用して情報の採取、解析を行うことができます。Windows,UNIX共通です。
コマンドを実行するには、まず環境設定を行います。
採取する情報別にコマンドを実行し情報を採取します。
情報採取用のコマンドは以下に格納されています。
${OrbRoot}/scripts/collect/
情報採取用の各種コマンドは以下のようになります。
| コマンド名 | 機能説明 | 出力情報 | 備考 |
|---|---|---|---|
| ospi_collect_installer |
インストールされているWebOTX製品のバージョン情報等の 詳細情報を採取します。 |
${OrbRoot}/scripts/logs/collect/ospi_collect_installer_info.log | 共通 |
| 登録されているWebOTX製品のライセンス情報を全て採取します。 | 共通 | ||
| ${AS_INSTALL}配下のファイルリストを採取します。 | WebOTX Application Server | ||
| ${OrbRoot}配下のファイルリスト採取します。 | Object Broker | ||
| ospi_collect_log | ${INSTANCE_ROOT}/logs配下のログファイルを全て採取します。 | ${OrbRoot}/scripts/logs/collect/all-logs/ドメイン名/logs | WebOTX Application Server |
| ${OrbRoot}/log配下のログファイル採取を全て採取します。 | ${OrbRoot}/scripts/logs/collect/all-logs/ObjectBroker | Object Broker ※Windowsの場合 | |
| ${OrbRoot}/scripts/logs/collect/all-logs/ObjectSpinner | Object Broker ※UNIXの場合 | ||
| ospi_collect_os | OSのシステム情報(OS名、OSバージョン等)を採取します。 | ${OrbRoot}/scripts/logs/collect/ospi_collect_os_info.log | 共通 |
| OSのTCP/IP情報を全て採取します。 | 共通 | ||
| OSのhosts情報を採取します。 | 共通 | ||
| ospi_collect_process | OSの全てのプロセス情報を採取します。 | ${OrbRoot}/scripts/logs/collect/ospi_collect_process_info.log | 共通 |
| OSのネットワーク情報を採取します。 | 共通 | ||
| Object Brokerサービス(oad,namesv,irsv,corbaloc,cnamesv)の ファイルディスクリプタ情報を採取します。 |
共通 | ||
| ospi_collect_setting | 登録されているWebOTX Application Server/Object Brokerの 全てのレジストリ情報を採取します。 |
${OrbRoot}/scripts/logs/collect/ospi_collect_setting_info.log | 共通 ※Windowsのみ |
| ${INSTANCE_ROOT}/config配下を採取します。 | ${OrbRoot}/scripts/logs/collect/all-conf/ドメイン名/config | WebOTX Application Server | |
| ${OrbRoot}/conf配下を採取します。 | ${OrbRoot}/scripts/logs/collect/all-conf/ObjectBroker/conf | Object Broker ※Windowsの場合 | |
| ${OrbRoot}/scripts/logs/collect/all-conf/ObjectSpinner/conf | Object Broker ※UNIXの場合 | ||
| ospi_collect_syslog | root直下を検索しcoreファイルが存在した場合のみ採取します。 | ${OrbRoot}/scripts/logs/collect/core | 共通 ※UNIXの場合のみ |
| OSのシステムログを全て採取します。 | ${OrbRoot}/scripts/logs/collect/ospi_collect_system_info.log | WebOTX Application Server | |
| ospi_collect_all | 上記のコマンドを一括実行し情報を採取 | - | - |
解析したい情報別にコマンドを実行し結果を出力します。
解析用のコマンドは以下に格納されています。
${OrbRoot}/scripts/check/
解析用の各種コマンドは以下のようになります。
| コマンド名 | 機能説明 | 出力情報 | 備考 |
|---|---|---|---|
| ospi_check_hostname | 設定されている各種ホスト名の設定とOSのホスト名との妥当性を解析し結果を出力します。 | ${OrbRoot}/scripts/logs/check/ospi_check_hostname_info.log | 共通 |
| ospi_check_log | Object Broker関連ログについてファイルサイズ、ログレベルを解析し結果を出力します。 | ${OrbRoot}/scripts/logs/check/ospi_check_log_info.log | 共通 |
| Object Broker関連ログについてエラーコード（マイナー）を解析し結果を出力します。 解析対象のログファイル名は以下になります。 oad.log,namesv.log,cnamesv.log,corbaloc.log, InterfaceRepository.log,ObLog.log, syslog.log(バックアップされたログも対象です。*_old) |
${OrbRoot}/scripts/logs/check/convminor/ ドメイン名_ログ名_convminercode_info.txt |
WebOTX Application Server | |
| ${OrbRoot}/scripts/logs/check/convminor/ ospi_ログ名_convminercode_info.txt |
Object Broker | ||
| ospi_check_ndf | Object Brokerのnamesv.ndf(backup.ndf)を解析し、結果を出力します。 | ${OrbRoot}/scripts/logs/check/ ドメイン名_ログ名_namesv.ndf_check_info.txt ドメイン名_ログ名_backup.ndf_check_info.txt |
WebOTX Application Server |
| ${OrbRoot}/scripts/logs/check/ ospi_ログ名_namesv.ndf_check_info.txt ospi_ログ名_backup.ndf_check_info.txt |
Object Broker | ||
| ospi_check_service | Object Brokerサービスの起動・停止、一時ポートの設定の有無を解析し結果を出力します。 | ${OrbRoot}/scripts/logs/check/ospi_check_service_info.log | 共通 |
| ospi_check_syslog | OSのシステムログからObject Broker関連のError,Warningを抽出し結果を出力します。 | ${OrbRoot}/scripts/logs/check/ospi_check_syslog_info.log | 共通 |
| ospi_check_timeout | Object Broker関連のタイムアウト設定値の妥当性を解析し結果を出力します。 | ${OrbRoot}/scripts/logs/check/ospi_check_timeout_info.log | 共通 |
| ospi_check_all | 上記のコマンドを一括実行し情報を解析 | - | - |
WebOTXが起動中にストール状態になる、または、コマンドからの応答がなく停止できない状態など、WebOTXが無応答状態に陥った場合には以下の手順でJava VMのスレッドダンプを取得します。
多くの場合、スレッドダンプの内容を解析することで、障害の原因を突き止めることができます。
スレッドダンプの取得方法には以下のようなものがあります。システムの動作環境や障害の状況に応じて適切な方法を選択してください。
運用管理コマンド(otxadmin)の generate-jvm-report サブコマンドを利用した方法です。本コマンドの操作に慣れているとこの方法が便利です。
利用可能なOSやJDKなどの制約はありませんが、スレッドダンプの採取にJavaヒープメモリを使用するため、該当プロセスのヒープメモリの空きが枯渇している状況では採取に失敗することがあります。
また、運用管理コマンドから取得対象のドメインに接続できない状態では本方法を実行することができません。
診断サービスによる障害解析のための情報収集機能で、スレッドダンプを取得することができます。診断機能に対する操作に慣れているとこの方法が便利です。
利用可能なOSやJDKなどの制約はありませんが、統計情報やサーバのログなどとまとめて採取されますので、それらの採取が不要な場合には不向きです。
また、運用管理ツールから取得対象のドメインに接続できない状態ではスレッドダンプの採取に失敗することがあります。
WebOTXが提供する運用インタフェースにより、単一の操作でスレッドダンプを取得します。各種運用管理ツールの操作に慣れているとこの方法が便利です。
ただし、運用管理ツールから取得対象のドメイン、または管理ドメイン(WebOTXAdmin)のいずれにも接続できない状態では、エージェントプロセスに対してこの方法は実行できません。
OSが提供するコマンドやオペレーションを用いた方法です。
動作環境や障害の状況により先述している各方法での採取ができない場合には、この方法で取得を試みます。
ただし、Windows環境では、利用するOSバージョンや動作状況により幾つかの事前作業が伴います。また、問題再発時に取得しなければならない場合があります。
JDKに付属のスレッドダンプ採取ツール(jstack、jvisualvm)を用いた方法です。これらのツールの操作に慣れているとこの方法が便利です。
動作環境や障害の状況により先述している各方法での採取ができない場合には、この方法で取得を試みます。
ただし、HP-UX環境では利用できません。
以上の取得方法について説明します。
以下の手順でスレッドダンプを採取します。
無限ループによる障害を検出するために、数秒間隔で複数回実行するようにしてください。
otxadmin> generate-jvm-report --type thread <サーバ名>
<サーバ名>には、情報取得の対象となるサーバ(Javaプロセス)の名前を指定します。 サーバ名は次のようになります。
* ドメインのエージェントプロセス : server
* プロセスグループのアプリケーションプロセス : <アプリケーショングループ名>-<プロセスグループ名>
なお、<サーバ名>が省略された場合は "server" がデフォルトとして指定されます。
詳しい取得方法については、 [ ドメイン構築・基本設定ガイド > 3. ドメイン > 3.11. Javaプロセスの監視・管理 > 3.11.3. 統計レポート出力 ] の「スレッド情報の表示」を参照してください。
以下の手順でスレッドダンプを採取します。
・ドメインのエージェントプロセスを対象とする場合
otxadmin> set server.diagnostic-service.jvm-thread-dump=true
・プロセスグループのアプリケーションプロセスを対象とする場合
otxadmin> set server.diagnostic-service.jvm-pg-stack=true
・ドメインのエージェントプロセスが起動している場合
otxadmin> generate-diagnostic-report <対象ドメイン名>
・ドメインのエージェントプロセスが起動していない場合
otxadmin> generate-diagnostic-report --local=true <対象ドメイン名>
(注) 本方法では、プロセスグループのアプリケーションプロセスに対する採取はできません。
・エージェントプロセスを対象とする場合
「<ドメイン名>」-「アプリケーションサーバ」-「診断サービス」
「JVM」タブ内の「JVMスレッドダンプ」
・プロセスグループのアプリケーションプロセスを対象とする場合
「<ドメイン名>」-「アプリケーションサーバ」-「診断サービス」
「JVM」タブ内の「プロセスグループのスタックトレース」
診断サービスを実行すると、テキストファイルにスレッドダンプが出力されます。
詳しい取得方法については、 [ ドメイン構築・基本設定ガイド > 10. 診断サービス > 10.2. 診断サービスの実行 ] を参照してください。
ユーザドメインに接続して、スレッドダンプ採取オペレーションを実行する方法です。
以下の手順でスレッドダンプを採取します。
無限ループによる障害を検出するために、数秒間隔で複数回実行するようにしてください。
次のコマンドを実行します。
・エージェントプロセスを対象とする場合
otxadmin> invoke domain.generateThreadDump
・プロセスグループのアプリケーションプロセスを対象とする場合
otxadmin> invoke tpsystem.applicationGroups.<アプリケーショングループ名>.processGroups.<プロセスグループ名>.stackTraceまたは、従来より提供しているプロセスグループ向けの専用コマンド(wostack)を使用することでも採取できます。詳しくは、[ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.6. TPシステム > 4.6.5. wostack ] を参照してください。
対象ドメインのオペレーションから「スレッドダンプの採取」を選択します。
「実行」を押下します。
スレッドダンプの出力先は以下の通りです。
Windows: ${INSTANCE_ROOT}\logs\diagnostics\jvminfo\threaddump.txt
UNIX: ${INSTANCE_ROOT}/logs/server.log
対象ドメインの該当するプロセスグループのオペレーションから「スタックトレースの採取」を選択します。
スレッドダンプの出力先はアプリケーションログおよびシステムトレースです。
ユーザドメインがストールに陥ってしまった等で運用管理ツールからユーザドメインに接続できない場合には、管理ドメインからユーザドメインのスレッドダンプを採取することができます。
なお、このオペレーションを実行するためには、管理ドメインが起動している必要があります。
(注) 本方法では、プロセスグループのアプリケーションプロセスに対する採取はできません。
以下の手順でスレッドダンプを採取します。
無限ループによる障害を検出するために、数秒間隔で複数回実行するようにしてください。
次のコマンドを実行します。
otxadmin> invoke --port <管理ドメインの管理ポート> domain.generateThreadDump <ドメイン名>
管理ドメインのオペレーションから「スレッドダンプの採取」を選択します。
スレッドダンプを採取するドメイン名を選択し、「実行」を押下します。
スレッドダンプの出力先は以下の通りです。
Windows: ${INSTANCE_ROOT}\logs\diagnostics\jvminfo\threaddump.txt
UNIX: ${INSTANCE_ROOT}/logs/server.log
(注) 管理ドメインからスレッドダンプ採取オペレーションを実行した場合、${INSTANCE_ROOT}は採取対象ドメインのドメインルートディレクトリを表します。
UNIXとWindowsについて、それぞれのスレッドダンプ採取の手順を示します。
以下の手順でスレッドダンプを採取します。
psコマンドによりドメインのJava VMを特定します。
・ドメインのエージェントプロセスを対象とする場合psコマンドの結果では、他のjavaプロセスとの区別がつきにくいため、Java VMに指定された-Xオプションを手がかりにプロセスを特定します。
ps -exf |grep java |grep <ドメイン名> |grep ' -X'
ドメインのエージェントプロセスのJava VMにはデフォルトで以下のオプションが引数に指定されています。-Dwebotx.funcid=agent がエージェントプロセスを表します。
-server -Dwebotx.funcid=agent -Ddomain.name=domain1 -Xms64m -Xmx512m -XX:NewRatio=2
・プロセスグループのアプリケーションプロセスを対象とする場合次のpsコマンドの結果を手がかりにプロセスを特定します。
ps -exf |grep THTPPJAVA2 |grep <アプリケーショングループ名>-<プロセスグループ名>
無限ループによる障害を検出するために、数秒間隔で複数回実行するようにしてください。
kill -QUIT <プロセス番号>
ドメインのエージェントプロセスの場合、スレッドダンプは ${INSTANCE_ROOT}/logs/server.log に出力されます。 プロセスグループのアプリケーションプロセスの場合、アプリケーションログおよびシステムトレースに出力されます。
Windowsでは、jstack という JDK 付属のツールを利用します。また、WebOTX AS Agent Serviceサービスからドメインを起動している場合は、jstack ツールに加えてMicrosoft社が提供する純正のフリーツールである PsExec というツールを利用します。詳細は、[1.1.3.5.1. jstackツール]を参照してください。
JDKに付属の監視ツールであるjstack、jvisualvmの各ツールを用いてスレッドダンプを取得する方法について説明します。
<ドメインディレクトリ>\config\appserv_pid
Windows: <JDKインストールディレクトリ>\bin\jstack.exe <プロセスID> >> <任意ファイル名>
UNIX: <JDKインストールディレクトリ>/bin/jstack <プロセスID> >> <任意ファイル名>
無限ループによる障害を検出するために、数秒間隔で複数回実行するようにしてください。
WebOTX AS Agent Serviceサービスからドメインを起動している場合は、jstack に加えてMicrosoft社が提供する純正のフリーツールである PsExec というツールを利用します。
(注)タスクスケジューラからWebOTXを起動する運用の場合、Windowsの仕様によりコンソールが表示されないことがあります。 その場合は、Windows標準の「AT」コマンド(「interactive」オプション指定が必要)での代用を検討してください。
事前作業
PsExec を予め次に示す URL のページよりダウンロードしておきます。
[URL] http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
なお、最初の実行時には、ライセンスの確認のためのダイアログが表示されます。表示される内容を確認の上、承諾します。
取得方法
<ドメインディレクトリ>\config\appserv_pid
PsExec.exe -s <JDKインストールディレクトリ>\bin\jstack.exe <プロセスID> >> <任意ファイル名>
無限ループによる障害を検出するために、数秒間隔で複数回実行するようにしてください。
Windows: <JDKインストールディレクトリ>\bin\jvisualvm.exe
UNIX: <JDKインストールディレクトリ>/bin/jvisualvm
無限ループによる障害を検出するために、数秒間隔で複数回実行するようにしてください。
WebOTXエージェントプロセスが何らかの原因でストールもしくは異常終了した場合に、WebOTXで起動された各サービス(Agent、JMS、Webサーバ、TPモニタ・マネージャ、Transactionサービス、ObjectBrokerサービス)のプロセスが残存することがあります。運用管理コマンドを使用し、以下の手順でドメインの強制停止を行ってください。
以下の手順でドメインを強制停止します。
stop-domainの--forceオプションと--wait_timeoutオプションを指定して、該当ドメインを停止してください(domain1の部分がドメイン名を表します)。
例)
otxadmin stop-domain --force --wait_timeout 180 domain1
--wait_timeoutオプション指定時は指定した時間[秒]だけ通常停止を試みた後、強制停止処理を実行します。
--wait_timeoutオプションを指定しない場合は--wait_timeoutオプションの既定値として1800[秒]が設定されます。
--forceオプション指定時のログは${AS_INSTALL}/domains/domain1/logs/agent/webotx_prcstop.log に出力されます。
ドメインを強制停止した後、ドメインのプロセスが残存していないか確認してください。
引数に「-Dwebotx.funcid=agent -Ddomain.name=${DOMAIN_NAME}」という文字列が指定されますのでそれが目印になります。