Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理

12c リリース1 (12.1.1)

B65917-02(原本部品番号:E24428-02)

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープおよび対象読者

- このドキュメントの手引き

- 関連ドキュメント

- ロギングのサンプルとチュートリアル

- Avitek Medical Recordsアプリケーション(MedRec)とチュートリアル

- MedRecへのLog4jの統合

- WebLogic Server配布キットのロギングのサンプル

- このリリースでのロギングの新機能と変更点

2 WebLogicロギング・サービスの理解

- WebLogicロギング・サービスの特長

- WebLogicロギング・サービスの仕組み

- コンポーネントと環境

- 用語

- ロギング・プロセスの概要

- ベスト・プラクティス: WebLogicロギング・サービスへのJavaロギングまたはLog4jの統合

- サーバー・ログ・ファイルとドメイン・ログ・ファイル

- サーバー・インスタンスからドメイン・ログへのメッセージ転送の仕組み

- サーバー・ログとサブシステム・ログ

- サーバー・ログ

- サブシステム・ログ

- ログ・メッセージのフォーマット

- 標準出力と標準エラーへの出力のフォーマット

- メッセージの属性

- メッセージの重大度

- WebLogic Serverログの表示

- サーバー・ロギング・ブリッジ

- Javaロギング

- Log4Jロギング

- ルート・ロガーへのログ・メッセージの伝播

- ベスト・プラクティス: 一般的なオーバーライドを使用したロギング・プロパティ・ファイルの挿入

3 WebLogicロギング・サービスの構成

- 構成のシナリオ

- ロギング・サービス構成の概要

- ログの重大度の使用

- ログ・フィルタの使用

- ロギングの構成タスク: 主な手順

- Log4jとCommons Logging API

- Log4jについて

- ロガー

- アペンダ

- レイアウト

- WebLogicロギング・サービスでのLog4jの使い方

- WebLogic ServerロギングのLog4jを構成および有効にするためのWLSTの使い方

- WebLogicロギング・サービスでのCommons APIの使い方

- ロガーの重大度の指定

- WebLogic Serverサブシステム・ロガーの重大度の指定

- Commons Logging APIロガーの重大度の指定

- ログ・ファイルのローテーション

- アーカイブされたログ・ファイルの場所の指定

- ローテーションの通知

- JVMの出力のリダイレクト

4 WebLogic Serverログ・メッセージのフィルタ処理

- ロガーとハンドラの役割

- 重大度などの条件によるメッセージのフィルタ処理

- ロガーとハンドラに対する重大度の設定

- ロガーに対する重大度の設定

- ハンドラに対する重大度の設定

- ロガーとハンドラのフィルタの設定

- ドメイン・ログ・メッセージのフィルタ処理

- Log4jアペンダに対する重大度とフィルタの設定

5 メッセージのサブスクライブ

- メッセージ・ハンドラの概要

- ハンドラの作成とサブスクライブ: 主な手順

- 例: サーバーJVMでのメッセージのサブスクライブ

- 例: ハンドラ・クラスの実装

- 例: ロガー・クラスのサブスクライブ

- 例: Log4jアペンダ・クラスの実装

- Javaロギング・ハンドラとJMXリスナーの比較

Oracle® Fusion Middleware

Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理

12c リリース1 (12.1.1)

B65917-02(原本部品番号:E24428-02)

2012年1月

このドキュメントは、WebLogicロギング・サービスを構成し、サーバーおよびサブシステムのイベントをモニターするシステム管理者、およびJava Platform, Enterprise Edition (Java EE)アプリケーション・ログをWebLogic Serverログに統合するJava EEアプリケーション開発者に情報を提供するものです。

Oracle Fusion Middleware Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理, 12c リリース1 (12.1.1)

B65917-02

Copyright © 2007, 2012, Oracle and/or its affiliates.All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

はじめに

ここでは、このガイド『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』で使用されるアクセシビリティ機能および表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleのお客様は、My Oracle Supportから電子サポートにアクセスできます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

このドキュメントでは、WebLogic Serverロギング・サービスを使用して、サーバー、サブシステム、およびアプリケーション・イベントをモニターする方法について説明します。メッセージをログ・ファイルに書き込み、WebLogic Serverがブロードキャストするログ・メッセージをリスニングするようにWebLogic Serverを構成する方法について説明します。また、WebLogic Server管理コンソールを介してログ・メッセージを表示する方法についても説明します。

この章では、このガイド『ログ・ファイルの構成とログ・メッセージのフィルタ処理』の内容と構成について説明します。

- ドキュメントのスコープおよび対象読者

- このドキュメントの手引き

- 関連ドキュメント

- ロギングのサンプルとチュートリアル

- このリリースでのロギングの新機能と変更点

ドキュメントのスコープおよび対象読者

このドキュメントでは、WebLogic Serverロギング・サービスを使用して、サーバー、サブシステム、およびアプリケーション・イベントをモニターする方法について説明します。メッセージをログ・ファイルに書き込み、WebLogic Serverがブロードキャストするログ・メッセージをリスニングするようにWebLogic Serverを構成する方法について説明します。また、WebLogic Server管理コンソールを介してログ・メッセージを表示する方法についても説明します。

このドキュメントは、WebLogicロギング・サービスを構成し、サーバーおよびサブシステムのイベントをモニターするシステム管理者、およびJava Platform, Enterprise Edition (Java EE)アプリケーション・ログをWebLogic Serverログに統合するJava EEアプリケーション開発者に情報を提供するものです。このドキュメントの内容は、開発からテストおよび本番まで、ソフトウェア・プロジェクトのすべての段階に関連しています。

このドキュメントでは、アプリケーションのロギングまたはログ・メッセージ・カタログのローカライズおよび国際化は扱いません。これらのトピックに関する情報へのリンクについては、「関連ドキュメント」を参照してください。

Java EE技術、Web技術、オブジェクト指向プログラミング技術、およびJavaプログラミング言語について読者が精通していることを前提としています。

このドキュメントの手引き

このドキュメントの構成は次のとおりです。

- この章「概要とロードマップ」では、このドキュメントの構成および関連ドキュメントについて説明します。

- 第2章「WebLogicロギング・サービスの理解」では、ロギング・プロセス、ログ・ファイル、およびログ・メッセージについて説明します。

- 第3章「WebLogicロギング・サービスの構成」では、基本的な構成のシナリオおよびタスクについて説明します。

- 第4章「WebLogic Serverログ・メッセージのフィルタ処理」では、WebLogic Serverがログまたは標準出力に書き込むメッセージの種類を指定する方法について説明します。

- 第5章「メッセージのサブスクライブ」では、ログ・メッセージを受信して出力するメッセージ・ハンドラが、WebLogic Serverによってどのようにインスタンス化されサブスクライブされるのかについて説明します。

関連ドキュメント

WebLogic Serverのすべてのマニュアルは、Webサイトで公開されています。特に、WebLogic Serverインスタンスにより生成されるログ・ファイルの表示方法および構成方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのログの表示と構成に関する項を参照してください。また、WebLogic Serverのメッセージ・カタログ、非カタログ・ロギング、およびサーブレット・ロギングを使用してアプリケーションまたはリモートJavaクライアントからログ・メッセージを生成する方法、およびログ・メッセージの国際化とローカライズに対するWebLogicのサポートについては、『Oracle WebLogic Serverアプリケーション・ロギングのためのロギング・サービスの使用』を参照してください。

ロギングのサンプルとチュートリアル

このドキュメントの他にも、ロギングの構成やAPIの使い方を示す様々なサンプル・ロギング・コードが用意されています。

Avitek Medical Recordsアプリケーション(MedRec)とチュートリアル

MedRecはWebLogic Serverに付属したエンドツーエンドのサンプルJava EEアプリケーションであり、一元的で独立した医療記録管理システムをシミュレートします。MedRecアプリケーションには、患者、医師、および管理者に対して、様々なクライアントを使用して患者のデータを管理するフレームワークが用意されています。

MedRecはWebLogic ServerとJava EEの機能を例示し、推奨されるベスト・プラクティスを重要点として示します。MedRecはWebLogic Server配布キットに含まれており、Windowsマシンの「スタート」メニューからアクセスできます。Linuxなどのプラットフォームでは、WL_HOME\samples\domains\medrecディレクトリからMedRecを起動できます。ただし、WL_HOMEは、WebLogic Serverの最上位のインストール・ディレクトリです。

MedRecへのLog4jの統合

WebLogic ServerとともにインストールされるMedRecドメインは、Log4jロギングを有効にするように構成されています。一部のアクション・クラスとMedRecユーティリティ・クラスでは、weblogic.logging.log4j.Log4jLoggingHelperクラスを使用して、新しいロガーの作成、Log4jアペンダへのアクセス、ロガーへのアペンダの登録が可能です。これにより、ベース・クラスを拡張するクラスは、ロガーを使用して情報メッセージをWebLogic Serverログ・ファイルに書込めます。

WebLogic Server配布キットのロギング・サンプル

WebLogic Serverでは、必要に応じてAPIサンプル・コードをWL_HOME\samples\server\examples\src\examplesにインストールできます。ただし、WL_HOMEはWebLogic Serverの最上位インストール・ディレクトリです。WebLogic Serverのスタート・メニューからサンプル・サーバーを起動して、サンプルとその実行手順に関する情報を確認できます。

このリリースでのロギングの新機能と変更点

WebLogic Serverのこのリリースに追加された新機能の一覧については、『Oracle WebLogic Serverの新機能』を参照してください。

2 WebLogicロギング・サービスの理解

この章では、WebLogicロギング・サービスに、ログ・メッセージの作成、表示、フィルタ処理、およびリスニング機能を提供する方法について説明します。ログ・メッセージは、WebLogic Serverインスタンス、サブシステム、およびWebLogic ServerまたはクライアントJVM上で実行されるJava EEアプリケーションによって生成されます。

この章の内容は以下のとおりです。

- WebLogicロギング・サービスの特長

- WebLogicロギング・サービスの仕組み

- サーバー・ログとサブシステム・ログ

- ログ・メッセージのフォーマット

- メッセージの属性

- メッセージの重大度

- WebLogic Serverログの表示

- サーバー・ロギング・ブリッジ

WebLogicロギング・サービスの特長

WebLogic Serverサブシステムは、ロギング・サービスを使用して、新しいアプリケーションのデプロイメント、1つまたは複数のサブシステムの障害などのイベントに関する情報を提供します。サーバー・インスタンスは、それを使用してサーバーのステータスを通知したり、特定のイベントに応答したりします。たとえば、WebLogicロギング・サービスを使用すると、エラー状態を報告したり、特定のサブシステムからログ・メッセージをリスニングしたりすることが可能です。

各WebLogic Serverインスタンスで、サーバー・ログが保持されます。各WebLogic ServerドメインはWebLogic Serverの複数のインスタンスを同時に実行できるので、ロギング・サービスにより複数のサーバー・インスタンスで生成されるメッセージを収集して、単一の、ドメイン全体のメッセージ・ログにまとめます。ドメイン・ログでは、ドメイン全体のステータスを確認できます。「サーバー・ログ・ファイルおよびドメイン・ログ・ファイル」を参照してください。

WebLogicロギング・サービスの仕組み

以下の節では、ロギング環境について説明し、ロギング・プロセスの概要を示します。

コンポーネントと環境

どのロギング・システムも、基本的にはログ・メッセージを生成するコンポーネントとメッセージを配信(パブリッシュ)するコンポーネントで構成されます。デフォルトでは、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ロギング・プロセス

「図2-1 WebLogic Serverロギング・プロセス」の説明

図2-1は、以下のプロセスを図示したものです。

1. クライアント(この場合はWebLogic ServerサブシステムまたはJava EEアプリケーション)により、WebLogic Server用に生成されたカタログ・ロガーまたはCommons Logging実装のどちらかのメソッドが呼び出されます。

1. WebLogic Serverメッセージ・カタログおよびNonCatalogLoggerでメッセージが生成されるとき、それらのメッセージはサーバーのLoggerオブジェクトに配信されます。

2. Jakarta Commons Logging APIでは、サーバーのLoggerオブジェクトにログ・リクエストをディスパッチするLogger参照を取得するためのファクトリAPIが定義されます。
サーバーのLoggerオブジェクトは、java.util.logging.Loggerまたはorg.apache.log4j.Loggerのいずれかのインスタンスです。

2. サーバーのLoggerオブジェクトにより、Loggerをサブスクライブしているメッセージ・ハンドラにメッセージがパブリッシュされます。
たとえば、標準出力ハンドラはフォーマットされたメッセージを標準出力に出力し、ファイル・ハンドラはフォーマットされた出力をサーバー・ログ・ファイルに書き込みます。ドメイン・ログ・ブロードキャスタは管理サーバーにあるドメイン・ログにログ・メッセージを送信し、JMXログ・ブロードキャスタはリモート・クライアント上のJMXリスナーにログ・メッセージを送信します。

ベスト・プラクティス: WebLogicロギング・サービスへのJavaロギングまたはLog4jの統合

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を参照してください)。

図2-2 WebLogicのサーバー・ログとドメイン・ログ

「図2-2 WebLogicのサーバー・ログとドメイン・ログ」の説明

各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

メッセージの発生源を識別します。

- Server Nameは、メッセージが生成されたWebLogic Serverインスタンスの名前です。

- Machine Nameは、サーバー・インスタンスをホストするコンピュータのDNS名。

- Thread IDは、JVMがメッセージの発生源のスレッドに割り当てる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はBEA-で始まる0 - 499999の範囲の数字。

アプリケーションでは国際化されたメッセージ・カタログのかわりにNonCatalogLoggerというJavaクラスを使用してログ・メッセージを生成できます。NonCatalogLoggerメッセージのメッセージIDは常に000000です。

『Oracle WebLogic Serverアプリケーション・ロギングのためのロギング・サービスの使用』のWebLogic Serverログへのメッセージの書込みに関する項を参照してください。

メッセージ・テキスト

イベントまたは条件の説明。

メッセージの重大度

WebLogic Serverのログ・メッセージの重大度属性は、メッセージで報告されるイベントまたは状況の潜在的な影響を示します。

表2-2は、WebLogic Serverサブシステムからのログ・メッセージの重大度を、最低の影響レベルから最高の影響レベルまで示したものです。

表2-2 メッセージの重大度

重大度

意味

TRACE

診断アクション・ライブラリからのメッセージの場合に使用します。サーバーおよびアプリケーション・クラスの診断インストゥルメンテーションを有効にすると、TRACEメッセージはメソッドのリクエスト・パスに従います。

『Oracle WebLogic Server診断フレームワークの構成と使用』の診断アクション・ライブラリに関する項を参照してください。

DEBUG

デバッグ・メッセージが生成されました。

INFO

通常の処理を報告するために使用する、低レベルの情報メッセージ。

NOTICE

重要度が高い情報メッセージ。

WARNING

不審なオペレーションまたは構成が発生しましたが、通常のオペレーションには影響しません。

ERROR

ユーザー・エラーが発生したことを示します。システムまたはアプリケーションでは、割込みやサービスの限定的な低下を起こすことなくエラーに対処できます。

CRITICAL

システム・エラーまたはサービス・エラーが発生したことを示します。システムをリカバリできますが、サービスの一時的な損失や永久的な低下が発生する場合があります。

ALERT

特定のサービスが使用不能の状態にある一方で、システムのほかの部分は依然として機能しています。自動リカバリを実行できません。この問題を解決するには、管理者がすぐに措置を講じる必要があります。

EMERGENCY

サーバーが使用不能な状態にあります。この重大度は、重大なシステム障害または問題があることを示します。

WebLogic Serverのサブシステムでは、重大度の低いメッセージが数多く生成され、重大度の高いメッセージほど数が少なくなります。たとえば、通常の環境では、INFOメッセージが多く生成され、EMERGENCYメッセージは生成されません。

アプリケーションでWebLogicロギング・サービスを使用している場合は、DEBUGという重大度も使用できます。『Oracle WebLogic Serverアプリケーション・ロギングのためのロギング・サービスの使用』のデバッグ・メッセージの書込みに関する項を参照してください。

WebLogic Serverログの表示

WebLogic Server 管理コンソールでは、ドメイン内の全ログ・ファイルのログ・ビューアを利用できます。ログ・ビューアでは、日付、サブシステム、重大度、マシン、サーバー、スレッド、ユーザーID、トランザクションID、コンテキストID、タイムスタンプ、メッセージID、またはメッセージの中から任意の属性を基にして、メッセージの検索や表示を行うことができます。また、ロギングされた時点でメッセージを表示することも、過去のログ・メッセージを検索することもできます(図2-3を参照してください)。

図2-3 ログ・ビューア

「図2-3 ログ・ビューア」の説明

メッセージ・ログの表示、構成、および検索の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のトピックを参照してください。

- 「ログの表示と構成」

- 「サーバー・ログの表示」

- 「ドメイン・ログの表示」

WebLogic Serverメッセージ・カタログのログ・メッセージの詳細については、『WebLogic Serverエラー・メッセージ・リファレンス』を参照してください。このメッセージ・カタログには、WebLogicサブシステムによって出力されるすべてのメッセージ、エラー、考えられる原因、およびエラーを回避または修正するための推奨アクションに関する説明が記載されています。詳細を参照するには、「範囲」列(範囲に基づいた参照の場合)、あるいは「サブシステム」列(サブシステムに基づいた参照の場合)の適切なエントリをクリックします。

サーバー・ロギング・ブリッジ

サーバー・ロギング・ブリッジは、現在JavaロギングまたはLog4Jロギングを使用してログ・メッセージをWebLogicロギング・サービスにリダイレクトさせているアプリケーションに対して軽量のメカニズムを提供します。アプリケーションは既存の構成のままでサーバー・ロギング・ブリッジを使用できます。コードを変更したり、WebLogicロギングAPIをプログラムで使用する必要はありません。

サーバー・ロギング・ブリッジを使用するには、次の項で説明するとおりに、ロギング構成プロパティ・ファイルを作成するだけです。WebLogicロギング・サービス用に有効化されたロギングAPIを再構成する必要はありません。サーバー・ロギング・ブリッジは、WebLogicロギング・サービスがJavaロギング(デフォルト)またはLog4j用に現在構成されているかどうかに関係なく機能します。

注意:

com.oracle.wlsネームスペースを使用するアプリケーションでは、サーバー・ロギング・ブリッジを使用するためにロギング・プロパティ・ファイルやその他の構成変更は必要ありません。

Javaロギング

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

注意:

ベスト・プラクティスとして、LogMBean.LoggerSeverityProperties属性でログの重大度を構成することをお薦めします。この方法は、動的であり、ドメインのconfig.xmlファイルに保持できるためです。詳細は、「WebLogic Serverサブシステム・ロガーの重大度の指定」を参照してください。

例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

注意:

前述の例に示すように、logging.propertiesファイルを渡してWebLogic Serverを起動する場合、JAVA_HOME/jre/libにあるデフォルトのJava logging.propertiesファイルはオーバーライドされます。weblogic.Serverコマンドに明示的に渡すlogging.propertiesファイルを個別に作成するには、デフォルトのJava logging.propertiesファイルを、サーバー・ロギング・ブリッジ・ハンドラを使用するためのプロパティで更新する方法もあります。

Log4Jロギング

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

注意:

ベスト・プラクティスとして、LogMBean.LoggerSeverityProperties属性でログの重大度を構成することをお薦めします。この方法は、動的であり、ドメインのconfig.xmlファイルに保持できるためです。詳細は、「WebLogic Serverサブシステム・ロガーの重大度の指定」を参照してください。

例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へのアプリケーションのデプロイ』のファイル・ローディングの一般的なオーバーライドに関する項を参照してください。

3 WebLogicロギング・サービスの構成

この章では、WebLogic Serverのロギングのシナリオと基本的な構成タスクについて説明します。メッセージのフィルタ処理とサブスクライブの詳細な手順については、第4章「WebLogic Serverログ・メッセージのフィルタ処理」および第5章「メッセージのサブスクライブ」を参照してください。

この章の内容は以下のとおりです。

- 構成のシナリオ

- ロギング・サービス構成の概要

- ロギングの構成タスク: 主な手順

- Log4jとCommons Logging API

- WebLogicロギング・サービスでのLog4jの使い方

- WebLogicロギング・サービスでのCommons APIの使い方

- ログ・ファイルのローテーション

- JVMの出力のリダイレクト

構成のシナリオ

WebLogic Serverシステム管理者と開発者は、ロギング出力を構成し、ログ・メッセージをフィルタ処理してエラーをトラブルシューティングしたり、特定のイベントの通知を受信したりします。

以下に、ロギングの構成シナリオの一部を示します。

- DEBUGメッセージおよびINFOメッセージがログ・ファイルに記録されないようにします。

- HTTPサブシステムからのINFOレベルのメッセージを、標準出力ではなくログ・ファイルにパブリッシュできるようにします。

- 重大度がWARNING以上のメッセージをハンドラがパブリッシュするように指定します。

- クラスタ内の個別のサーバーのログ情報を追跡します。

ロギング・サービス構成の概要

ロギングの量の制御は、LogMBeanインタフェースを介して行えます。ロギング・プロセスでは、サブスクライブされたハンドラまたはアペンダにロギング・リクエストがディスパッチされます。WebLogic Serverでは、ログ・メッセージを標準出力に送信するためのハンドラ、サーバー・ログ・ファイル、ドメイン・ログへのメッセージのブロードキャスト機能、リモート・クライアント、ログ・イベントを末尾表示するためのメモリー・バッファがWebLogic Server管理コンソールから利用できます。各種ハンドラの量の制御を行うには、重大度などの条件を基にログ・メッセージをフィルタ処理します。LogMBean(Oracle WebLogic Server MBeanリファレンスに説明があります)は、WebLogic Serverのハンドラに対する重大度の設定およびフィルタ条件の指定に使用できる属性を定義します。

以前のバージョンのWebLogic Serverでは、システム管理者と開発者は、ロガーとハンドラにプログラム的なアクセスしかできませんでした。このリリースのWebLogic Serverでは、MBeanを使用してハンドラを構成できるので、最も基本的なロギング構成のコードを記述する必要はありません。管理コンソールとWebLogic Server Scripting Tool (WLST)では、ロギングMBeanとやりとりするためのインタフェースが提供されます。また、Dweblogic.log.attribute-name=value(たとえば、Dweblogic.log.StdoutSeverity=Debug)を使用して、コマンドラインでLogMBeanパラメータを指定することもできます。『Oracle WebLogic Serverコマンド・リファレンス』のメッセージの出力とロギングに関する項を参照してください。

さらにシナリオを高度に利用したり、ロガーを構成したりする場合は、JavaロギングAPIを使用します。

ロギングの量の制御で最も単純なのは、ハンドラに対して重大度を設定することです。基準となる重大度を指定して、それより低いレベルのメッセージの拒否するように設定することなどができます。たとえば、標準出力ハンドラには、デフォルトの重大度のしきい値としてNOTICEが設定されています。そのため、INFOおよびDEBUGレベルのメッセージは標準出力に送信されません。

ハンドラに対してフィルタを構成すると、HTTPおよびJDBCサブシステムからのメッセージのみを標準出力に送信するなど、パブリッシュ用にログ・メッセージを受け付ける条件を指定できます。

注意:

ユーザーがロガーまたはハンドラの構成を変更できるには、java.util.logging.LoggingPermissionクラス(http://docs.oracle.com/javase/6/docs/api/java/util/logging/LoggingPermission.htmlを参照)が必要です。本番環境では、現在のユーザーに対してjava.util.logging.LoggingPermissionを有効にしたJavaセキュリティ・マネージャの使用をお薦めします。

『Oracle WebLogic Serverセキュリティのプログラミング』のJavaセキュリティ・マネージャを使用したWebLogicリソースの保護に関する項、および「Java Logging Overview」(http://docs.oracle.com/javase/6/docs/technotes/guides/logging/overview.html)を参照してください。

以下の節では、WebLogic Serverのロギング動作を構成する際の基準点について詳細を説明します。

ログの重大度の使用

各ログ・メッセージには、関連する重大度があります。重大度は、ログ・メッセージの重要性と緊急度を大まかに示します。WebLogic Serverでは、TRACEからEMERGENCYまでの重大度があらかじめ定義されています。これらの重大度は、ログ・リクエストがロガーにディスパッチされるとログ・レベルに変換されます。ログ・レベル・オブジェクトは、以下の値(影響の小さい方から大きい方の順で並んでいる)のいずれかを指定できます。

TRACE、DEBUG、INFO、NOTICE、WARNING、ERROR、CRITICAL、ALERT、EMERGENCY

ロガーとハンドラに対してログの重大度を設定できます。ロガーに対してセキュリティ・レベル設定した場合、いずれのハンドラも、ロガーによって拒否されたイベントを受信しません。たとえば、ロガーに対してログ・レベルをNOTICEに設定した場合、ハンドラは、INFOレベルのイベントを受信しません。ハンドラに対してログ・レベルを設定した場合、制約はそのハンドラにのみ適用され、他のハンドラには及びません。たとえば、ファイル・ハンドラに対してDEBUGをオフにしても、DEBUGメッセージがログ・ファイルに書き込まれないわけではありません。ただし、DEBUGメッセージは標準出力に書き込まれます。

サポートされている重大度の詳細は、Oracle WebLogic Server APIリファレンスのweblogic.logging.Severitiesクラスに関する説明を参照してください。

ハンドラおよびロガーに対するログ・レベルの設定は、管理コンソール、WLST、またはコマンド・ラインで行います。ロガーのセキュリティ・レベルの設定を参照してください。ロガーおよびハンドラは、APIでも構成できます。「ロガーとハンドラに対する重大度の設定」を参照してください。

ログ・フィルタの使用

Loggerオブジェクトがパブリッシュするメッセージをより細かく管理できるようにするために、フィルタを作成して設定できます。フィルタはカスタム・ロジックによりログ記録の内容を評価するクラスで、ログ・メッセージを受け入れるか拒否するかの判断に使用します。たとえば、特定の重大度のメッセージや、特定のサブシステムに由来するメッセージなど、指定した条件に従ってメッセージを選択的に除去することが可能です。Loggerオブジェクトは、フィルタの基準を満たすログ・メッセージだけをパブリッシュします。各サーバー・インスタンスから、サーバーのログ・ファイル、標準出力、メモリー・バッファに書き込まれるメッセージ、またはドメイン全体のメッセージ・ログにブロードキャストされるメッセージについて、個別にフィルタを作成できます。

フィルタをロガーやハンドラに関連付けることができます。ハンドラに対するフィルタの構成は、管理コンソール、WLST、またはコマンド・ラインで行います。標準出力、ログ・ファイル、ログ・ブロードキャスタ、およびメモリー・ハンドラに対してフィルタを定義するためのLogFilterMBean属性があります。LogFilterMBean(Oracle WebLogic Server MBeanリファレンスに説明があります)は、ユーザーIDおよびサブシステムを基にしたフィルタ条件を定義します。ロガーに対するフィルタの構成にはAPIのみを使用できます。

「ロガーおよびハンドラのフィルタの設定」を参照してください。

ロギングの構成タスク: 主な手順

以下の手順に、WebLogic Serverが生成するログ・メッセージを構成およびフィルタ処理する方法を示します。この手順の詳細は、関連ドキュメントおよびこのドキュメントの後半の節で説明します。

1. 管理コンソールを使用して、ログ・ファイルを管理し、次のロギング・オプションを構成します。

1. ドメイン・ログおよびサーバー・ログのファイル名と場所、ローテーション・パターン、アーカイブされたログ・ファイルの場所、ログ・ファイル数が格納されます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのログの表示と構成に関する項を参照してください。

2. サーバーが標準出力に送信するメッセージの種類。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの標準出力するメッセージの指定に関する項を参照してください。

3. サーバー・インスタンスがドメイン・ログに送信するメッセージ。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのドメイン・ログへのメッセージの転送に関する項を参照してください。

4. HTTPリクエストに対するログ・ファイル。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのHTTPログの有効化と構成に関する項を参照してください。

5. ロギングの実装(JavaロギングまたはLog4j)を指定します。「WebLogicロギング・サービスでのLog4jの使い方」を参照してください。

6. メッセージの宛先を指定し、重大度や他の条件によるログ・メッセージのフィルタ処理を構成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのログ・メッセージのフィルタ処理に関する項を参照してください。「ロガーの重大度の指定」も参照してください。

2. または、WebLogic Scripting Toolを使用して、メッセージ・ハンドラに対するログ・メッセージのフィルタ処理を構成します。『Oracle WebLogic Scripting Tool』の既存のドメインの構成に関する項を参照してください。

3. Java APIを使用して、ロガーからパブリッシュされるログ・メッセージをフィルタ処理します。「重大度などの条件によるメッセージのフィルタ処理」を参照してください。

Log4jとCommons Logging API

WebLogic Serverメッセージ・カタログとWebLogicロギング・サービスを使用して、ログ・メッセージを生成するアプリケーションを開発する場合は、XMLとJava APIに関する知識が必要です。開発者とシステム管理者の多くは、JavaロギングAPIの前身であるLog4jを使用しています。Log4jは、アプリケーション内にログ文を入れるために開発されたオープン・ソースのツールです。Log4jロギング機能は、Apache FoundationのJakartaプロジェクトによって開発されています。Log4jプロジェクトに関する詳細は、http://logging.apache.org/log4j/を参照してください。

WebLogic Serverでは、WebLogicロギング・サービスの構成にLog4jを使用できます。「WebLogicロギング・サービスでのLog4jの使い方」を参照してください。

Jakarta Commons Logging APIでは、基底のログ実装(Log4jまたはJavaロギングAPI)からユーザーを分離する抽象レイヤーが提供されています。WebLogic ServerにはCommons LogFactoryインタフェースの実装が用意されており、このAPIを使用してサーバーのLoggerにリクエストを発行できます。「WebLogicロギング・サービスでのCommons APIの使い方」を参照してください。

Log4jについて

Log4jには、ロガー、アペンダ、レイアウトの3つの主要コンポーネントがあります。以下の節では、Log4jについて簡単に説明します。

ロガー

Log4jには、Loggerクラスを定義します。1つのアプリケーションで、各々が一意の名前を持つ複数のロガーを作成できます。Log4jの一般的な使い方では、アプリケーションで、ログ・メッセージを出力する各アプリケーション・クラスのLoggerインスタンスが作成されます。ロガーはネームスペースの階層内に存在し、その階層における上位クラスから動作を継承します。

階層の任意のレベルで各ロガーの重大度を設定できます。「ロガーの重大度の指定」を参照してください。

アペンダ

Log4jには、ロギング出力の宛先を表すアペンダ(ハンドラ)を定義します。複数のアペンダを定義できます。たとえば、1つのアプリケーションで、ログ・メッセージを標準出力に送信するアペンダと、ファイルに書き込むアペンダを定義できます。個々のロガーを構成して、0または1つ以上のアペンダに書き込むように構成することもできます。一例としては、すべてのロギング・メッセージ(全レベル)をログ・ファイルに送信する一方で、標準出力にはERRORレベル・メッセージのみを送信する使い方があります。

レイアウト

Log4jには、ログ・メッセージのフォーマットを制御するレイアウトを定義します。各レイアウトにより、特定のメッセージ・フォーマットが指定されます。特定のレイアウトが各アペンダと関連付けられます。これにより、たとえばファイル出力とは違うログ・メッセージ・フォーマットを標準出力に対して指定できます。

WebLogicロギング・サービスでのLog4jの使い方

WebLogicロギング・サービスでは、Java Logging APIに基づいた実装がデフォルトで使用されます。ただし、WebLogicロギング・サービスでLog4jを再構成できます。

デフォルトのJavaロギングのかわりにLog4jを使用するには、次の手順を実行します。

1. log4j.jarファイルのコピーを取得します。WebLogic ServerではLog4jバージョンを配布していませんが、次の場所にあるApacheからダウンロードできます。
http://logging.apache.org/log4j/

2. log4j.jarファイルとWL_HOME/server/lib/wllog4j.jarファイルをサーバーのクラスパスにコピーします。この操作は、両ファイルをDOMAIN_NAME/libディレクトリにコピーするだけで実行できます。これで、サーバーの起動中に両ファイルは動的にサーバーのクラスパスに追加されます。
これらの.jarファイルを別の場所に格納する場合は、両方を同じディレクトリに格納し、サーバーのクラスパスに指定されているパスを、そのディレクトリに変更する必要があります。

3. 次のいずれかのメソッドを使用し、WebLogic Serverを構成してLog4jロギングを使用します。

- WebLogic Server管理コンソール。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのロギングの実装の指定に関する項を参照してください。

- WebLogic Serverを起動するJavaコマンドの-Dweblogic.log.Log4jLoggingEnabled=trueオプション。詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Server構成オプションに関する項を参照してください。

- LogMBean.isLog4jLoggingEnabled属性を有効にするWLSTスクリプト。詳細は、「WebLogic ServerロギングのLog4jを構成および有効にするためのWLSTの使い方」を参照してください。

Log4jが有効化されていると、weblogic.logging.log4j.Log4jLoggingHelperクラスから、サーバーが使用しているorg.apache.log4j.Loggerへの参照を取得できます。

Log4j Logger参照により、独自のカスタム・アペンダをアタッチしてサーバー・ログ・イベントを受け取ることができます。たとえば、サーバー・ログ・イベントをSyslogまたはWindowsイベント・ビューアに送るアペンダをアタッチできます。また、Logger参照を使用してWebLogicロギング・サービスにログ・リクエストを発行できます。この場合、デプロイされたアプリケーションでLog4jライブラリが使用可能になっている必要があります。

アプリケーションがWebLogicロギング・サービスと対話する必要がない場合、アプリケーションのLIBディレクトリにLog4jライブラリをパッケージ化します。サーバー・ロギングでは、引続きデフォルトのJavaロギング実装が使用されます。

例3-2は、Log4j Loggerの使い方を実証するLog4jコードのサンプルです。

WebLogic ServerロギングのLog4jを構成および有効にするためのWLSTの使い方

この項では、WLSTを使用して、デフォルトのJavaロギングのかわりにLog4jロギングを構成して有効にする方法について説明します。Javaロギングは、クライアント側およびサーバー側のロギングのデフォルトです。Log4jは、サーバー側でのみ使用できます。クライアント側ではサポートされていません。

例3-1は、管理サーバーでLog4j Loggerへのロギングを有効にするための、Log4jLoggingEnabledプロパティ値の設定を示します。このスクリプトの実行後、設定を有効化するにはサーバーを再起動する必要があります。

例3-1 Log4jロギングの有効化

#invoke WLST
C:\>java weblogic.WLST
#connect WLST to an Administration Server
wls:/offline> connect('username','password')
#navigate to the writable MBean configuration tree
wls:/mydomain/serverConfig> edit()
wls:/mydomain/edit> startEdit()
#set cmo to the server log config
wls:/mydomain/edit !> cd("Servers/myserver/Log/myserver")
#set log4j logging to true
wls:/mydomain/edit/Servers/myserver/Log/myserver !> cmo.setLog4jLoggingEnabled(true)
#save and activate the changes
wls:/mydomain/edit/Servers/myserver/Log/myserver !> save()
wls:/mydomain/edit/Servers/myserver/Log/myserver !> activate()

isLog4jLoggingEnabledの詳細は、Oracle WebLogic Server MBeanリファレンスのLogMBeanを参照してください。

管理サーバーのみに存在するドメインのLoggerだけでなく、サーバーのLoggerでもLog4jを使用できます。ドメインのLog4j Logger参照は、weblogic.logging.log4j.Log4jLoggingHelper.getLog4jDomainLogger()メソッドを呼び出すと利用可能になります。例3-2は、Log4jを使用するためのサーバーのLoggerと、デフォルトのJava Loggerを使用するためのドメインのLoggerを構成する方法を示します。

例3-2 Log4jのサンプル・コード

import org.apache.log4j.Logger;
import weblogic.logging.log4j.Log4jLoggingHelper;
import weblogic.logging.LoggerNotAvailableException;
/**
* This example shows how to use the Log4j server Logger.
*/
public class MyLog4jTest {
public void testWLSLog4j() {
try {
Logger logger = Log4jLoggingHelper.getLog4jServerLogger();
logger.addAppender(myAppender); // The Appender is configured using either the log4j props file or other custom mechanism.
logger.info("Test log message");
} catch(LoggerNotAvailableException lex) {
System.err.println("Unable to get a reference to the log4j Logger: "+
lex.getMessage())
}
}
}

例3-3はLog4jロギング構成のサンプルで、標準出力に対する重大度、およびサーバー・ログ・ファイルに送信されるメッセージに対するフィルタをconfig.xmlファイルで指定する方法を示します。

例3-3 ロギング構成のサンプル

<con:log>
<con:name>medrec</con:name>
<con:file-name>medrec.log</con:file-name>
<con:rotation-type>bySize</con:rotation-type>
<con:file-min-size>20000</con:file-min-size>
<con:log4j-logging-enabled>false</con:log4j-logging-enabled>
</con:log>
<con:log>
<con:name>MedRecServer</con:name>
<con:rotation-type>bySize</con:rotation-type>
<con:file-min-size>20000</con:file-min-size>
<con:stdout-severity>Debug</con:stdout-severity>
<con:stdout-filter>MyFilter</con:stdout-filter>
<con:log4j-logging-enabled>true</con:log4j-logging-enabled>
</con:log>
<con:log-filter>
<con:name>MyFilter</con:name>
<con:subsystem-name>HTTP</con:subsystem-name>
<con:subsystem-name>IIOP</con:subsystem-name>
<con:subsystem-name>JDBC</con:subsystem-name>
<con:subsystem-name>JMS</con:subsystem-name>
</con:log-filter>

構成するために、プログラムでLog4j Loggerおよびそのアペンダ(ハンドラ)およびレイアウト(フォーマッタ)にアクセスできます。「Log4jアペンダに対する重大度とフィルタの設定」を参照してください。

WLSTの使用に関する詳細は、『Oracle WebLogic Scripting Tool』のWebLogic Scripting Toolの使用に関する項を参照してください。

WebLogicロギング・サービスでのCommons APIの使い方

WebLogicロギング・サービスでは、WebLogicロギング・サービスで使用される基底ロギング実装にリクエストを送るCommons LogFactoryインタフェースとLogインタフェースを利用できます。

Commons Loggingを使用する場合は、WebLogic固有のCommonsクラス$MW_HOME/modules/com.bea.core.weblogic.commons.logging_1.3.0.0.jarをcommons-logging.jarファイルとともに以下のいずれかの場所に格納します。

- APP-INF/LIBディレクトリまたはWEB-INF/LIBディレクトリ

- DOMAIN_NAME/LIBディレクトリ

- サーバーのCLASSPATH

注意:

WebLogic Serverの配布キットにCommonsロギング・バージョンは含まれていません。

例3-4では、適切なシステム・プロパティを設定してCommonsインタフェースを使用する方法を示します。

注意:

Commonsインタフェースは、ここに示す手順でorg.apache.commons.logging.LogFactoryシステム・プロパティを使用して実装すると、サーバーで実行中のすべてのアプリケーション・インスタンスに対して実装されます。他のアプリケーションに影響を与えることなく、Commonsロギングを特定のアプリケーション・インスタンスに実装するには、JDKサービス検出メカニズムまたはcommons-logging.propertiesメカニズムを使用してLogFactoryを指定します(http://commons.apache.org/logging/apidocs/org/apache/commons/logging/LogFactory.html#getFactory()を参照)。

1. システム・プロパティorg.apache.commons.logging.LogFactoryをweblogic.logging.commons.LogFactoryImplに設定します。
このLogFactoryは、org.apache.commons.logging.Logインタフェースを実装するweblogic.logging.commons.LogFactoryImplのインスタンスを作成します。

2. LogFactoryから、名前を基準にCommons Logオブジェクトへの参照を取得します。
この名前は、ログ・ファイル内でサブシステム名として表示されます。

3. Logオブジェクトを使用して、ログ・リクエストをWebLogicロギング・サービスに発行します。
Commons Logインタフェース・メソッドは、オブジェクトを受け付けます。ほとんどの場合、これはメッセージ・テキストを含む文字列です。

Commons LogObjectは、コンストラクタでメッセージID、サブシステム名、および文字列メッセージ引数を取ります。org.apache.commons.logging (http://commons.apache.org/logging/apidocs/index.html)を参照してください。

4. weblogic.logging.commons.LogImplログ・メソッドは、メッセージをサーバー・ログに送ります。

例3-4 Commonsのサンプル・コード

import org.apache.commons.logging.LogFactory;
import org.apache.commons.logging.Log;

public class MyCommonsTest {
public void testWLSCommonsLogging() {
System.setProperty(LogFactory.FACTORY_PROPERTY,
"weblogic.logging.commons.LogFactoryImpl");
Log clog = LogFactory.getFactory().getInstance("MyCommonsLogger");
// Log String objects
clog.debug("Hey this is common debug");
clog.fatal("Hey this is common fatal", new Exception());
clog.error("Hey this is common error", new Exception());
clog.trace("Dont leave your footprints on the sands of time");
}
}

ロガーの重大度の指定

WebLogic Serverには、以下の重大度を指定できる階層ロガー・ツリーがあります。

- weblogic.i18ngenを使用してXML I18Nカタログから生成されたメッセージ・カタログ・ロガー・クラス。

- Commons org.apache.commons.logging.LogFactoryインタフェースのWebLogic Server実装が有効化されている場合のCommons Logging APIのインスタンス。

すべてのロガーは、ツリー内で最も近い親から重大度を継承します。しかし、特定のロガーの重大度を明示的に設定し、その最も近い親に設定されている重大度をオーバーライドすることができます。ロガーの重大度は管理コンソール、WLST、またはコマンド・ラインから設定できます。

WebLogic Serverサブシステム・ロガーの重大度の指定

メッセージ・カタログ・ロガーを使用している場合、特定のサブシステムから届くメッセージの重大度は、ルート・ロガーの重大度によって決まります。ただし、DeploymentServiceロガー、Securityロガー、EJBロガーなど、個々のサブシステム・ロガーのルート・ロガーの重大度はオーバーライドすることができます。たとえば、ルート・ロガーの重大度がCRITICALで、その重大度をSecurityサブシステム・ロガーについてはNOTICEに、EJBサブシステム・ロガーについてはWARNINGに設定するものとします。この設定は、管理コンソール、WLST、またはコマンド・ラインから行うことができます。

- 管理コンソールから、サーバーの「ロギング」→「一般」タブのロガーの重大度プロパティ・ボックスで次のエントリを作成します。各文字列はこのプロパティの各行に入力されます。つまり、各文字列の後で[Enter]キーを押して「保存」をクリックします。

Security=Notice
EJB=Warning

- WLSTの場合、setコマンドを使用して、LogMBeanのLoggerSeverityProperties属性の値を設定します(『Oracle WebLogic Scripting Tool』を参照)。

- コマンド・ラインの場合、起動コマンドで以下のパラメータを指定します。

-Dweblogic.Log.LoggerSeverityProperties="Security=Notice;EJB=Warning"

すべてのサブシステム名の完全なインデックスについては、『Oracle WebLogic Serverエラー・メッセージ・リファレンス』を参照してください。サブシステム名は大文字と小文字が区別されるため、この索引の「サブシステム」列に表示されているとおりに入力する必要があります。

Commons Logging APIロガーの重大度の指定

Commons Logging APIを使用する場合、ロガー名はJavaパッケージのドット表記法によるネーミング・ルールに従います。たとえば、ロガーが使用されているクラスの名前に応じて、a.b.FooLoggerまたはa.b.c.Barloggerなどのロガー名になります。この場合、それぞれのドット区切りの識別子は、ロガー・ツリーのノードとして表されます。この例の場合、ルート・ロガーの下に「a」という名前の子ノードがあり、「b」という名前の子ノードが、その親である「a」の下にあります。

ツリー内の任意のレベルにあるパッケージやロガーの重大度を構成することができます。たとえば、パッケージa.bの重大度をa.b=Infoと指定すると、そのパッケージのすべての子ノードから届くDEBUGメッセージおよびTRACEメッセージがブロックされます。しかし、子ノードの値を明示的に設定すると、親ノードの重大度をオーバーライドすることができます。たとえば、FooLoggerの重大度をa.b.FooLogger=Debugと指定すると、このロガーから届くすべてのログ・メッセージは許可されますが、a.b下のその他の子ノードについては、DEBUGメッセージおよびTRACEメッセージがフィルタ処理されます。

パッケージまたはロガーの重大度は、管理コンソール、WLST、またはコマンド・ラインで指定できます。

- 管理コンソールの場合、サーバーの「ロギング」>「全般」タブの「ロガー重大度プロパティ」ボックスに、以下のセミコロン区切りの文字列を入力します。

a.b=Info;a.b.FooLogger=Debug

- WLSTの場合、setコマンドを使用して、LogMBeanのLoggerSeverityProperties属性の値を設定します(『Oracle WebLogic Scripting Tool』を参照)。

- コマンド・ラインの場合、起動コマンドで以下のパラメータを指定します。

-Dweblogic.Log.LoggerSeverityProperties="a.b=Info;a.b.FooLogger=Debug"

ログ・ファイルのローテーション

デフォルトでは、WebLogic Serverインスタンスを開発モードで起動すると、サーバーではローカルのサーバー・ログ・ファイルがSERVER_NAME.log.nという名前に自動で変更(ローテーション)されます。以降のサーバー・セッションでは、ログ・メッセージは、そのファイル・サイズが500KBになるまで、SERVER_NAME.logに蓄積されます。

サーバー・ログ・ファイルがこのサイズに達するたびに、サーバーではログ・ファイルの名前が変更され、新しいメッセージを格納するための新しいSERVER_NAME.logが作成されます。デフォルトでは、ローテーションされたログ・ファイルは作成順に番号が付けられます(filenamennnnn)。filenameは、ログ・ファイルに構成された名前です。ローテーションされたログ・ファイルのファイル名に日付と時刻が含まれるように、サーバー・インスタンスを構成することもできます(server-name-%yyyy%-%mm%-%dd%-%hh%-%mm%.logなど)。

デフォルトでは、サーバー・インスタンスを本番モードで起動すると、ファイル・サイズが5000KBになるたびに、サーバーではサーバー・ログ・ファイルのローテーションが行われます。サーバーの起動時にはローカルのサーバー・ログ・ファイルはローテーションされません。サーバーの起動モードの変更に関する詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの本番モードへの変更に関する項を参照してください。

ログ・ファイルのローテーションに関するこれらのデフォルト設定は変更できます。たとえば、サーバーがログ・ファイルをローテーションするファイル・サイズを変更したり、時間間隔に基づいてログ・ファイルをローテーションするように構成したりできます。蓄積可能なローテーションするファイルの最大数を指定することもできます。ログ・ファイル数がこの制限に達すると、以降のファイル・ローテーションによって最も古いログ・ファイルが削除され、最新の接尾辞の付いた新しいログ・ファイルが作成されます。

注意:

WebLogic Serverでは、ログ・ファイルが大きくなり過ぎないように、500MBのしきい値サイズ制限を設定しており、それを超えると強制的にローテーションが行われます。

ログ・ファイル・ローテーションの設定に関する詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのログ・ファイルのローテーションに関する項を参照してください。

サーバー、ドメイン、またはHTTPアクセス・ログ・ファイルのローテーションをすぐに行うには、LogRuntime.forceLogRotation()メソッドを使用します。Oracle WebLogic Server MBeanリファレンスのLogRuntimeMBeanを参照してください。

例3-5のWLSTコマンドは、サーバー・ログ・ファイルのローテーションをすぐに行います。

例3-5 オン・デマンドのログ・ローテーション

#invoke WLST
C:\>java weblogic.WLST
#connect WLST to an Administration Server
wls:/offline> connect('username','password')
#navigate to the ServerRuntime MBean hierarchy
wls:/mydomain/serverConfig> serverRuntime()
wls:/mydomain/serverRuntime>ls()
#navigate to the server LogRuntimeMBean
wls:/mydomain/serverRuntime> cd('LogRuntime/myserver')
wls:/mydomain/serverRuntime/LogRuntime/myserver> ls()
-r--   Name                                         myserver
-r--   Type                                         LogRuntime
-r-x   forceLogRotation                             java.lang.Void :
#force the immediate rotation of the server log file
wls:/mydomain/serverRuntime/LogRuntime/myserver> cmo.forceLogRotation()
wls:/mydomain/serverRuntime/LogRuntime/myserver>

サーバーは即座にファイルのローテーションを行い、次のメッセージを出力します。

<Mar 2, 2005 3:23:01 PM EST> <Info> <Log Management> <BEA-170017> <The log file
C:\diablodomain\servers\myserver\logs\myserver.log will be rotated. Reopen the
log file if tailing has stopped. This can happen on some platforms like Windows.>
<Mar 2, 2005 3:23:01 PM EST> <Info> <Log Management> <BEA-170018> <The log file
has been rotated to C:\diablodomain\servers\myserver\logs\myserver.log00001. Log
messages will continue to be logged in C:\diablodomain\servers\myserver\logs\myserver.log.>

アーカイブされたログ・ファイルの場所の指定

デフォルトでは、ローテーションされたファイルはログ・ファイルと同じディレクトリに格納されます。アーカイブされたログ・ファイルの格納先に別のディレクトリを指定するには、管理コンソールを使用するか、コマンドラインからLogFileMBeanのLogFileRotationDirプロパティを設定します。Oracle WebLogic Server MBeanリファレンスのLogFileMBeanを参照してください。

次のコマンドでは、-Dweblogic.log.LogFileRotationDir Java起動オプションを使用して、アーカイブされたログ・ファイルのディレクトリを指定します。

java -Dweblogic.log.LogFileRotationDir=c:\foo
-Dweblogic.management.username=installadministrator
-Dweblogic.management.password=installadministrator weblogic.Server

ローテーションの通知

ログ・ファイルが指定のローテーションしきい値を超えると、サーバー・インスタンスはログ・ファイルがローテーションされることを知らせるログ・メッセージを出力します。次に、サーバー・インスタンスはログ・ファイルをローテーションし、古いメッセージが格納されたファイルの名前を知らせる追加メッセージを出力します。

たとえば、サイズに基づいてログ・ファイルのローテーションを行うように設定し、最小ローテーション・サイズとして500Kを指定した場合、サーバーはファイル・サイズが500Kを超えたと判断すると次のメッセージを出力します。

<Sept 20, 2004 1:51:09 PM EST> <Info> <Log Management> <MachineName>
<MedRecServer> <ExecuteThread: '2' for queue: 'weblogic.kernel.System'> <<WLS
Kernel>> <> <> <1095692939895> <BEA-170017> <The log file
C:\Oracle\Middleware\wlserver_12.1\samples\domains\medrec\servers\MedRecServer\logs\medrec.log will be rotated.
Reopen the log file if tailing has stopped. This can happen on some platforms like Windows.>

サーバーは即座にファイルのローテーションを行い、次のメッセージを出力します。

<Sept 20, 2004 1:51:09 PM EST> <Info> <Log Management> <MachineName>
<MedRecServer> <ExecuteThread: '2' for queue: 'weblogic.kernel.System'>
<<WLS Kernel>> <> <> <1095692939895> <BEA-170018> <The log file has been rotated
to C:\Oracle\Middleware\wlserver_12.1\samples\domains\medrec\servers\MedRecServer\logs\medrec.log00001.
Log messages will continue to be logged in C:\Oracle\Middleware\wlserver_12.1\samples\domains\medrec\servers\MedRecServer\logs\medrec.log.>

どちらのメッセージの重大度もINFOです。ローテーション前のメッセージのメッセージIDは常にBEA-170017で、ローテーション後のメッセージのメッセージIDは常にBEA-170018です。

標準Windowsファイル・システムなどのファイル・システムでは、読取り用に開いているファイルにロックが設定されます。このようなファイル・システムでは、アプリケーションでログ・ファイルの末尾を表示している場合、またはコマンド・プロンプトでDOS tail -fなどのコマンドを使用する場合、サーバーがログ・ファイルのローテーションを行った後にその操作が停止します。tail -fコマンドは、ファイルに行が追加されたときにメッセージを標準出力に出力します。詳細情報を参照するには、DOSプロンプトでhelp tailと入力してください。

アプリケーションでログ・ファイルの末尾を表示する場合、こうした状況を解決するには、サーバーがログ・ローテーション・メッセージを出力したときにアプリケーションに通知を行うJMXリスナーを作成します。アプリケーションは、このメッセージを受信したときに末尾表示の操作を再起動できます。JMXリスナーの例については、第5章「メッセージのサブスクライブ」を参照してください。

JVMの出力のリダイレクト

WebLogic Serverインスタンスが動作しているJVMは、メッセージを標準エラーおよび標準出力に送信します。サーバーとアプリケーション・コードは、ロギング・メカニズムを使用するかわりに、これらのストリームに直接書き込みます。構成オプションを使用すると、サーバーのターミナル・コンソールやログ・ファイルなど、登録されているすべてのログ宛先にJVMの出力をリダイレクトできます。有効にした場合、ログ・エントリは、重大度がNOTICEのメッセージとして表示されます。JVM出力のリダイレクトによって、ネイティブ・コードからの出力(たとえば、JVMからのスレッド・ダンプ)はキャプチャされません。

たとえば、JVMの標準出力メッセージをリダイレクトするには、次の手順に従います。

- 管理サーバーの起動時に、weblogic.Serverコマンドに次のJavaオプションを指定します。

-Dweblogic.log.RedirectStdoutToServerLogEnabled=true

『Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Server構成オプションに関する項を参照してください。

- 管理サーバーが起動したら、管理コンソールでJVM標準出力メッセージをリダイレクトします。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJVMの出力のリダイレクトに関する項を参照してください。

- WLSTを使用してLogMBeanのRedirectStdoutToServerLogEnabledプロパティの値を変更し、サーバーを再起動します。
例3-6のWLSTコマンドは、管理サーバーのJVM標準出力メッセージをサーバー・ロギング宛先にリダイレクトします。

例3-6 サーバー・ロギング宛先への標準出力のリダイレクト

C:\>java weblogic.WLST
wls:/offline> connect('username','password')
wls:/mydomain/serverConfig> edit()
wls:/mydomain/edit> startEdit()
wls:/mydomain/edit !> cd("Servers/myserver/Log/myserver")
wls:/mydomain/edit/Servers/myserver/Log/myserver !> cmo.setRedirectStdoutToServerLogEnabled(true)
wls:/mydomain/edit/Servers/myserver/Log/myserver !> save()
wls:/mydomain/edit/Servers/myserver/Log/myserver !> activate()

WLSTの使用に関する詳細は、『Oracle WebLogic Scripting Tool』のMBeanのナビゲート(WLSTオンライン)に関する項を参照してください。RedirectStdoutToServerLogEnabledの詳細は、Oracle WebLogic Server MBeanリファレンスのLogMBeanを参照してください。

4 WebLogic Serverログ・メッセージのフィルタ処理

この章では、WebLogicロギング・サービスが提供するフィルタ処理オプションを説明します。このため、どのメッセージがWebLogic Serverログ・ファイルと標準出力に書き込まれ、どのメッセージがクライアントJVMが管理するログ・ファイルと標準出力に書き込まれるのかを柔軟に指定できます。それらのフィルタ処理機能のほとんどは、 java.util.logging パッケージのJavaロギングAPIの実装です。

この章の内容は以下のとおりです。

- ロガーとハンドラの役割

- 重大度などの条件によるメッセージのフィルタ処理

- ロガーとハンドラに対する重大度の設定

- ロガーとハンドラのフィルタの設定

- Log4jアペンダに対する重大度とフィルタの設定

関連情報については、以下を参照してください。

- WebLogic Serverインスタンスに対するログ・フィルタの設定方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのログ・フィルタの作成に関する項を参照してください。

- メッセージ・ハンドラの作成方法およびサブスクライブ方法については、第5章「メッセージのサブスクライブ」

ロガーとハンドラの役割

WebLogic Serverメッセージ・カタログおよびNonCatalogLoggerでメッセージが生成されるとき、それらのメッセージはjava.util.logging.Loggerオブジェクトに配信されます。Loggerオブジェクトは、Loggerをサブスクライブしているメッセージ・ハンドラにメッセージをパブリッシュします。

WebLogic Serverでは、以下の3つの異なるコンテキストでLoggerオブジェクトおよびHandlerオブジェクトがインスタンス化されます(図4-1を参照)。

- WebLogicロギング・サービスを使用するクライアントJVMで。このクライアントLoggerオブジェクトは、クライアントJVMで動作するクライアント・アプリケーションから送信されるメッセージをパブリッシュします。
以下のハンドラが、クライアントJVMのLoggerオブジェクトをサブスクライブします。

- ConsoleHandler。クライアントJVMからのメッセージをクライアントの標準出力に出力します。
クライアントJVMで-Dweblogic.log.StdoutSeverityLevel Java起動オプションを使用すると、WebLogicロギング・サービスにより、ハンドラから標準出力に書き込まれるメッセージを制限するフィルタがこのハンドラ用に作成されます。『Oracle WebLogic Serverアプリケーション・ロギングのためのロギング・サービスの使用』のクライアント・アプリケーションからのメッセージの書込みに関する項を参照してください。

- FileStreamHandler。クライアントJVMからのメッセージをクライアントのログ・ファイルに書き込みます。

- WebLogic Serverの各インスタンスで。このサーバーLoggerオブジェクトは、サーバー・インスタンスで動作するサブシステムおよびアプリケーションから送信されるメッセージをパブリッシュします。
以下のハンドラが、サーバーLoggerオブジェクトをサブスクライブします。

- ConsoleHandler。メッセージをサーバーの標準出力に出力できるようにします。

- FileStreamHandler。サーバー・ログ・ファイルにメッセージを書き込みます。

- 内部ハンドラ。ドメイン・ログおよびJMXクライアントにメッセージをブロードキャストし、管理サーバーにメッセージをパブリッシュします。

- 管理サーバーはサーバーLoggerオブジェクトに加えてドメインLoggerオブジェクトも管理します。ドメインLoggerオブジェクトは、各管理対象サーバーのLoggerオブジェクトからメッセージを受信します。
以下のハンドラが、ドメインLoggerオブジェクトをサブスクライブします。

- FileStreamHandler。ドメイン・ログ・ファイルにメッセージを書き込みます。

図4-1 WebLogicロギング・サービスのコンテキスト

「図4-1 WebLogicロギング・サービスのコンテキスト」の説明

重大度などの条件によるメッセージのフィルタ処理

WebLogic Serverメッセージ・カタログおよびNonCatalogLoggerでメッセージが生成されるときには、メッセージの重大度がweblogic.logging.WLLevelオブジェクトに変換されます。WLLevelオブジェクトは、以下の値(影響の小さい方から大きい方の順で並んでいます)のいずれかを指定できます。

TRACE, DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY

Loggerオブジェクトは、デフォルトでは全レベルのメッセージをパブリッシュします。Loggerオブジェクトがパブリッシュする最低レベルのメッセージを設定するには、単純なLogger.setLevel APIを使用します。メッセージを受信すると、LoggerオブジェクトはそのメッセージのレベルとsetLevel APIで設定されたレベルを照合します。メッセージのレベルがLoggerのレベルより下である場合は、すぐに復帰します。メッセージのレベルがLoggerのレベルより上である場合、Loggerはそのメッセージを説明するWLLogRecordオブジェクトを割り当てます。

たとえば、LoggerオブジェクトのレベルをWARNINGに設定した場合、LoggerオブジェクトはWARNING、ERROR、CRITICAL、ALERT、またはEMERGENCYのメッセージのみをパブリッシュします。

Loggerオブジェクトがパブリッシュするメッセージをより細かく管理できるようにするために、フィルタを作成して設定することもできます。フィルタとは、WLLogRecordオブジェクトのデータを一連の条件と比較するクラスのことです。Loggerオブジェクトは、フィルタの条件を満たすWLLogRecordオブジェクトだけをパブリッシュします。たとえば、フィルタを使用してJDBCサブシステムからのメッセージのみパブリッシュするようにLoggerを構成できます。フィルタを作成するには、java.util.logging.Filterオブジェクトをインスタンス化し、Logger.setFilter APIを使用してそれをLoggerオブジェクトに設定します。

Loggerオブジェクトがパブリッシュするメッセージのレベルとフィルタを設定するかわりに(またはそれに加えて)、個々のメッセージ・ハンドラでレベルとフィルタを設定することもできます。

たとえば、LoggerがWARNINGレベル以上のメッセージをパブリッシュするように指定できます。その場合、さらに各ハンドラで以下のように設定できます。

- ConsoleHandlerにおいて、JDBC、JMS、およびEJBサブシステムからのALERTメッセージのみを選択するレベルとフィルタを設定します。設定するとJDBC、JMS、およびEJBサブシステムからのALERTメッセージのみが標準出力で表示されます。

- FileStreamHandlerにおいては、レベルまたはフィルタ条件を追加設定しません。LoggerオブジェクトはWARNINGレベル以上のメッセージのみをパブリッシュするように構成されているので、ログ・ファイルには、すべてのサブシステムからの、重大度がWARNING以上のすべてのメッセージが格納されます。

- 重大度がWARNING以上のすべてのメッセージを管理サーバーのドメイン全体のメッセージ・ログにパブリッシュします。

ロガーとハンドラに対する重大度の設定

管理コンソールとWLSTを使用すると、標準MBeanコマンドでHandlerオブジェクトに対する重大度を設定できます。Loggerオブジェクトに対して重大度を設定するには、Logger APIを使用できます。ロガーの重大度は、管理者コンソール、WLSTまたはコマンド・ラインからも設定することができます。「ロガーの重大度の指定」を参照してください。WLSクライアント(EJBやWeb Serviceクライアント等)に対してロガーおよびハンドラの重大度を構成するには、Java Logging APIを使用する必要があります。

ロガーに対する重大度の設定

Loggerオブジェクトの重大度を設定するには、次のように動作するクラスを作成します。

1. 以下のLoggingHelperメソッドの1つを呼び出します。

- getClientLogger (現在のコンテキストがクライアントJVMである場合)。

- getServerLogger (現在のコンテキストがサーバーJVMであり、かつローカル・サーバー・ログを管理するためにサーバーで使用されるLoggerオブジェクトを取得する必要がある場合)。

- getDomainLogger (現在のコンテキストが管理サーバーであり、かつドメイン・ログを管理するLoggerオブジェクトを取得する必要がある場合)。

LoggerHelperメソッドは、Loggerオブジェクトを返します。Loggerクラスについては、APIのドキュメント(http://docs.oracle.com/javase/6/docs/api/java/util/logging/Logger.html)を参照してください。

2. Logger.setLevel(Level level)メソッドを呼び出します。
WebLogic Server Loggerオブジェクトのレベルを設定するには、weblogic.logging.WLLevelクラスで定義されている値を渡す必要があります。WebLogic Serverは、java.util.logging.Levelを、対応するWLLevelにマップします。有効な値については、Oracle WebLogic Server APIリファレンスのweblogic.logging.WLLevelクラスに関する説明を参照してください。

例:

setLevel(WLLevel.ALERT)

ハンドラに対する重大度の設定

APIを使用してHandlerオブジェクトの重大度を設定するには、次のように動作するクラスを作成します(例4-1を参照)。

1. 以下のLoggingHelperメソッドの1つを呼び出します。

- getClientLogger (現在のコンテキストがクライアントJVMである場合)。

- getServerLogger (現在のコンテキストがサーバーJVMであり、かつローカル・サーバー・ログを管理するためにサーバーで使用されるLoggerオブジェクトを取得する必要がある場合)。

- getDomainLogger (現在のコンテキストが管理サーバーであり、かつドメイン・ログを管理するLoggerオブジェクトを取得する必要がある場合)。

LoggerHelperメソッドは、Loggerオブジェクトを返します。Loggerクラスについては、APIのドキュメント(http://docs.oracle.com/javase/6/docs/api/java/util/logging/Logger.html)を参照してください。

2. Logger.getHandlers()メソッドを呼び出します。
このメソッドは、Loggerオブジェクトに登録されているすべてのハンドラの配列を返します。

3. レベルを設定する必要のあるHandlerオブジェクトが見つかるまでハンドラの配列を検索します。
Handler.getClass().getName()を使用すると、現在の配列索引が示しているハンドラのタイプがわかります。

4. Handler.setLevel(Level level)メソッドを呼び出します。
WebLogic Server Handlerオブジェクトのレベルを設定するには、weblogic.logging.WLLevelクラスで定義されている値を渡す必要があります。WebLogic Serverは、java.util.logging.Levelを、対応するWLLevelにマップします。有効な値については、Oracle WebLogic Server APIリファレンスのweblogic.logging.WLLevelクラスに関する説明を参照してください。

例:

setLevel(WLLevel.ALERT)

例4-1 例: APIを使用したHandlerオブジェクトの重大度の設定

import java.util.logging.Logger;
import java.util.logging.Handler;
import weblogic.logging.LoggingHelper;
import weblogic.logging.WLLevel;
public class LogLevel {
public static void main(String[] argv) throws Exception {
Logger serverlogger = LoggingHelper.getServerLogger();
Handler[] handlerArray = serverlogger.getHandlers();
for (int i=0; i < handlerArray.length; i++) {
Handler h = handlerArray[i];
if(h.getClass().getName().equals
("weblogic.logging.ConsoleHandler")){
h.setLevel(WLLevel.ALERT);
}
}
}
}

管理コンソールまたはコマンド・ラインを使用すると、LogMBeanインタフェースでHandlerオブジェクトの重大度を構成できます。

- 重大度の設定方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのログ・メッセージのフィルタ処理に関する項を参照してください。

- 例4-2のWLSTコマンドは、標準出力ハンドラの重大度をINFOに設定します。

例4-2 標準出力ハンドラに対する重大度の設定

C:\>java weblogic.WLST
wls:/offline> connect('username','password')
wls:/mydomain/serverConfig> edit()
wls:/mydomain/edit> startEdit()
wls:/mydomain/edit !> cd("Servers/myserver/Log/myserver")
wls:/mydomain/edit/Servers/myserver/Log/myserver !> cmo.setStdoutSeverity("Info")
wls:/mydomain/edit/Servers/myserver/Log/myserver !> save()
wls:/mydomain/edit/Servers/myserver/Log/myserver !> activate()

WLSTの使用に関する詳細は、『Oracle WebLogic Scripting Tool』のWebLogic Scripting Toolの使用に関する項を参照してください。setStdoutSeverityの詳細は、Oracle WebLogic Server MBeanリファレンスのLogMBeanを参照してください。

ロガーとハンドラのフィルタの設定

Loggerオブジェクトでフィルタを設定した場合、そのフィルタはオブジェクトがどのメッセージをパブリッシュするのかを指定します。したがって、フィルタはLoggerオブジェクトに登録されているすべてのハンドラにも影響します。ハンドラでフィルタを設定した場合、そのフィルタはその特定のハンドラの動作にのみ影響します。

管理コンソールとWLSTを使用すると、標準MBeanコマンドでHandlerオブジェクトに対するフィルタを設定できます。Loggerオブジェクトにフィルタを設定するには、Logger APIを使用する必要があります。クライアント側ロギングの場合、フィルタはJavaロギングAPIでのみ設定できます。

フィルタを設定するには:

1. java.util.logging.Filterを実装するクラスを作成します。例4-3を参照してください。
そのクラスには、Filter.isLoggableメソッドと、受信メッセージを評価するロジックが必要です。ロジックがtrueと評価した場合、isLoggableメソッドはLoggerオブジェクトがそのメッセージをパブリッシュできるようにします。

2. Loggerオブジェクトが動作しているJVMのクラスパスにフィルタ・オブジェクトを配置します。

3. Loggerオブジェクトのフィルタを設定するには、次のように動作するクラスを作成します。

1. 以下のLoggingHelperメソッドの1つを呼び出します。

- getClientLogger (現在のコンテキストがクライアントJVMである場合)。

- getServerLogger (現在のコンテキストがサーバーJVMであり、かつローカル・サーバー・ログを管理するためにサーバーで使用されるLoggerオブジェクトをフィルタ処理する必要がある場合)。

- getDomainLogger (現在のコンテキストが管理サーバーであり、かつドメイン・サーバー・ログを管理するLoggerオブジェクトをフィルタ処理する必要がある場合)。

1. Logger.setFilter(Filter newFilter)メソッドを呼び出します。

4. APIを使用してHandlerオブジェクトのフィルタを設定するには、次のように動作するクラスを作成します。

1. 以下のLoggingHelperメソッドの1つを呼び出します。

- getClientLogger (現在のコンテキストがクライアントJVMである場合)。

- getServerLogger (現在のコンテキストがサーバーJVMであり、かつローカル・サーバー・ログを管理するためにサーバーで使用されるLoggerオブジェクトをフィルタ処理する必要がある場合)。

- getDomainLogger (現在のコンテキストが管理サーバーであり、かつドメイン・サーバー・ログを管理するLoggerオブジェクトをフィルタ処理する必要がある場合)。

1. レベルを設定する必要のあるHandlerオブジェクトが見つかるまでハンドラの配列を検索します。
Handler.getClass().getName()を使用すると、現在の配列索引が示しているハンドラのタイプがわかります。

2. Handler.setFilter(Filter newFilter)メソッドを呼び出します。

例4-3は、Deployerサブシステムからのすべてのメッセージを拒否するクラスのサンプルです。

例4-3 Java Loggerオブジェクトのフィルタのサンプル

import java.util.logging.Logger;
import java.util.logging.Filter;
import java.util.logging.LogRecord;
import weblogic.logging.WLLogRecord;
import weblogic.logging.WLLevel;
public class MyFilter implements Filter {
public boolean isLoggable(LogRecord record) {
if (record instanceof WLLogRecord) {
WLLogRecord rec = (WLLogRecord)record;
if (rec.getLoggerName().equals("Deployer")) {
return false;
} else {
return true;
}
} else {
return false;
}
}
}

管理コンソールまたはコマンド・ラインを使用すると、LogMBeanインタフェースでHandlerオブジェクトのフィルタを構成できます。

- WebLogic Serverインスタンスに対するログ・フィルタの設定方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのログ・フィルタの作成に関する項を参照してください。

- 例4-4のWLSTコマンドは、ドメイン・ログ・ブロードキャスタに対するフィルタを作成して設定します。

例4-4 ドメイン・ログ・フィルタの設定

C:\>java weblogic.WLST
wls:/offline> connect('username','password')
wls:/mydomain/serverConfig> edit()
wls:/mydomain/edit> startEdit()
wls:/mydomain/edit !> cmo.createLogFilter('myFilter')
wls:/mydomain/edit !> cd("Servers/myserver/Log/myserver")
wls:/mydomain/edit/Servers/myserver/Log/myserver !> cmo.setDomainLogBroadcastFilter(getMBean('/LogFilters/myFilter'))
wls:/mydomain/edit/Servers/myserver/Log/myserver !> save()
wls:/mydomain/edit/Servers/myserver/Log/myserver !> activate()

WLSTの使用に関する詳細は、『Oracle WebLogic Scripting Tool』のWebLogic Scripting Toolの使用に関する項を参照してください。setDomainLogBroadcastFilterの詳細は、Oracle WebLogic Server MBeanリファレンスのLogMBeanを参照してください。

ドメイン・ログ・メッセージのフィルタ処理

各管理対象サーバーからドメイン・ログにパブリッシュされるメッセージをフィルタ処理する場合は、管理コンソール (「ログ・フィルタの作成」を参照)またはWLST (例4-4を参照)を使用して、ドメイン・ログのログ・フィルタを作成できます。

ただし、サーバー・インスタンスのログ・ファイルを管理するLoggerオブジェクトでJavaロギングの重大度またはフィルタを設定すると、ドメイン・ログ・フィルタは無効となります。たとえば、サーバーのLoggerオブジェクトの重大度がWARNINGに設定されている場合、ドメイン・ログ・フィルタはWARNINGレベル以上のメッセージのみを受信します。

1つまたは複数のサーバーがドメイン・ログに送信するメッセージを変更するドメイン・ログ・フィルタを定義できます。デフォルトでは、重大度がNOTICE以上のすべてのメッセージが送られます。

注意:

重大度がDEBUGのメッセージは、フィルタを使用してもドメイン・ログには送信されません。

管理コンソールを使用したWebLogic Serverインスタンスのドメイン・ログ・フィルタの構成については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのログ・メッセージのフィルタ処理に関する項を参照してください。

Log4jアペンダに対する重大度とフィルタの設定

管理コンソールとWLSTを使用すると、標準MBeanコマンドでAppenderオブジェクトに対する重大度を設定できます。Loggerオブジェクトの重大度を設定するには、この項で説明するようにLoggerAPIを使用するか、「ロガーの重大度の指定」で説明するように管理コンソール、WLST、またはコマンドラインを使用して設定できます。

APIを使用してAppenderオブジェクトの重大度を設定するには、次のように動作するクラスを作成します。

1. 以下のLog4jLoggingHelperメソッド(例4-5を参照)の1つを呼び出します。

- getLog4jServerLogger (現在のコンテキストがサーバーJVMであり、かつローカル・サーバー・ログを管理するためにサーバーで使用されるLoggerオブジェクトを取得する必要がある場合)。

- getLog4jDomainLogger (現在のコンテキストが管理サーバーであり、かつドメイン・ログを管理するLoggerオブジェクトを取得する必要がある場合)。

2. logger.getAllAppenders()メソッドを呼び出します。

Enumeration e = logger.getAllAppenders();

このメソッドは、Loggerオブジェクトに登録されているすべてのアペンダを返します。

3. アペンダのリストを検索して、各アペンダ名を取得します。

4. app.setThreshold(WLLog4jLevel level)メソッドを呼び出します。
Log4j Appenderオブジェクトのレベルを設定するには、weblogic.logging.log4j.WLLog4jLevelクラスで定義されている値を渡す必要があります。WebLogic Serverは、org.apache.log4j.Levelを、対応するWLLevelにマップします。有効な値については、Oracle WebLogic Server APIリファレンスのweblogic.logging.WLLevelクラスに関する説明を参照してください。

フィルタを設定するには、org.apache.log4j.Filterを拡張するクラスを実装し、フィルタをアペンダに追加して、app.addFilter(Filter newFilter)メソッドを呼び出します。

例4-5は、以下のことを行うクラスのサンプルです。

- 重大度がWARNING以上のメッセージをサーバー・ログにパブリッシュします。

- 重大度がINFO以上のメッセージを標準出力にパブリッシュします。

- HTTPサブシステムからのINFOメッセージを拒否します。

例4-5 例: Log4jの重大度とフィルタの設定

package weblogic.logging.examples;
import java.util.Enumeration;
import org.apache.log4j.AppenderSkeleton;
import org.apache.log4j.Logger;
import org.apache.log4j.spi.Filter;
import org.apache.log4j.spi.LoggingEvent;
import weblogic.logging.LoggerNotAvailableException;
import weblogic.logging.NonCatalogLogger;
import weblogic.logging.Severities;
import weblogic.logging.log4j.AppenderNames;
import weblogic.logging.log4j.Log4jLoggingHelper;
import weblogic.logging.log4j.WLLog4jLevel;
import weblogic.logging.log4j.WLLog4jLogEvent;
/**
* This class sets a level and filter on a Log4j Appender.
*/
public class Log4jFilterExamplesStartup {
public static void main(String[] args) {
try {
System.out.println("Invoked the log4j filter example startup class");
Logger logger = Log4jLoggingHelper.getLog4jServerLogger();
Enumeration e = logger.getAllAppenders();
while (e.hasMoreElements()) {
AppenderSkeleton app = (AppenderSkeleton) e.nextElement();
String name = app.getName();
if (name == null) continue;
if (name.equals(AppenderNames.LOG_FILE_APPENDER)) {
// Set the threshold level of messages going to the log file to WARNING
// This will result in NOTICE, INFO, DEBUG, and TRACE messages being
// suppressed from going to the server log file
app.setThreshold(WLLog4jLevel.WARN);
System.out.println("Set WARNING level on the log file appender");
} else if (name.equals(AppenderNames.STDOUT_APPENDER)) {
// Set level to INFO on the stdout filter
app.setThreshold(WLLog4jLevel.INFO);
// First clear the existing filters on the appender
app.clearFilters();
// Add a filter to block INFO messages from the HTTP subsystem
app.addFilter(new MyFilter());
}
}
// Now test the filter
NonCatalogLogger nc = new NonCatalogLogger("MyFilterTest");
nc.info("INFO messages will not be published to the file but to stdout");
nc.warning("WARNINFG messages will be published to the file and stdout");

} catch(LoggerNotAvailableException lex) {
System.err.println("Log4j logger is not available on this server
}
}
/**
* Deny messages from the HTTP subsystem of level INFO
*/
private static class MyFilter extends Filter {
public int decide(LoggingEvent event) {
if (event instanceof WLLog4jLogEvent) {
WLLog4jLogEvent wlsEvent = (WLLog4jLogEvent)event;
if (wlsEvent.getSubsystem().equals("HTTP")
&& wlsEvent.getSeverity() == Severities.INFO) {
return DENY;
}
}
return ACCEPT;
}
}
}

5 メッセージのサブスクライブ

この章では、メッセージ・ハンドラの作成とサブスクライブについて説明します。WebLogic Serverメッセージ・カタログおよび NonCatalogLogger でメッセージが生成されるとき、それらのメッセージは java.util.logging.Logger オブジェクトに配信されます。Loggerオブジェクトは、メッセージを説明するWLLogRecordオブジェクトを割り当て、Loggerをサブスクライブしているすべてのメッセージ・ハンドラにそのWLLogRecordをパブリッシュします。

この章の内容は以下のとおりです。

- メッセージ・ハンドラの概要

- ハンドラの作成とサブスクライブ: 主な手順

- 例: サーバーJVMでのメッセージのサブスクライブ

- 例: Log4jアペンダ・クラスの実装

- Javaロギング・ハンドラとJMXリスナーの比較

WebLogic Serverのロガーおよびハンドラの詳細は、「ロガーとハンドラの役割」を参照してください。

メッセージ・ハンドラの概要

WebLogic Serverは、ログ・メッセージを受信して出力するメッセージ・ハンドラをインスタンス化し、サブスクライブさせます。独自のメッセージ・ハンドラを作成して、WebLogic ServerのLoggerオブジェクトをサブスクライブするようにもできます(図5-1を参照)。

図5-1 ハンドラのサブスクライブ

「図5-1 ハンドラのサブスクライブ」の説明

たとえば、アプリケーションがクライアントJVMで動作しており、そのアプリケーションがアプリケーションの生成するメッセージをリスニングするようにする場合は、ハンドラを作成し、そのハンドラをクライアントJVMのLoggerオブジェクトにサブスクライブすることができます。アプリケーションが特定サブシステムの障害を知らせるログ・メッセージを受信した場合、そのアプリケーションは以下のようなアクションを実行できます。

- WebLogic Serverの管理者にログ・メッセージを電子メールで送信します。

- 自身またはそのサブシステムを終了または再起動します。

注意:

ユーザー独自のメッセージ・ハンドラを作成する場合は、サーバーの初期化が完了して実行状態になる前に、WebLogic Serverプロセスで実行されるカスタム・コードを実行しないように注意します。場合によっては、初期化中のサーバー・サービスにカスタム・コードが干渉する場合があります。たとえば、IIOPサーバー・サービスの初期化の前にPortableRemoteObjectを使用する発信RMI呼出しを行うカスタム・ログ・ハンドラは、サーバーの起動が失敗する原因になる場合があります。

ハンドラの作成とサブスクライブ: 主な手順

作成し、Loggerオブジェクトをサブスクライブさせたハンドラでは、そのLoggerの重大度とフィルタ基準を満たすすべてのメッセージが受信されます。ハンドラでは、Loggerがパブリッシュする特定のメッセージだけに応答するように重大度とフィルタ基準を追加で指定することもできます。

ハンドラを作成してサブスクライブさせるには:

1. 以下の最小限のインポート文が含まれるハンドラ・クラスを作成します。

import java.util.logging.Handler;
import java.util.logging.LogRecord;
import java.util.logging.ErrorManager;
import weblogic.logging.WLLogRecord;
import weblogic.logging.WLLevel;
import weblogic.logging.WLErrorManager;
import weblogic.logging.LoggingHelper;

2. ハンドラ・クラスで、java.util.logging.Handlerを拡張します。

3. ハンドラ・クラスで、Handler.publish(LogRecord record)メソッドを実装します。
このメソッドは次のように機能します。

1. 受信したLogRecordオブジェクトをWLLogRecordオブジェクトとしてキャストします。

2. ハンドラで設定されているフィルタを適用します。

3. WLLogRecordオブジェクトがフィルタの基準を満たしている場合は、WLLogRecordのメソッドを使用してメッセージからデータを取得します。

4. 必要に応じて、メッセージのデータを1つまたは複数のリソースに書き込みます。

4. ハンドラ・クラスで、Handler.flushメソッドとHandler.closeメソッドを実装します。
リソースと連係して機能するハンドラはすべて、flushメソッド(バッファされた出力をフラッシュするため)およびcloseメソッド(開いているリソースを閉じるため)を実装する必要があります。

親Loggerオブジェクトが閉じると、すべてのハンドラでHandler.closeメソッドが呼び出されます。closeメソッドは、flushメソッドを呼び出してからそれ独自のロジックを実行します。

5. Handlerオブジェクトが受信するメッセージのタイプを指定するフィルタ・クラスを作成します。「ロガーおよびハンドラのフィルタの設定」を参照してください。

6. 次のいずれかのLoggingHelperメソッドを呼び出すクラスを作成します。

- getClientLogger (現在のコンテキストがクライアントJVMである場合)。

- getServerLogger (現在のコンテキストがサーバーJVMであり、サーバーのLoggerオブジェクトにハンドラをアタッチする必要がある場合)。

- getDomainLogger (現在のコンテキストが管理サーバーであり、ドメインのLoggerオブジェクトにハンドラをアタッチする必要がある場合)。
LoggingHelper.getDomainLogger()は、ドメイン・ログを管理するLoggerオブジェクトを取得します。カスタム・ハンドラにこのロガーをサブスクライブさせて、単一の場所にある全サーバーからのログ・メッセージを処理できます。

7. このクラスで、Logger.addHandler(Handler myHandler)メソッドを呼び出します。

8. 省略可能です。Logger.setFilter(Filter myFilter)メソッドを呼び出してフィルタを設定します。

例: サーバーJVMでのメッセージのサブスクライブ

この例では、JDBCデータ・ソースに接続し、メッセージをデータベース表に挿入するSQL文を発行するハンドラを作成します。この例では、以下のクラスを実装します。

- Handlerクラス。「例: ハンドラ・クラスの実装」を参照してください。

- Filterクラス。「ロガーおよびハンドラのフィルタの設定」を参照してください。

- ハンドラおよびフィルタにサーバーのLoggerクラスをサブスクライブさせるクラス。「例: ロガー・クラスのサブスクライブ」を参照してください。

例: ハンドラ・クラスの実装

例5-1のHandlerクラスの例では、次のようにしてデータベースにメッセージを書き込みます。

1. java.util.logging.Handlerを拡張します。

2. javax.naming.InitialContextオブジェクトを作成し、Context.lookupメソッドを呼び出してmyPoolDataSourceというデータ・ソースをルックアップします。

3. javax.sql.DataSource.getConnectionメソッドを呼び出して、データ・ソースとの接続を確立します。

4. setErrorManagerメソッドを実装します。このメソッドは、このハンドラのjava.util.logging.ErrorManagerオブジェクトを作成します。
このハンドラでエラーが生じると、エラー・マネージャのerrorメソッドが呼び出されます。この例のerrorメソッドは次のように機能します。

1. エラー・メッセージを標準エラーに出力します。

2. LoggingHelper.getServerLogger().removeHandler(MyJDBCHandler.this)を呼び出してハンドラを無効にします。

注意:

独立したクラス・ファイルでErrorManagerクラスを定義するかわりに、この例ではErrorManagerが無名内部クラスとして内包されています。

エラー・マネージャの詳細は、java.util.logging.ErrorManagerクラスのAPIドキュメント(http://docs.oracle.com/javase/6/docs/api/java/util/logging/ErrorManager.html)を参照してください。

5. Handler.publish(LogRecord record)メソッドを実装します。このメソッドは、次のことを実行します。

1. 受信した各LogRecordオブジェクトをWLLogRecordオブジェクトとしてキャストします。

2. isLoggableメソッドを呼び出して、ハンドラに設定されているフィルタを適用します。isLoggableメソッドは、このハンドラ・クラスの最後に定義されています。

3. WLLogRecordのメソッドを使用して、メッセージからデータを取得します。
WLLogRecordメソッドの詳細は、Oracle WebLogic Server APIリファレンスのweblogic.logging.WLLogRecordクラスに関する説明を参照してください。

4. メッセージのデータをSQL prepareStatementとしてフォーマットし、データベースの更新を実行します。
この例で使用される表のスキーマは次のとおりです。

表5-1 サンプル・ハンドラのデータベース表のスキーマ

名前

Null?

型

MSGID

n/a

CHAR(25)

LOGLEVEL

n/a

CHAR(25)

SUBSYSTEM

n/a

CHAR(50)

MESSAGE

n/a

CHAR(1024)

6. flushメソッドを呼び出して、接続をフラッシュします。

7. Handler.closeメソッドを実装して、データ・ソースとの接続を閉じます。
親Loggerオブジェクトが閉じると、Handler.closeメソッドが呼び出されます。このメソッドは、Handler.flushメソッドを呼び出してからそれ独自のロジックを実行します。

例5-1に、この節で説明した手順を示します。

例5-1 例: ハンドラ・クラスの実装

import java.util.logging.Handler;
import java.util.logging.LogRecord;
import java.util.logging.Filter;
import java.util.logging.ErrorManager;
import weblogic.logging.WLLogRecord;
import weblogic.logging.WLLevel;
import weblogic.logging.WLErrorManager;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.sql.DataSource;
import java.sql.Connection;
import java.sql.SQLException;
import java.sql.Statement;
import java.sql.PreparedStatement;
import weblogic.logging.LoggingHelper;
public class MyJDBCHandler extends Handler {
private Connection con = null;
private PreparedStatement stmt = null;
public MyJDBCHandler() throws NamingException, SQLException {
InitialContext ctx = new InitialContext();
DataSource ds = (DataSource)ctx.lookup("myPoolDataSource");
con = ds.getConnection();
PreparedStatement stmt = con.prepareStatement
setErrorManager(new ErrorManager() {
public void error(String msg, Exception ex, int code) {
System.err.println("Error reported by MyJDBCHandler "
+ msg + ex.getMessage());
//Removing any prior istantiation of this handler
LoggingHelper.getServerLogger().removeHandler(
MyJDBCHandler.this);
}
});
}
public void publish(LogRecord record) {
WLLogRecord rec = (WLLogRecord)record;
if (!isLoggable(rec)) return;
try {
("INSERT INTO myserverLog VALUES (?, ?, ? ,?)");
stmt.setEscapeProcessing(true);
stmt.setString(1, rec.getId());
stmt.setString(2, rec.getLevel().getLocalizedName());
stmt.setString(3, rec.getLoggerName());
stmt.setString(4, rec.getMessage());
stmt.executeUpdate();
flush();
} catch(SQLException sqex) {
reportError("Error publihsing to SQL", sqex,
ErrorManager.WRITE_FAILURE);
}
}
public void flush() {
try {
con.commit();
} catch(SQLException sqex) {
reportError("Error flushing connection of MyJDBCHandler",
sqex, ErrorManager.FLUSH_FAILURE);
}
}
public boolean isLoggable(LogRecord record) {
Filter filter = getFilter();
if (filter != null) {
return filter.isLoggable(record);
} else {
return true;
}
}
public void close() {
try {
con.close();
} catch(SQLException sqex) {
reportError("Error closing connection of MyJDBCHandler",
sqex, ErrorManager.CLOSE_FAILURE);
}
}
}

例: ロガー・クラスのサブスクライブ

例5-2のLoggerクラスの例では、以下のことを行います。

1. LoggingHelper.getServerLoggerメソッドを呼び出して、Loggerオブジェクトを取得します。

2. Logger.addHandler(Handler myHandler)メソッドを呼び出します。

3. Logger.getHandlersメソッドを呼び出して、Loggerオブジェクトのすべてのハンドラを取得します。

4. myHandlerが見つかるまで配列を検索します。

5. Handler.setFilter(Filter myFilter)メソッドを呼び出します。

サーバーが起動するたびにハンドラとフィルタがサーバーのLoggerオブジェクトをサブスクライブするようにする場合は、このクラスをWebLogic Server起動クラスとしてデプロイします。起動クラスの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのカスタム・クラスを使用したサーバーの構成に関する項を参照してください。

例5-2 例: ロガー・クラスのサブスクライブ

import java.util.logging.Logger;
import java.util.logging.Handler;
import java.util.logging.Filter;
import java.util.logging.LogRecord;
import weblogic.logging.LoggingHelper;
import weblogic.logging.FileStreamHandler;
import weblogic.logging.WLLogRecord;
import weblogic.logging.WLLevel;
import java.rmi.RemoteException;
import weblogic.jndi.Environment;
import javax.naming.Context;
public class LogConfigImpl {
public void configureLogger() throws RemoteException {
Logger logger = LoggingHelper.getServerLogger();
try {
Handler h = null;
h = new MyJDBCHandler();
logger.addHandler(h);
h.setFilter(new MyFilter());
} catch(Exception nmex) {
System.err.println("Error adding MyJDBCHandler to logger "
+ nmex.getMessage());
logger.removeHandler(h);
}
}
public static void main(String[] argv) throws Exception {
LogConfigImpl impl = new LogConfigImpl();
impl.configureLogger();
}
}

例: Log4jアペンダ・クラスの実装

例5-3のAppenderクラスの例では、JDBCデータ・ソースに接続し、メッセージをデータベース表に挿入するSQL文を発行します。

1. AppenderSkeltonを拡張します。

2. javax.naming.InitialContextオブジェクトを作成し、Context.lookupメソッドを呼び出してMyDataSourceというデータ・ソースをルックアップします。

3. javax.sql.DataSource.getConnectionメソッドを呼び出して、データ・ソースとの接続を確立します。

4. append(LoggingEvent event)メソッドを実装します。このメソッドは、次のことを実行します。

1. 受信した各LoggingEventオブジェクトをWLLog4jLogEventとしてキャストします。

2. WLLog4jLogEventのメソッドを使用して、メッセージからデータを取得します。
WLLog4jLogEventメソッドの詳細は、Oracle WebLogic Server APIリファレンスのweblogic.logging.log4j.WLLog4jLogEventクラスに関する説明を参照してください。

3. SQL prepareStatementを作成し、ロギング・イベントを受け取るたびにデータベースを更新します。
この例で使用される表のスキーマは次のとおりです。

表5-2 サンプルLog4jアペンダのデータベース表のスキーマ

名前

Null?

型

SERVERNAME

n/a

CHAR(30)

MSGID

n/a

CHAR(20)

SEVERITYLEVEL

n/a

CHAR(20)

LOGGERNAME

n/a

CHAR(100)

MESSAGE

n/a

VARCHAR(2048)

TIMESTAMP

n/a

LONG

5. closeメソッドを実装して、データ・ソースとの接続を閉じます。

例5-3に、この節で説明した手順を示します。

例5-3 例: サンプルLog4jアペンダの起動

package weblogic.logging.examples;
import java.util.Enumeration;
import org.apache.log4j.AppenderSkeleton;
import org.apache.log4j.PropertyConfigurator;
import org.apache.log4j.Logger;
import org.apache.log4j.spi.Filter;
import org.apache.log4j.spi.LoggingEvent;
import weblogic.logging.LoggerNotAvailableException;
import weblogic.logging.NonCatalogLogger;
import weblogic.logging.Severities;
import weblogic.logging.log4j.AppenderNames;
import weblogic.logging.log4j.Log4jLoggingHelper;
import weblogic.logging.log4j.WLLog4jLevel;
import weblogic.logging.log4j.WLLog4jLogEvent;
import org.apache.log4j.jdbc.JDBCAppender;
import java.sql.Connection;
import java.sql.SQLException;
import javax.naming.InitialContext;
import weblogic.logging.log4j.WLLog4jLogEvent;
import weblogic.logging.Severities;
/**
* This class sets up a Log4j Appender as a listener to the
* Server Logger for log events.
*/
public class Log4jAppenderExampleStartup {
public static void main(String[] args) {
try {
System.out.println("Invoked the appender example startup class");
Logger serverLogger = Log4jLoggingHelper.getLog4jServerLogger();
// Configure the JDBC appender
MyJDBCAppender jdbcAppender = new MyJDBCAppender();
// Now add the JDBC appender to the server logger
serverLogger.addAppender(jdbcAppender);
// Now test the filter
NonCatalogLogger nc = new NonCatalogLogger("MyAppenderTest");
nc.info("Test INFO message");
nc.warning("Test WARNING message");
} catch(Exception ex) {
System.err.println("Init failure " + ex.getMessage());
ex.printStackTrace();
}
}
private static class MyJDBCAppender extends AppenderSkeleton {
private Connection connection;
private java.sql.PreparedStatement stmt;
public MyJDBCAppender() throws javax.naming.NamingException, SQLException {
InitialContext ctx = new InitialContext();
javax.sql.DataSource ds
= (javax.sql.DataSource) ctx.lookup ("MyDataSource");
connection = ds.getConnection();
// Table schema creation SQL command
// Create table SERVER_LOG (server_name char(30),msg_id char(20),
// severity_level char(20),logger_name char(100),message varchar(2048),
// timestamp long);
stmt = connection.prepareStatement("INSERT INTO SERVER_LOG VALUES (?, ?, ?, ?, ?, ?)");
stmt.setEscapeProcessing(true);
connection.setAutoCommit(true);
}
// Override execute method
public void append(LoggingEvent event) {
WLLog4jLogEvent wlsEvent = (WLLog4jLogEvent) event;
try {
stmt.setString(1, wlsEvent.getServerName());
stmt.setString(2, wlsEvent.getId());
stmt.setString(3, Severities.severityNumToString(wlsEvent.getSeverity()));
stmt.setString(4, wlsEvent.getSubsystem());
stmt.setString(5, wlsEvent.getMessage().toString());
stmt.setLong(6, wlsEvent.getTimestamp());
stmt.executeUpdate();
} catch (SQLException e) {
System.err.println(e.toString());
}
}
public boolean requiresLayout() {
return false;
}
public void close() {
try {
stmt.close();
connection.close();
} catch(SQLException sqlex) {
System.err.println("Error closing JDBC appender");
sqlex.printStackTrace();
}
}
}
}

Javaロギング・ハンドラとJMXリスナーの比較

WebLogic Server 8.1より前のリリースで、WebLogicロギング・サービスからメッセージを受信するには、Java Management Extensions (JMX)リスナーを作成して、それをLogBroadcasterRuntimeMBeanに登録する方法しかありませんでした。WebLogic Server 8.1では、Javaロギング・ハンドラを使用してログ・メッセージを受信(サブスクライブ)することもできます。

Javaロギング・ハンドラでもJMXリスナーでも同様の結果が得られますが、JavaロギングAPIにはFormatterクラスがあり、Handlerオブジェクトはこのクラスを使用して受信したメッセージをフォーマットできます。JMXでは、メッセージをフォーマットするこのようなAPIは提供されません。フォーマッタの詳細は、FormatterクラスのAPIドキュメント(http://docs.oracle.com/javase/6/docs/api/java/util/logging/Formatter.html)を参照してください。

さらに、JavaロギングHandler APIはJMX APIよりも使いやすく、過程が直接的です。たとえば、次のコードはJavaロギングLoggerオブジェクトを取得し、ハンドラにそのオブジェクトをサブスクライブさせます。

Logger logger = LoggingHelper.getServerLogger();
Handler h = null;
h = new MyJDBCHandler();
logger.addHandler(h)

JMXリスナーを登録して同様の結果を得るには、例5-4のようなコードを使用する必要があります。コードでMBeanHomeインタフェース、RemoteMBeanServerインタフェース、およびLogBroadcasterRuntimeMBeanをルックアップし、それからリスナーを登録します。

ローカル・マシンのログ・メッセージのサブスクライブにはJavaロギング・ハンドラ、リモート・マシンからのログ・メッセージの受信にはJMXリスナーが適しています。すでにモニターにJMXを使用しており、ログ・メッセージのフォーマットを変更したりログ・メッセージを別の出力に転送したりせずに単純にリスニングする場合は、JMXリスナーを使用します。それ以外の場合は、Javaロギング・ハンドラを使用します。

例5-4 JMXリスナーの登録

MBeanHome home = null;
RemoteMBeanServer rmbs = null;
//domain variables
String url = "t3://localhost:7001";
String serverName = "Server1";
String username = "weblogic";
String password = "weblogic";
//Using MBeanHome to get MBeanServer.
try {
Environment env = new Environment();
env.setProviderUrl(url);
env.setSecurityPrincipal(username);
env.setSecurityCredentials(password);
Context ctx = env.getInitialContext();
//Getting the Administration MBeanHome.
home = (MBeanHome) ctx.lookup(MBeanHome.ADMIN_JNDI_NAME);
System.out.println("Got the Admin MBeanHome: " + home );
rmbs = home.getMBeanServer();
} catch (Exception e) {
System.out.println("Caught exception: " + e);
}
try {
//Instantiating your listener class.
MyListener listener = new MyListener();
MyFilter filter = new MyFilter();
//Construct the WebLogicObjectName of the server's
//log broadcaster.
WebLogicObjectName logBCOname = new
WebLogicObjectName("TheLogBroadcaster",
"LogBroadcasterRuntime", domainName, serverName);
//Passing the name of the MBean and your listener class to the
//addNotificationListener method of MBeanServer.
rmbs.addNotificationListener(logBCOname, listener, filter, null);
} catch(Exception e) {
System.out.println("Exception: " + e);
}
}

Copyright © 2007, 2012, Oracle and/or its affiliates. All rights reserved.