1. 障害時の操作

障害発生時は、出力されたエラーメッセージや障害の状況などを確認し、 原因を解析してください。

情報採取に関する機能は [ 1.1. 情報採取 ] で説明しています。また、 [ 2. 障害解析 ]では、よくある障害の状況やログ情報などの観点から障害について説明しています。

障害が特定できたら、復旧作業を行ってください。 ドメインの復旧作業に関しては、 [ 高度な管理と運用サイクルガイド > 1. バックアップ/リストア ] を参照してください。

[ 高度な管理と運用サイクルガイド > 4. 監視 ] には、異常終了の状態別に対処方法を記載しています。

ドメインプロセスの異常等により復旧が行えない場合は、 [ 1.2. ドメインの強制停止 ] を参照してドメインプロセスを強制停止してください。

1.1. 情報採取

WebOTXでは、 [ 1.1.1. 診断サービス ]として自動に情報収集する機能を提供しています。 診断サービスで採取できない情報や、手動で情報を取得する場合は [ 1.1.2. 手動で情報採取する場合は ] を参照して採取してください。

JavaVMのスレッドダンプは、診断サービスを利用しなくても個別に採取することができます。 [ 1.1.3. JavaVMのスレッドダンプ取得 ] を参照してください。

1.1.1. 診断サービス

WebOTXでは、アプリケーションサーバに障害が起きたときに、 障害解析に必要な情報を収集する機能を「診断サービス」として提供しています。 アプリケーションサーバのログや、OSの種類やバージョン、 JVMのスレッドダンプなど様々な情報を収集することができます。

障害発生時は、この機能を利用して情報収集を行い、障害解析を行ってください。

診断サービスの機能詳細については、 [ 製品構成と提供機能 > 3. 提供機能 > 3.7. 運用管理 > 3.7.9. 診断サービス ] を参照してください。

診断サービスの設定項目と実行方法については、 [ ドメイン構築・基本設定ガイド > 10. 診断サービス ] を参照してください。

既定値では採取されない情報もあります。必要に応じて設定変更して採取してください。

1.1.2. 手動で情報採取する場合は

ここでは、各モジュール単位に採取すべき情報について説明します。 診断サービスを利用せずに診断サービスと同等の情報採取をする場合は、 [ ドメイン構築・基本設定ガイド > 10. 診断サービス > 10.1. 診断サービスの設定 ] を参照して必要な情報採取を行ってください。

以下、各モジュール単位に採取すべき情報について説明します。

1.1.2.1. 共通

障害が発生した場合、採取すべき全ての情報について説明します。

エージェントログファイル

${INSTANCE_ROOT}/logsディレクトリのファイル全て

イベントログ情報(UNIXはsyslog)

(Windows) イベントログ(アプリケーション、システム)

(HP-UX) /var/adm/syslog/syslog.log

(Solaris) /var/adm/messages

(Linux) /var/log/messages

プロセス異常終了情報

(Windows)

ワトソンログ %SystemDrive%\Documents and Settings\All Users\Documents\DrWatson

クラッシュダンプ %SystemDrive%\Documents and Settings\All Users\Documents\DrWatson\user.dmp

JavaVM が出力するエラーリポート hs_err_pid<プロセスID>.log

(UNIX)

JavaVM が出力するエラーリポート hs_err_pid<プロセスID>.log

coreファイル(gdbなどのツールでcoreからスタックトレースを採取してください)

UNIX版におけるcoreファイルの出力先は以下のようになります。

1.1.2.2. HTTPサーバ

${INSTANCE_ROOT}/logs/WebServerディレクトリのファイル全て

(access.log/error.log等)

${INSTANCE_ROOT}/config/WebServerディレクトリのファイル全て

(httpd.conf/ssl.conf等)

1.1.2.3. Webコンテナ

${INSTANCE_ROOT}/logsディレクトリのファイル全て

1.1.2.4. EJBコンテナ

• Expressの場合

${INSTANCE_ROOT}/logsディレクトリのファイル全て

• Standard/Enterpriseの場合

${INSTANCE_ROOT}/logsディレクトリのファイル全てと、${INSTANCE_ROOT}/logs/tpsystem配下の全ファイル

Standard/EnterpriseのEJBコンテナの詳細ログを採取する場合は、プロセスグループのトレースレベルを7に設定してください。

1.1.2.5. ＪＮＤＩサービス

${INSTANCE_ROOT}/logs/jndi/webotx_jndisp.log

1.1.2.6. JMS

${INSTANCE_ROOT}/wojms/instances/wojmsbroker/props/config.properties

JMSサーバに関する設定情報が格納されるファイルです。
診断サービスで採取されません。

${INSTANCE_ROOT}/logs/wojms/wojmsserver.log

JMSサーバに関する動作がロギングされるファイルです。ファイルの切り替えが発生すると、wojmsserver.log,wojmsserver_1.log,…,wojmsserver_9.logという名前（デフォルトで最大10個）のファイルが作成されます。

${INSTANCE_ROOT}/logs/wojms/wojmsadmin.log

JMSサーバに対する運用管理操作の履歴がロギングされるファイルです。ファイルの切り替えが発生すると、wojmsadmin.log,wojmsadmin_1.log,…,wojmsadmin_9.logという名前（デフォルトで最大10個）のファイルが作成されます。

${INSTANCE_ROOT}/logs/wojms/wojmspacket.log

JMSサーバに対して送受信されるパケットの情報がロギングされるファイルです。ファイルの切り替えが発生すると、wojmspacket.log,wojmspacket_1.log,…,wojmspacket_9.logという名前（デフォルトで最大10個）のファイルが作成されます。

${INSTANCE_ROOT}/logs/wojms/wojmsmessage.log

JMSメッセージのライフサイクル情報がロギングされるファイルです。ファイルの切り替えが発生すると、wojmsmessage.log,wojmsmessage_1.log,…,wojmsmessage_9.logという名前（デフォルトで最大10個）のファイルが作成されます。

${INSTANCE_ROOT}/logs/wojms/wojmserror.log

JMSサーバに関するエラーがロギングされるファイルです。ファイルの切り替えが発生すると、wojmserror.log,wojmserror_1.log,…,wojmserror_9.logという名前（デフォルトで最大10個）のファイルが作成されます。

${INSTANCE_ROOT}/logs/wojms/std.log

JMSサーバ起動時のエラーや、スレッドのダンプの取得結果がロギングされるファイルです。JMSサーバが起動するタイミングでファイルを切り替え、直前に作成されたファイルのみstd.log.bakという名前で残します。

${INSTANCE_ROOT}/logs/wojms/webotx_wojms.log

JMSクライアントに関する動作がロギングされるファイルです。ファイルの切り替えが発生すると、webotx_wojms.log,webotx_wojms.log.1,webotx_wojms.log.2という名前（デフォルトで最大3個）のファイルが作成されます。

${INSTANCE_ROOT}/logs/wojms/wojmssv.pid

Windowsの場合、JMSサーバ起動時のjavaプロセスのプロセスIDが出力されるファイルです。

${INSTANCE_ROOT}/logs/wojms/wojmsserver.pid

UNIXの場合、JMSサーバ起動時のjavaプロセスのプロセスIDが出力されるファイルです。

1.1.2.7. Transactionサービス

${INSTANCE_ROOT}/config/TS配下の全ファイル

このディレクトリ配下に格納されるのはTransactionサービス内部で使用する設定情報ファイル、および実行中トランザクションの情報が格納されたファイルなどです。

${INSTANCE_ROOT}/logs/TS配下の全ファイル

「*.trc」という名前のファイルが格納されますが、これらはTransactionサービスの動作に関する情報を採取したトレースファイルです。ファイルのサイズや情報採取レベルについてはotxadminコマンドにより設定することが可能です。

採取するレベルは0(採取しない)〜5(デバッグレベル)まで6段階あります。レベルを上げると情報量は増えますがその分トランザクションの処理速度が遅くなります。通常はレベルを低い設定にしておき、障害が発生した際にレベルを上げて原因を特定するのが通常の運用です。

またこのファイルの内容を参照するためのツールをTransactionサービスで提供しています。Windows版ではGUIツールである「トレースビューア」、UNIX、Linux版では「trcview」コマンドです。トレースビューアは<WebOTXインストールディレクトリ>\TS\binの配下にあるtrcview.exeです。またtrcviewコマンドは<WebOTXインストールディレクトリ>/TS/sbinの配下にあります。トレースビューアの使い方はツールのメニューからヘルプファイルを参照してください。

1.1.2.8. TPシステム

1.1.2.8.1 アプリケーション障害発生時に必要となる可能性が高いログ

${INSTANCE_ROOT}/logs/tpsystem/webotx_tpmmgr.log

TPモニタ・マネージャに関する動作がロギングされるファイルです。ファイルの切り替えが発生すると、webotx_tpmmgr.log, webotx_tpmmgr.log.1, webotx_tpmmgr.log.2という名前（デフォルトで最大3個）のファイルが作成されます。

${INSTANCE_ROOT}/logs/tpsystem配下の次のファイル

- history.act,history.act.1, history.act.2・・・ : サーバアプリケーションの起動、停止履歴

- sysmsg.trc, sysmsg.trc.1, sysmsg.trc.2・・・ : APサーバへの接続履歴

.<数字>が付くファイルはそれぞれのバックアップファイルです。10000行(既定値)を超えるかTPシステム起動時にファイルが切り替わります。10世代(既定値)を超えるとファイルは上書きされますので、障害発生時はファイルが上書きされる前に採取してください。

${INSTANCE_ROOT}/logs/tpsystem/<アプリケーショングループ名>/<プロセスグループ名>配下の全ファイル

アプリケーショングループとプロセスグループ別にサーバアプリケーションのログファイルが出力されます。

1.1.2.8.2. 障害の解析方法

WebOTXで障害を検出した場合は、イベントログ（UNIXの場合はsyslog）に障害情報を出力します。 障害が起きた場合は、まずイベントログを調査して下さい。

サーバアプリケーションが異常終了した場合は、アプリケーションログを確認して下さい。

WebOTXサーバを構成するプロセス群の起動、停止情報はhistory.actというファイルに格納されています。 何らかのプロセス障害、例えばWebOTXの起動に失敗したり、アプリケーショングループの停止に失敗した場合は、history.actを確認して下さい。

1.1.2.8.3. 標準で採取される障害情報

イベントログ

イベントログ（UNIXの場合はsyslog）への出力形式は以下の通りです。

• イベントログの場合

  ソースが「WebOTX_ASMonitor <TPシステム名>」または「WebOTX AS」となります。

• syslogの場合

  OTXMで始まるメッセージを出力します。 フォーマットは次のようになります。

  OTXM:<TPシステム名>(※1):<プロセスグループ名>(※1):<プロセスID>(※1): <種類>(※2):<メッセージ詳細>
  

  ※1：省略されることがあります。 また、サーバAP以外の障害ではプロセスグループ名以外の名前が表示されることがあります。
  ※2：I:情報、W:警告、E:エラー

  また、WebOTX_Agentで始まるメッセージを出力します。 フォーマットは次のようになります。

  WebOTX_Agent: <ロガーの種類> <メッセージ詳細>
  

  「TPSxx-yyyyy」と出力されるメッセージは、xxの部分で該当コンポーネントを特定することができます。 xxとコンポーネントの対応は以下の通りです。
  
  • 07：各種リスナ（IIOPリスナ、RMIリスナ、OLFリスナ）
  • 09：VDサーバ
  • 10：サーバAP（ベースライブラリ）
  • 12：tpadm
  • 15：モニタ
  
  以上を参考にして、種類のところが警告、もしくはエラーとなっているものを確認していきます。

アプリケーションログ

サーバアプリケーションで障害が発生した場合、アプリケーションログを確認してください。

${INSTANCE_ROOT}/logs/tpsystem/<アプリケーショングループ名>/<プロセスグループ名>/<プロセスグループ名>.<プロセスID>.log

history.act

history.actファイルの所在は以下の通りです。

${INSTANCE_ROOT}/logs/tpsystem/history.act

history.act, history.act.1, history.act.2 ・・・

1.1.2.8.4. 各コンポーネントにおける障害解析

サーバアプリケーションのログ採取

サーバで発生した障害はWindowsのイベントログ、UNIXのsyslogとWebOTX サーバのトレースファイルに出力されます。 イベントログの参照などの操作に関しては、Windows のマニュアルを参照してください。 障害の詳しい情報を採取したい場合は、トレースログを取得することにより詳細なデータを取得することができます。 トレースログはログファイルに出力されます。

プロセスグループからトレース用APIを呼び出すと、同じファイルに出力されます。

プロセスグループのトレース出力に関する設定は、統合運用管理ツールで指定します。

1. 統合運用管理ツールを起動します
2. トレースを設定するプロセスグループを選択します
3. [トレース設定]タブを選択します
4. 「ファイルサイズ」、「トレースレベル」を設定します
5. 設定後すぐにトレースファイルが作成されます

アプリケーションログの見方

アプリケーションログの例を以下に示し、その見方を説明します。

                       :
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)

• (1) 日付
• (2) 時刻
• (3) プロセスID（トレース編集機能を使った場合のみ出力されます）
• (4) スレッドID
• (5) メッセージ部
• (6) 各オペレーションの最初に出力されるトレースです。 クライアントのIPアドレス、実行対象のインタフェース名およびオペレーション名が出力されます。

ワトソンログ採取

Windows OS で C++アプリケーションで障害が発生した場合、障害解析にワトソンログが必要となる場合があります。例外時にワトソンログを出力させるには、統合運用管理ツールからTPシステムの[例外ハンドル]タブを選択し、「WebOTXで例外処理を行う」のチェックを外してTPシステムを再起動してください。

・WebOTXが例外をキャッチしなくなり、例外時にはオペレーションを閉塞させずに、プロセスが即停止します。 該当プロセスで実行中の処理があれば、その処理は異常終了します。

・OnTPSAbort() が呼ばれなくなり、後始末の処理が行われなくなります。

・TPシステムの属性の「プロセス障害時の再起動」の値が2以上の値になっていれば、 その回数までは例外して落ちたプロセスは自動再起動されます。 ただし、OSの設定やワトソン博士の設定によっては例外時に何らかのダイアログが出てしまうことがあります。 その場合はダイアログを閉じるまでプロセスが終了せず再起動もされません。

また、OSの設定でワトソンログを採取する設定になっていない場合はコマンドプロンプトで 「drwtsn32 -i」を実行してください。 「-i」を指定すると、必要な変更がレジストリに対して行われます。

TPモニタ

TPモニタのログ出力の設定方法は次の通りです。

--運用管理コマンドの場合--
以下のコマンドを実行してドメインを再起動します。

otxadmin> set tpsystem.collectTpmonitorTrace=true
otxadmin> set tpsystem.tpmonitorTraceSize=100000

（collectTpmonitorTrace は true で採取有り、false で採取無しで、既定値はfalse）
（tpmonitorTraceSize は ログの最大行数で、既定値は100,000）

--統合運用管理ツールの場合--
以下の属性を設定してドメインを再起動します。

1. 統合運用管理ツールを起動します
2. トレースを採取するTPシステムを選択します
3. [システム情報]タブを選択します
4. 「TPモニタのログを採取する」、「TPモニタのログの最大ライン数」を設定します

ドメイン再起動後、以下のログが出力されます。

${INSTANCE_ROOT}/logs/tpsystem/tpmonitor.trc

TPA

TPAのログ出力の設定方法は次の通りです。

--運用管理コマンドの場合--
以下のコマンドを実行してドメインを再起動します。

otxadmin> set tpsystem.collectTpaTrace=true
otxadmin> set tpsystem.tpaTraceSize=100000

（collectTpaTrace は true で採取有り、false で採取無しで、既定値はfalse）
（tpaTraceSize は ログの最大行数で、既定値は100,000）

--統合運用管理ツールの場合--
以下の属性を設定してドメインを再起動します。

1. 統合運用管理ツールを起動します
2. トレースを採取するTPシステムを選択します
3. [システム情報]タブを選択します
4. 「TPAのログを採取する」、「TPAのログの最大ライン数」を設定します

ドメイン再起動後、以下のログが出力されます。

${INSTANCE_ROOT}/logs/tpsystem/tpadmd.trc

IIOPリスナ

IIOPリスナは二つのトレースファイルから構成されます。 一つは通信管理部分。 もう一つは振り分け部分になります。

• 通信管理部分のトレース
  

  --運用管理コマンドの場合--
  以下のコマンドを実行してTPシステムを再起動します。

  otxadmin> set tpsystem.IIOPListener.collectIiopManagementLog=true
  otxadmin> set tpsystem.IIOPListener.iiopManagementLogSize=10240
  

  （collectIiopManagementLog は true で採取有り、false で採取無しで、既定値はfalse）
  （iiopManagementLogSize は ログファイルの最大サイズで、既定値は10,240KB）
  

  --統合運用管理ツールの場合--
  以下の属性を設定してTPシステムを再起動します。

  1. 統合運用管理ツールを起動します
  2. トレースを採取するIIOPリスナを選択します
  3. [リスナ]タブを選択します
  4. 「通信管理部分のログを採取する」、「通信管理部分のログファイルサイズ」を設定します

  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システムを再起動します。

  1. 統合運用管理ツールを起動します
  2. トレースを採取するIIOPリスナを選択します
  3. [リスナ]タブを選択します
  4. 「振り分け部分のログを採取する」、「振り分け部分のログファイルサイズ」を設定します

  TPシステム再起動後、以下のログが出力されます。

  ${INSTANCE_ROOT}/logs/tpsystem/<システム名>_IIOPLsn.log
  

どちらのトレースも詳細な通信ログを採取するため、性能劣化が発生します。トレースの採取が終わりましたら、設定は元に戻してください。

OLFリスナ

${INSTANCE_ROOT}/config/tpsystsem/olf.sg

VDサーバ

トレースを採取する場合は、該当TPシステムのカタログディレクトリにあるvdserver.pedファイルに、以下の行を追加します。

ARGS -OltpTplibTrace F=<filename>,<line>

（filename　はトレースファイル名（フルパス）で、採取時は必ず指定する）
（line　は行数で、採取時は必ず指定する）

管理TPP

トレースを採取する場合は、該当TPシステムのカタログディレクトリにあるwosystpp.pedファイルに、以下の行を追加します。

ARGS -OltpTplibTrace F=<filename>,<line>

（filename はトレースファイル名（フルパス）で、採取時は必ず指定する）
（line は行数で、採取時は必ず指定する）

1.1.2.9. OLF/TP Adapter

OLF/TP Adapter の詳細については、 [ WebOTX OLF/TP Adapter > 運用ガイド ] を参照してください。

1.1.2.10. Object Broker

${OrbRoot}/scripts/に格納されたツールを使用して情報の採取、解析を行うことができます。Windows,UNIX共通です。

1.1.2.10.1 環境設定

コマンドを実行するには、まず環境設定を行います。

${OrbRoot}/scripts/env/setenv

PRODUCTTYPE(製品種別)を指定してください。デフォルト値はOSPIです。

• OSPI
  単体版のObject Broker製品を対象とします。
• EDITION
  各WebOTX Application Server製品に作成されているドメインに関するObject Brokerと単体版のObject Broker製品を対象とします。

1.1.2.10.2 情報採取方法

採取する情報別にコマンドを実行し情報を採取します。

情報採取用のコマンドは以下に格納されています。

${OrbRoot}/scripts/collect/

情報採取用の各種コマンドは以下のようになります。

1.1.2.10.3 解析方法

解析したい情報別にコマンドを実行し結果を出力します。

解析用のコマンドは以下に格納されています。

${OrbRoot}/scripts/check/

解析用の各種コマンドは以下のようになります。

1.1.3. Java VMのスレッドダンプ取得

WebOTXが起動中にストール状態になる、または、コマンドからの応答がなく停止できない状態など、WebOTXが無応答状態に陥った場合には以下の手順でJava VMのスレッドダンプを取得します。
多くの場合、スレッドダンプの内容を解析することで、障害の原因を突き止めることができます。

スレッドダンプの取得方法には以下のようなものがあります。システムの動作環境や障害の状況に応じて適切な方法を選択してください。

• 1.1.3.1. 統計レポート出力コマンドを利用した取得方法

運用管理コマンド(otxadmin)の generate-jvm-report サブコマンドを利用した方法です。本コマンドの操作に慣れているとこの方法が便利です。

利用可能なOSやJDKなどの制約はありませんが、スレッドダンプの採取にJavaヒープメモリを使用するため、該当プロセスのヒープメモリの空きが枯渇している状況では採取に失敗することがあります。
また、運用管理コマンドから取得対象のドメインに接続できない状態では本方法を実行することができません。

• 1.1.3.2. 診断サービスを利用した取得方法

診断サービスによる障害解析のための情報収集機能で、スレッドダンプを取得することができます。診断機能に対する操作に慣れているとこの方法が便利です。

利用可能なOSやJDKなどの制約はありませんが、統計情報やサーバのログなどとまとめて採取されますので、それらの採取が不要な場合には不向きです。
また、運用管理ツールから取得対象のドメインに接続できない状態ではスレッドダンプの採取に失敗することがあります。

• 1.1.3.3. スレッドダンプ採取オペレーションを利用した取得方法

WebOTXが提供する運用インタフェースにより、単一の操作でスレッドダンプを取得します。各種運用管理ツールの操作に慣れているとこの方法が便利です。

ただし、運用管理ツールから取得対象のドメイン、または管理ドメイン(WebOTXAdmin)のいずれにも接続できない状態では、エージェントプロセスに対してこの方法は実行できません。

• 1.1.3.4. 各OS固有の取得方法

OSが提供するコマンドやオペレーションを用いた方法です。

動作環境や障害の状況により先述している各方法での採取ができない場合には、この方法で取得を試みます。

ただし、Windows環境では、利用するOSバージョンや動作状況により幾つかの事前作業が伴います。また、問題再発時に取得しなければならない場合があります。

• 1.1.3.5. JDK付属のツールを利用した取得方法

JDKに付属のスレッドダンプ採取ツール(jstack、jvisualvm)を用いた方法です。これらのツールの操作に慣れているとこの方法が便利です。

動作環境や障害の状況により先述している各方法での採取ができない場合には、この方法で取得を試みます。

ただし、HP-UX環境では利用できません。

以上の取得方法について説明します。

1.1.3.1. 統計レポート出力コマンドを利用した取得方法

以下の手順でスレッドダンプを採取します。
無限ループによる障害を検出するために、数秒間隔で複数回実行するようにしてください。

1. 次のコマンドを実行します。コンソール上にスレッドダンプが出力されます。

   otxadmin> generate-jvm-report --type thread <サーバ名>
   

<サーバ名>には、情報取得の対象となるサーバ(Javaプロセス)の名前を指定します。 サーバ名は次のようになります。

なお、<サーバ名>が省略された場合は "server" がデフォルトとして指定されます。

詳しい取得方法については、 [ ドメイン構築・基本設定ガイド > 3. ドメイン > 3.11. Javaプロセスの監視・管理 > 3.11.3. 統計レポート出力 ] の「スレッド情報の表示」を参照してください。

1.1.3.2. 診断サービスを利用した取得方法

以下の手順でスレッドダンプを採取します。

運用管理コマンド

1. 次のコマンドにてスレッドダンプ取得のための属性値をtrueに設定します。

   ・ドメインのエージェントプロセスを対象とする場合

   otxadmin> set server.diagnostic-service.jvm-thread-dump=true
   

   ・プロセスグループのアプリケーションプロセスを対象とする場合

   otxadmin> set server.diagnostic-service.jvm-pg-stack=true
   

2. 次のコマンドで診断サービスを実行します。

   ・ドメインのエージェントプロセスが起動している場合

   otxadmin> generate-diagnostic-report <対象ドメイン名>
   

   ・ドメインのエージェントプロセスが起動していない場合

   otxadmin> generate-diagnostic-report --local=true <対象ドメイン名>
   

   (注) 本方法では、プロセスグループのアプリケーションプロセスに対する採取はできません。

統合運用管理ツール

1. 次のスレッドダンプ取得の設定項目にチェックを入れます。

   ・エージェントプロセスを対象とする場合

   「<ドメイン名>」-「アプリケーションサーバ」-「診断サービス」
   「JVM」タブ内の「JVMスレッドダンプ」

   ・プロセスグループのアプリケーションプロセスを対象とする場合

   「<ドメイン名>」-「アプリケーションサーバ」-「診断サービス」
   「JVM」タブ内の「プロセスグループのスタックトレース」

2. 「診断サービス」を右クリックして表示される「診断レポートの生成」を実行してください。

診断サービスを実行すると、テキストファイルにスレッドダンプが出力されます。

詳しい取得方法については、 [ ドメイン構築・基本設定ガイド > 10. 診断サービス > 10.2. 診断サービスの実行 ] を参照してください。

1.1.3.3. スレッドダンプ採取オペレーションを利用した取得方法

1.1.3.3.1. ユーザドメインからオペレーションを実行

ユーザドメインに接続して、スレッドダンプ採取オペレーションを実行する方法です。

以下の手順でスレッドダンプを採取します。
無限ループによる障害を検出するために、数秒間隔で複数回実行するようにしてください。

運用管理コマンド

次のコマンドを実行します。

・エージェントプロセスを対象とする場合

otxadmin> invoke domain.generateThreadDump

・プロセスグループのアプリケーションプロセスを対象とする場合

otxadmin> invoke tpsystem.applicationGroups.<アプリケーショングループ名>.processGroups.<プロセスグループ名>.stackTrace

統合運用管理ツール

対象ドメインのオペレーションから「スレッドダンプの採取」を選択します。

「実行」を押下します。

スレッドダンプの出力先は以下の通りです。

Windows: ${INSTANCE_ROOT}\logs\diagnostics\jvminfo\threaddump.txt
UNIX:      ${INSTANCE_ROOT}/logs/server.log

対象ドメインの該当するプロセスグループのオペレーションから「スタックトレースの採取」を選択します。
スレッドダンプの出力先はアプリケーションログおよびシステムトレースです。

1.1.3.3.2. 管理ドメインからオペレーションを実行

ユーザドメインがストールに陥ってしまった等で運用管理ツールからユーザドメインに接続できない場合には、管理ドメインからユーザドメインのスレッドダンプを採取することができます。
なお、このオペレーションを実行するためには、管理ドメインが起動している必要があります。

(注) 本方法では、プロセスグループのアプリケーションプロセスに対する採取はできません。

以下の手順でスレッドダンプを採取します。
無限ループによる障害を検出するために、数秒間隔で複数回実行するようにしてください。

運用管理コマンド

次のコマンドを実行します。

otxadmin> invoke --port <管理ドメインの管理ポート> domain.generateThreadDump <ドメイン名>

統合運用管理ツール

管理ドメインのオペレーションから「スレッドダンプの採取」を選択します。

スレッドダンプを採取するドメイン名を選択し、「実行」を押下します。

スレッドダンプの出力先は以下の通りです。

Windows: ${INSTANCE_ROOT}\logs\diagnostics\jvminfo\threaddump.txt
UNIX:      ${INSTANCE_ROOT}/logs/server.log

(注) 管理ドメインからスレッドダンプ採取オペレーションを実行した場合、${INSTANCE_ROOT}は採取対象ドメインのドメインルートディレクトリを表します。

1.1.3.4. 各OS固有の取得方法

UNIXとWindowsについて、それぞれのスレッドダンプ採取の手順を示します。

1.1.3.4.1. UNIXのスレッドダンプ

以下の手順でスレッドダンプを採取します。

取得方法

1. ドメインのJava VMを特定します。

   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 <アプリケーショングループ名>-<プロセスグループ名>
   

2. 特定したプロセス番号に対して kill -QUIT を実行します。

   無限ループによる障害を検出するために、数秒間隔で複数回実行するようにしてください。

   kill -QUIT <プロセス番号>
   

ドメインのエージェントプロセスの場合、スレッドダンプは ${INSTANCE_ROOT}/logs/server.log に出力されます。 プロセスグループのアプリケーションプロセスの場合、アプリケーションログおよびシステムトレースに出力されます。

1.1.3.4.2. Windowsのスレッドダンプ

Windowsでは、jstack という JDK 付属のツールを利用します。また、WebOTX AS Agent Serviceサービスからドメインを起動している場合は、jstack ツールに加えてMicrosoft社が提供する純正のフリーツールである PsExec というツールを利用します。詳細は、[1.1.3.5.1. jstackツール]を参照してください。

1.1.3.5. JDK付属のツールを利用した取得方法

JDKに付属の監視ツールであるjstack、jvisualvmの各ツールを用いてスレッドダンプを取得する方法について説明します。

1.1.3.5.1. jstackツール

取得方法

1. 取得対象のドメインが出力する次のファイルに記載されている、取得対象のJavaプロセスに対するプロセスIDを調べます。

<ドメインディレクトリ>\config\appserv_pid

2. jstackツールを、次のように実行します。

Windows: <JDKインストールディレクトリ>\bin\jstack.exe <プロセスID> >> <任意ファイル名>
UNIX:      <JDKインストールディレクトリ>/bin/jstack <プロセスID> >> <任意ファイル名>

無限ループによる障害を検出するために、数秒間隔で複数回実行するようにしてください。

WebOTX AS Agent Serviceサービスでドメインを起動している場合の取得方法 (Windowsのみ)

WebOTX AS Agent Serviceサービスからドメインを起動している場合は、jstack に加えてMicrosoft社が提供する純正のフリーツールである PsExec というツールを利用します。

(注)タスクスケジューラからWebOTXを起動する運用の場合、Windowsの仕様によりコンソールが表示されないことがあります。 その場合は、Windows標準の「AT」コマンド(「interactive」オプション指定が必要)での代用を検討してください。

事前作業

PsExec を予め次に示す URL のページよりダウンロードしておきます。

1. 上記サイトのページに表示される「Download PsTools」のリンクより、PSTools.zip ファイルをダウンロードします。
2. スレッドダンプ取得対象のマシン上の任意のディレクトリに、ダウンロードしたPSTools.zip ファイルを展開します。
3. コマンドプロンプトを開き、展開した PSTools.zip 中に含まれるPsExec.exe を実行します。

なお、最初の実行時には、ライセンスの確認のためのダイアログが表示されます。表示される内容を確認の上、承諾します。

取得方法

1. 取得対象のドメインが出力する次のファイルに記載されている、取得対象のJavaプロセスに対するプロセスIDを調べます。

<ドメインディレクトリ>\config\appserv_pid

2. jstackツールを、PsExecツールを介して、次のように実行します。

PsExec.exe -s <JDKインストールディレクトリ>\bin\jstack.exe <プロセスID> >> <任意ファイル名>

無限ループによる障害を検出するために、数秒間隔で複数回実行するようにしてください。

1.1.3.5.2. jvisualvmツール

取得方法

1. jvisualvmツールを次のように起動します。

Windows: <JDKインストールディレクトリ>\bin\jvisualvm.exe
UNIX:      <JDKインストールディレクトリ>/bin/jvisualvm

2. 「リモート」のツリーノードを選択後、「ファイル(F)」メニューを選択し、表示される操作一覧から「JMX接続を追加(J)」を選択します。
3. 「接続(C)」項目に <ホスト名>:<管理ポート番号> の形式で値を入力します。
   また、ドメインのエージェントプロセスをスレッドダンプの取得対象とする場合、「セキュリティー保証書を使用(E)」にチェックを入れ、「ユーザー名(U)」には管理ユーザ名を、「パスワード(P)」に管理ユーザのパスワードを入力します。
   その後、「了解」ボタンを押下します。
4. 「リモート」のツリーノード配下に表示された <ユーザ名>@<ホスト名>:<管理ポート番号> の名前を持つノードを選択し、右クリックするか、「アプリケーション(A)」メニューを選択し、表示される操作一覧から「スレッドダンプ(T)」を選択します。

無限ループによる障害を検出するために、数秒間隔で複数回実行するようにしてください。

5. スレッドダンプ採取のタイミングで作成された "[threaddump]日時" の名前を持つツリーノードを選択後、右クリックするか、「アプリケーション(A)」メニューを選択し、表示される操作一覧から「別名保存(S)」を選択して任意のファイルに保存します。

1.2. ドメインの強制停止

WebOTXエージェントプロセスが何らかの原因でストールもしくは異常終了した場合に、WebOTXで起動された各サービス(Agent、JMS、Webサーバ、TPモニタ・マネージャ、Transactionサービス、ObjectBrokerサービス)のプロセスが残存することがあります。運用管理コマンドを使用し、以下の手順でドメインの強制停止を行ってください。

1.2.1. 停止方法

以下の手順でドメインを強制停止します。

強制停止方法

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}」という文字列が指定されますのでそれが目印になります。