WebOTX トラブルシューティング(概要)

1 はじめに
本書はWebOTX実行環境を運用するための運用操作法について概要や具体的な設定項目や設定方法について記載しています。
対象読者

このマニュアルはWebOTX Application Server Web Edition、Standard-J Edition、Standard Edition、Enterprise Editionを使って運用環境を構築するシステムエンジニア、日々の運用を行うオペレータを対象としています。
表記について

パス名表記

本書ではパス名の表記については特にOSを限定しない限りセパレータはスラッシュ’/’で統一しています。Windows環境においては’\’に置き換えてください。

環境変数表記

インストールディレクトリやドメインルートディレクトリなど環境によって値の異なるものについては環境変数を用いて表します。

${env} または　$(env)で表しています。

例)
${AS_INSTALL} : インストールディレクトリ
${INSTANCE_ROOT}: ドメインルートディレクトリ

製品名表記

以後の説明で「WebOTX」としているものは、「WebOTX Application Server」のことをあらわします。

コマンド操作について

本書中では運用操作に用いるコマンドの詳細についての説明は省略しています。コマンドの詳細は「運用管理コマンド」、「運用管理コマンドリファレンス」を参照してください。

2 障害解析

障害発生時採取する情報について説明します。

2.1 全般

障害が発生した場合、障害内容にかかわらず採取すべき情報について説明します。

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

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

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

(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

(UNIX)

coreファイル

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

サービス名 プロセス名 出力場所 備考
WebOTXエージェント java (agent)${INSTANCE_ROOT}/config  
Webサーバ(Apache) httpd ${INSTANCE_ROOT}/  
ObjectBrokerサービスoad ${INSTANCE_ROOT}/config  
namesv ${INSTANCE_ROOT}/config  
cnamesv ${INSTANCE_ROOT}/config Enterprise Editionのみ
java (oadj) ${INSTANCE_ROOT}/config  
ospprxy ${INSTANCE_ROOT}/config Enterprise Editionのみ
JMSサービス java (jms) ${INSTANCE_ROOT}/config  
Transactionサービス rcssv ${INSTANCE_ROOT}/config
Standard Edition/
Enterprise Editionのみ
TPシステム iioplsn ${AS_INSTALL}/Trnsv/logs
Standard Edition/
Enterprise Editionのみ
tpmonitor ${AS_INSTALL}/Trnsv
Standard Edition/
Enterprise Editionのみ
THTPPJAVA2
THTPPCTL<数字>
THTPPOTS<数字>
THTPPDB<数字>
 ${AS_INSTALL}/Trnsv
Standard Edition/
Enterprise Editionのみ
<数字>には9,8,7のいずれかが入ります
TPモニタ制御サービス tpadmd ${AS_INSTALL}/Trnsv
Standard Edition/
Enterprise Editionのみ
WebOTX Standard Edition/Enterprise Editionでの障害を未然に防ぐために知っておきたい知識や、障害発生時の原因究明に役立つ機能について、2.1.1以降に記述しています。

2.1.1 アプリケーションプロセス異常終了に対する機能
WebOTX Standard Edition/Enterprise EditionではTPモニタ機能により、アプリケーションプロセスの状態を常に監視しています。アプリケーションプロセスが異常終了した場合、そのアプリケーションプロセスは自律的に復旧されます。またその際に、詳細な障害情報を記録しますので、後からの障害解析を容易に行うことができます。
2.1.1.1 異常終了の検出と自律復旧
アプリケーションプロセスの異常終了を検知し、そのプロセスが使用していたリソース(コネクション、共有メモリ、データベース資源)をWebOTXが解放します。さらに指定に従ってプロセスの再起動を行うことができます。これにより、障害発生後もそれ以前と同じ処理能力を維持することができます。
アプリケーションプロセスの異常終了が検出されると、イベントログ・シスログに以下のようなメッセージが出力されます。 異常が発生した場合はまずはイベントログ・シスログを確認してください。
OTXM:<システム名>::<プロセスID>: W:13:TPS15-01107 Process abnormal end. PID=[<プロセスID>], class[<プロセスグループ名>], ped[<アプリケーショングループ名>.ped]

プロセスグループが複数プロセスで構成される場合、その中の一つのアプリケーションプロセスが異常終了しても、他のアプリケーションプロセスは通常通り処理を行うことができます。このため、プロセスグループとしては、異常終了したアプリケーションプロセスが再起動されるまでの間もサービスの継続性を確保できます。

アプリケーションプロセスの再起動回数を設定することができます。プロセスの異常終了があるとこの指定に応じて再起動されます。ただし一度障害が発生した後に自動的に再起動させても同じ障害の繰り返しとなる可能性もありますので注意が必要です。また自動的に再起動させてしまうと障害が起きたことに気づかない恐れがあるので、テスト環境で使用する場合は再起動させない設定とし、本番運用では再起動する設定とすることを推奨します(統合運用管理ツールの[TPシステム]-[上限設定]-[プロセス障害時の再起動回数])。

C++で作成されたサーバアプリケーションの場合は、異常終了発生後にオペレーションを閉塞状態にしてクライアントから実行させないようにすることができます。アプリケーション作成者は、閉塞している間にプログラムのチェックを実施することになります。オペレーション単位で閉塞状態にすることができるので、正常動作している他のオペレーションは引き続き動作させることは可能です。閉塞されたオペレーションを呼び出すと以下のメッセージがイベントログ・シスログに出力され、問題のオペレーションは実行されません。

OTXM:<システム名>:<プロセスグループ名>:<プロセスID>: E:1:TPS10-03201OPERATION BLOCKED. TX-GROUP プロセスグループ名 プロセスID

オペレーションの閉塞に関する設定は統合運用管理ツールのプロセスグループの[スレッド制御]-[オペレーション異常終了時にオペレーションを閉塞させる]で行います。

なお、V5までは閉塞するのがデフォルトの設定となっていましたが、V6以降では閉塞させないのがデフォルトの設定と変わりました。

2.1.1.2 リクエスト保障

オペレーション実行中に何らかの障害が発生してプロセス終了となった場合、TPモニタがそのプロセスに代わりエラー応答をクライアントに返します。イベントログ・シスログにも情報を残します。キューで待っていたリクエストは、別プロセスが引き継いで処理をすることができます。他に起動中のアプリケーションプロセスがなく、かつプロセス再起動回数を使い果たした場合は別プロセスに引き継げませんが、この場合はエラー応答をクライアントアプリケーションに返すため、サーバアプリケーションの異常終了に引きずられてクライアントアプリケーションが無応答になることはありません。

クライアントアプリケーションに返却されるエラーコードの詳細は「メッセージ編」を参照してください。

2.1.1.3 障害情報記録(Java)

オペレーション実行中にJavaランタイム例外が発生した場合、正確にはWebOTXの基盤でJavaランタイム例外を捕捉した場合はアプリケーションプロセスを異常終了させますが、この際に捕捉した例外のスタックトレースがシステムトレースに記録されます。この情報から、Javaソースのどの行が原因で異常終了したかを特定することができます。

デフォルトでは以下の場所にアプリケーションログを出力しています。

${ INSTANCE_ROOT}/logs/tpsystem/(アプリケーショングループ名)/(プロセスグループ名)

なお異常終了してしまった場合はsaveディレクトリにログが移動しますのでsaveディレクトリも確認ください。

ファイル名：
(プロセスグループ名).(時間をベースとした識別子).(プロセスID).log
例:
2005/07/15 10:23:53.125|001: Error: Occur exception(catch java.lang.RuntimeException) at Invoking. message=null
java.lang.RuntimeException
at complex.basicApObj.exceptionEnd(basicApObj.java:21)
at complex.basicApPOA._invoke(basicApPOA.java:55)
・・・
2.1.1.4 障害情報記録(C++)

オペレーション実行中にネイティブ例外が発生した場合、正確には例外ハンドリングを行う設定(C++デフォルト)にしたアプリケーションのWebOTXの基盤でネイティブ例外を捕捉した場合は該当スレッドを閉塞させます。スレッドの残りがない場合はプロセスを終了させます。ネイティブ例外を捕捉した際はイベントログ・シスログにメッセージを出し、ネイティブ例外エラーコードも共に出力します。

さらにシステムトレースに記録されたライブラリロードアドレスと開発時のmapファイルを使用することにより、障害箇所を特定できる可能性があります。

例外発生時の情報はアプリケーションログに出力されます。デフォルトでは以下の場所にアプリケーションログを出力しています。

${ INSTANCE_ROOT}/logs/tpsystem/(アプリケーショングループ名)/(プロセスグループ名)

なお異常終了してしまった場合はsaveディレクトリにログが移動しますのでsaveディレクトリも確認ください。

ファイル名：
(プロセスグループ名).(時間をベースとした識別子).(プロセスID).log


2005/12/08 16:47:34.283|001: Error: AbortExit(exitkey=82, endkey=00).
2005/12/08 16:47:34.283|001: Error: Exception occurred. repositoryID=IDL:demo3:1.0 operation=AbortCall3
2005/12/08 16:47:34.283|001: Error: AbortExit(exitkey=82, endkey=00)(finished).
Thu Dec 08 16:47:34 2005 TPS10-13201 TPabortによるプロセス終了 CODE:0 TX-GROUP demo3PG 11156
Thu Dec 08 16:47:35 2005 TPS10-13201 TPabortによるプロセス終了 CODE:0 TX-GROUP demo3PG 11156

アプリケーションログにはアプリケーションエラーが発生した旨のエラーメッセージを出力します。これによりどのオペレーション呼び出しでエラーが発生したか特定することは可能ですが、Javaのようにスタックを出力することはできません。スタックイメージを確認するには例外ハンドルの設定を無効にし、ワトソンログ出力を有効にする必要があります。

例外ハンドルの設定は統合運用管理ツールの[TPシステム]-[例外ハンドル]-[例外ハンドルを行う]です。

2.1.1.5 異常終了時のオペレーション状態記録

アプリケーションプロセスが異常終了時に、実行中だった未完のオペレーションの状態がシステムトレースに記録されます。この情報から、どのオペレーション実行中に異常終了したかをオペレーション単位で絞り込むことができます。本情報がなくとも前記2.1.1.3、2.1.1.4の情報で十分な場合もありますが、2.1.1.3, 2.1.1.4で説明した機能はアプリケーションプロセス中で実行される機能であるため異常の程度によっては機能しないことがあります(例えばkillコマンドやタスクマネージャで強制終了させた場合)。これに対し、本機能はアプリケーションプロセスが実行の都度共有メモリに記録している情報を元に出力しているので、あらゆる終了に対応できます。

[出力例]
以下のログは 7/15 10:19:09.703に開始したオペレーション(オペレーション名:LoopBack, インタフェース名:IDL:sample/LoopBackSample:1.0, モジュール名:loopback_jsv.jar)が実行している最中にアプリケーションプロセスが異常終了したことを示します。

Error:　 The following TX execution is unfinished.
-------------------------------------
PID　　　ThID　　　TxID　　　　StartTime
-------------------------------------
03761　00001　QKAAAC　　7/15 10:19:09.703
　　　　　　　　　　QKAAAC:　　 LoopBack (IDL:sample/LoopBackSample:1.0;loopback_jsv.jar)

2.1.2 無応答障害に対する機能

Standard Edition/Enterprise Editionでは、アプリケーションプロセスが無応答や極度の遅延に陥った場 合も、それを検出し、情報を採取し、リカバリを行う機能を実装しています。

2.1.2.1 プロセス起動停止の実行時間超過の検出および全スレッドストールの検出

プロセス起動処理(Java VMの起動,ORB初期化など)、プロセス終了処理(ORB解放,Java VM停止など)の無応答障害をAPループ検出機能により検出し、該当アプリケーションプロセスは強制終了します。起動処理の障害で且つ再起動設定があれば再起動されます。また、次の2.1.2.2や2.1.2.3で説明する監視機能はアプリケーションプロセス中の制御スレッドで実装されていますが、この制御スレッドさえも正常に機能しないような異常状態になった場合も、APループ検出機能により障害を検出し、アプリケーションプロセスを強制終了します。タイマの設定方法は「運用編(チューニング) 2.5.2 起動・停止タイムアウト(プロセス終了)」を参照してください。

2.1.2.2 スレッド起動停止の実行時間超過の検出

スレッド起動処理(サーバオブジェクトや常駐オブジェクト作成)、スレッド終了処理(サーバオブジェクトや常駐オブジェクト削除)の際の無応答障害を検出してプロセスは強制終了します。起動処理の障害で且つ再起動設定があれば再起動されます。スレッド初期化タイムアウト時間はプロセスグループ単位に設定できます。タイマの設定方法は「運用編(チューニング) 2.5.2 起動・停止タイムアウト(プロセス終了)」を参照してください。

2.1.2.3 オペレーション実行時間超過の検出と自律復旧

サーバアプリケーションでオペレーションを実行した際の無応答障害を検出し、自律復旧させることができます。

実行時間上限設定を超えてもサーバアプリケーションから応答がない場合、WebOTXはアプリケーショ ンプロセスが無応答障害に陥っていると判断し、アプリケーションプロセスを強制終了し、再起動設 定があれば再起動させます。これによりクライアントに応答が返らない事態やサーバの資源を無制限 に消費する事態を回避できます。

実行時間上限値はオペレーション毎に設定することができます。設定方法は「運用編(チューニング) 2.5.4 実行時間タイムアウト」を参照してください。

また、データベースのデッドロック等、再試行可能な障害の発生も考えられます。その場合に、そのオペレーションを自動的にやり直したり、データベースがオーバーフローしたりした場合には、更新系のサービス(オペレーション)だけを停止する等、障害発生時にきめ細かいリカバリ処理を行うこともできます。

2.1.2.4 リクエスト保証(AP応答監視タイマ)

AP応答監視タイマ機能によりサーバアプリケーションの無応答障害を検出し、別プロセスが異常状態のアプリケーションプロセスに成り代わってクライアントアプリケーションにエラー応答(NO_RESPONSE(3920))を返すことができます。これによりサーバアプリケーションの無応答障害が発生しても、クライアントアプリケーションは無応答状態とならずに応答を受け取ることができます。

AP応答監視タイマ機能はプロセスグループ毎に設定することができます。設定方法は「運用編(チューニング) 2.5.3 呼び出しタイムアウト」を参照してください。

2.1.2.5 スレッド状態表示

WebOTXではサーバアプリケーションの全スレッドでどのような処理が行われているかの情報を取得することができます。各スレッドの状態(IDLE状態/実行状態など)、実行中のオペレーション名、実行中オペレーションの開始時刻、接続しているクライアントアプリケーションのIPアドレスが可視化されており、各スレッドの詳細情報を確認できます。無応答障害が発生している最中にこの情報を確認することで、障害原因を絞り込むことができます。また、各スレッドのCPU時間を確認することで、CPUループを引き起こしているオペレーションを特定することもできます。

* Linux版、Solaris版では各スレッドのCPU時間を採取できません

また、各プロセスのCPU使用率、CPU使用時間(ユーザモード/システムモード)、メモリ使用量（仮想/物理）コンテナ状態（起動処理の進み具合）についても採取することができます。

* Linux版ではCPU情報を採取できません

2.1.2.6 障害情報記録(スタック採取)

無応答障害に陥っているアプリケーションプロセス(Java)のスタックトレースを採取することができます。この情報より、サーバアプリケーション中のどの箇所で無応答となっているかを特定することができます。上記の実行時間上限監視により無応答障害を検出すると、このスタックトレースを採取しAPトレースに記録します。

例:
2005/07/15 10:23:53.125|001: Error: Occur exception(catch java.lang.RuntimeException) at Invoking. message=null
java.lang.RuntimeException
at complex.basicApObj.exceptionEnd(basicApObj.java:21)
at complex.basicApPOA._invoke(basicApPOA.java:55)
・・・

無応答障害発生中に、運用管理者がコマンドwostack（「運用コマンドリファレンスマニュアル」→「CORBAアプリケーション」→「wostack」)を使用することにより、任意のタイミングでスタックトレースをAPトレースに記録することも可能です。このコマンドによりアプリケーションを停止させるなどの影響はありません。

また、実行時間上限監視により無応答障害を検出すると、終了直前に実行中だった未完のオペレーションの状態がシステムトレース(運用編（ロギング） 2.5.1 サーバアプリケーショントレース採取)に記録されます。この情報から異常終了の原因をオペレーション単位で絞り込むことができます。

例：
Error:　 The following TX execution is unfinished.
-------------------------------------
PID　　　ThID　　　TxID　　　　StartTime
-------------------------------------
03761　00001　QKAAAC　　7/15 10:19:09.703
　　　　　　　　　　QKAAAC:　　 LoopBack (IDL:sample/LoopBackSample:1.0;loopback_jsv.jar)

2.1.3 ネットワーク/クライアント障害に対する機能
2.1.3.1 通信の監視(無通信監視)

接続しているクライアントアプリケーションより、一定時間が経過してもオペレーション呼び出しがない場合、強制的にクライアントからの接続を切断させることができます。これにより、長時間使用されていない不必要と思われる接続が切断され、ネットワークリソースの消費を抑えることができます。設定方法は「運用編(チューニング) 2.5.5 クライアント無通信監視間隔」を参照してください。

また、WebOTXで提供する、コールバック用のAPIを利用すると、CORBAサーバアプリケーションがクライアント障害の発生の通知をシステムから受け取って、独自の後処理を行うことができます。

2.1.3.2 アライブチェックによる監視

TCPレベルのkeepalive機能を設定することにより、アライブチェックを行うことができます。これによりネットワーク障害で使用不可能となってしまった接続を検出し切断することができます。 keepalive機能自体はOSが持つ監視機能となります。WebOTXではOSのkeepalive機能使用有無のみを設定します。keepalive機能のアライブチェック間隔は各OSに依存します。WebOTXに対する設定は「クライアント接続数オーバへの対応」を参照してください。

2.1.4 スローダウン障害に対する機能
2.1.4.1 スローダウン障害検出

オペレーションの呼び出し時間の統計より、通常よりオペレーション実行時間が長くなっている場合、スローダウンとして検出し通知を行ないます。一般的な監視機構とは違い、オペレーションごとの閾値設定なしでスローダウン障害を検出できます。

スローダウン発生時は、イベントログ・シスログに以下のメッセージが出力されます。

“OTX20110100 オペレーションｚｚｚのスローダウンを検出しました。current:平均実行時間=xxx秒。normal:平均実行時間=www秒。プロセスグループ=vvv。 ObjectName=yyy”
“OTX20110100 The Operation ｚｚｚ get late. Average of current time is xxx s. Average of normal time is www s. The Process Group is vvv. The ObjectName is yyy“.

オペレーションのスローダウンを検出してから「スローダウン継続監視時間」を超えてなお、スローダウン状態が継続していると以下のメッセージを統合運用管理ツールに通知し、イベントログ/syslog,webotx_agent.log(webotx_tpmmgr.log)に出力します。

“OTX20110200 オペレーションｚｚｚの長期にわたるスローダウン状態を検出しました。current:平均実行時間=xxx秒。normal:平均実行時間=www秒。スローダウン継続時間=uuu分。プロセスグループ名=vvv, ObjectName=yyy”
“OTX20110200 The Operation zzz is slow for a long time. Average of current time is xxx s. Average of normal time is www s. Duration of slow is uuu m. The Process Group is vvv. The ObjectName is yyy “

「長期にわたるスローダウン状態」を検出すると、メッセージ出力とともに、該当プロセスグループのスタックトレースを採取します。このAPログに出力されるスタックトレースを参照することで、スローダウンの原因を調査することができます。

詳しくは「運用編（TPモニタの運用操作） 2.40 運用アシスタントに関する設定」を参照してください。
スローダウン検出後は、ジャーナル、オペレーションジャーナル、イベントジャーナルなどの統計データから原因を絞り込むことができます。詳しくはオペレーション遅延への対応を参照してください。

2.2 モジュール別採取情報

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

2.2.1 HTTPサーバ
${ INSTANCE_ROOT}/logs/WebServerディレクトリのファイル全て
(access.log/error.log等)
${ INSTANCE_ROOT}/config/WebServerディレクトリのファイル全て
(httpd.conf/ssl.conf等)

2.2.2 Webコンテナ
${ INSTANCE_ROOT}/logsディレクトリのファイル全て

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

2.2.4 ＪＮＤＩサービス
${ INSTANCE_ROOT}/logs/jndi/webotx_jndisp.log

2.2.5 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
JMSサーバ起動時のjavaプロセスのプロセスIDが出力されるファイルです。

2.2.6 Transactionサービス
${ INSTANCE_ROOT}/config/TS配下の全ファイル
このディレクトリ配下に格納されるのはTransactionサービス内部で使用する設定情報ファイル、および実行中トランザクションの情報が格納されたファイルなどです。
${ INSTANCE_ROOT}/logs/TS配下の全ファイル
「*.trc」という名前のファイルが格納されますが、これらはTransactionサービスの動作に関する情報を採取したトレースファイルです。ファイルのサイズや情報採取レベルについてはotxadminコマンドにより設定することが可能です。
採取するレベルは0(採取しない)〜5(デバッグレベル)まで6段階あります。レベルを上げると情報量は増えますがその分トランザクションの処理速度が遅くなります。通常はレベルを低い設定にしておき、障害が発生した際にレベルを上げて原因を特定するのが通常の運用です。

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

2.2.7 TPモニタ・マネージャ
${ 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.sav : サーバアプリケーションの起動、停止履歴
- sysmsg.trc,sysmsg.sav : APサーバへの接続履歴
.savファイルはそれぞれのバックアップファイルです。50000行を超えるかtpsystem起動時にファイルが切り替わりますので、障害発生時はサービス再起動前に採取してください。
${ INSTANCE_ROOT}/logs/tpsystem配下の全ファイル
アプリケーショングループとプロセスグループ別にサーバアプリケーションのログファイルが出力されます。

2.2.8 OLF/TPアダプタ

オプション製品 - OLF/TPアダプタ - <WebOTX OLF/TPアダプタ 運用ガイド>を参照してください。

2.3 予防措置

以下にあげる措置を講じておくと、障害予防または障害発生時の早期解決に役立ちます。

2.4 開発元へのお問い合わせ

開発元へお問い合わせの際は、以下の情報をお知らせください。

WebOTXに関する情報

WebOTXのEdition
WebOTXのバージョン
WebOTXのパッチ適用状況

環境に関する情報

OS情報
JDKのバージョン
最近変更した内容

システム構成に関する情報

使用言語
ステートレス/ステートフル

障害に関する情報

本番環境/評価環境
再現性の有無
障害内容とログ

3 障害対策

障害が発生した場合の対策について説明します。

3.1 プロセス監視

外部ツールなどを用いて、WebOTXのプロセス監視を行ないたい場合、監視を行なうべきプロセスおよび復旧方法について説明します。実際にプロセス監視を行なう場合は、以下を参考に必要に応じて監視プロセスの選択を行なってください。

なお、WebOTX上で動作するプロセス一覧については、「運用編（ドメインの運用）」の「3.システムに関する設定」を参照ください。

3.1.1 WebOTXエージェント
監視プロセス
java -server -Dwebotx.funcid=agent -Ddomain.name=domain1 -Xms64m -Xmx512m -XX:NewRatio=2 -Dsun.io.useCanonCaches=false ...
監視を行なう場合の注意点
javaプロセスであるため引数まで識別してプロセスを特定する必要があります。エージェントのJavaプロセスは、-Dwebotx.funcid=agent のシステムプロパティにより識別可能です。ドメインは、-Ddomain.nameシステムプロパティにより識別可能です。
異常検出時の復旧方法
エージェントプロセスの監視で異常を検出した場合は該当ドメインの再起動が必要です。
(停止) otxadmin> stop-domain domain1
(起動) otxadmin> start-domain  domain1

(注1) Windows OSの場合、[ ドメイン構築・基本設定ガイド > 4. ドメインの運用操作 > 4.4. ドメインの起動停止 > 4.4.4. サービスでの運用とコマンドでの運用の違い ] で説明しているように、復旧対象ドメインのプロセスユーザがコマンドを実行したユーザとなります。普段サービスから起動停止して運用しているような場合、ドメインプロセスのユーザが異なることで、アクセス権が変わり、業務アプリケーションに影響が出る可能性がありますのでご注意ください。

3.1.2 TPシステム
監視プロセス
iiopリスナ
iioplsn PLUNAME (5151) ...
ＴPモニタ
tpmonitor -n MySystem

TPモニタプロセスは、tpmonitorが親プロセス、tpmMainが子プロセスになります。tpmMainが異常終了すると、tpmonitor も終了します。従って、tpmonitor を監視すれば、両方の監視ができます。ただし、tpmonitor だけが終了した場合、実質的な業務への影響はほとんどありません。
監視を行なう場合の注意点
iiopリスナ：PLUNAMEで示されている番号が、IIOPリスナのポート番号(tpsystem.IIOPListener.listenerPortNumber)です。
TPモニタ： -n の次がWebOTXシステム名となっています。
異常検出時の復旧方法
iiopリスナプロセスの監視で異常を検出した場合は該当ドメインのTPシステムの再起動が必要です。
(停止) otxadmin> stop-system
(起動) otxadmin> start-system

TPモニタプロセスの監視で異常を検出した場合は該当マシンの再起動が必要です。クラスタ構成の場合は縮退もしくはフェイルオーバさせてください。

(停止) otxadmin> stop-system
(起動) otxadmin> start-system

3.1.3 ObjectBrokerサービス
監視プロセス
namesv
/usr/lib/ObjectSpinner/bin/namesv -WOdomain /opt/WebOTX/domains/domain1
cnamesv
/usr/lib/ObjectSpinner/bin/cnamesv -WOdomain /opt/WebOTX/domains/domain1
cnamesv
/usr/lib/ObjectSpinner/bin/cnamesv -WOdomain /opt/WebOTX/domains/domain1
oad
/usr/lib/ObjectSpinner/bin/oad -WOdomain /opt/WebOTX/domains/domain1
oadj
java -Dwebotx.funcid=oadj -Ddomain.name=domain1 -classpath /usr/lib/ObjectSpinner/lib/ospiorb50…
ospprxy
/usr/lib/ObjectSpinner/bin/ospprxy　…
監視を行なう場合の注意点
namesv, cnamesv, oad, oadjの場合、domain1の部分がドメイン名となります。
異常検出時の復旧方法
namesv、oad
WebOTXの全てのEdition製品にインストールされます。
異常を検出した場合は該当ドメインの再起動が必要です。
(停止) otxadmin stop-domain domain1
(起動) otxadmin start-domain domain1

oadj
WebOTXの全てのEdition製品にインストールされます。
異常を検出した場合は該当ドメインの oadj の再起動が必要です。
(停止) otxadmin stop-oadj
(起動) otxadmin start-oadj

cnamesv
Enterprise Editionで、選択した場合にだけインストールされます。
異常を検出した場合は該当ドメインのcnamesvの再起動が必要です。
(停止) invoke server.objectbrokerservice.cnamesv.stop
(起動) invoke server.objectbrokerservice.cnamesv.start

それでも復旧しない場合は、該当ドメインの再起動が必要です。
(停止) otxadmin stop-domain domain1
(起動) otxadmin start-domain domain1

ospprxy
Enterprise Editionで、選択した場合にだけインストールされます。
異常を検出した場合はospprxyの再起動が必要です。
(停止) start-ospprxy
(起動) stop-ospprxy

それでも復旧しない場合は、該当ドメインの再起動が必要です。
(停止) otxadmin stop-domain domain1
(起動) otxadmin start-domain domain1

3.1.4 JMSサービス
監視プロセス
JMSサーバ
java -server -Dwebotx.funcid=jms -Ddomain.name=domain1 -cp ....
監視を行なう場合の注意点
javaプロセスであるため引数まで識別してプロセスを特定する必要があります。JMSサーバのJavaプロセスは、-Dwebotx.funcid=jmsのシステムプロパティにより識別可能です。ドメインは、-Ddomain.nameシステムプロパティにより識別可能です。
異常検出時の復旧方法
異常を検出した場合は該当ドメインのJMSサーバの再起動が必要です。
(停止) otxadmin stop-jms
(起動) otxadmin start-jms

それでも復旧しない場合は、該当ドメインの再起動が必要です。
(停止) otxadmin stop-domain domain1
(起動) otxadmin start-domain domain1

3.1.5 Transactionサービス
監視プロセス
RCS(C++)
rcssv domain1C …
監視を行なう場合の注意点
RCS(C++)
domain1Cのdomain1の部分がドメイン名となります。
異常検出時の復旧方法
異常を検出した場合はトランザクションサービスの再起動が必要です。
(停止) otxadmin stop-transaction-service
(起動) otxadmin start-transaction-service

それでも復旧しない場合は該当ドメイン再起動が必要です。
(停止) otxadmin stop-domain domain1
(起動) otxadmin start-domain domain1

3.1.6 Webサーバ(Apache)

インストール時に、Webサーバ(Apache)を選択した場合に有効です。Javaの内蔵Webサーバを利用する場合には、本プロセスを監視する必要はありません。

監視プロセス
利用するApacheのバージョンにより、監視するプロセスが異なります。

(Apache 1.3.x 利用時)
(UNIX)　　　 /opt/WebOTX/WebServer/bin/httpd ……
(Windows) <INSTALLDIR>\WebServer\apache.exe

(Apache 2.0.x 利用時)
(UNIX)　　　 /opt/WebOTX/WebServer2/bin/httpd ……
(Windows) <INSTALLDIR>\WebServer2\bin\apache.exe
監視を行なう場合の注意点
Apacheは、UNIXの場合、1つの親プロセスと複数の子プロセスが動作し、その子プロセスはアクセス数に応じて自動的に増減しますので監視は親プロセスのみを対象にしてください。Windowsの場合、１つの親プロセスと１つ（複数スレッド）の子プロセスが動作しますので、両方のプロセスを監視対象にしてください。
異常検出時の復旧方法
異常を検出した場合は、該当ドメインのWebサーバ(Apache)の再起動が必要です。
(停止) otxadmin invoke server.internal-lifecycle-module.WebServerService.stop
(起動) otxadmin invoke server.internal-lifecycle-module.WebServerService.start

それでも復旧しない場合は該当ドメイン再起動が必要です。
(停止) otxadmin stop-domain domain1
(起動) otxadmin start-domain domain1

3.1.7 rotatelogs (server.log、server_err.log)

エージェントプロセスの標準出力/標準エラー出力先ファイルをローテートするためのプロセスです。このプロセスが停止した場合、エージェントプロセス上で標準出力/標準エラーに出力したメッセージがリダイレクト先のログファイル(既定値：${INSTANCE_ROOT}/logs/server.log)に出力されなくなります。

監視プロセス
(UNIX)
/opt/WebOTX/bin/rotatelogs -g3 ${INSTANCE_ROOT}/logs/server.log 2M
(Windows)
${INSTALL_ROOT}\bin\rotatelogs -g3 ${INSTANCE_ROOT}/logs/server.log 2M
監視を行なう場合の注意点
既定の場合、rotatelogsプロセスは1ドメインに対し1プロセス起動しますが、 標準出力と標準エラーを別のファイルに分ける設定を行っている場合、 1ドメインに対し標準出力用と標準エラー用の2プロセスが起動します。
また、Webサーバのログのログローテーション設定を行っている場合、同名のプロセス(rotatelogs)が起動するため、 引数まで識別してプロセスを特定する必要があります。
標準出力/標準エラー出力先ログファイル用のrotatelogsプロセスは、 引数の出力先ログファイルにより識別してください。
出力先ログファイルの設定は以下のコマンドを実行して確認してください。 
otxadmin > get server.log-service.file
標準出力と標準エラーを別のファイルに分ける設定を行っている場合、 標準エラー出力先ログファイルの設定は以下のコマンドを実行して確認してください。 
otxadmin > get server.log-service.err-file
異常検出時の復旧方法
異常を検出した場合は、該当ドメイン再起動が必要です。
(停止) otxadmin stop-domain domain1
(起動) otxadmin start-domain domain1

3.2 ログ監視

外部ツールなどを用いて、WebOTXのログ監視を行ないたい場合、監視を行なうべきログファイルおよび監視メッセージについて説明します。実際にログ監視を行なう場合は、以下を参考に必要に応じて監視ログの選択を行なってください。

3.2.1 イベントログ
説明
Windows OSでイベントログ(アプリケーションログ)に出力するWebOTXが出力する障害メッセージを監視させることが可能です。
監視メッセージ
以下のイベントソースがWebOTXで出力するイベントです。

イベントソース名 説明
WebOTX AS WebOTXエージェントが出力するイベントログです。致命的なメッセージを監視するには「エラー」レベルを監視対象にします。(※１)
WebOTXAgentService 「WebOTX　Agent Service」が出力するイベントログです。Windowsのサービス経由でWebOTXの起動・停止を行なったときのメッセージが出力されます。致命的なメッセージを監視するには「エラー」レベルを監視対象にします。
WebOTX_ASMonitor
systemname
 Standard/Enterprise Editionにおける「TPモニタ」サービスが出力するイベントログです。systemnameには該当ドメインで設定したシステム名が入ります。監視の詳細は3.2.4章を参照してください。
WebOTX_ASMonitor Standard/Enterprise EditionにおけるTPモニタ制御サービス(TPAサーバ：WebOTX TPBASEadmサービス)が出力するイベントログです。監視の詳細は3.2.4章「TPS12:TPAサーバ(運用管理)が出力するメッセージ」を参照してください。
WebOTX_TS 旧バージョンのWebOTX Transactionサービスが出力するイベントログです。Transactionサービスの旧互換ライブラリを使用している場合のみ出力します。致命的なメッセージを監視するには「エラー」レベルを監視対象にします。

※1 イベントIDのフォーマットについて

Windows環境において、各イベントログに対応するイベントIDは32bitのビット列で構成されています。

ビット数 定義
1〜2 Severity
3 Customer bit
4 Reserved bit
5〜16 Facility code
17〜32 Status code

WebOTXでは、イベントソース「WebOTX_AS」および「WebOTX_ObjectSpinner」で出力されるイベントログのイベントIDは、 イベントレベルにかかわらず 32bit 値の上位 16bit (「Severity」 から 「Facility code」まで) を常に「0」に設定しています。
そのため、監視ツールにおいて、イベントソース「WebOTX_AS」および「WebOTX_ObjectSpinner」のイベントIDを監視対象に設定する場合は、 イベントIDの上位 16bitが「0」となるように設定を行う必要があります。

例えば、NEC製のサーバ監視製品「ESMPRO/ServerAgent」,「WebSAM AlertManager」では、イベントソース名と32bit値のイベントIDをキーに監視を行います。
上記製品において監視対象とするイベントIDを設定する際、設定画面において10進数表示のまま監視対象を設定すると、イベントレベルに応じて 32bit値の最上位 2bit(Severity)が設定された状態で監視製品側に設定されます。

最上位2bit 種類
00 成功
01 情報
10 警告
11 異常

32bit値のイベントIDを使ってイベントソース「WebOTX_AS」および「WebOTX_ObjectSpinner」のイベントログを監視対象とする場合は、 [アラートマネージャ設定画面]の[表示]-[16進数表示]を選択し、上位 16bit を「0」として設定してください。

他のイベントログ監視ツールを利用する場合においても、同様の対処を行ってください。

3.2.2 シスログ
説明
UNIX OSでシスログに出力するWebOTXが出力する障害メッセージを監視させることが可能です。
監視メッセージ
以下のイベントソースがWebOTXで出力するイベントです。

ログ識別名 説明
WebOTX AS WebOTX内部で共有メモリやセマフォの作成、取得に失敗した場合に出力するイベントログです。また、Transactionサービスが出力するイベントログです。致命的なメッセージを監視するには「Error」レベル以上を監視対象にします。
WebOTX_Agent WebOTXエージェントが出力するイベントログです。致命的なメッセージを監視するには「Error」レベル以上を監視対象にします。
OTXM：systemname Standard/Enterprise Editionにおける「TPモニタ」サービスが出力するイベントログです。systemnameには該当ドメインで設定したシステム名が入ります。監視の詳細は3.2.4章を参照してください。
WebOTX_TS 旧バージョンのWebOTX Transactionサービスが出力するイベントログです。Transactionサービスの旧互換ライブラリを使用している場合のみ出力します。致命的なメッセージを監視するには「Error」レベル以上を監視対象にします。

3.2.3 WebOTX独自ログ
説明
WebOTXで独自に出力するログファイルを監視させることが可能です。
監視メッセージ
監視対象にするファイルについて以下に説明します。

ファイル名 説明
${INSTANCE_ROOT}/logs
WebOTX_Agent.log
 WebOTXドメインのエージェント内のJVMで出力される全てのメッセージを統合したログでです。致命的なメッセージを監視するには「ERROR」レベルを監視対象にします。
${INSTANCE_ROOT}/logs/WebServer
error_log
 WebOTX WebServerのエラーログです。致命的なメッセージを監視するにはログの先頭に「error」または「emerg」が出力されたメッセージを監視対象にします。
${INSTANCE_ROOT}/logs/ObjectBroker
oad.log
 Object Brokerのoadが出力するログファイルです。致命的なメッセージを監視するには、「ERROR: Startup of oad faild.」を含むメッセージを監視対象にします。
${INSTANCE_ROOT}/logs/ObjectBroker
namesv.log
 Object Brokerの名前サーバが出力するログファイルです。致命的なメッセージを監視するには、「ERROR: Startup of namesv faild.」を含むメッセージを監視対象にします。
${INSTANCE_ROOT}/logs/ObjectBroker
cnamesv.log
 Object Brokerのキャッシュ名前サーバが出力するログファイルです。致命的なメッセージを監視するには、「ERROR: Startup of cnamesv faild.」を含むメッセージを監視対象にします。

3.2.4 監視対象メッセージ(TPSメッセージ)
説明
イベントログ・シスログで監視すべきTPSメッセージは基本的にERRORレベルになります。ただし、ERRORレベルであっても条件によっては正常時に出力されるメッセージや、INFOレベルであっても監視対象にすべきメッセージが存在します。これらのメッセージ監視について説明します。
監視メッセージ
監視対象にするメッセージIDとエラーレベル、説明と注意事項について以下に説明します。メッセージ内容や処置についてはオペレータメッセージ編を参照してください。

TPS01：内部テーブルアクセスが出力するメッセージ
監視メッセージは特にありません。

TPS04：システムTPPが出力するメッセージ
以下のメッセージIDを監視対象としてください。TPS04-00703とTPS04-00713以外のERRORメッセージを監視する必要があります。

メッセージID エラーレベル 説明・注意事項
TPS04-00102ERROR
システムTPP の初期処理でエラーが発生したので、システムTPPは終了しました。エラーには以下の場合があります。
1. キュー制御初期化時のエラー
2. テーブル参照の失敗
3. 環境変数の不正
TPS04-00103ERROR キューの送受信で永久障害が発生したので、システムTPPは終了しました。
TPS04-00105ERROR TPBASE 内部テーブルのロック/アンロックの異常により、システムTPPは終了しました。
TPS04-00203ERROR WebOTX内部で使用するテーブルが正しくありません。
TPS04-00204ERROR カタログディレクトリ下のtpsmsgディレクトリへの移動に失敗しました。ERRNOは、内部で発行しているシステムのchdir 関数のerrnoです。
TPS04-00406ERROR 端末情報の取得に失敗しました。
TPS04-00703ERROR 共有作業域確保/ 解放関数でエラーが発生しました。
TPS04-00807ERROR アプリケーション初期プロセスが異常終了しました。
TPS04-00813ERROR アプリケーション初期プロセスを起動できません。
TPS04-00816ERROR アプリケーション初期プロセスからのレスポンスを、待ち時間を経過した後に受信しました。トランザクションの実行結果に関係なく電文を破棄しました。負荷が高い状態で運用されていることが考えられます。
TPS04-00903ERROR オペレータメッセージの送信処理でエラーが発生しました。
TPS04-00905ERROR オペレータメッセージの送信処理でエラーが発生しました。
TPS04-01002ERROR アプリケーショングループの起動に失敗しました。
TPS04-01003ERROR アプリケーショングループの停止に失敗しました。
TPS04-01011ERROR 内部テーブルが正しくありません。
TPS04-01012ERROR VDサーバから不正な電文を受信しました。
TPS04-01013ERROR VDサーバに対する電文の送信でエラーが発生しました。
TPS04-01201ERROR キュー制御関数でエラーが発生しました。一時障害なら処理を続行します。永久障害ならシステムTPPは終了します。
TPS04-01202ERROR メモリプール関数でエラーが発生しました。一時障害なら処理を続行します。永久障害ならシステムTPP は終了します。
TPS04-01203ERROR キュー制御関数でエラーが発生しました。一時障害なら処理を続行します。永久障害ならシステムTPP は終了します。
TPS04-01301ERROR メモリ不足のため作業領域が確保できません。
TPS04-01302ERROR
割り込みが発生しました。SIGIDはシグナル種別です。
SIGID=15 であれば、モニタ正常終了時でも出力されることがあります。
TPS04-01404ERROR VDの起動に失敗しました。
TPS04-01405ERROR VDの停止に失敗しました。
TPS04-01503ERROR activeディレクトリへのアクセスが失敗しました。

TPS06：キュー制御が出力するメッセージ
監視メッセージは特にありません。

TPS07：通信リスナが出力するメッセージ
以下のメッセージIDを監視対象としてください。TPS07-00307以外のERRORを監視する必要があります。

メッセージID エラーレベル 説明・注意事項
TPS07-00106ERROR リスナでキュー制御関数が失敗しました。エラーの内容はERRNOに依存します。
TPS07-00312ERROR 内部テーブルにアタッチできません。
TPS07-00313ERROR テーブルのロック／アンロックでエラーが発生しました。
TPS07-00401ERROR リスナが起動後、着呼待ちを行うための通信手順を行う際に致命的エラーがメッセージ内に表示される通信API関数で発生しました。
TPS07-00402ERROR リスナ起動に必須である関数（メッセージ内に表示）でエラーが発生したため、リスナが起動できません。
TPS07-00403ERROR メッセージ内に表示されるキュー制御関数で致命的エラーが発生しました。異常の内容はERRNOに依存します。
TPS07-00602ERROR TPBASE内部のキュー制御関数でエラーが発生しました。

TPS09：VDサーバが出力するメッセージ
以下のメッセージIDを監視対象としてください。監視しないERRORメッセージがあります。

メッセージID エラーレベル 説明・注意事項
TPS09-00101ERROR VDサーバの初期化処理に失敗しました。
TPS09-00106WARNING VDサーバがVD解放処理に失敗しました。VDを閉塞します。
TPS09-00107WARNING VDサーバがVD接続処理に失敗しました。VDを閉塞します。
TPS09-00114ERROR 電文の再送に失敗しました。
TPS09-00115WARNING トランザクション型VDで起動先オペレーションのレスポンス待ち時間をオーバーしました。
TPS09-00202WARNING VDサーバがVDごとの制御テーブルを検索できませんでした。
TPS09-00203WARNING VDサーバがクライアントごとの制御テーブルを検索できませんでした。
TPS09-00204WARNING VDサーバがオペレーションごとの制御テーブルを検索できませんでした。
TPS09-00205WARNING VDサーバが接続中のクライアントごとの制御テーブルを検索できませんでした。
TPS09-00206WARNING VDサーバが接続中のVDごとの制御テーブルを検索できませんでした。
TPS09-00309ERROR メモリの確保に失敗しました。
TPS09-00401ERROR VDサーバがメモリプールの初期化をできませんでした。
TPS09-00402ERROR VDサーバがメモリプールの生成をできませんでした。
TPS09-00403ERROR VDサーバがメモリプールの削除をできませんでした。
TPS09-00404ERROR VDサーバが端末送受信用メモリプールID の取得に失敗しました。
TPS09-00406ERROR 電文送信用に確保したメモリブロックの解放に失敗しました。
TPS09-00501ERROR VDサーバがキュー制御の初期化をできませんでした。
TPS09-00502ERROR VDサーバがキューを生成できませんでした。
TPS09-00503ERROR VDサーバがキューを削除できませんでした。
TPS09-00504ERROR VDサーバがキュー制御のリセットをできませんでした。
TPS09-00506WARNING VDサーバがキューをデキューイング禁止にできませんでした。
TPS09-00507WARNING VDサーバがキューをデキューイング禁止解除にできませんでした。
TPS09-00509WARNING VDサーバがトランザクション型VDの電文を送信できませんでした。このVDを閉塞します。
TPS09-00511WARNING VDサーバが端末型VDの電文を送信できませんでした。このVDを閉塞します。
TPS09-00512WARNING 正常に送信完了した電文をキューから削除できませんでした。このVDを閉塞します。
TPS09-00513WARNING VDサーバがキューをキューイング禁止にできませんでした。このVDを閉塞します。
TPS09-00514WARNING VDサーバがキューをキューイング禁止解除にできませんでした。このVDを閉塞します。
TPS09-00516WARNING VDサーバが滞留電文数を取得するためのキュー情報取得に失敗しました。このVDを閉塞します。
TPS09-00518WARNING VDサーバがキューの電文をパージ(デキューイング)できませんでした。
TPS09-00601WARNING リソース不足検出時のリトライ処理のためのタイマ登録に失敗しました。このVDを閉塞します。
TPS09-00602WARNING レスポンス時間監視用タイマ登録に失敗しました。
TPS09-00603WARNING レスポンス時間監視用タイマキャンセルに失敗しました。
TPS09-01110WARNING VD サーバへのVD滞留電文削除要求に失敗しました。
TPS09-01114WARNING VD作成に失敗しました。
TPS09-01119WARNING VDキューの滞留電文数の取得に失敗しました。
TPS09-01124WARNING 処理の途中でクライアントが切断されました。
TPS09-01201WARNING ファイル型VDのファイルオープンでエラーが発生しました。
TPS09-01202WARNING ファイル型VDのファイルリードでエラーが発生しました。
TPS09-01203WARNING ファイル型VDのファイルライトでエラーが発生しました。
TPS09-01204WARNING ファイル型VDのメッセージ登録に失敗しました。

TPS10：tplib(サーバAPライブラリ)が出力するメッセージ
以下のメッセージIDを必須の監視対象としてください。

メッセージID エラーレベル 説明・注意事項
TPS10-00301ERROR メモリプールIDが取得できません。
TPS10-00401ERROR 内部で利用される共有メモリが不足しています。
TPS10-00501ERROR メモリプールの初期化ができません。
TPS10-00601ERROR メモリブロックの解放ができません。
TPS10-00701ERROR メモリプールの作成ができません。
TPS10-00801ERROR 内部で利用されるキュー制御関数の初期化ができません。
TPS10-00901ERROR 内部で利用されるキューの生成ができません。
TPS10-01001ERROR 内部で利用されるキュー制御関数でエラーが発生しました。
TPS10-01101ERROR 内部で利用されるキュー制御関数でエラーが発生しました。
TPS10-01201ERROR 内部で利用されるキュー制御関数でエラーが発生しました。
TPS10-01301ERROR 内部で利用されるメモリブロックの確保ができませんでした。
TPS10-01401ERROR 内部で利用される共有メモリが不足しています。
TPS10-02501ERROR 指定されたプロセスグループは存在しない。
TPS10-02601ERROR なんらかの原因で内部で利用されるテーブルが破壊されています。
TPS10-02701ERROR なんらかの原因で内部で利用されるテーブルが破壊されています。
TPS10-02901ERROR メモリ不足です。
TPS10-03001ERROR activeディレクトリに書き込み権がありません。
TPS10-04501ERROR なんらかの原因で内部で利用されるテーブルが破壊されています。
TPS10-11301ERROR 送信スレッドの停止状態を検出しました。
TPS10-11701ERROR 実行スレッドが全て停止しました。
TPS10-13501ERROR WebOTXの制御外でスレッドが消滅しているのを検出した。
TPS10-14201ERROR 内部で利用されるキュー制御関数でエラーが発生しました。

以下のメッセージIDは利用者側の判断で監視対象としてください。

メッセージID エラーレベル 説明・注意事項
TPS10-01901ERROR メモリ不足です。
TPS10-02101ERROR メモリ不足です。
TPS10-02201ERROR メモリ不足です。
TPS10-02301ERROR メモリ不足です。
TPS10-03101ERROR 停止中のアプリケーショングループに対して呼び出しが発生しました。
TPS10-03201ERROR 閉塞中のオペレーションに対して呼び出しが発生しました。
TPS10-03301ERROR サーバコンポーネント(dllディレクトリの.so、.sl、.dll)の形式不正。
TPS10-03501ERROR データベースの接続ができませんでした。
TPS10-03601ERROR データベースの切り離しに失敗しました。
TPS10-03701ERROR オペレーションの再実行回数が設定値になりました。
TPS10-04401ERROR オペレーション実行中に例外が発生しました。コードに続いてアプリケーショングループ名、プロセスグループ名、プロセスIDを表示しています。
TPS10-04901ERROR なんらかの原因で内部テーブルが破壊されています。
TPS10-05101ERROR ディスク容量不足で、ファイル型VDへの書き込みエラーが発生しました。
TPS10-05301ERROR ORACLEのエラーが検出されました。
TPS10-11001ERROR スレッド情報の初期化に失敗しました。
TPS10-11101ERROR スレッド生成後の初期化処理にてタイムアウトが発生しました。
TPS10-12001ERROR 内部エラー。
TPS10-12201ERROR 内部エラー。
TPS10-12301ERROR 内部エラー。
TPS10-13001ERROR TPSAbort(0) （スレッドの終了）が呼び出されました。ユーザ実装部でTPSAbort(0)を呼んだか、もしくは、Javaで作られた常駐オブジェクトのコールバックがランタイム例外を発生したためにそれを検出したオブジェクトマネージャがTPSAbort(0)を呼び出しました。
TPS10-13101ERROR TPSAbort(1) （スレッドのリスタート）が呼び出されました。
TPS10-13201ERROR TPSAbort(-1) （プロセスの終了）が呼び出されました。ユーザ実装部でTPSAbort(-1)を呼んだか、もしくは、Javaで作られたユーザ実装部がランタイム例外を発生したためにそれを検出したオブジェクトマネージャがTPSAbort(-1)を呼び出しました。
TPS10-13301ERROR オペレーションの実行時間上限を超えたため処理を打ち切りました。
TPS10-14001ERROR メモリ不足です。
TPS10-14101ERROR メモリ不足です。
TPS10-16001ERROR DB連携機能を使用したプロセスで例外が発生したためプロセスを強制終了しました。
TPS10-16101ERROR DB連携機能を使用したプロセスで実行時間超過が発生したためプロセスを強制終了しました。

TPS11：ジャーナルが出力するメッセージ
監視メッセージは特にありません。

TPS12：TPAサーバ(運用管理)が出力するメッセージ
以下のメッセージIDを監視対象としてください。

メッセージID エラーレベル 説明・注意事項
TPS12-00101ERROR ホスト名がhostsファイル内に定義されていません。
TPS12-00103ERROR socketシステムコールでエラーが発生しました。
TPS12-00104ERROR connectシステムコールでエラーが発生しました。
TPS12-00112ERROR
Windowsのみ
サービス制御のためのハンドル取得に失敗しました。
TPS12-00113ERROR
Windowsのみ
ステータス取得に失敗しました。
TPS12-00115ERROR
Windowsのみ
bindシステムコールでエラーが発生しました。
TPS12-00116ERROR
Windowsのみ
listenシステムコールでエラーが発生しました。
TPS12-00117ERROR
Windowsのみ
acceptシステムコールでエラーが発生しました。
TPS12-00119ERROR getaddrinfoシステムコールでエラーが発生しました。
TPS12-00120ERROR ソケットの作成に失敗しました。
TPS12-00121ERROR selectシステムコールでエラーが発生しました。
TPS12-01310ERROR
Windowsのみ
WSAStartupの実行に失敗しました。
TPS12-01311ERROR
Windowsのみ
OpenSCManagerの実行に失敗しました。
TPS12-01312ERROR
Windowsのみ
TPBASEadmの起動に失敗しました。
TPS12-01313ERROR
Windowsのみ
起動待ち時間内にTPBASEadmの起動が完了しませんでした。
TPS12-54101ERROR
Windowsのみ
サービス WebOTX AS TPBASEadm 起動時に、エラー番号の要因により、レジストリ(SOFTWARE\NEC\WebOTX\TPBASE)のオープン関数RegOpenKeyEx()に失敗しました。
TPS12-54102ERROR
Windowsのみ
サービス WebOTX AS TPBASEadm 起動時に、エラー番号の要因により、レジストリキー値の取得関数RegQueryValueEx()に失敗しました。
TPS12-54112ERROR
Windowsのみ
サービス WebOTX AS TPBASEadm 起動時に、エラー番号の要因により、StartServiceCtrlDispatcher()の実行に失敗しました。
TPS12-54132ERROR
Windowsのみ
サービス WebOTX AS TPBASEadm 起動時に、エラー番号の要因により、RegisterServiceCtrlHandler()の実行に失敗しました。
TPS12-54133ERROR
Windowsのみ
サービス WebOTX AS TPBASEadmの起動、または、停止時に、エラー番号の要因により、サービス制御マネージャへの通知関数ReportStatus()の実行に失敗しました。
TPS12-54134ERROR
Windowsのみ
サービス WebOTX AS TPBASEadm起動時に、エラー番号の要因により、CreateProcess()の実行に失敗しました。
TPS12-54239ERROR
Windowsのみ
サービス WebOTX TPBASEadm起動後の、サービス監視関数の実行に失敗しました。(リトライ失敗)

TPS13：メッセージ制御が出力するメッセージ
以下のメッセージIDを監視対象としてください。全ERRORメッセージを監視対象にする必要があります。

メッセージID エラーレベル 説明・注意事項
TPS13-00102ERROR メッセージ制御の初期処理でエラーが発生したため終了しました。以下の場合があります。
  • キュー制御初期化のエラー
  • テーブル参照の失敗
  • 環境変数の不正
    		•
    TPS13-00103ERROR キューの送受信で永久障害が発生したので、メッセージ制御は終了しました。
    TPS13-00105ERROR 内部テーブルのロック／アンロックの異常により、メッセージ制御は終了しました。
    TPS13-00201INFO 内部で使用するテーブルが正しくありません。
    TPS13-00301INFO 受信電文に必要な最低限の長さがありません。
    TPS13-00302ERROR 受信電文の要求種別はメッセージ送信TPP で扱わないものです。
    TPS13-00502ERROR 割り込みが発生しました。

    TPS15：TPモニタが出力するメッセージ
    以下のメッセージIDを監視対象としてください。監視しないERRORメッセージがあります。

    メッセージID エラーレベル 説明・注意事項
    TPS15-00102ERROR プロセスの起動に失敗しました。
    TPS15-00106ERROR TPシステムが起動時情報登録に失敗しました。
    TPS15-00602ERROR メモリ不足のため、コマンド管理テーブルの作成に失敗しました。
    TPS15-00603ERROR メモリ不足のため、プロセス管理テーブルの作成に失敗しました。
    TPS15-00604ERROR 共有メモリはすでに存在しています。
    TPS15-00605ERROR 共有メモリの確保に失敗しました。
    TPS15-00612ERROR メッセージキューが処理待ちのメッセージでいっぱいになりました。
    TPS15-00701ERROR TPBASE構成ファイル中のTBLKEY で共有テーブルが作成できませんでした。
    TPS15-00702ERROR TPBASE構成ファイル中のTBLKEYで共有テーブルが作成できませんでした。
    TPS15-00901ERROR 構成ファイル(tpbase.cnf)の処理中にエラーが発生しました。
    TPS15-01101ERROR TPシステムの起動に失敗しました。
    TPS15-01102ERROR TPシステムが異常終了しました。
    TPS15-01103ERROR アプリケーショングループの起動に失敗しました。続く名前はアプリケーショングループ名。
    TPS15-01105ERROR プロセスグループの起動に失敗しました。CLASSはプロセスグループ名、PEDはアプリケーショングループ名。
    TPS15-01107ERROR
    TPシステムからの停止指示以外の原因でプロセスが終了しました。PIDはプロセスID、classはプロセスグループ名、pedはアプリケーショングループ名。

    リスナ異常終了対策として、TPS15-01107とclass[IIOPLSN_CLS] のand条件、TPS15-01107 と class[OLFTPLSN_CLS] のand条件、を監視して下さい。なお、WebOTXを起動したままOSシャットダウンを行なうと本メッセージがでる場合があることに留意してください。検出時の対処としては、TPS07で始まるその他のメッセージが出ている場合はその対処に従い、特に出ていない場合はWebOTX開発元に連絡して下さい。
    TPS15-01313ERROR ファイルI/Oエラーが発生しました。
    TPS15-02002ERROR TPモニタプロセス(tpmMain)で例外が発生しました。
    TPS15-02003ERROR sigaction()コールの失敗により、TPシステムの起動に失敗しました。
    TPS15-02004ERROR fork()コールの失敗により、TPシステムの起動に失敗しました。
    TPS15-02009ERROR TPシステム登録情報が不正です。
    TPS15-02022ERROR レジストリへのアクセスに失敗しました。
    TPS15-02023ERROR レジストリへのアクセスに失敗しました。
    TPS15-02026ERROR CreateProcess()コールの失敗により、TPモニタの起動に失敗しました。
    TPS15-02027ERROR sigaction()コールの失敗により、TPモニタの起動に失敗しました。
    TPS15-02028ERROR execvp()コールの失敗により、TPモニタの起動に失敗しました。
    TPS15-02029ERROR fork()コールの失敗により、TPモニタの起動に失敗しました。
    TPS15-02030ERROR waitpid()コールの失敗により、TPモニタの起動に失敗しました。
    TPS15-02034ERROR sigaction()コールの失敗により、TPモニタの起動に失敗しました。
    TPS15-02101ERROR TPモニタが予期しないシグナル xxxx を受信し、例外しました。
    TPS15-10001ERROR キュー管理ロックテーブルの初期化に失敗しました。
    TPS15-10002ERROR キュー管理テーブルの共有メモリの確保に失敗しました。
    TPS15-10003ERROR キュー管理テーブルの共有メモリのアタッチに失敗しました。
    TPS15-10004ERROR メッセージ管理テーブルの共有メモリの確保に失敗しました。
    TPS15-10005ERROR メッセージ管理テーブルの初期化に失敗しました。
    TPS15-10006ERROR メモリプールテーブルの共有メモリの確保に失敗しました。
    TPS15-10007ERROR メモリプールテーブルの初期化に失敗しました。
    TPS15-10008ERROR メモリプールテーブルの作成に失敗しました。

    TPS17：タイマデーモンが出力するメッセージ
    監視メッセージは特にありません。

    TPS18：データベースインタフェースが出力するメッセージ
    監視メッセージは特にありません。

    TPS19：VDキュー管理が出力するメッセージ
    以下のメッセージIDを監視対象としてください。全ERRORメッセージを監視対象にする必要があります。

    メッセージID エラーレベル 説明・注意事項
    TPS19-00101ERROR VD用データファイルが壊れています。または、未初期化のデータファイルを使用しています。
    TPS19-00102ERROR VD用データファイルが壊れています。または、未初期化のデータファイルを使用しています。
    TPS19-00103WARNING VD用データファイルの破損を検出しましたが修復しました。
    TPS19-00104WARNING VD用データファイルの破損を検出しましたが修復しました。
    TPS19-00105ERROR VD用データファイルの設定変更に失敗しました。変更内容は以下の場合があります。
  • filesize：ファイルサイズが現在使用中のサイズより小さく縮小できない。
    		•
    TPS19-00106ERROR VD用データファイルに空き領域がありません。
    TPS19-00107ERROR VD用データファイルが壊れている可能性があります。
    TPS19-00201ERROR VD用キューの管理データが壊れています。
    TPS19-00202ERROR VD用キューの管理データが壊れています。
    TPS19-00203WARNING VD用キューの管理データの破損を検出しましたが修復しました。
    TPS19-00204WARNING VD用キューの管理データの破損を検出しましたが修復しました。
    TPS19-00207ERROR VD用キューの管理テーブルが存在しません。または、未初期化のデータファイルを使用しています。管理テーブルは以下の場合があります。
  • file management table：データファイル管理テーブル
  • file list table            ：ファイルリストテーブル
  • queue list table        ：キューリストテーブル
    		•
    TPS19-00208ERROR 重複するキューを作成しようとしました。
    TPS19-00209ERROR 最大キュー数を越えてキューを作成しようとしました。
    TPS19-00210ERROR 最大ファイル数を越えて VD データファイルを作成しようとしました。
    TPS19-00211ERROR 送信禁止状態のキューにデータを送信しようとしました。VD データファイルが壊れている可能性があります。
    TPS19-00212ERROR 受信禁止状態のキューからデータを受信しようとしました。VD データファイルが壊れている可能性があります。
    TPS19-00213ERROR 優先送信不可状態のキューにデータを優先送信しようとしました。VD データファイルが壊れている可能性があります。
    TPS19-00302ERROR 他プロセスが掛けたロックをアンロックしようとしました。VD データファイルが壊れている可能性があります。
    TPS19-00303ERROR ロックファイル名称を取得できませんでした。
    TPS19-01101ERROR WebOTX 内部で使用する SG テーブルが正しくありません。
    TPS19-01102ERROR 最大値を越えた要求です。
  • tpbase.cnf/MAXVDF ：VD データファイル数のオーバー
    		•
    TPS19-02101ERROR OSのライブラリ関数呼び出しでエラーが発生しました。資源不足やシステム異常が発生している可能性があります。
    TPS19-02102ERROR OSのライブラリ関数呼び出しでエラーが発生しました。資源不足やシステム異常が発生している可能性があります。
    TPS19-02103ERROR OSのライブラリ関数呼び出しでエラーが発生しました。資源不足やシステム異常が発生している可能性があります。
    TPS19-02104ERROR OSのライブラリ関数呼び出しでエラーが発生しました。資源不足やシステム異常が発生している可能性があります。
    TPS19-02105ERROR OSのライブラリ関数呼び出しでエラーが発生しました。資源不足やシステム異常が発生している可能性があります。

    TPS20：VDキューツールコマンドが出力するメッセージ
    監視メッセージは特にありません。

    3.3 Object Broker での例外と対処
    Object Brokerサービスに関する例外と対処について説明します。

    3.3.1 Object Broker Java例外一覧
    Object BrokerJavaで発生する例外ごとに、マイナーコード別の原因と対策を一覧にしています。

    NO_RESPONSE

    COMM_FAILURE

    UNKNOWN

    INITIALIZE

    MARSHAL

    OBJ_ADAPTER

    OBJECT_NOT_EXIST

    NO_IMPLEMENT

    INV_OBJREF

    BAD_PARAM

    NO_PERMISSION

    BAD_OPERATION

    3.3.2 Object Broker C++例外一覧
    Object BrokerC++で発生する例外ごとに、マイナーコード別の原因と対策を一覧にしています。

    BAD_PARAM

    COMM_FAILURE

    INV_OBJREF

    NO_PERMISSION

    NO_RESPONSE

    TRANSIENT

    OBJ_ADAPTER

    3.4 JavaVMのスレッドダンプ取得
    WebOTXが起動中にストール状態になる、または、コマンドからの応答がなく停止できない状態など、WebOTXが無応答状態に陥った場合には以下の手順でJavaVMのスレッドダンプを取得し開発元に問い合わせを行ってください。

    スレッドダンプの取得方法には以下のようなものがあります。


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

    3.4.1 統計レポート出力コマンドを利用した取得方法
    運用管理コマンドを使用して、Javaプロセスに対する様々な監視項目をレポート形式で出力できます。
    以下の方法でスレッドダンプを採取します。
    取得方法
    1. 次のコマンドを実行して下さい。コンソール上にスレッドダンプが出力されます。
      2. otxadmin> generate-jvm-report --type thread <サーバ名>

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

      * ドメインに対するエージェントプロセス : server

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

    詳しい取得方法については、運用編-3.運用と操作-ドメインの運用の 「4.11.3 統計レポート出力」の「スレッド情報の表示」を参照してください。

    3.4.2 診断サービスを利用した取得方法
    診断サービスという、障害解析のための情報収集機能に、スレッドダンプを取得する機能があります。
    以下の方法でスレッドダンプを採取します。
    取得方法
    1. 運用管理ツール、もしくは次のコマンドにてスレッドダンプ取得の属性値をtrueとします。
      2. otxadmin> set server.diagnostic-service.capture-thread-dump=true
    2. 運用管理ツールの診断レポートの生成を実行するか、次のコマンドで診断サービスを実行して下さい。

      3. ・ドメインに対するエージェントプロセスが起動している場合

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

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

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

    診断サービスを実行すると、テキストファイルにスレッドダンプが出力されます。
    詳しい取得方法については、運用編-3.運用と操作-診断サービスの 「2. 診断サービスの実行」を参照してください。

    3.4.3 各OS固有の取得方法

     UNIXとWindowsについて、それぞれ以下のような手順でスレッドダンプを取得します。

    3.4.3.1 UNIXのスレッドダンプ
    以下の手順でスレッドダンプを採取します。
    取得方法
    1. ドメインのJavaVMを特定します。

      2. psコマンドによりドメインのJavaVMを特定します。psコマンドの結果では、他のjavaプロセスとの区別がつきにくいためJavaVMに指定された-Xオプションを手がかりにプロセスの特定を行ってください。

      ps -exf |grep java |grep ドメイン名 |grep ' -X'

      ドメインのJavaVMにはデフォルトインストールで以下のオプションが引数に指定されています。

      -server -Dwebotx.funcid=agent -Ddomain.name=domain1 -Xms64m -Xmx512m -XX:NewRatio=2

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

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

      kill -QUIT <pid>

    スレッドダンプが/opt/WebOTX/domains/ドメイン名/logs/server.logに出力されます。

    3.4.3.2 Windowsのスレッドダンプ
    Windowsでは、Javaプロセスに対して Ctrl+Break キーを送信することでスレッドダンプが出力されます。しかし、WebOTXはサービスとして起動されているために通常ではスレッドダンプの取得は行えません。スレッドダンプを出力させるようにするには以下の設定を行うことで取得できます。
    ドメインを再起動する必要があるため再現性のある問題に対して有効です。ただし、この設定をすることによりドメインの起動時にデスクトップ上にコンソールが表示されます。 この状態でログオフを行うとWindowsの仕様によりドメインプロセスが停止してしまいます。そのため、調査中はログオフを行わないようにしてください。また、障害調査以外の通常運用時は設定を元にもどすようにしてください。
    (注)タスクスケジューラからWebOTXを起動する運用の場合、Windowsの仕様によりコンソールが表示されないことがあります。 この場合は、Windows標準の「AT」コマンド(「interactive」オプション指定が必要)での代用をご検討ください。
    設定方法
    1. コンソール表示を有効にする。

      2. ドメイン起動時に以下のコマンドによりコンソール出力設定を有効にしてください。

      server.log-service.alloc-console=true

    2. ドメインを再起動し、javaw.exeのコンソールが表示されることを確認してください。
    3. 表示されたコンソールをアクティブな状態にしてCtrl + Breakを送信してください。

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

    設定解除方法
    1. コンソール表示を無効にする。 　　　

      ドメイン起動時に以下のコマンドによりコンソール出力設定を無効にしてください。

      server.log-service.alloc-console=false

    2. ドメインを再起動し、javaw.exeのコンソールが表示されないことを確認してください。

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

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

    stop-domainの--forceオプションと--wait_timeoutオプションを指定して、該当ドメインを停止してください(domain1の部分がドメイン名を表します)。

    例)

    otxadmin stop-domain --force --wait_timeout 180 domain1

    　　　　　　　　　　　
    --wait_timeoutオプション指定時は指定した時間[秒]だけ通常停止を試みた後、強制停止処理を実行します。
    --wait_timeoutオプションを指定しない場合は--wait_timeoutオプションの既定値として600[秒]が設定されます。
    --forceオプション指定時のログは
    ${AS_INSTALL}/domains/domain1/logs/agent/webotx_prcstop.log に出力されます。