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.1-1
サービス名 プロセス名 出力場所 備考
運用管理エージェント java (agent) ${INSTANCE_ROOT}/config  
Webサーバ(Apache) 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
Standard/
Enterpriseのみ
TPシステム iioplsn ${AS_INSTALL}/Trnsv/logs
Standard
Enterpriseのみ
tpmonitor ${AS_INSTALL}/Trnsv
Standard/
Enterpriseのみ
THTPPJAVA2
THTPPCTL<数字>
THTPPOTS<数字>
THTPPDB<数字>
${AS_INSTALL}/Trnsv
Standard/
Enterpriseのみ
<数字>には9,8,7のいずれかが入ります
TPモニタ制御サービス tpadmd ${AS_INSTALL}/Trnsv
Standard/
Enterpriseのみ

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コンテナ

${INSTANCE_ROOT}/logsディレクトリのファイル全て
${INSTANCE_ROOT}/logsディレクトリのファイル全てと、${INSTANCE_ROOT}/logs/tpsystem配下の全ファイル
Standard/EnterpriseのEJBコンテナの詳細ログを採取する場合は、プロセスグループのトレースレベルを7に設定してください。

1.1.2.5. JNDIサービス

${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/wojms.log
JMSクライアントに関する動作がロギングされるファイルです。ファイルの切替が発生すると、wojms.log,wojms.log.1,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}/config/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)への出力形式は以下の通りです。

アプリケーションログ

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

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

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

${INSTANCE_ROOT}/config/tpsystem/history.act
historyは既定値では10世代まで出力されます。ファイル名は次のようになります。
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)
ワトソンログ採取

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

ただし、この設定を変更すると以下の影響があるため注意が必要です。
・WebOTXが例外をキャッチしなくなり、例外時にはオペレーションを閉塞させずに、プロセスが即停止します。 該当プロセスで実行中の処理があれば、その処理は異常終了します。
・OnTPSAbort() が呼ばれなくなり、後始末の処理が行われなくなります。
・TPシステムの属性の「プロセス障害時の再起動」の値が2以上の値になっていれば、 その回数までは例外して落ちたプロセスは自動再起動されます。 ただし、OSの設定やワトソン博士の設定によっては例外時に何らかのダイアログが出てしまうことがあります。 その場合はダイアログを閉じるまでプロセスが終了せず再起動もされません。

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

モニタ

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

--UNIXの場合--
/opt/WebOTX/Trnsv/bin/tpadm2.shに以下の記述を追加してドメインを再起動します。

TPA_TPM_TRACE=<ON/OFF>
export TPA_TPM_TRACE
TPA_TPM_TRACELINE=<line> 
export TPA_TPM_TRACELINE

(TPA_TPM_TRACE は ON で採取有り、OFF で採取無し で、既定値はOFF)
(TPM_TRACELINE は line が行数 で、既定値は20,000)

--Windowsの場合--
以下のレジストリを設定してドメインを再起動します。

\\HKEY_LOCAL_MACHINE\SOFTWARE\NEC\WebOTX\TPBASE(配下)
Trace <ON/OFF>
TraceDir <path> 
TraceLine <line>   

(Trace は ON で採取有り、OFF で採取無しで、既定値はOFF)
(TraceDir は path が出力ディレクトリで、既定値はカタログディレクトリ)
(TraceLine は line が行数で、既定値は20,000)

モニタのログはシステム名.trcというファイル名で出力されます。 UNIXの場合はカタログディレクトリに出力されます。

tpadm

tpadmdプロセスのログ出力の設定方法は次の通りです。

--UNIXの場合--
/opt/WebOTX/Trnsv/bin/tpadmd2.shのtpadmd起動行を以下のように設定してドメインを再起動します。

(トレース採取無しの場合)
tpadmd
(トレース採取有りの場合)
tpadmd -OltpTplibTrace F=<filename>,<line>

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

--Windowsの場合--
以下のレジストリを設定してドメインを再起動します。

\\HKEY_LOCAL_MACHINE\SOFTWARE\NEC\WebOTX\TPBASE(配下)
TpaTrace <ON/OFF> 
TraceDir <path> 
TraceLine <line> 

(TpaTrace は ONで採取有り、OFFで採取無しで、既定値はOFF)
(TraceDir は pathが出力ディレクトリで、既定値は${AS_INSTALL}\Trnsv)
(TraceLine は lineが行数で、既定値は20,000)

tpadmdプロセスのログは、UNIXの場合は指定したファイル名にプロセスIDを付与した名前で作成されます。 Windowsの場合は、tpadm.<プロセスID>.trcというファイル名で出力されます。

IIOPリスナ

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

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

OLFリスナ
${INSTANCE_ROOT}/config/tpsystsem/olf.sg
をnotepadかviなどのエディタで開いてください。 トレース採取の有無、トレースファイル名、ファイルサイズを設定できます
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です。
1.1.2.10.2 情報採取方法

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

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

${OrbRoot}/scripts/collect/

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

表1.1.2.10-1
コマンド名 機能説明 出力情報 備考
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 上記のコマンドを一括実行し情報を採取
1.1.2.10.3 解析方法

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

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

${OrbRoot}/scripts/check/

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

表1.1.2.10-2
コマンド名 機能説明 出力情報 備考
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 上記のコマンドを一括実行し情報を解析

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

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

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

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

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

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

  1. 次のコマンドを実行します。コンソール上にスレッドダンプが出力されます。
    otxadmin> generate-jvm-report --type thread <サーバ名>
    

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

* ドメインのエージェントプロセス : server

* プロセスグループのアプリケーションプロセス : <アプリケーショングループ名>-<プロセスグループ名>

なお、<サーバ名>が省略された場合は "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. 「診断サービス」を右クリックして表示される「診断レポートの生成」を実行してください。

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

詳しい取得方法については、 [ 診断サービスの実行 ] を参照してください。

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

(注) Windowsの場合、スレッドダンプ採取オペレーションはJDK 6の環境のみ提供しています。

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

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

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

運用管理コマンド

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

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

otxadmin> invoke domain.generateThreadDump

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

otxadmin> invoke tpsystem.applicationGroups.<アプリケーショングループ名>.processGroups.<プロセスグループ名>.stackTrace
または、従来より提供しているプロセスグループ向けの専用コマンド(wostack)を使用することでも採取できます。詳しくは、[ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.6. TPシステム > 4.6.5. wostack ] を参照してください。
統合運用管理ツール
・エージェントプロセスを対象とする場合

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

運用管理ツールからのスレッドダンプ採取方法1

「実行」を押下します。

運用管理ツールからのスレッドダンプ採取方法2

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

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

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

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

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

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

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

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

運用管理コマンド

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

otxadmin> invoke --port <管理ドメインの管理ポート> domain.generateThreadDump <ドメイン名>
統合運用管理ツール

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

運用管理ツールからのスレッドダンプ採取方法3

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

運用管理ツールからのスレッドダンプ採取方法4

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

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では、Javaプロセスに対して Ctrl + Break キーを送信することでスレッドダンプが出力されます。 しかし、WebOTXはサービスとして起動されるために通常ではスレッドダンプの取得は行えません。スレッドダンプを出力させるようにするには、次のいずれかの方法を行います。

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

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

まず、「コンソール表示による取得」の手順について以下に示します。なお、通常運用時には変更した設定を元に戻すようにしてください。

取得方法(対象のOSバージョンを参照)
  1. サービスに対して、デスクトップとの対話を有効にします。
  2. サービスの一覧から「WebOTX AS Agent Service」を選択し、「プロパティ」を開きます。
    プロパティ画面上の「ログオン」タブを選択し、項目「デスクトップとの対話をサービスに許可」にチェックを入れます。

  3. コンソール表示を有効にします。
  4. ドメイン起動時に以下のコマンドによりコンソール出力設定を有効にします。

    otxadmin> set server.log-service.alloc-console=true
    
  5. ドメインを再起動後、サービス「Interactive Services Detection」を開始します。
  6. この時、「対話型サービスダイアログの検出」というプロンプトが表示されますので、「メッセージを表示する」を選択します。

  7. 表示されたコンソールをアクティブな状態にして Ctrl + Break を送信します。
  8. 無限ループによる障害を検出するために、数秒間隔で複数回実行するようにしてください。

    なお、コンソールを閉じるとドメインが停止してしまうため注意してください。

  9. プロンプト画面上の「すぐに戻る」を選択し、元の画面に戻ります。
  10. サービス「Interactive Services Detection」を停止します。

Ctrl + Break を送信したタイミングでのスレッドダンプが ${INSTANCE_ROOT}\logs\server.log に出力されます。

(注)本方法を実施した際、イベントログに次のメッセージが出力されますが、WebOTX や業務アプリケーションの動作には影響がありませんので無視してください。

「WebOTX AS Agent Service サービスは、対話型サービスとしてマークされています。しかし、システムは対話型サービスを許可しないように構成されています。このサービスは正常に機能しない可能性があります。」

設定解除方法
  1. コンソール表示を無効にします。
  2. ドメイン起動時に以下のコマンドによりコンソール出力設定を無効にします。

    otxadmin> set server.log-service.alloc-console=false
    
  3. ドメインを再起動し、javaw.exe のコンソールが表示されないことを確認します。

一方、「PsExecツールを用いた取得」の場合、Microsoft社が提供する純正のフリーツールを予め次に示すサイト上のページよりダウンロードする必要があります。

[URL] http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

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

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

取得方法
  1. 取得対象のドメインが出力する次のファイルに記載されている、取得対象のJavaプロセスに対するプロセスIDを調べます。
  2. <ドメインディレクトリ>\config\appserv_pid

  3. jstackツールを、PsExecツールを介して、次のように実行します。
  4. PsExec.exe -s <JDKインストールディレクトリ>\bin\jstack.exe <プロセスID> << <任意ファイル名>
    

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

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

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

1.1.3.5.1. jstackツール
取得方法
  1. 取得対象のドメインが出力する次のファイルに記載されている、取得対象のJavaプロセスに対するプロセスIDを調べます。
  2. <ドメインディレクトリ>\config\appserv_pid

  3. jstackツールを、次のように実行します。
  4. Windows: <JDKインストールディレクトリ>\bin\jstack.exe <プロセスID> << <任意ファイル名>
    UNIX:      <JDKインストールディレクトリ>/bin/jstack <プロセスID> << <任意ファイル名>

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

1.1.3.5.2. jvisualvmツール

(注)本ツールは JDK 6 Update 7 以降のリリースに含まれています。

取得方法
  1. jvisualvmツールを次のように起動します。
  2. Windows: <JDKインストールディレクトリ>\bin\jvisualvm.exe
    UNIX:      <JDKインストールディレクトリ>/bin/jvisualvm

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

  7. スレッドダンプ採取のタイミングで作成された "[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}」という文字列が指定されますのでそれが目印になります。