| Oracle® Fusion Middleware Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタリング 12c (12.2.1.1.0) E79364-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタリング 12c (12.2.1.1.0) E79364-01 |
|
|
前 |
次 |
この章には次の項が含まれます:
WebLogic Serverサブシステムは、ロギング・サービスを使用して、新しいアプリケーションのデプロイメント、1つまたは複数のサブシステムの障害などのイベントに関する情報を提供します。サーバー・インスタンスは、それを使用してサーバーのステータスを通知したり、特定のイベントに応答したりします。たとえば、WebLogicロギング・サービスを使用すると、エラー状態を報告したり、特定のサブシステムからログ・メッセージをリスニングしたりすることが可能です。
各WebLogic Serverインスタンスで、サーバー・ログが保持されます。各WebLogic ServerドメインはWebLogic Serverの複数のインスタンスを同時に実行できるので、ロギング・サービスにより複数のサーバー・インスタンスで生成されるメッセージを収集して、単一の、ドメイン全体のメッセージ・ログにまとめます。ドメイン・ログでは、ドメイン全体のステータスを確認できます。詳細は、「サーバー・ログ・ファイルとドメイン・ログ・ファイル」を参照してください。
次のセクションでは、ロギング環境およびロギング・プロセスの概要について説明します。
どのロギング・システムも、基本的にはログ・メッセージを生成するコンポーネントとメッセージを配信(パブリッシュ)するコンポーネントで構成されます。デフォルトでは、WebLogic Serverサブシステムは、メッセージ・カタログ機能を使用してメッセージを生成し、Java Logging APIを使用してメッセージを配信します。開発するアプリケーションに対してメッセージ・カタログを使用することもできます。
メッセージ・カタログ・フレームワークでは、アプリケーションがWebLogicのサーバー・ログに独自のメッセージ・セットを送るために使用する一連のユーティリティとAPIが提供されます。このフレームワークは、ログ・メッセージをローカライズする必要のあるアプリケーションにとって理想的ですが、ローカライズの不要なアプリケーションの場合でも、ステータスの通信や出力のためにフレキシブルで優れた一連のツールを利用できます。
詳細は、『Oracle WebLogic ServerでのWebLogicロギング・サービスのアプリケーション・デプロイへの追加』のWebLogicサーバーを使用したメッセージ・カタログの使用に関する項を参照してください。
アプリケーションでは、メッセージ・カタログ・フレームワークの他に次のメカニズムを使用して、WebLogicサーバー・ログにメッセージを送信できます。
weblogic.logging.NonCatalogLoggerのAPI
NonCatalogLoggerを使用する場合、カタログからメッセージを呼び出すのではなく、アプリケーション・コードにメッセージ・テキストを直接配置します。詳細は、『Oracle WebLogic ServerでのWebLogicロギング・サービスのアプリケーション・デプロイへの追加』の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/8/docs/api/java/util/logging/package-summary.html)を参照してください。
または、ログ・メッセージの配信にJakarta Project Log4j APIを使用するようにWebLogic Serverを構成することもできます。詳細は、Log4jとCommons Logging APIを参照してください。
WebLogicロギング・サービスを理解するには、関連する次の用語を理解する必要があります。
ロガー - 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リスナーにログ・メッセージを送信します。
サブシステムおよびアプリケーションからのメッセージは、すべてローカル・ホスト・コンピュータ上のサーバー・ログ・ファイルに書き込まれます。デフォルトでは、サーバー・ログ・ファイルは、サーバー・インスタンスのルート・ディレクトリ配下のlogsディレクトリに格納されています(DOMAIN_NAME\servers\SERVER_NAME\logs\SERVER_NAME.logなど。ただし、DOMAIN_NAMEはドメインを配置したディレクトリの名前、SERVER_NAMEはサーバーの名前)。
メッセージをサーバー・ログ・ファイルに書き込む他にも、各サーバー・インスタンスはそのメッセージのサブセットをドメイン全体のログ・ファイルに転送できます。デフォルトでは、重大度が注意以上のメッセージのみが転送されます。転送されるメッセージ・セットは変更できますが、サーバーは重大度が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のホスト・コンピュータにログインして標準のテキスト・エディタを使用するか、任意のコンピュータにログインしてWebLogic Server管理コンソールのログ・ファイル・ビューアを使用します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー・ログの表示に関する項を参照してください。
注意:
ログ・ファイルの修正は、手動編集で行わないことをお薦めします。ログ・ファイルを修正すると、タイム・スタンプが変更されてログ・ファイルのローテーションが混乱するおそれがあります。また、編集によりファイルがロックされて、WebLogic Serverから更新できなくなり、アクセサの動作を妨げる場合があります。
診断アクセサ・サービスの詳細は、『Oracle WebLogic Server診断フレームワークの構成と使用』の「データ・アクセサを使用した診断データへのアクセス」を参照してください。
メッセージをログ・ファイルに書き込むほかにも、各サーバー・インスタンスはメッセージのサブセットを標準出力に出力することができます。通常、標準出力は、サーバー・インスタンスが実行されているシェル(コマンド・プロンプト)です。ただし、オペレーティング・システムによっては他の場所に標準出力をリダイレクトできます。デフォルトでは、サーバー・インスタンスは重大度がNotice以上のメッセージのみを標準出力に出力します。(重大度については、下記の「メッセージの重大度」を参照)。重大度のしきい値を変更すると、サーバーが標準出力に出力するメッセージを増減できます。
ノード・マネージャを使用して管理対象サーバーを起動する場合、通常は管理対象サーバーの起動時にstdoutまたはstderrに出力されるメッセージが、かわりにWebLogic Server管理コンソールに表示され、そのサーバー・インスタンスの単一のログ・ファイル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は、ノード・マネージャのルート・ディレクトリ(デフォルトでは、DOMAIN_HOME/nodemanager)です。
ノード・マネージャ・ログ・ファイルの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの構成ファイルとログ・ファイルに関する項を参照してください。
サーバー・ログ・メッセージとログ・ファイルは、サーバーまたはアプリケーションの動作に影響を与えるイベントおよび状況を通知します。一部のサブシステムでは、通常の操作状況でサブシステムの対話を監査するために追加のログ・ファイルが保持されます。以下のリストに、それぞれの追加ログ・ファイルを示します。
HTTPサブシステムはすべてのHTTPトランザクションのログをテキスト・ファイルに保存します。HTTPアクセス・ログのデフォルトの場所とローテーション・ポリシーは、サーバー・ログと同じです。定義した各サーバーまたは各仮想ホストに対して、HTTPアクセス・ログの動作を定義する属性を設定できます。詳細は、『Oracle WebLogic Serverサーバー環境の管理』のHTTPアクセス・ログの設定に関する項およびOracle WebLogic Server管理コンソール・オンライン・ヘルプのHTTPログの有効化および構成に関する項を参照してください。
各サーバーには、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を格納するトランザクション・ログが備わっています。WebLogic Serverでは、システムのクラッシュやネットワーク障害からの回復時にトランザクション・ログを使用します。トランザクション・ログを直接表示することはできません。このファイルはバイナリ・フォーマットです。
トランザクション・マネージャは、デフォルト永続ストアを使用して、トランザクション・ログ・ファイルを格納します。WebLogic Server管理コンソールを使用すると、デフォルト・ストアの場所を変更できます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービスの移行のためのデフォルト永続ストアの構成に関する項を参照してください。
WebLogic監査プロバイダは、WebLogicセキュリティ・フレームワークで内部的に決定された、複数のセキュリティ・リクエストの情報を記録します。また、WebLogic監査プロバイダはこれらのセキュリティ・リクエストに関連付けられているイベント・データとリクエストの結果も記録します。監査プロバイダの構成は任意です。デフォルト・セキュリティ・レルム(myrealm)には監査プロバイダは構成されていません。詳細は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』の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 12.2.1以降のマルチテナントのサポートのために、サーバー・ログ、ドメイン・ログ、ドメイン・スコープJDBCログおよび収集されたデータ・アーカイブなどのWebLogic Serverコンポーネントの共有ログに、2つのフィールドが追加されて、パーティションにかわって生成されたメッセージを区別することができます。
partition-id
partition-name
共有ログのファイル形式にこれらのフィールドが追加されたため、旧バージョンのWebLogic Serverで作成されたスクリプトおよびレガシー・ログ・ファイル形式に依存するスクリプトとの互換性の問題が生じます。ロギング・サービスを構成して、旧バージョンのWebLogic Serverで使用するレガシー・ログ形式に戻すには、DomainMBean.LogFormatCompatibilityEnabled属性をtrueに設定します。WebLogic Server 12.2.1以降では、この属性のデフォルト値はfalseです。
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ロギング・サービスの追加』の「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ロギング・サービスの追加』のデバッグ・メッセージの書込みに関する項を参照してください。
WebLogic Server 管理コンソールでは、ドメイン内の全ログ・ファイルのログ・ビューアを利用できます。ログ・ビューアでは、日付、サブシステム、重大度、マシン、サーバー、スレッド、ユーザーID、トランザクションID、コンテキストID、タイムスタンプ、メッセージID、またはメッセージの中から任意の属性を基にして、メッセージの検索や表示を行うことができます。また、ロギングされた時点でメッセージを表示することも、過去のログ・メッセージを検索することもできます。(図2-3を参照してください。)
メッセージ・ログの表示、構成、および検索の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のトピックを参照してください。
WebLogic Serverメッセージ・カタログのログ・メッセージの詳細は、エラー・メッセージを参照してください。このメッセージ・カタログには、WebLogicサブシステムによって出力されるすべてのメッセージ、エラー、考えられる原因、およびエラーを回避または修正するための推奨アクションに関する説明が記載されています。詳細を参照するには、「範囲」列(範囲に基づいた参照の場合)、あるいは「サブシステム」列(サブシステムに基づいた参照の場合)の適切なエントリをクリックします。
サーバー・ロギング・ブリッジは、Java APIまたはLog4jロギング実装を使用して、デフォルトでロガー・ツリーのルート・ロガーに添付されています。WebLogic Serverがデフォルトのjava.util.logging実装を使用していて、アプリケーションがLog4j APIを使用している場合、アプリケーション・ログ・メッセージをサーバー・ログにリダイレクトするには、次のように構成および設定を行います。
log4j.propertiesファイルに次の行を追加します。
log4j.rootLogger=server log4j.appender.server=weblogic.logging.log4j.ServerLoggingAppender
log4j.jarファイルのコピーを取得します。WebLogic ServerではLog4jバージョンを配布していませんが、次の場所にあるApacheからダウンロードできます。
log4j.jarファイルおよびWL_HOME/server/lib/wllog4j.jarファイルをサーバーのクラスパスにコピーします。DOMAIN_NAME/libディレクトリに両方のファイルをコピーすることで簡単に実行できます。クラスパス上で、ファイルはサーバー起動時に動的にサーバー・クラスパスに追加されます。
これらの.jarファイルを別の場所に格納する場合は、両方を同じディレクトリに格納し、サーバーのクラスパスに指定されているパスを、そのディレクトリに変更する必要があります
WebLogic ServerがLog4j APIをロギング実装として使用するように構成されていて、アプリケーションがjava.util.loggingを使用している場合、logging.propertiesを構成して、次のようにjava.util.loggingからサーバー・ログにメッセージをリダイレクトします。
ルート・ロガーで作成するハンドラを指定します。
handlers = weblogic.logging.ServerLoggingHandler
新しいFileHandlerインスタンスのデフォルト・ロギング・レベルを設定します
weblogic.logging.ServerLoggingHandler.level = ALL
注意:
サーバー・ロギング・ブリッジが構成されているWebLogicドメインをアップグレードする際に必要となる可能性がある構成変更に関する重要な説明は、Oracle WebLogic Serverのアップグレードのサーバー・ロギング・ブリッジに関する項を参照してください。
WebLogic Serverでは、WebLogic Serverロギング構成内からの、JDK LogManagerの指定ロガーに対するjava.util.logging.Loggerレベルの構成がサポートされています。
指定ロガーのjava.util.loggingレベルは、LogMBeanのPlatformLoggerLevels属性を使用して構成できます。この構成は、JDKのデフォルトのグローバルLogManagerのjava.util.logging.Loggerインスタンスに適用されます。
注意:
この構成は、WebLogicロギング構成の一部として永続化され、logging.propertiesファイルには含まれません。
WebLogicドメインがOracle JRFを含み、かつOracle Diagnostic Logging (ODL)を使用するように構成されている場合、LogMBean.PlatformLoggerLevels属性で設定されたjava.util.loggingレベルは無視されます。ODLロギングの詳細は、『Oracle Fusion Middlewareの管理』の「ログ・ファイルと診断データの管理」を参照してください。
WebLogic Serverロガーを構成するには、LogMBeanのLoggerSeverities属性を使用します。詳細は、表2-2を参照してください。これらのロガーは、JDKのデフォルトのグローバルLogManagerでは使用できません。
WebLogic Server管理コンソールを使用したjava.util.loggingロガー・レベルの構成方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのjava.util.loggingロガー・レベルの構成に関する項を参照してください。
次の例は、WLSTを使用したjava.util.loggingロガー・レベルの構成を示しています。
wls:/mydomain/serverConfig> edit()
wls:/mydomain/edit> startEdit()
wls:/mydomain/edit !> cd ('/Servers/myserver/Log/myserver')
wls:/mydomain/edit/Servers/myserver/Log/myserver !> props = java.util.Properties()
wls:/mydomain/edit/Servers/myserver/Log/myserver !> props.put("foo.bar","INFO")
wls:/mydomain/edit/Servers/myserver/Log/myserver !>
wls:/mydomain/edit/Servers/myserver/Log/myserver !> cmo.setPlatformLoggerLevels(props)
wls:/mydomain/edit/Servers/myserver/Log/myserver !> save()
Saving all your changes ...
Saved all your changes successfully.
wls:/mydomain/edit/Servers/myserver/Log/myserver !> activate()
Activating all your changes, this may take a while ...
The edit lock associated with this edit session is released once the activation is completed.
Activation completed
WebLogicロギング・サービスでJavaロギングまたはLog4jを使用する場合は、以下の推奨事項を考慮します。
アプリケーション・ロギングにLog4jを使用している場合、log4j.propertiesファイルは、WebLogic Serverの一般的なオーバーライド機能を使用して、既存のデプロイメント・プラン・ディレクトリ構造にこのファイルを挿入できます。一般的なオーバーライド機能により、アプリケーションで使用される特定のリソース・タイプの挿入や変更が便利になり、アプリケーションJARファイルを変更せずにアプリケーションの既存のクラスローダーやリソース・ローディング・ルールを引き続き使用できます。
詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の汎用ファイル・ロード・オーバーライドに関する項を参照してください。
