Oracle® Fusion Middleware Oracle WebLogic Server ログ ファイルのコンフィグレーションとログ メッセージのフィルタ処理 11g リリース 1 (10.3.1) B55548-01 |
|
![]() 戻る |
![]() 次へ |
WebLogic ロギング サービスには、ログ メッセージの作成、表示、フィルタ、およびリスン機能があります。ログ メッセージは、WebLogic Server インスタンス、サブシステム、および WebLogic Server またはクライアント JVM 上で実行される Java EE アプリケーションによって生成されます。
以下の節では、WebLogic ロギング サービス環境、ロギング プロセス、およびログ ファイルについて説明します。
WebLogic Server サブシステムは、ロギング サービスを使用して、新しいアプリケーションのデプロイメント、1 つまたは複数のサブシステムの障害などのイベントに関する情報を提供します。サーバ インスタンスは、それを使用してサーバの状態を通知したり、特定のイベントに応答したりします。たとえば、WebLogic ロギング サービスを使用すると、エラー状態を報告したり、特定のサブシステムからログ メッセージをリスンしたりすることが可能です。
各 WebLogic Server インスタンスで、サーバ ログが保持されます。各 WebLogic Server ドメインは WebLogic Server の複数のインスタンスを同時に実行できるので、ロギング サービスにより複数のサーバ インスタンスで生成されるメッセージを収集して、単一の、ドメイン全体のメッセージ ログにまとめます。ドメイン ログでは、ドメイン全体の状態を確認できます。「サーバ ログ ファイルとドメイン ログ ファイル」を参照してください。
以下の節では、ロギング環境について説明し、ロギング プロセスの概要を示します。
どのロギング システムも、基本的にはログ メッセージを生成するコンポーネントとメッセージを配信 (パブリッシュ) するコンポーネントで構成されます。デフォルトでは、WebLogic Server サブシステムは、メッセージ カタログ機能を使用してメッセージを生成し、Java Logging API を使用してメッセージを配信します。開発するアプリケーションに対してメッセージ カタログを使用することもできます。
メッセージ カタログ フレームワークでは、アプリケーションが WebLogic のサーバ ログに独自のメッセージ セットを送るために使用する一連のユーティリティと API が提供されます。このフレームワークは、ログ メッセージをローカライズする必要のあるアプリケーションにとって理想的ですが、ローカライズの不要なアプリケーションの場合でも、状態の通信や出力のためにフレキシブルで優れた一連のツールを利用できます。
『Oracle Fusion Middleware Oracle WebLogic Server アプリケーション ロギングのロギング サービス ユーザーズ ガイド』の「WebLogic Server でのメッセージ カタログの使い方」を参照してください。
インターナショナライズする必要がないメッセージまたは WebLogic I18n フレームワークの外部でインターナショナライズされたメッセージをロギングするために、メッセージ カタログ フレームワークの使用に加え、アプリケーションで weblogic.logging.NonCatalogLogger
API を使用して WebLogic サーバ ログにメッセージを送信できます。カタログからメッセージを呼び出す代わりに NonCatalogLogger
を使用することで、メッセージ テキストをアプリケーション コードに直接配置します。
『Oracle Fusion Middleware Oracle WebLogic Server アプリケーション ロギングのロギング サービス ユーザーズ ガイド』の「NonCatalogLogger API の使用」を参照してください。
メッセージを配信するために、WebLogic Server では Java ベースのロギングがデフォルトでサポートされています。LoggingHelper
クラスを使用すると、サーバ ロギング用の java.util.logging.Logger
オブジェクトへのアクセスが可能になります。これにより、Java Logging API を利用してカスタム ハンドラ、フィルタ、およびフォーマッタを追加できます。Sun API のドキュメント (http://java.sun.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
参照を使用する。
WebLogic ロギング サービスを使用してアプリケーション イベントをパブリッシュするために、アプリケーションが Java ロギングまたは Log4j に対応するようにコンフィグレーションされている場合、メッセージ カタログまたは Commons API を使用して WebLogic ロギング サービスにアプリケーション イベントをリレーするカスタム ハンドラまたはアペンダを作成する。
詳細については、「WebLogic ロギング サービスでの Log4j の使い方」を参照してください。
サブシステムおよびアプリケーションからのメッセージは、すべてローカル ホスト コンピュータ上のサーバ ログ ファイルに書き込まれます。デフォルトでは、サーバ ログ ファイルは、サーバ インスタンスのルート ディレクトリ配下の logs
ディレクトリに格納されています (DOMAIN_NAME
\servers\
SERVER_NAME
\logs\
SERVER_NAME
.log
など。ただし、DOMAIN_NAME
はドメインを配置したディレクトリの名前、SERVER_NAME
はサーバの名前)。
メッセージをサーバ ログ ファイルに書き込むほかにも、各サーバ インスタンスはそのメッセージのサブセットをドメイン全体のログ ファイルに転送できます。デフォルトでは、重大度が NOTICE
以上のメッセージのみが転送されます。転送されるメッセージ セットは変更できますが、サーバは重大度が DEBUG
のメッセージを転送できません。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「ドメイン ログへのメッセージの転送」を参照してください。
ドメイン ログ ファイルは、ドメイン全体のステータスを確認するための中心となるファイルです。ドメイン ログは、管理サーバの logs
ディレクトリにあります。ドメイン ログ ファイルのデフォルトの格納場所および名前は、DOMAIN_NAME
\servers\
ADMIN_SERVER_NAME
\logs\
DOMAIN_NAME
.log
です。ただし、DOMAIN_NAME
はドメインを配置したディレクトリの名前、ADMIN_SERVER_NAME
は管理サーバの名前です。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「ドメイン ログ ファイルの名前と場所の変更」を参照してください。
ドメイン ログ内のレコードのタイムスタンプは、そのメッセージの送信元であるサーバのタイムスタンプです。ドメイン ログのログ レコードは、各自のタイムスタンプ順ではなくメッセージの到着順に書き込まれます。管理対象サーバが一定の期間、管理サーバと通信できなくなることがありますが、そうした場合にはメッセージがローカルにバッファされ、サーバ間が再び接続された時点で管理サーバに送信されます。
ドメイン ログにメッセージを転送するために、各サーバ インスタンスはそのログ メッセージをブロードキャストします。サーバは、重大度が DEBUG
のメッセージを除くすべてのメッセージとメッセージ テキストをブロードキャストします。
管理サーバは、これらのメッセージのサブセットをリスンし、それらをドメイン ログ ファイルに書き込みます。これらのメッセージをリスンするために、管理サーバはリスナを各管理対象サーバに登録します。デフォルトでは、リスナには重大度が NOTICE
以上のメッセージのみを管理サーバに転送するためのフィルタが含まれます (図 2-2 を参照してください)。
各 WebLogic Server インスタンスに対して、デフォルト フィルタをオーバーライドし、デフォルトとは異なるメッセージ セットをドメイン ログ ファイルに書き込むログ フィルタを作成できます。WebLogic Server インスタンスのログ フィルタの設定については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「ログ フィルタの作成」を参照してください。
管理サーバにアクセスできない場合、管理対象サーバでは自身のローカル サーバ ログ ファイルに対してメッセージの書き込みが続けられます。ただしデフォルトではサーバ間が再接続された際に、接続の切断中に書き込まれたメッセージがすべてドメイン ログ ファイルに転送されるとは限りません。サーバ間の再接続時にメッセージを管理サーバへ転送できるように、管理対象サーバのバッファには指定した数のメッセージが保持されます。
このバッファに保持されるメッセージ数は LogMBean
の DomainLogBroadcasterBufferSize
属性でコンフィグレーションします。DomainLogBroadcasterBufferSize
は、管理対象サーバからドメイン サーバへログ メッセージが送信される頻度を制御します。デフォルトでは、この属性には 1
が設定されているため、ログ メッセージのバッチ処理はなく、管理サーバのドメイン ログに転送されるのは最後に記録されたメッセージのみです。たとえば、2 時間アクセスできなかった後に管理サーバが復元された場合、その 2 時間に生成されたメッセージはドメイン ログに含まれません。『Oracle Fusion Middleware 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 Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「ドメイン ログ ファイルの名前と場所の変更」を参照してください。
サーバ ログ ファイルのメッセージを参照するには、WebLogic Server のホスト コンピュータにログインして標準のテキスト エディタを使用するか、任意のコンピュータにログインして Administration Console のログ ファイル ビューアを使用します。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「サーバ ログの表示」を参照してください。
注意 : ログ ファイルは手作業で編集しないようにします。ログ ファイルを修正すると、タイムスタンプが変更されてログ ファイルのローテーションが混乱するおそれがあります。また、編集によりファイルがロックされて、WebLogic Server から更新できなくなり、アクセサの動作を妨げる場合があります。診断アクセサ サービスの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server 診断フレームワークのコンフィグレーションと使い方』の「データ アクセサを使用した診断データへのアクセス」を参照してください。 |
メッセージをログ ファイルに書き込むほかにも、各サーバ インスタンスはメッセージのサブセットを標準出力に出力することができます。通常、標準出力は、サーバ インスタンスが実行されているシェル (コマンド プロンプト) です。ただし、オペレーティング システムによっては他の場所に標準出力をリダイレクトできます。デフォルトでは、サーバ インスタンスは重大度が NOTICE
以上のメッセージのみを標準出力に出力します (重大度については、下記の「メッセージの重大度」を参照)。重大度のしきい値を変更すると、サーバが標準出力に出力するメッセージを増減できます。
ノード マネージャを使用して管理対象サーバを起動する場合、通常は管理対象サーバの起動時に stdout
または stderr
に出力されるメッセージが、代わりに Administration Console に表示され、そのサーバ インスタンスの単一のログ ファイル 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 Fusion Middleware Oracle WebLogic Server ノード マネージャ管理者ガイド』の「ノード マネージャのコンフィグレーション ファイルとログ ファイル」を参照してください。
サーバ ログ メッセージとログ ファイルは、サーバまたはアプリケーションの動作に影響を与えるイベントおよび状況を通知します。一部のサブシステムでは、通常の操作状況でサブシステムの対話を監査するために追加のログ ファイルが保持されます。以下のリストに、それぞれの追加ログ ファイルを示します。
HTTP サブシステムはすべての HTTP トランザクションのログをテキスト ファイルに保存する。HTTP アクセス ログのデフォルトの場所とローテーション ポリシーは、サーバ ログと同じです。定義した各サーバまたは各仮想ホストに対して、HTTP アクセス ログの動作を定義する属性を設定できます。『Oracle Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション』の「HTTP アクセス ログの設定」、および Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「HTTP ログの有効化とコンフィグレーション」を参照してください。
各サーバには、そのサーバで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を格納するトランザクション ログが備えられている。WebLogic Server では、システムのクラッシュやネットワーク障害からの回復時にトランザクション ログを使用します。トランザクション ログを直接表示することはできません。このファイルはバイナリ フォーマットです。
トランザクション マネージャは、デフォルト永続ストアを使用して、トランザクション ログ ファイルを格納します。Administration Console を使用すると、デフォルト ストアの場所を変更できます。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「トランザクション回復サービスの移行のためのデフォルト永続ストアのコンフィグレーション」を参照してください。
WebLogic 監査プロバイダは、WebLogic Security フレームワークで内部的に決定された、複数のセキュリティ要求の情報を記録する。また、WebLogic 監査プロバイダはこれらのセキュリティ要求に関連付けられているイベント データと要求の結果も記録します。監査プロバイダのコンフィグレーションは任意です。デフォルト セキュリティ レルム (myrealm) には監査プロバイダはコンフィグレーションされていません。『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「WebLogic 監査プロバイダのコンフィグレーション」を参照してください。
WebLogic 監査プロバイダによって記録されたすべての監査情報は、WL_HOME\DOMAIN_NAME
\servers\
SERVER_NAME
\logs\DefaultAuditRecorder.log
に保存されます。監査プロバイダはセキュリティ レルム単位でコンフィグレーションされますが、各サーバは監査データをサーバ ディレクトリにある各自のログ ファイルに書き込みます。
JDBC サブシステムには、JDBC ドライバの登録や SQL 例外など、JDBC 接続に関するさまざまなイベントが記録される。JDBC に関連するイベントは、接続が作成または更新された場合や、JDBC オブジェクトのコンフィグレーションが変更された場合などに、サーバ ログに書き込まれます。『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「WebLogic JDBC リソースの管理」を参照してください。
JMS ロギングは、JMS サーバを作成するとデフォルトで有効になる。ただし、この JMS サーバに対象指定する JMS モジュールのメッセージ送り先 (または送り先で使用する JMS テンプレート) では、JMS ロギングを明示的に有効にする必要があります。
JMS サーバ ログ ファイルには、メッセージの生成、消費、削除など、メッセージの基本的なライフ サイクル イベントについての情報が格納されます。サブジェクト メッセージをホストする JMS 送り先のコンフィグレーションでメッセージのロギングが有効になっている場合、メッセージの基本的なライフ サイクル イベントは、JMS メッセージ ログ ファイルにメッセージ ログ イベントを生成します。
メッセージ ログは、サーバ インスタンスのルート ディレクトリ配下の logs
ディレクトリに格納されています (DOMAIN_NAME
\servers\
SERVER_NAME
\logs\jmsServers\
SERVER_NAME
JMSServer\jms.messages.log
など。ただし、DOMAIN_NAME
はドメインを配置したディレクトリの名前、SERVER_NAME
はサーバの名前)。
JMS サーバを作成した後には、ログ ファイルのデフォルト名を変更できるほか、古いログ メッセージを別のファイルに移動 (ローテーション) するための条件をコンフィグレーションできます。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「トピック メッセージのロギングのコンフィグレーション」、および『Oracle Fusion Middleware 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 インスタンスがメッセージを標準出力に書き込むとき、その出力に ####
というプレフィクスと、Server Name、Machine Name、Thread ID、User ID、Transaction ID、Diagnostic Context ID、および Raw Time Value フィールドは含まれません。
次に、前節のメッセージがどのように標準出力に出力されるかを示します。
<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 サーバ ログのメッセージ属性
属性 | 説明 |
---|---|
Locale-formatted Timestamp |
メッセージが発生した時刻と日付。書式はロケールに基づく。各 WebLogic Server インスタンスを実行する JVM (Java 仮想マシン) は、ローカルのタイム ゾーンと書式に関する情報についてホスト コンピュータのオペレーティング システムを参照する。 |
Severity |
メッセージで報告されるイベントの影響または深刻さの度合いを示す。「メッセージの重大度」を参照。 |
Subsystem |
EJB (Enterprise Java Bean) コンテナや JMS (Java Messaging Service) などの、メッセージを生成した WebLogic Server のサブシステムを示す。 |
Machine Name Server Name Thread ID |
メッセージの発生源を識別する。
クライアント JVM 内で生成されるログ メッセージには、これらの属性は含まれない。たとえば、アプリケーションがクライアント JVM で実行されており、WebLogic ロギング サービスを使用する場合、そのアプリケーションが生成して WebLogic クライアント ログ ファイルに送信するメッセージにはこれらの属性が含まれない。 |
User ID |
関連付けられたイベントを実行したユーザ ID。 内部コードの一部を実行する場合、WebLogic Server では実行を開始したユーザの ID を認証してから、特別な Kernel Identity ユーザ ID でコードを実行する。 サーバ インスタンスにデプロイされている EJB などの Java EE モジュールは、モジュールがサーバに渡すユーザ ID を報告する。 クライアント JVM 内で生成されるログ メッセージには、これらのフィールドは含まれない。 |
Transaction ID |
トランザクションのコンテキスト内でロギングされたメッセージの場合にのみ示される。 |
Diagnostic Context ID |
特定の要求またはアプリケーションから受け取ったメッセージを相互に関連付けるコンテキスト情報。 |
Raw Time Value |
タイムスタンプ (ミリ秒)。 |
Message ID |
ユニークな 6 桁の識別子。 WebLogic Server システム メッセージが生成するすべてのメッセージ ID は アプリケーションではインターナショナライズされたメッセージ カタログの代わりに 『Oracle Fusion Middleware Oracle WebLogic Server アプリケーション ロギングのロギング サービス ユーザーズ ガイド』の「WebLogic Server ログへのメッセージの書き込み」を参照。 |
Message Text |
イベントまたは条件の説明。 |
WebLogic Server のログ メッセージの重大度属性は、メッセージで報告されるイベントまたは状況の潜在的な影響を示します。
表 2-2 は、WebLogic Server サブシステムからのログ メッセージの重大度を、レベルが低い順に示したものです。
表 2-2 メッセージの重大度
重大度 | 意味 |
---|---|
TRACE |
診断アクション ライブラリからのメッセージの場合に使用する。サーバおよびアプリケーション クラスの診断インスツルメンテーションを有効にすると、 『Oracle Fusion Middleware Oracle WebLogic Server 診断フレームワークのコンフィグレーションと使い方』の「診断アクション ライブラリ」を参照。 |
DEBUG |
デバッグ メッセージが生成された。 |
INFO |
通常の処理を報告するために使用する、低レベルの情報メッセージ。 |
NOTICE |
重要度が高い情報メッセージ。 |
WARNING |
問題のあるオペレーションまたはコンフィグレーションがあったが、通常のオペレーションに支障は生じない。 |
ERROR |
ユーザ エラーが発生したことを示す。システムまたはアプリケーションでは、割り込みやサービスの限定的な低下を起こすことなくエラーに対処できる。 |
CRITICA |
システム エラーまたはサービス エラーが発生したことを示す。システムを回復できるが、サービスの一時的な損失や永久的な低下が発生する場合がある。 |
ALERT |
システムの特定のサービスだけが使用不能の状態にある。自動回復を実行できない。この問題を解決するには管理者がすぐに措置を講じる必要がある。 |
EMERGENCY |
サーバが使用不能な状態にある。この重大度は、重大なシステム障害または問題があることを示す。 |
WebLogic Server のサブシステムでは、重大度の低いメッセージが数多く生成され、重大度の高いメッセージほど数が少なくなります。たとえば、通常の環境では、INFO
メッセージが多く生成され、EMERGENCY
メッセージは生成されません。
アプリケーションで WebLogic ロギング サービスを使用している場合は、DEBUG
という重大度も使用できます。『Oracle Fusion Middleware Oracle WebLogic Server アプリケーション ロギングのロギング サービス ユーザーズ ガイド』の「デバッグ メッセージの書き込み」を参照してください。
WebLogic Server Administration Console では、ドメイン内の全ログ ファイルのログ ビューアを利用できます。ログ ビューアでは、日付、サブシステム、重大度、マシン、サーバ、スレッド、ユーザ ID、トランザクション ID、コンテキスト ID、タイムスタンプ、メッセージ ID、またはメッセージの中から任意の属性を基にして、メッセージの検索や表示を行うことができます。また、ロギングされた時点でメッセージを表示することも、過去のログ メッセージを検索することもできます (図 2-3 を参照してください)。
メッセージ ログの表示、コンフィグレーション、および検索の詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプにある以下のトピックを参照してください。
WebLogic Server メッセージ カタログのログ メッセージに関する詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Message Catalog』を参照してください。このメッセージ カタログには、WebLogic サブシステムによって出力されるすべてのメッセージ、エラー、考えられる原因、およびエラーを回避または修正するための推奨アクションに関する説明が記載されています。詳細を参照するには、「Range」カラム (範囲に基づいた参照の場合)、あるいは「Subsystem」カラム (サブシステムに基づいた参照の場合) の適切なエントリをクリックします。