ログ・レベル設定

このトピックを使用して、ログ・レベル設定を構成および管理します。

この管理コンソール・ページを表示するには、「トラブルシューティング」 > 「ログおよびトレース」 > server_name > 「ログ詳細レベルの変更」をクリックします。

ログ・レベルを使用すると、Java™ ロギングによってどのイベントを処理するかを制御することができます。 ロガーのレベルを変更すると、その変更はロガーの子に伝搬されます。

注: このトピックでは、 1 つ以上のアプリケーション・サーバー・ログ・ファイルを参照します。推奨される代替案として、分散システムや IBM® i システムの SystemOut.logSystemErr.logtrace.logactivity.log ファイルではなく、High Performance Extensible Logging (HPEL) ログおよびトレース・インフラストラクチャーを使用するようにサーバーを構成できます。また HPEL は、ネイティブ z/OS® ロギング機能と連携させて使用することができます。HPEL を使用する場合、LogViewer コマンド・ライン・ツールを サーバー・プロファイルの bin ディレクトリーから使用して、すべてのログ・ファイルにアクセスし、 情報をトレースできます。HPEL の使用について詳しくは、HPEL を使用してのアプリケーションの トラブルシューティングに関する情報を参照してください。
機密の可能性があるデータのロギングとトレースを使用不可にする
アプリケーション・サーバーには、機密の可能性がある情報をログに書き込み、トレースするためのロガーのリストが含まれています。 例えば、特定の HTTP に関連したロガーを FINEST レベルで使用可能にすると、機密性のある HTTP 要求からのユーザー指定情報がトレース・ファイルに保管される場合があります。機密情報の可能性があるデータに使用されるレベルで、サーバーがこれらのロガーを使用できないようにするには、「機密の可能性があるデータのロギングとトレースを使用不可にする (Disable logging and tracing of potentially sensitive data)」チェック・ボックスをチェックします。 サーバーが始動すると、あるいはログ詳細レベルの仕様がランタイム時に変更されると、サーバーは、ログ詳細レベルの仕様で指定されたロガーおよびレベルのリストと、機密ロガー・リストのロガーおよびレベルのリストを比較し、必要に応じてログ詳細レベルの仕様を更新します。
ログ詳細レベルの変更

トレースするコンポーネント、パッケージ、またはグループを指定するログ詳細レベルを入力します。 ログ詳細レベル・ストリングは、このトピックに記載されている特定の文法に準拠していなければなりません。 ログ詳細レベル・ストリングを直接入力するか、 またはグラフィカル・トレース・インターフェースを使用して生成することができます。

「構成」タブを選択し、「コンポーネントとグループ」を 展開すると、既知のコンポーネント、 パッケージ、およびグループの静的リストが表示されます。このリストはすべてを網羅していない場合があります。

「ランタイム」タブを 選択し、「コンポーネントとグループ」を展開すると、コンポーネント、パッケージ、 およびグループのリストが、稼働中のアプリケーション・サーバーに登録されているすべての コンポーネントと静的リスト内のすべてのコンポーネントとともに表示されます。

ログ詳細レベル仕様のフォーマットは、次のとおりです。
<component> = <level>

ここで、<component> は、ログ詳細レベルを設定するコンポーネントになります。 <level> は、 有効なロガー・レベル (off、fatal、severe、warning、audit、info、config、 detail、fine、finer、finest、all) のいずれかになります。 複数のログ詳細レベル仕様は、 コロン (:) で区切ります。

トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): トレース仕様に含まれる節は、ストリング内の順序で読み取られます。したがって、*=info 節の複数のバリエーションがトレース仕様に含まれる場合、最後に指定された値がシステム・ログのトレース・レベルを決定する値となります。*=info を最後の節として指定した場合、トレース・ストリングに指定されている他の節に関係なく、トレースは情報レベルで行われます。例えば、次のトレース・ストリングを指定したとします。
*=info:PMGR=all:*=info:com.ibm.ws.sm.*=all  
これは、 次のような単純な指定と等価です。
*=all
最後の節は、ストリング内でその前に指定されたすべての節をオーバーライドするからです。gotcha
コンポーネントは、Java パッケージおよびクラス、または Java パッケージの集合に対応しています。 アスタリスク (*) をワイルドカードとして使用して、 指定されたコンポーネントに含まれているすべてのパッケージ内の、 すべてのクラスが含まれているコンポーネントを示します。 以下に例を示します。
*
製品システム・コードおよびカスタマー・コードを含め、 アプリケーション・サーバーで稼働しているすべてのトレース可能なコードを指定します。
com.ibm.ws.*
com.ibm.ws で始まるパッケージ名を持つすべてのクラスを指定します。
com.ibm.ws.classloader.JarClassLoader
JarClassLoader クラスのみを指定します。

「グループ」および「コンポーネント」の両方のリストから選択した場合、 ログ詳細レベル仕様を管理コンソールから設定する際に、エラーが起こる可能性があります。 場合によっては、あるリストから行われた選択が、 別のリストからの選択を追加するときに失われる場合があります。 この問題に対処するには、ログ詳細レベル仕様を直接、ログ詳細レベル入力フィールドに入力します。

ログ詳細レベルを設定するコンポーネントまたはグループを選択します。以下の表に、WebSphere® Application Server バージョン 6 以降の アプリケーション・サーバーで有効なレベルをリストします。
トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): ロギング・レベルの値は大/小文字を区別し、小文字で始まります。gotcha
表 1. 有効なロギング・レベル. 次の表に、WebSphere Application Server バージョン 6 以降の アプリケーション・サーバーで有効なレベルをリストします。
バージョン 6 以降でのロギング・レベル 内容/重要度
off ロギングはオフにされています。
fatal タスクは継続できず、コンポーネント、アプリケーション、サーバーは機能しません。
severe タスクは継続できませんが、コンポーネント、アプリケーション、 サーバーは機能できます。このレベルは、リカバリー不能エラーの兆候を示す場合もあります。
warning 可能性のあるエラーまたは今にも起こりそうなエラー。このレベルは、 進行性の障害 (例えば、リソースのリークの可能性) を示すこともできます。
audit サーバー状態またはリソースに影響する重大なイベント
info 全体的なタスクの進行を概説する一般情報
config 構成変更または状況
detail サブタスクの進行の詳細を示す一般情報
fine トレース情報 - 一般トレース + メソッド・エントリー、終了、戻り値
finer トレース情報 - 詳細トレース
finest トレース情報 - 問題をデバッグするために必要な詳細がすべて含まれるより詳細なトレース
all すべてのイベントがログに記録されます。カスタム・レベルを作成する場合、 「すべて」はそれらのレベルを含み、「極細」より詳細なトレースを提供します。
バージョン 6.0 以降でロギング・レベルを使用可能にした場合は、 それ以上の重大度を持つすべてのレベルも使用可能になります。 例えば、バージョン 6.x アプリケーション・サーバーで ロギング・レベルを warning に設定した場合、warningsevere、および fatal の イベントが処理されます。

[基本モードのロギング] Fine、Finer、および Finest の各レベルのイベントであるトレース情報は、トレース・ログにのみ書き込まれます。 したがって、診断トレースを使用可能にしない場合、 ログ詳細レベルを Fine、Finer、または Finest に設定しても、記録されるデータに影響を与えません。

相関
有効にする相関設定を指定します。アプリケーション・サーバーの相関を 有効にする場合は、「ログとトレースの相関を有効にする」チェック・ボックスを 選択します。アプリケーション・サーバーの相関を 無効にする場合は、「ログとトレースの相関を有効にする」チェック・ボックスを クリアします。必要に応じて、「要求 ID をログ・レコードとトレース・レコードに組み込む」「要求 ID をログ・レコードとトレース・レコードに組み込み、相関ログ・レコードを作成する」、 または「要求 ID をログ・レコードとトレース・レコードに組み込み、相関ログ・レコードを作成し、データ・スナップショットを取り込む」を 選択します。
ベスト・プラクティス ベスト・プラクティス: すべてのスレッドおよびアプリケーション・サーバー・プロセス内の どのログ項目およびトレース項目が同じ要求に関連しているか確認する必要がある場合、XCT を有効にして、 要求 ID をログ・ファイルとトレース・ファイルに組み込みます。要求 ID は、HPEL ログおよび トレース・モードを使用している場合にのみ記録され、logViewer コマンドを使用してフィルタリングするときに 表示したり使用したりできます。bprac
ベスト・プラクティス ベスト・プラクティス: 要求がスレッドやプロセス間でどのように 分岐しているかログに記録し、各要求についての詳細な情報を確認する必要がある場合、XCT を有効にして、 相関ログ・レコードを作成します。 XCT を有効にして相関ログ・レコードを作成すると、システムのパフォーマンスに大きく 影響する可能性があるため、このオプションはテスト環境や開発環境に最も適しています。bprac
ベスト・プラクティス ベスト・プラクティス: 要求および応答の本文全体をファイル・システムに 保管する必要がある場合、XCT を有効にして、データ・スナップショットを取り込みます。XCT を有効にして データ・スナップショットを取り込むと、システムのパフォーマンスに大きく 影響する可能性があるため、このオプションはテスト環境や開発環境に最も適しています。XCT は、SIBus によって 処理されるメッセージ要求および応答のデータ・スナップショットを取り込みます。bprac
トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): データ・スナップショットは、$SERVER_LOG_ROOT/snapdata ディレクトリーに取り込まれ、書き込まれます。 アプリケーション・サーバーは、このディレクトリーのファイルを自動的にクリーンアップしません。データ・スナップショットの取り込みを有効に している場合は、ユーザーがこのディレクトリーからファイルを定期的に削除する必要があります。データ・スナップショットは、要求と応答の 内容全体を保管するため、機密情報を含んでいる場合があります。このオプションは、実稼働環境での使用には適さないことがあります。gotcha
ランタイム変更も構成に保存する
稼働中のサーバーの動的状態とサーバー構成の両方に変更が加えられることを指定します (サーバー構成への変更は次に再始動したときに有効になります)。このチェック・ボックスを選択しないと、サーバーは設定をサーバー構成にコピーしません。

トピックのタイプを示すアイコン 参照トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=utrb_loglevel
ファイル名:utrb_loglevel.html