Component Containerのログとして取得する資料の出力先を次に示します。それぞれの資料の詳細については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「5.2　アプリケーションサーバのログ」を参照してください。

表3-41　Webコンテナサーバおよびリダイレクタのログの出力先（デフォルト）

（凡例）−：該当しない

注

チャネル名は，ログの出力先を識別する名称です。ログの属性（サイズ，面数）を変更する場合のキー値として使用します。

注※1

［n］：ログファイル名の［n］部分には，面の番号（1から面数（最大16）まで）が付きます。また，［nn］の部分には01〜99の通し番号が付きます。

注※2

ディレクトリ，ファイル名は，isapi_redirect.conf（Microsoft IIS用リダイレクタ動作定義ファイル），またはmod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）で設定できます。リダイレクタのログ取得の設定については，「3.7.5　トラブルシューティングの資料取得の設定」を参照してください。isapi_redirect.conf（Microsoft IIS用リダイレクタ動作定義ファイル）については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「9.2　isapi_redirect.conf（Microsoft IIS用リダイレクタ動作定義ファイル）」を参照してください。mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「9.3　mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）」を参照してください。

注※3

サーブレット，JSPで発生した例外のスタックトレースについても出力されます。

注※4

標準出力にも出力されます。また，サーブレット，JSPでのSystem.out，およびSystem.errへの出力はユーザ出力ログ，およびユーザエラーログに出力されます。

注※5

起動プロセス情報だけを取得するログです。主にWebコンテナサーバの起動または終了時に出力されるため，オンライン中に出力されることはほとんどありません。ファイルのサイズが上限に達したときは，<製品のインストールディレクトリ>\CC\web\containers\<サーバ名称>\logs下（Windowsの場合），または/opt/Cosminexus/CC/web/containers/<サーバ名称>/logs下（UNIXの場合）のcjstdout_save.logまたはcjstderr_save.logに退避されます。すでにcjstdout_save.logまたはcjstderr_save.logがあったときは，上書きされます。

注意

WebサーバとしてMicrosoft IISを使用している場合，リダイレクタのログファイルは，Webサーバへの初回アクセス時に，isapi_redirect.confで指定したファイルサイズで，指定した面数分，すべて作成されます。このとき，トレースファイルは空白(0x20)で初期化されます。デフォルトのファイルサイズと面数で運用している場合，ログの出力先に指定したディレクトリに，52メガバイトのディスク容量が必要になります。

なお，Webコンテナサーバおよびリダイレクタのログの出力先を変更している場合は，次の表に示す，ログの出力先を設定するユーザ定義ファイルを参照して出力先を確認してください。

表3-42　ログの出力先を設定するユーザ定義ファイル（サーブレットエンジンモードの場合）

ログの出力先の変更方法など，トラブルシューティングの資料取得の設定については，「3.7.5　トラブルシューティングの資料取得の設定」を参照してください。

(a)　Performance Tracerのログ

Performance Tracerのログの出力先を次に示します。

それぞれの資料の詳細については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「5.2　アプリケーションサーバのログ」を参照してください。

表3-43　Performance Tracerのログの出力先

注

[n]には「01」または「02」が表示されます。

(b)　DABroker Libraryのログ

それぞれの資料の詳細については，「4.6.3　DABroker Libraryのスプール情報の内容」を参照してください。

DABroker Libraryでは，トラブルシューティングに使用するログとして，スプール情報を取得します。

次のディレクトリ下のすべてのファイルをコピーして保存してください。

• Windowsの場合
  <DABroker Libraryの運用ディレクトリ>\spool
  
• UNIXの場合
  <DABroker Libraryの運用ディレクトリ>/spool
  

参考

DABroker Libraryでは，スプール情報のほかに次のJDBCドライバのトレースも取得できます。

• JDBCインタフェースメソッドトレース
• DABroker Libraryとのイベントトレース

ただし，JDBCドライバで次のトレースを取得するためには，アプリケーション開発時にあらかじめ指定されている必要があります。トレースを取得するための情報の設定については，「4.7　DABroker Library を使用したデータベース接続の実装」を参照してください。

(c)　Webアプリケーションのログ

Webアプリケーションのログは，トレース共通ライブラリ形式で出力するように設定している場合に取得できます。

Webアプリケーションのログの出力先については，usrconf.properties（Webコンテナサーバ用ユーザプロパティファイル）のejbserver.application.userlog.CJLogHandler.<ハンドラ名>.pathキーの値を参照してください。なお，<ハンドラ名>には，キーの値を区別するためのハンドラ名が指定されています。

usrconf.propertiesファイルの格納場所を次に示します。

• Windowsの場合
  <製品のインストールディレクトリ>\CC\web\containers\<サーバ名称>\usrconf\usrconf.properties
  
• UNIXの場合
  /opt/Cosminexus/CC/web/containers/<サーバ名称>/usrconf/usrconf.properties
  

なお，Webアプリケーションのユーザログ出力の設定については，「3.7.5(10)　Webアプリケーションのユーザログ出力の設定」を参照してください。

性能解析トレースの収集方法については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「7.　性能解析トレースを使用した性能解析」を参照してください。セッショントレースも同様に取得できます。

性能解析トレースの格納場所は次のとおりです。

• Windowsの場合
  <環境変数PRFSPOOLの設定ディレクトリ>\utt\prf\<PRF識別子>
  
• UNIXの場合
  $PRFSPOOL/utt/prf/<PRF識別子>
  

ここでは，JavaVMのスレッドダンプを取得する方法について説明します。

なお，Webコンテナサーバの起動オプションとして-XX:+HitachiThreadDumpが設定されている場合，拡張スレッドダンプを取得できます。-XX:+HitachiThreadDumpToStdoutが設定されている場合，スレッドダンプは標準出力にも出力されます。

また，-XX:+HitachiOutOfMemoryAbortが設定されている場合に，-XX:+HitachiOutOfMemoryAbortThreadDumpが設定されていると，OutOfMemoryErrorによって強制終了した時に，スレッドダンプが出力されます。ただし，次の場合は除きます。

• J2SEクラスライブラリ内でCヒープ不足が発生した場合
• JavaVMの処理中にCヒープ不足が発生した場合

cjstartwebプロセスが存在する場合のスレッドダンプの取得方法を次に示します。

• Windowsの場合
  cjstartwebプロセスが存在する場合，次を実行します（3秒おきに10回程度）。
  

  <製品のインストールディレクトリ>\CC\web\bin\cjdumpweb <Webコンテナサーバ名>

  　
  
• UNIXの場合
  cjstartwebプロセスが存在する場合，cjdumpwebコマンドまたはkillコマンドを使用してWebコンテナサーバのスレッドダンプを取得します（3秒おきに10回程度）。
  
  • cjdumpwebコマンドを使用する場合
    

    /opt/Cosminexus/CC/web/bin/cjdumpweb <Webコンテナサーバ名>

  • killコマンドを使用する場合
    

    ps -ef | grep cjstartweb kill -3 <WebコンテナサーバのプロセスID>

  スレッドダンプは，「/opt/Cosminexus/CC/web/containers/<サーバ名称>/javacore*.txt」，およびサーバ標準出力ログ（cjstdout.log）に出力されます。
  　
  

また，javacore<プロセス番号>.<コマンド実行日時>.txtファイルの出力先は，環境変数JAVACOREDIRで変更できます。ただし，指定したディレクトリへの書き込みに失敗した場合は，カレントディレクトリに出力されます。このディレクトリにも出力できなかった場合は，標準エラー出力にだけ出力されます。

参考

スレッドダンプが出力されると，標準出力に，次のメッセージが出力されます。そのあと，javaプログラムの実行が継続されます。このメッセージは，-XX:+HitachiThreadDumpToStdoutの設定とは関係なく出力されます。

Writing Java core to <ファイル名（フルパス）>...OK

　

JavaVMのGCログは，JavaVMまたはWebコンテナサーバ起動前にログ出力先が設定されている場合にだけ取得できます。

ユーザ定義ファイルを使用して設定している場合は，usrconf.cfgファイルのweb.server.log.directoryのキーを確認してください。

また，実行中のJavaプロセスでGCを発生させたい場合は，javagcコマンドを実行してください。javagcコマンドは，トラブル発生時の要因調査のほか，1トランザクション当たりのメモリ使用量の測定，メモリリークの調査，アプリケーションのデバッグなどの目的でも使用できます。

実行中のJavaプロセスを指定してGCを発生させる場合，javagcコマンドは，次の形式で実行します。なお，これ以外に指定できるオプションについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「javagc（GCの強制発生）」を参照してください。

　
javagc -p プロセスID
　

実行結果として，次のログが出力されます。なお，これは，オプションとして，-XX:+HitachiVerboseGCPrintCauseが指定されている場合の例です。

• Windowsの場合
  

  [VGC]<Wed Mar 17 00:42:30 2004>(Skip Full:0,Copy:0)[ Full GC 149K->149K(1984K),0.0786038 secs] [ DefNew::Eden:264K->0K(512K)] [ DefNew::Survivor:0K->63K(64K)] [ Tenured: 85K->149K(1408K)] [Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)] [ cause:System.gc]

• UNIXの場合
  

  [VGC]<Wed Mar 17 00:42:30 2004>(Skip Full:0,Copy:0)[ Full GC 149K->149K(1984K),0.0786038 secs] [ DefNew::Eden:264K->0K(512K)] [ DefNew::Survivor:0K->63K(64K)] [ Tenured: 85K->149K(1408K)] [Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)] [ cause:JavaGC Command]

javagcコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「javagc（GCの強制発生）」を参照してください。

なお，-XX:+HitachiVerboseGCPrintCauseオプションは，usrconf.cfgに指定します。オプションの設定方法については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「-XX:[+|-]HitachiVerboseGCPrintCause（GC要因内容出力オプション）」を参照してください。

メモリダンプの取得の取得方法についてOSごとに説明します。

(a)　Windowsの場合

Webコンテナサーバを再起動するときに，メモリダンプを取得します。メモリダンプは，システムでトラブルが発生したときに，保守員が障害解析するために使用します。

Webコンテナサーバが稼働している場合（cjstartwebプロセスが存在する場合），タスクマネージャからcjstartwebのプロセスIDを取得します。userdump.exe <プロセスID> を実行し，メモリダンプ（user.dump）を採取します。

(b)　UNIXの場合

Webコンテナサーバを再起動するときに，メモリダンプとして，Webコンテナサーバのcoreダンプを取得します。メモリダンプは，システムでトラブルが発生したときに，保守員が障害解析するために使用します。

cjstartwebプロセスがダウンした場合，「/opt/Cosminexus/CC/web/containers/<サーバ名称>/core*」に出力されたcoreダンプを取得します。

coreダンプのファイル名は，cjstartwebプロセスの再起動時に「core.<出力日時^※>」（AIX，HP-UXの場合）または「core.<プロセスID>.<出力日時^※>」（Linuxの場合）にリネームされます。cjstartwebプロセスの再起動時にcoreダンプが上書き保存されないため，障害発生時のcoreダンプを保存できます。

注※

出力日時は「YYMMDDhhmmss」の形式で出力されます。

YY：西暦（下2けた）　MM：月（2けた）　DD：日（2けた）

hh：時（2けた[24時間表記]）　mm：分（2けた）　ss：秒（2けた）

なお，保存するcoreダンプは上限値を設定できます。cjstartwebプロセスの再起動時に「/opt/Cosminexus/CC/web/containers/<サーバ名称>/」に出力されるcoreダンプファイルの合計が上限値を超えた場合，出力日時が古い順に削除されます。上限値は，usrconf.cfgのweb.server.corefilenumキーに指定します。なお，ファイルの削除はcjstartwebプロセスの再起動時に実行されます。

coreダンプを取得したあとに，coreダンプからスタックトレース情報だけを取得する場合は，javatraceコマンドを実行してください。スタックトレース情報は，JavaVMの異常終了の原因を究明するために必要な情報です。スタックトレース情報の取得方法は，J2EEサーバモードの場合と同様です。マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「4.18　JavaVMのスタックトレース情報」を参照してください。

coreダンプは次のような場合にも取得できます。それぞれの場合の取得方法について説明します。

• cjstartwebプロセスが稼働している状態でcoreダンプを取得する場合
• 実行中のJavaプロセスでcoreダンプとスレッドダンプを同時に取得する場合

cjstartwebプロセスが稼働している状態でcoreダンプを取得する場合

cjstartwebプロセス（Webコンテナサーバ）が稼働している状態でcoreダンプを取得する場合，cjstartwebプロセスのプロセスIDを確認して，killコマンドを実行します。killコマンドは次の形式で実行してください。なお，killコマンドを実行するとプロセスが終了するため，再起動する前にkillコマンドを実行することを推奨します。

kill -6 <cjstartwebプロセスID>

実行中のJavaプロセスでcoreダンプとスレッドダンプを同時に取得する場合

実行中のJavaプロセスでcoreダンプとスレッドダンプを同時に取得する方法は，J2EEサーバモードの場合と同様です。マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「4.9　メモリダンプ」を参照してください。

アプリケーションサーバの定義を取得します。この情報を使用して，発生した障害によって定義の設定を確認します。

Webコンテナサーバに関する定義情報

次のディレクトリ下に格納されているファイル一式を取得します。

Windowsの場合

• <製品のインストールディレクトリ>\CC\web\containers\<サーバ名称>\usrconf下すべて

UNIXの場合

• /opt/Cosminexus/CC/web/containers/<サーバ名称>/usrconf下すべて

DABroker Libraryに関する定義情報

次のファイルを取得します。

Windowsの場合

• <DABroker Library運用ディレクトリ>\conf\dasys.conf（DABroker Library動作環境定義ファイル）
• <DABroker Library運用ディレクトリ>\conf\dabenv（接続先データベース定義ファイル）

UNIXの場合

• <DABroker Library運用ディレクトリ>/conf/dasys.conf（DABroker Library動作環境定義ファイル）
• <DABroker Library運用ディレクトリ>/conf/dabenv（接続先データベース定義ファイル）

なお，トラブルシューティング用に保存するファイルからは，パスワードなどの公開できない情報を削除することをお勧めします。

システムでトラブルが発生した場合に，保守員による原因究明のため作業ディレクトリを調査に使用する場合があります。

• 環境変数「PRFSPOOL」の設定ディレクトリ下すべて^※
• <製品のインストールディレクトリ>\CC\web\containers\<サーバ名称>\webapps下すべて（Windowsの場合）
• /opt/Cosminexus/CC/web/containers/<サーバ名称>/webapps下すべて（UNIXの場合）

注※

環境変数「PRFSPOOL」未設定の場合は，「<製品のインストールディレクトリ>\PRF\spool下すべて」（Windowsの場合），または「/opt/Cosminexus/PRF/spool下すべて」（UNIXの場合）になります。

設定を確認の上，トラブルが発生した場合に保存しておいてください。

システムで使用しているWebサーバ（HTTP ServerまたはMicrosoft IIS）のログを取得します。

HTTP Serverを使用している場合，ログの格納場所は「<製品のインストールディレクトリ>\httpsd\logs」（Windowsの場合），「/opt/hitachi/httpsd/logs」（UNIXの場合）です。

Microsoft IISを使用している場合，ログの格納場所は「C:\inetpub\logs」です（C:の部分にはシステムドライブを指定します）。

そのほかの情報を取得するための方法は，すべてJ2EEサーバモードの場合と同様です。参照先を次に示します。

表3-44　取得する情報の種類と参照先