| Oracle® Fusion Middleware Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理 12c リリース1 (12.1.1) B65917-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理 12c リリース1 (12.1.1) B65917-02 |
|
前 |
次 |
この章では、WebLogicロギング・サービスに、ログ・メッセージの作成、表示、フィルタ処理、およびリスニング機能を提供する方法について説明します。ログ・メッセージは、WebLogic Serverインスタンス、サブシステム、およびWebLogic ServerまたはクライアントJVM上で実行されるJava EEアプリケーションによって生成されます。
この章の内容は以下のとおりです。
WebLogic Serverサブシステムは、ロギング・サービスを使用して、新しいアプリケーションのデプロイメント、1つまたは複数のサブシステムの障害などのイベントに関する情報を提供します。サーバー・インスタンスは、それを使用してサーバーのステータスを通知したり、特定のイベントに応答したりします。たとえば、WebLogicロギング・サービスを使用すると、エラー状態を報告したり、特定のサブシステムからログ・メッセージをリスニングしたりすることが可能です。
各WebLogic Serverインスタンスで、サーバー・ログが保持されます。各WebLogic ServerドメインはWebLogic Serverの複数のインスタンスを同時に実行できるので、ロギング・サービスにより複数のサーバー・インスタンスで生成されるメッセージを収集して、単一の、ドメイン全体のメッセージ・ログにまとめます。ドメイン・ログでは、ドメイン全体のステータスを確認できます。「サーバー・ログ・ファイルおよびドメイン・ログ・ファイル」を参照してください。
以下の節では、ロギング環境について説明し、ロギング・プロセスの概要を示します。
どのロギング・システムも、基本的にはログ・メッセージを生成するコンポーネントとメッセージを配信(パブリッシュ)するコンポーネントで構成されます。デフォルトでは、WebLogic Serverサブシステムは、メッセージ・カタログ機能を使用してメッセージを生成し、Java Logging APIを使用してメッセージを配信します。開発するアプリケーションに対してメッセージ・カタログを使用することもできます。
メッセージ・カタログ・フレームワークでは、アプリケーションがWebLogicのサーバー・ログに独自のメッセージ・セットを送るために使用する一連のユーティリティとAPIが提供されます。このフレームワークは、ログ・メッセージをローカライズする必要のあるアプリケーションにとって理想的ですが、ローカライズの不要なアプリケーションの場合でも、ステータスの通信や出力のためにフレキシブルで優れた一連のツールを利用できます。
『Oracle WebLogic Serverアプリケーション・ロギングのためのロギング・サービスの使用』のWebLogic Serverでのメッセージ・カタログの使い方に関する項を参照してください。
アプリケーションでは、メッセージ・カタログ・フレームワークの他に次のメカニズムを使用して、WebLogicサーバー・ログにメッセージを送信できます。
weblogic.logging.NonCatalogLoggerのAPI
NonCatalogLoggerを使用する場合、カタログからメッセージを呼び出すのではなく、アプリケーション・コードにメッセージ・テキストを直接配置します。『Oracle WebLogic Serverアプリケーション・ロギングのためのロギング・サービスの使用』のNonCatalogLogger APIの使用に関する項を参照してください。
サーバー・ロギング・ブリッジ
WebLogic Serverには、ロギング・アプリケーションでそのメッセージをWebLogicロギング・サービスにリダイレクトできるメカニズムがあります。このメカニズムでは、コードを変更したり、適切なWebLogicロギングAPIを実装したりする必要はありません。「サーバー・ロギング・ブリッジ」を参照してください。
NonCatalogLoggerのAPIまたはサーバー・ロギング・ブリッジのいずれかの使用は、国際化する必要のないメッセージや、WebLogic I18nフレームワーク以外で国際化されるメッセージのログを記録する場合に適しています。
メッセージを配信するために、WebLogic ServerではJavaベースのロギングがデフォルトでサポートされています。LoggingHelperクラスを使用すると、サーバー・ロギング用のjava.util.logging.Loggerオブジェクトへのアクセスが可能になります。これにより、Java Logging APIを利用してカスタム・ハンドラ、フィルタ、およびフォーマッタを追加できます。java.util.logging APIのドキュメント(http://docs.oracle.com/javase/6/docs/api/java/util/logging/package-summary.html)を参照してください。
または、ログ・メッセージの配信にJakarta Project Log4j APIを使用するようにWebLogic Serverを構成することもできます。「Log4jとCommons Logging API」を参照してください。
ロガー - Loggerオブジェクトは、特定のサブシステムまたはアプリケーション・コンポーネントのメッセージをロギングします。WebLogicロギング・サービスは、java.util.logging.Loggerのインスタンスを1つ使ってメッセージ・カタログ、NonCatalogLogger、およびデバッグ・システムからのメッセージをロギングします。
ハンドラ - java.util.logging.Handlerを拡張するクラス。ロガーに送られたログ・リクエストを受信します。各Loggerインスタンスは、ログ・メッセージをディスパッチする対象となる複数のハンドラに関連付けられます。ハンドラは、サーバー・ログ・ファイルの場合はファイル・ハンドラなど、特定の種類のログ・メッセージにアタッチされます。
アペンダ - Log4jでハンドラに当たるもの。この場合は、org.apache.log4j.Appenderを実装するクラスのインスタンスで、ログ・イベントを受信するorg.apache.log4j.Loggerに登録されます。
WebLogic Serverサブシステムまたはアプリケーション・コードから、ログ・リクエストをLoggerオブジェクトに送信します。Loggerオブジェクトでは、パブリッシュ用にHandlerオブジェクトに渡されるLogRecordオブジェクトを割り当てます。ロガーとハンドラではともに重大度と(必要に応じて)フィルタを使用して、特定のLogRecordオブジェクトに焦点を絞るかどうかが決定されます。外部にLogRecordオブジェクトをパブリッシュする必要がある場合、ハンドラでは必要に応じてフォーマッタを使用し、ログ・メッセージをローカライズおよびフォーマットしてからI/Oストリームにパブリッシュできます。
図2-1は、WebLogic Serverのロギング・プロセスを示したものです。メッセージの生成にはWebLogicカタログAPIまたはCommons Logging APIを使用します。また、メッセージ配信のオプションとしてJava Logging (デフォルト)またはLog4jを選択できます。
図2-1は、以下のプロセスを図示したものです。
クライアント(この場合はWebLogic ServerサブシステムまたはJava EEアプリケーション)により、WebLogic Server用に生成されたカタログ・ロガーまたはCommons Logging実装のどちらかのメソッドが呼び出されます。
WebLogic Serverメッセージ・カタログおよびNonCatalogLoggerでメッセージが生成されるとき、それらのメッセージはサーバーのLoggerオブジェクトに配信されます。
Jakarta Commons Logging APIでは、サーバーのLoggerオブジェクトにログ・リクエストをディスパッチするLogger参照を取得するためのファクトリAPIが定義されます。
サーバーのLoggerオブジェクトは、java.util.logging.Loggerまたはorg.apache.log4j.Loggerのいずれかのインスタンスです。
サーバーのLoggerオブジェクトにより、Loggerをサブスクライブしているメッセージ・ハンドラにメッセージがパブリッシュされます。
たとえば、標準出力ハンドラはフォーマットされたメッセージを標準出力に出力し、ファイル・ハンドラはフォーマットされた出力をサーバー・ログ・ファイルに書き込みます。ドメイン・ログ・ブロードキャスタは管理サーバーにあるドメイン・ログにログ・メッセージを送信し、JMXログ・ブロードキャスタはリモート・クライアント上のJMXリスナーにログ・メッセージを送信します。
WebLogicロギング・サービスでJavaロギングまたはLog4jを使用する場合は、以下の推奨事項を考慮します。
WebLogicロギング・サービスでパブリッシュされるログ・メッセージの生成には、CatalogロガーおよびNonCatalogロガーまたはCommons APIを使用します。
メッセージをパブリッシュするために、カスタム・ハンドラ、アペンダ、またはフィルタをWebLogicロギング・サービスに追加する場合は、JavaロギングまたはLog4j Logger参照を使用します。
アプリケーションをJavaロギングまたはLog4jに構成する場合、WebLogicロギング・サービスを使用してアプリケーション・イベントを公開するには、次のいずれかを実行できます。
(推奨)サーバー・ロギング・ブリッジを使用するようにアプリケーションのロガーを構成します。これにより、コードを変更せずにアプリケーションのログ・メッセージをWebLogicロギング・サービスにリダイレクトする軽量の方法が提供されます。詳細は、「サーバー・ロギング・ブリッジ」を参照してください。
カスタム・ハンドラ、またはプログラムによるAPIを使用してWebLogicロギング・サービスにアプリケーション・イベントをリレーするアペンダを作成します。詳細は、「WebLogicロギング・サービスでのLog4jの使い方」を参照してください。
サブシステムおよびアプリケーションからのメッセージは、すべてローカル・ホスト・コンピュータ上のサーバー・ログ・ファイルに書き込まれます。デフォルトでは、サーバー・ログ・ファイルは、サーバー・インスタンスのルート・ディレクトリ配下のlogsディレクトリに格納されています(DOMAIN_NAME\servers\SERVER_NAME\logs\SERVER_NAME.logなど。ただし、DOMAIN_NAMEはドメインを配置したディレクトリの名前、SERVER_NAMEはサーバーの名前)。
メッセージをサーバー・ログ・ファイルに書き込む他にも、各サーバー・インスタンスはそのメッセージのサブセットをドメイン全体のログ・ファイルに転送できます。デフォルトでは、重大度がNOTICE以上のメッセージのみが転送されます。転送されるメッセージ・セットは変更できますが、サーバーは重大度がDEBUGのメッセージを転送できません。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのドメイン・ログへのメッセージの転送に関する項を参照してください。
ドメイン・ログ・ファイルは、ドメイン全体のステータスを確認するための中心となるファイルです。ドメイン・ログは、管理サーバーのlogsディレクトリにあります。ドメイン・ログ・ファイルのデフォルトの格納場所および名前は、DOMAIN_NAME\servers\ADMIN_SERVER_NAME\logs\DOMAIN_NAME.logです。ただし、DOMAIN_NAMEはドメインを配置したディレクトリの名前、ADMIN_SERVER_NAMEは管理サーバーの名前です。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのドメイン・ログ・ファイルの名前と場所の変更に関する項を参照してください。
ドメイン・ログ内のレコードのタイムスタンプは、そのメッセージの送信元であるサーバーのタイムスタンプです。ドメイン・ログのログ・レコードは、各自のタイムスタンプ順ではなくメッセージの到着順に書き込まれます。管理対象サーバーが一定の期間、管理サーバーと通信できなくなることがあります。その場合には、メッセージはローカルにバッファされ、サーバー間が再接続された時点で管理サーバーに送信されます。
ドメイン・ログにメッセージを転送するために、各サーバー・インスタンスはそのログ・メッセージをブロードキャストします。サーバーは、重大度がDEBUGのメッセージを除くすべてのメッセージとメッセージ・テキストをブロードキャストします。
管理サーバーは、これらのメッセージのサブセットをリスニングし、それらをドメイン・ログ・ファイルに書き込みます。これらのメッセージをリスニングするために、管理サーバーはリスナーを各管理対象サーバーに登録します。デフォルトでは、リスナーには重大度がNOTICE以上のメッセージのみを管理サーバーに転送するためのフィルタが含まれます(図2-2を参照してください)。
各WebLogic Serverインスタンスに対して、デフォルト・フィルタをオーバーライドし、デフォルトとは異なるメッセージ・セットをドメイン・ログ・ファイルに書き込むログ・フィルタを作成できます。WebLogic Serverインスタンスに対するログ・フィルタの設定方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのログ・フィルタの作成に関する項を参照してください。
管理サーバーにアクセスできない場合、管理対象サーバーでは自身のローカル・サーバー・ログ・ファイルに対してメッセージの書込みが続けられます。ただしデフォルトではサーバー間が再接続された際に、接続の切断中に書き込まれたメッセージがすべてドメイン・ログ・ファイルに転送されるとは限りません。サーバー間の再接続時にメッセージを管理サーバーへ転送できるように、管理対象サーバーのバッファには指定した数のメッセージが保持されます。
このバッファに保持されるメッセージ数はLogMBeanのDomainLogBroadcasterBufferSize属性で構成します。DomainLogBroadcasterBufferSizeは、管理対象サーバーからドメイン・サーバーへログ・メッセージが送信される頻度を制御します。デフォルトでは、この属性には1が設定されているため、ログ・メッセージのバッチ処理はなく、管理サーバーのドメイン・ログに転送されるのは最後に記録されたメッセージのみです。たとえば、2時間アクセスできなかった後に管理サーバーが復元された場合、その2時間に生成されたメッセージはドメイン・ログに含まれません。『Oracle WebLogic Serverサーバーの起動と停止の管理』のMSIモードとドメイン・ログ・ファイルに関する項を参照してください。本番モードでは、管理対象サーバーのデフォルトのバッファ・サイズは10です。バッファが制限サイズに達すると、そのバッファ内のメッセージは管理サーバーのドメイン・ログに送られフラッシュされます。パフォーマンスに関する理由から、本番モードではこの値を10以上に設定することをお薦めします。値を高く設定するほど、バッファがドメイン・ログにブロードキャストされる頻度が低くなります。
1よりも大きな値を構成すると、管理対象サーバーが管理サーバーに再接続したときに、指定した数のメッセージがドメイン・ログに転送されます。
|
注意: こうした動作のため、ドメイン・ログ・ファイルでは、タイム・スタンプが後のメッセージよりも後ろにタイム・スタンプが前のメッセージがリストされる場合があります。以前に接続が切断されていた管理対象サーバーのバッファから管理サーバーにメッセージがフラッシュされる際、メッセージは(ドメイン・ログの前のメッセージより早く生成されたものであっても)、単純にドメイン・ログの最後尾に追加されます。 |
WebLogic Server内の各サブシステムは、ログ・メッセージを生成してそのステータスを送信します。たとえば、WebLogic Serverインスタンスを起動すると、セキュリティ・サブシステムによって初期化ステータスを報告するメッセージが書き込まれます。サブシステムが生成するメッセージの記録を保持するために、WebLogic Serverによって生成されたメッセージがログ・ファイルに書き込まれます。
サーバー・ログには、サーバーの起動と停止、新しいアプリケーションのデプロイメント、1つまたは複数のサブシステムの障害などのイベントに関する情報が記録されます。サーバー・ログ・メッセージには、イベントの時刻と日付についての情報や、イベントを開始したユーザーのIDが含まれます。
これらのサーバー・ログ・メッセージを表示してソートすることで、問題の検出、フォルト発生源の特定、およびシステム・パフォーマンスの監視ができます。また、これらのメッセージをリスニングして自動的に応答するクライアント・アプリケーションを作成することもできます。たとえば、サブシステムの障害を知らせるメッセージをリスニングし、システム管理者に電子メールを送信するアプリケーションを作成できます。
サーバー・ログ・ファイルは、サーバー・インスタンスのホスト・コンピュータに配置されます。各サーバー・インスタンスには、独自のサーバー・ログ・ファイルがあります。デフォルトでは、サーバー・ログ・ファイルは、サーバー・インスタンスのルート・ディレクトリ配下のlogsディレクトリに格納されています(DOMAIN_NAME\servers\SERVER_NAME\logs\SERVER_NAME.logなど。ただし、DOMAIN_NAMEはドメインを配置したディレクトリの名前、SERVER_NAMEはサーバーの名前)。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー・ログ・ファイルの名前と場所の変更に関する項を参照してください。
サーバー・ログ・ファイルのメッセージを参照するには、WebLogic Serverのホスト・コンピュータにログインして標準のテキスト・エディタを使用するか、任意のコンピュータにログインして管理コンソールのログ・ファイル・ビューアを使用します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー・ログの表示と構成に関する項を参照してください。
|
注意: ログ・ファイルは手作業で修正しないようにします。ログ・ファイルを修正すると、タイム・スタンプが変更されてログ・ファイルのローテーションが混乱するおそれがあります。また、編集によりファイルがロックされて、WebLogic Serverから更新できなくなり、アクセサの動作を妨げる場合があります。 診断アクセサ・サービスの詳細は、『Oracle WebLogic Server診断フレームワークの構成と使用』のデータ・アクセサを使用した診断データへのアクセスに関する項を参照してください。 |
メッセージをログ・ファイルに書き込むほかにも、各サーバー・インスタンスはメッセージのサブセットを標準出力に出力することができます。通常、標準出力は、サーバー・インスタンスが実行されているシェル(コマンド・プロンプト)です。ただし、オペレーティング・システムによっては他の場所に標準出力をリダイレクトできます。デフォルトでは、サーバー・インスタンスは重大度がNOTICE以上のメッセージのみを標準出力に出力します(重大度については、下記の「メッセージの重大度」を参照)。重大度のしきい値を変更すると、サーバーが標準出力に出力するメッセージを増減できます。
ノード・マネージャを使用して管理対象サーバーを起動する場合、通常は管理対象サーバーの起動時にstdoutまたはstderrに出力されるメッセージが、代わりに管理コンソールに表示され、そのサーバー・インスタンスの単一のログ・ファイルSERVER_NAME.outに書き込まれます。サーバー・インスタンスの出力ログは、WebLogic ServerのSERVER_NAME.logファイルとともに、サーバー・インスタンスのルート・ディレクトリ配下にある同じlogsディレクトリに格納されています(DOMAIN_NAME\servers\SERVER_NAME\logs\SERVER_NAME.outなど。ただし、DOMAIN_NAMEはドメインを配置したディレクトリの名前、SERVER_NAMEはサーバーの名前)。
ノード・マネージャでは、独自の起動メッセージとステータス・メッセージが単一のログ・ファイルNM_HOME/nodemanager.logに書き込まれます。ただし、NM_HOMEは、ノード・マネージャのインストール・ディレクトリ(デフォルトでは、WL_HOME/common/nodemanager)です。
ノード・マネージャのログ・ファイルに関する詳細は、『Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャの構成ファイルとログ・ファイルに関する項を参照してください。
サーバー・ログ・メッセージとログ・ファイルは、サーバーまたはアプリケーションの動作に影響を与えるイベントおよび状況を通知します。一部のサブシステムでは、通常の操作状況でサブシステムの対話を監査するために追加のログ・ファイルが保持されます。以下のリストに、それぞれの追加ログ・ファイルを示します。
HTTPサブシステムはすべてのHTTPトランザクションのログをテキスト・ファイルに保存します。HTTPアクセス・ログのデフォルトの場所とローテーション・ポリシーは、サーバー・ログと同じです。定義した各サーバーまたは各仮想ホストに対して、HTTPアクセス・ログの動作を定義する属性を設定できます。『Oracle WebLogic Serverサーバー環境の構成』の「HTTPアクセス・ログの設定」、およびOracle WebLogic Server管理コンソール・オンライン・ヘルプのHTTPログの有効化と構成に関する項を参照してください。
各サーバーには、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を格納するトランザクション・ログが備わっています。WebLogic Serverでは、システムのクラッシュやネットワーク障害からの回復時にトランザクション・ログを使用します。トランザクション・ログを直接表示することはできません。このファイルはバイナリ・フォーマットです。
トランザクション・マネージャは、デフォルト永続ストアを使用して、トランザクション・ログ・ファイルを格納します。管理コンソールを使用すると、デフォルト・ストアの場所を変更できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービスの移行のためのデフォルト永続ストアの構成に関する項を参照してください。
WebLogic監査プロバイダは、WebLogicセキュリティ・フレームワークで内部的に決定された、複数のセキュリティ・リクエストの情報を記録します。また、WebLogic監査プロバイダはこれらのセキュリティ・リクエストに関連付けられているイベント・データとリクエストの結果も記録します。監査プロバイダの構成は任意です。デフォルト・セキュリティ・レルム(myrealm)には監査プロバイダは構成されていません。『Oracle WebLogic Serverの保護』のWebLogic監査プロバイダの構成に関する項を参照してください。
WebLogic監査プロバイダによって記録されたすべての監査情報は、WL_HOME\DOMAIN_NAME\servers\SERVER_NAME\logs\DefaultAuditRecorder.logに保存されます。監査プロバイダはセキュリティ・レルム単位で構成されますが、各サーバーは監査データをサーバー・ディレクトリにある各自のログ・ファイルに書き込みます。
JDBCサブシステムには、JDBCドライバの登録やSQL例外など、JDBC接続に関する様々なイベントが記録されます。JDBCに関連するイベントは、接続が作成またはリフレッシュされた場合や、JDBCオブジェクトの構成が変更された場合などに、サーバー・ログに書き込まれます。『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のWebLogic JDBCリソースの監視に関する項を参照してください。
JMSロギングは、JMSサーバーを作成するとデフォルトで有効になります。ただし、このJMSサーバーにターゲット指定するJMSモジュールのメッセージ宛先(または宛先で使用するJMSテンプレート)では、JMSロギングを明示的に有効にする必要があります。
JMSサーバー・ログ・ファイルには、メッセージの生産、消費、削除など、メッセージの基本的なライフ・サイクル・イベントについての情報が格納されます。サブジェクト・メッセージをホストするJMS宛先の構成でメッセージのロギングが有効になっている場合、メッセージの基本的なライフ・サイクル・イベントは、JMSメッセージ・ログ・ファイルにメッセージ・ログ・イベントを生成します。
メッセージ・ログは、サーバー・インスタンスのルート・ディレクトリ配下のlogsディレクトリに格納されています(DOMAIN_NAME\servers\SERVER_NAME\logs\jmsServers\SERVER_NAMEJMSServer\jms.messages.logなど。ただし、DOMAIN_NAMEはドメインを配置したディレクトリの名前、SERVER_NAMEはサーバーの名前)。
JMSサーバーを作成した後には、ログ・ファイルのデフォルト名を変更できる他、古いログ・メッセージを別のファイルに移動(ローテーション)するための条件を構成できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトピック・メッセージのロギングの構成に関する項、および『Oracle WebLogic Server JMSの構成と管理』のJMS統計の監視とメッセージの管理に関する項を参照してください。
WebLogic Serverインスタンスは、メッセージをサーバー・ログ・ファイルに書き込みます。各メッセージの先頭行は####で始まり、その後にメッセージの属性が続きます。各属性は山カッコで囲まれます。
次に、サーバー・ログ・ファイルのメッセージの例を示します。
####<Sept 22, 2004 10:46:51 AM EST> <Notice> <WebLogicServer> <MyComputer> <examplesServer><main> <<WLS Kernel>> <> <null> <1080575211904> <BEA-000360> <Server started in RUNNING mode>
この例では、メッセージの属性は、Locale-formatted Timestamp、Severity、Subsystem、Machine Name、Server Name、Thread ID、User ID、Transaction ID、Diagnostic Context ID、Raw Time Value、Message ID、およびMessage Textです(各属性については、「メッセージの属性」を参照)。
メッセージがトランザクションのコンテキストで記録されたものではない場合、Transaction IDは存在しませんが、Transaction IDのための山カッコは配置されます。
メッセージにスタック・トレースが含まれている場合、スタック・トレースはメッセージ・テキストに含まれます。
WebLogic Serverではメッセージの書込みに、ホスト・コンピュータのデフォルトの文字エンコーディングを使用します。
WebLogic Serverインスタンスがメッセージを標準出力に書き込むとき、その出力に####という接頭辞と、サーバー名、マシン名、スレッドID、ユーザーID、トランザクションID、診断コンテキストID、生の時間値フィールドは含まれません。
次に、前節のメッセージがどのように標準出力に出力されるかを示します。
<Sept 22, 2004 10:51:10 AM EST> <Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode>
この例では、メッセージの属性は、Locale-formatted Timestamp、Severity、Subsystem、Message ID、およびMessage Textです。
どのWebLogic Serverインスタンスのメッセージにも、表2-1に示す一連の属性が含まれています。また、アプリケーションにおいてWebLogicロギング・サービスを介して生成されるメッセージにも、これらの属性が含まれます。
表2-1 サーバー・ログのメッセージ属性
| 属性 | 説明 |
|---|---|
|
ロケール書式のタイムスタンプ |
メッセージが発生した時刻と日付。書式はロケールに基づきます。各WebLogic Serverインスタンスを実行するJVM (Java仮想マシン)は、ローカルのタイム・ゾーンと書式に関する情報についてホスト・コンピュータのオペレーティング・システムを参照します。 |
|
重大度 |
メッセージで報告されるイベントの影響または深刻さの度合いを示します。「メッセージの重大度」を参照してください。 |
|
サブシステム |
EJB (Enterprise Java Bean)コンテナやJMS (Java Messaging Service)などの、メッセージを生成したWebLogic Serverのサブシステムを示します。 |
|
マシン名 サーバー名 スレッドID |
メッセージの発生源を識別します。
クライアントJVM内で生成されるログ・メッセージには、これらの属性は含まれません。たとえば、アプリケーションがクライアントJVMで実行されており、WebLogicロギング・サービスを使用する場合、そのアプリケーションが生成してWebLogicクライアント・ログ・ファイルに送信するメッセージにはこれらの属性が含まれません。 |
|
ユーザーID |
関連付けられたイベントを実行したユーザーID。 内部コードの一部を実行する場合、WebLogic Serverでは実行を開始したユーザーのIDを認証してから、特別なKernel IdentityユーザーIDでコードを実行します。 サーバー・インスタンスにデプロイされているEJBなどのJava EEモジュールは、モジュールがサーバーに渡すユーザーIDを報告します。 クライアントJVM内で生成されるログ・メッセージには、これらのフィールドは含まれません。 |
|
トランザクションID |
トランザクションのコンテキスト内でロギングされたメッセージの場合にのみ示されます。 |
|
診断コンテキストID |
特定のリクエストまたはアプリケーションから受け取ったメッセージを相互に関連付けるコンテキスト情報。 |
|
生の時間値 |
タイムスタンプ(ミリ秒)。 |
|
メッセージID |
一意の6桁の識別子。 WebLogic Serverシステム・メッセージが生成するすべてのメッセージIDは アプリケーションでは国際化されたメッセージ・カタログのかわりに 『Oracle WebLogic Serverアプリケーション・ロギングのためのロギング・サービスの使用』のWebLogic Serverログへのメッセージの書込みに関する項を参照してください。 |
|
メッセージ・テキスト |
イベントまたは条件の説明。 |
WebLogic Serverのログ・メッセージの重大度属性は、メッセージで報告されるイベントまたは状況の潜在的な影響を示します。
表2-2は、WebLogic Serverサブシステムからのログ・メッセージの重大度を、最低の影響レベルから最高の影響レベルまで示したものです。
表2-2 メッセージの重大度
| 重大度 | 意味 |
|---|---|
|
TRACE |
診断アクション・ライブラリからのメッセージの場合に使用します。サーバーおよびアプリケーション・クラスの診断インストゥルメンテーションを有効にすると、 『Oracle WebLogic Server診断フレームワークの構成と使用』の診断アクション・ライブラリに関する項を参照してください。 |
|
DEBUG |
デバッグ・メッセージが生成されました。 |
|
INFO |
通常の処理を報告するために使用する、低レベルの情報メッセージ。 |
|
NOTICE |
重要度が高い情報メッセージ。 |
|
WARNING |
不審なオペレーションまたは構成が発生しましたが、通常のオペレーションには影響しません。 |
|
ERROR |
ユーザー・エラーが発生したことを示します。システムまたはアプリケーションでは、割込みやサービスの限定的な低下を起こすことなくエラーに対処できます。 |
|
CRITICAL |
システム・エラーまたはサービス・エラーが発生したことを示します。システムをリカバリできますが、サービスの一時的な損失や永久的な低下が発生する場合があります。 |
|
ALERT |
特定のサービスが使用不能の状態にある一方で、システムのほかの部分は依然として機能しています。自動リカバリを実行できません。この問題を解決するには、管理者がすぐに措置を講じる必要があります。 |
|
EMERGENCY |
サーバーが使用不能な状態にあります。この重大度は、重大なシステム障害または問題があることを示します。 |
WebLogic Serverのサブシステムでは、重大度の低いメッセージが数多く生成され、重大度の高いメッセージほど数が少なくなります。たとえば、通常の環境では、INFOメッセージが多く生成され、EMERGENCYメッセージは生成されません。
アプリケーションでWebLogicロギング・サービスを使用している場合は、DEBUGという重大度も使用できます。『Oracle WebLogic Serverアプリケーション・ロギングのためのロギング・サービスの使用』のデバッグ・メッセージの書込みに関する項を参照してください。
WebLogic Server 管理コンソールでは、ドメイン内の全ログ・ファイルのログ・ビューアを利用できます。ログ・ビューアでは、日付、サブシステム、重大度、マシン、サーバー、スレッド、ユーザーID、トランザクションID、コンテキストID、タイムスタンプ、メッセージID、またはメッセージの中から任意の属性を基にして、メッセージの検索や表示を行うことができます。また、ロギングされた時点でメッセージを表示することも、過去のログ・メッセージを検索することもできます(図2-3を参照してください)。
メッセージ・ログの表示、構成、および検索の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のトピックを参照してください。
WebLogic Serverメッセージ・カタログのログ・メッセージの詳細については、『WebLogic Serverエラー・メッセージ・リファレンス』を参照してください。このメッセージ・カタログには、WebLogicサブシステムによって出力されるすべてのメッセージ、エラー、考えられる原因、およびエラーを回避または修正するための推奨アクションに関する説明が記載されています。詳細を参照するには、「範囲」列(範囲に基づいた参照の場合)、あるいは「サブシステム」列(サブシステムに基づいた参照の場合)の適切なエントリをクリックします。
サーバー・ロギング・ブリッジは、現在JavaロギングまたはLog4Jロギングを使用してログ・メッセージをWebLogicロギング・サービスにリダイレクトさせているアプリケーションに対して軽量のメカニズムを提供します。アプリケーションは既存の構成のままでサーバー・ロギング・ブリッジを使用できます。コードを変更したり、WebLogicロギングAPIをプログラムで使用する必要はありません。
サーバー・ロギング・ブリッジを使用するには、次の項で説明するとおりに、ロギング構成プロパティ・ファイルを作成するだけです。WebLogicロギング・サービス用に有効化されたロギングAPIを再構成する必要はありません。サーバー・ロギング・ブリッジは、WebLogicロギング・サービスがJavaロギング(デフォルト)またはLog4j用に現在構成されているかどうかに関係なく機能します。
|
注意:
|
JavaロギングAPIを使用するアプリケーションの場合、WebLogic Serverは、サーバー・ロギング・ブリッジをハンドラ・オブジェクト(weblogic.logging.ServerLoggingHandler)として公開します。WebLogic Serverに構成されるロギング実装は、Javaロギング(デフォルト)またはLog4Jロギングのいずれかになります。ハンドラがjava.util.logging.LogRecordオブジェクト形式でアプリケーション・ログ・メッセージを受け取ると、そのメッセージは、標準出力、サーバー・ログ、ドメイン・ログなどのWebLogicロギング・サービス宛先に適宜リダイレクトされます。
LogRecordに含まれる次の情報によって、ログ・メッセージのリダイレクト方法が決まります。
メッセージの重大度
重大度は、ログ・メッセージがリダイレクトされると、標準WebLogicロギング・サービスのいずれかの重大度に自動で変換されます。
ロガー名
サーバー・ロギング・ブリッジ・ハンドラは、LogRecordに含まれるロガー名に一致する、WebLogicロガー・ツリーのロガーにアプリケーション・メッセージを公開します。
LogRecordにロガー名がない場合、メッセージはルート・ロガーに公開されます。
ログ・レベル
LogRecordのレベルは、ログ・メッセージがリダイレクトされると、標準WebLogicロギング・サービスのいずれかの重大度に自動で変換されます。
サーバー・ロギング・ブリッジ・ハンドラを使用するには、サーバーのweblogic.Server起動コマンドの引数として渡されるlogging.propertiesファイルを作成します。任意のディレクトリに配置できるこのプロパティ・ファイルは、アプリケーションのロガー・ツリーにサーバー・ロギング・ブリッジ・ハンドラを登録します。Javaロギングの構成の詳細は、次のJavaロギングAPIドキュメントを参照してください。
http://docs.oracle.com/javase/6/docs/technotes/guides/logging/overview.html
|
注意: ベスト・プラクティスとして、 |
例2-1は、JavaロギングAPIを使用するアプリケーションのlogging.propertiesファイルの例を示しています。
例2-1 ServerLoggingHandlerを使用したlogging.propertiesファイルの例
# Specify the handlers to create in the root logger handlers = weblogic.logging.ServerLoggingHandler # Register handlers for the com.foo.toyshop and its child loggers com.foo.toyshop.handlers = java.util.logging.ConsoleHandler, weblogic.logging.ServerLoggingHandler # Do not send the toyshop log messages to the root handler com.foo.toyshop.useParentHandlers = false # Set the default logging level for the root logger .level = ALL # Set the default logging level for new ConsoleHandler instances java.util.logging.ConsoleHandler.level = INFO # Set the default logging level for new FileHandler instances weblogic.logging.ServerLoggingHandler.level = ALL
次の例は、weblogic.Server起動コマンドに-Djava.util.logging.config.file引数のlogging.propertiesファイルを渡す場合の例です。
java -Djava.util.logging.config.file=C:\mydomain\logging.properties weblogic.Server
|
注意: 前述の例に示すように、 |
Log4JロギングAPIを使用するアプリケーションの場合、WebLogic Serverは、サーバー・ロギング・ブリッジをアペンダ・オブジェクト(weblogic.logging.log4j.ServerLoggingAppender)として公開します。WebLogic Serverに構成されるロギング実装は、Javaロギング(デフォルト)またはLog4Jロギングのいずれかになります。アペンダがorg.apache.log4j.spi.LoggingEventオブジェクト形式でアプリケーション・ログ・メッセージを受け取ると、そのメッセージは、標準出力、サーバー・ログ、ドメイン・ログなどのWebLogicロギング・サービス宛先に適宜リダイレクトされます。
LoggingEventに含まれる次の情報によって、ログ・メッセージのリダイレクト方法が決まります。
メッセージの重大度
重大度は、ログ・メッセージがリダイレクトされると、標準WebLogicロギング・サービスのいずれかの重大度に自動で変換されます。
ロガー名
サーバー・ロギング・ブリッジ・アペンダは、LoggingEventに含まれるロガー名に一致する、WebLogic Log4Jロガー・ツリーのロガーにアプリケーション・メッセージを公開します。
LoggingEventにロガー名がない場合、メッセージはルート・ロガーに公開されます。
サーバー・ロギング・ブリッジ・アペンダを使用するには、アプリケーション・クラスパスに含めるlog4j.propertiesファイルを作成します。log4j.propertiesファイルは、アプリケーションのロガー・ツリーにサーバー・ロギング・ブリッジ・アペンダを登録します。Log4jロギングの構成の詳細は、logging.apache.orgで公開される次のロギング・サービス・ドキュメントを参照してください。
http://logging.apache.org/log4j/1.2/manual.html
|
注意: ベスト・プラクティスとして、 |
例2-2は、Log4Jロギングを使用するアプリケーションのlog4j.propertiesファイルの例を示しています。
例2-2 ServerLoggingAppenderを使用したlog4j.propertiesファイルの例
log4j.rootLogger=debug, stdout, server # ***** stdout is set to be a ConsoleAppender. log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n log4j.appender.server=weblogic.logging.log4j.ServerLoggingAppender
サーバー・ロギング・ブリッジでリダイレクトされる、ネームスペースcom.oracle.wlsのロガーから生じるログ・メッセージは、デフォルトでアプリケーションのルート・ロガーに伝播されません。ただし、LogMBean.ServerLoggingBridgeUseParentLoggersEnabled属性を有効にすることで、アプリケーションのルート・ロガーにメッセージを伝播できます。
詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「サーバー: ロギング: 全般」に記述されているサーバー・ロギング・ブリッジによる親ロガーの使用についての説明を参照してください。
アプリケーション・ロギングにLog4jを使用している場合、log4j.propertiesファイルは、WebLogic Serverの一般的なオーバーライド機能を使用して、既存のデプロイメント・プラン・ディレクトリ構造にこのファイルを挿入できます。一般的なオーバーライド機能により、アプリケーションで使用される特定のリソース・タイプの挿入や変更が便利になり、アプリケーションJARファイルを変更せずにアプリケーションの既存のクラスローダーやリソース・ローディング・ルールを引き続き使用できます。
詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のファイル・ローディングの一般的なオーバーライドに関する項を参照してください。
