1. Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタリング
  2. WebLogicロギング・サービスの構成

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

Oracle WebLogic Serverで特定のイベントのログ・メッセージを受信するようにロギング出力を構成することができます。WebLogic Server管理コンソール、WLSTコマンドまたはJavaロギングAPIを使用して、ロギング出力を構成します。

この章では、WebLogic Serverのロギングのシナリオと基本的な構成タスクについて説明します。

メッセージのフィルタリングとサブスクライブの詳細な手順については、「WebLogic Serverログ・メッセージのフィルタリング」および「メッセージのサブスクライブ」を参照してください。

構成のシナリオ

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

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

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

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

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

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

ロギング・プロセスでは、サブスクライブされたハンドラまたはアペンダにロギング・リクエストがディスパッチされます。ロギングの量の制御は、LogMBeanインタフェースを介して行えます。

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

以前のバージョンのWebLogic Serverでは、システム管理者と開発者は、ロガーとハンドラにプログラム的なアクセスしかできませんでした。このリリースのWebLogic Serverでは、MBeanを使用してハンドラを構成できるので、最も基本的なロギング構成のコードを記述する必要はありません。WebLogic Server管理コンソールと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/8/docs/api/java/util/logging/LoggingPermission.htmlを参照)が必要です。本番環境では、現在のユーザーに対してjava.util.logging.LoggingPermissionを有効にしたJavaセキュリティ・マネージャの使用をお薦めします。

『WebLogicセキュリティ・サービスによるアプリケーションの開発』のJavaセキュリティ・マネージャを使用したWebLogicリソースの保護に関する項を参照してください。Javaロギングの概要(http://docs.oracle.com/javase/8/docs/technotes/guides/logging/overview.html)も参照してください。

ログの重大度の使用

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

Trace、Debug、Info、Notice、Warning、Error、Critical、Alert、Emergency

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

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

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

ログ・フィルタの使用

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

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

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

ロギングの構成タスク: 主なステップ

WebLogic Serverが生成するログ・メッセージを構成およびフィルタ処理できます。WebLogic Server管理コンソール、WebLogic Scripting ToolまたはJava APIを使用できます。

次のステップに、ログ・メッセージを構成およびフィルタ処理できる方法を示します。このステップの詳細は、関連ドキュメントおよびこのガイドの後のセクションで説明します。

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

    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を使用して、メッセージ・ハンドラに対するログ・メッセージのフィルタ処理を構成します。『WebLogic Scripting Toolの理解』の既存のドメインの構成に関する項を参照してください。

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

Log4jとCommons Logging API

Log4jは、JavaロギングAPIの前身です。アプリケーション内にログ文を入れるために開発されたオープン・ソースのツールです。

ノート:

Javaロギングの代替としてWebLogicロギング・サービスでLog4jを使用することは、WebLogic Server 12.1.3では非推奨です。

WebLogic Serverメッセージ・カタログとWebLogicロギング・サービスを使用して、ログ・メッセージを生成するアプリケーションを開発する場合は、XMLとJava APIに関する知識が必要です。多くの開発者およびシステム管理者はLog4jを使用します。Log4jロギング機能は、Apache FoundationのJakartaプロジェクトによって開発されています。http://logging.apache.org/log4j/で、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には、Loggerクラスを定義します。1つのアプリケーションで、各々が一意の名前を持つ複数のロガーを作成できます。Log4jの一般的な使い方では、アプリケーションで、ログ・メッセージを出力する各アプリケーション・クラスのLoggerインスタンスが作成されます。ロガーはネームスペースの階層内に存在し、その階層における上位クラスから動作を継承します。

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

アペンダ

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

レイアウト

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

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

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

ノート:

Javaロギングの代替としてWebLogicロギング・サービスでLog4jを使用することは、WebLogic Server 12.1.3では非推奨です。
デフォルトのJavaロギングのかわりにLog4jを使用するには、次のステップを実行します:
  1. log4j.jarファイルのコピーを取得します。WebLogic ServerではLog4jバージョンを配布していませんが、次の場所にあるApacheからダウンロードできます。
  2. log4j.jarファイルとWL_HOME/server/lib/wllog4j.jarファイルをサーバーのクラスパスにコピーします。この操作は、両ファイルをDOMAIN_NAME/libディレクトリにコピーするだけで実行できます。これで、サーバーの起動中に両ファイルは動的にサーバーのクラスパスに追加されます。

    これらの.jarファイルを別の場所に格納する場合は、両方を同じディレクトリに格納し、サーバーのクラスパスに指定されているパスを、そのディレクトリに変更する必要があります。

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

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

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

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

Log4j Loggerの使い方を示すLog4jコード例の詳細は、「WebLogic ServerロギングのLog4jを構成および有効にするためのWLSTの使い方」を参照してください。

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

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

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

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

#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()

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

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())
    }
  }
}

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

<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アペンダに対する重大度とフィルタの設定」を参照してください。

『WebLogic Scripting Toolの理解』の「WebLogic Scripting Toolの使用」を参照してください。

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

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

Commons Loggingを使用する場合は、WebLogic固有のCommonsクラス($WL_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ロギング・バージョンは含まれていません。

例2-1では、適切なシステム・プロパティを設定して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ログ・メソッドは、メッセージをサーバー・ログに送ります。

例2-1 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のインスタンス。

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

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

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

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

    Security=Notice
EJB=Warning

  • WLSTを介して、setコマンドを使用してLogMBeanのLoggerSeverityProperties属性の値を設定します。『WebLogic Scripting Toolの理解』のロギングの構成に関する項を参照してください。

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

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

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

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メッセージがフィルタ処理されます。

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

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

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

  • WLSTを介して、setコマンドを使用してLogMBeanのLoggerSeverityProperties属性の値を設定します。『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管理コンソール・オンライン・ヘルプの本番モードへの変更に関する項を参照してください。

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

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

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

ノート:

LogMBeanプロパティではFileMinsize属性の有効な最大制限値として2 GBが定義されていますが、WebLogic Serverでは、ログ・ファイルが過剰に増大するのを防ぐためにハード・ローテーションが強制的に実行されるまで、しきい値サイズ制限が500 MBに設定されます。

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

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

#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.>

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

デフォルトでは、ローテーションされたファイルはログ・ファイルと同じディレクトリに格納されます。アーカイブされたログ・ファイルの格納先に別のディレクトリを指定するには、WebLogic Server管理コンソールを使用するか、コマンド行から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リスナーの例については、「メッセージのサブスクライブ」を参照してください。

JVMの出力のリダイレクト

WebLogic Serverインスタンスが動作しているJVMは、メッセージを標準エラーおよび標準出力に送信します。サーバーとアプリケーション・コードは、ロギング・メカニズムを使用するかわりに、これらのストリームに直接書き込みます。ただし、構成オプションを使用すると、サーバーのターミナル・コンソールやログ・ファイルなど、登録されているすべてのログ宛先にJVMの出力をリダイレクトできます。 

このリダイレクトを有効にした場合、ログ・エントリは、重大度がNoticeのメッセージとして表示されます。JVM出力のリダイレクトによって、ネイティブ・コードからの出力(たとえば、JVMからのスレッド・ダンプ)はキャプチャされないので注意してください。

ノート:

LogMBean属性を有効にしたWebLogicロギング・サービスへのJVM標準出力と標準エラー・メッセージのリダイレクトには、この項で説明するように、認識する必要がある2つの主要なデメリットがあります。

  • JVMメッセージは非同期でリダイレクトされます。過負荷状態の場合、これらのメッセージは削除されることがあります。

  • JVMメッセージを大量にWebLogicロギング・サービスへリダイレクトした場合、システム・パフォーマンスに深刻な悪影響を及ぼす可能性があるため、この方法はお薦めしません。

そのかわりにベスト・プラクティスとして、いずれかのサポートされたロギングAPIを使用して、JVM標準出力と標準エラー・メッセージをログ・ファイルに保存するようお薦めします。ロギングAPIを使用すると、システムの負荷が最大のときでも、それらのメッセージが大量に生成された場合も含めて、メッセージが削除されていないことが確認されます。

JVM出力をリダイレクトするようにWebLogic Serverを構成

JVM標準出力または標準エラー・メッセージをWebLogicロギング・サービスにリダイレクトするようにWebLogic Serverを構成するには、次のいずれかを実行します。

  • WebLogic Serverを起動するweblogic.Serverコマンドに、次のオプションのいずれかまたは両方を必要に応じて追加します。

    • -Dweblogic.log.RedirectStdoutToServerLogEnabled=true

      このオプションにより、JVM 標準出力メッセージがWebLogicロギング・サービスにリダイレクトされます。

    • -Dweblogic.log.RedirectStderrToServerLogEnabled=true

      このオプションにより、JVM 標準エラー・メッセージがWebLogicロギング・サービスにリダイレクトされます。

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

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

  • WLSTを使用して、次のLogMBeanの属性値のいずれかまたは両方を設定し、サーバーを再起動します。

    • RedirectStdoutToServerLogEnabled=true—JVM標準出力メッセージがWebLogicロギング・サービスにリダイレクトされます。

    • RedirectStderrToServerLogEnabled=true—JVM標準エラー・メッセージがWebLogicロギング・サービスにリダイレクトされます。

    次の例のWLSTコマンドは、管理サーバーのJVM標準出力メッセージをサーバー・ロギング宛先にリダイレクトします。

    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()

    『WebLogic Scripting Toolの理解』の「MBeanのナビゲート(WLSTオンライン)」を参照してください。RedirectStdoutToServerLogEnabled属性およびRedirectStderrToServerLogEnabled属性に関する詳細は、Oracle WebLogic Server MBeanリファレンスのLogMBeanを参照してください。

標準エラーおよび標準出力のリダイレクト

weblogic.RotatingFileRedirectorは、標準エラーおよび標準出力ストリームをローテーションするログ・ファイルにリダイレクトするためのスタンドアロン・ユーティリティ・ツールです。次のコマンドを使用してユーティリティを実行します。

java weblogic.RotatingFileRedirector [オプション]

オプションは、次のとおりです。

  • -help: サポートされているオプションおよびフラグに関するヘルプを印刷します

  • -verbose: 実行中の追加の出力を印刷します

  • -config Config Properties File: (オプション) ログ・ローテーション・ファイル・パラメータをキーと値のペアとして指定するプロパティ・ファイルです。指定されない場合、ローテーション・パラメータがデフォルト設定されます。

  • -configOverride: キーと値の構成プロパティ・ペアをオーバーライドします。これは同じconfig.propertiesが複数のサーバーで共有され、baseLogFileNameのみがサーバーごとに異なっている必要がある場合に有用です。たとえば、次に示すように複数のオーバーライドを指定できます

    -configOverride baseLogFileName=${SERVER_NAME}.out -configOverride rotatedFileCount=10

次の表に、構成できるプロパティおよびデフォルト値を示します。

表2-1 プロパティおよびデフォルト値

プロパティ名 デフォルト値 コメント

baseLogFileName

または

baseLogFilePath

redirect.log

baseLogFilePathは、WebLogic Serverバージョン12.2.1以降で有効です。それより前のバージョンではbaseLogFileNameを使用してください。

stdinのリダイレクト先のログ・ファイルを指定します。

logFileRotationDir

null

指定しない場合、ローテーションされるログ・ファイルはベース・ログ・ファイルとして同一ディレクトリ内に作成されます。

numberOfFilesLimited

false

ディスク上のローテーションされる古いファイルの数を制限するかどうかを指定します。

bufferSizeKB

8

コンテンツがディスクにフラッシュされるまでの出力ストリームのバッファ・サイズ(KB)です。

rotateLogOnStartupEnabled

true

起動時にログ・ファイルが存在する場合には、前の実行からローテーションします。

rotatedFileCount

7

numberOfFilesLimitedと組み合せて使用します。ローテーションされる古いログの保持する数を指定します。

rotationSize

500

KB単位で指定される、ローテーションが行われる際のサイズ制限です。

rotationTime

00:00

時間ベースのローテーションを使用する際にローテーションの開始時間を指定します。

rotationTimeSpan

24

ログ・ファイルをローテーションする間隔(時間)です。24時間にデフォルト設定されます。

rotationType

bySize

有効な値はbySizeまたはbyTimeのいずれかです。

例2-3 ユーティリティの使用

config.propertiesファイル・コンテンツの例: 

rotationSize=100 
baseLogFilePath=foo.log

ユーティリティは次のように実行されます。

{JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} ${JAVA_OPTIONS} -Dweblogic.Name=${SERVER_NAME} weblogic.Server 2>$DOMAIN_HOME/logs/mps/${SERVER_NAME}_stderr.log | ${JAVA_HOME}/bin/java -Xms128m -Xmx256m -cp $WL_HOME/server/lib/weblogic.jar weblogic.RotatingFileRedirector -configOverride baseLogFilePath=$DOMAIN_HOME/logs/mps/${SERVER_NAME}_stdout.log -config $DOMAIN_HOME/bt_stdout.prop &

過剰なロギングの防止

状況に応じて、ログ・メッセージが非常に高い頻度で生成され、メッセージの多くは同一の内容です。これにより、システムにログ・メッセージがあふれ、システムに過剰な負荷がかかります。 過剰なロギングは、様々な理由により時折発生します。たとえば、ネットワークが一時停止すると複数のコンポーネントが接続試行を繰り返すため、メッセージのログが発生し、また構成が正常ではない場合、コンポーネントが繰返しログ・メッセージを発行します。過剰なロギングにより、次のような問題が発生します。

  • システム・パフォーマンスが低下します。

  • ログ・ファイルがいっぱいになり、重要なメッセージが失われる危険が増加します。

  • キャプチャされた標準出力(stdout)ファイルが無制限に増大します。

  • 管理対象サーバーからのメッセージは、ドメイン・ログにブロードキャストされるため、ドメイン・ログ・ブロードキャスタがあふれて、さらにボトルネックが発生します。

  • スレッドがスタックします。

この問題を回避するために、WebLogicロギング・サービスは、ドメインでの過剰なロギングの存在を監視する機能を提供します。デフォルトで使用可能になっているログ監視は、指定された時間内に生成されるメッセージの数を計測して動作します。設定されたしきい値より高い値でメッセージが生成される場合、ロギング・サービスは個別のメッセージを調べ、特定のメッセージが繰返しログ出力されていないか判別します。そうである場合、ロギング・サービスはそのメッセージを抑制またはスロットルし、ロギング全体の速度を低下させます。スロットルは、メッセージ全体の生成量が低下すると自動的に無効になります。

繰返しログ出力されるメッセージは、次のパラメータを含む署名により識別されます。

  • メッセージを生成しているログ名

  • メッセージID

  • LogMonitoringThrottleMessageLength属性により確立されるメッセージの冒頭部分。(デフォルト値は50で、メッセージの部分を最初の50文字まで評価して、制限します。)

ログ監視を有効にするには、LogMBeanの次の値を構成します。

表2-2 属性

属性 説明
LogMonitoringEnabled={true|false}

ログ監視が有効かどうかを指定するフラグ。デフォルトでは、この値はtrueに設定されています。

LogMonitoringIntervalSecs=seconds

ログ出力されたメッセージの数を計測する秒単位の時間間隔。デフォルト値は30です。

LogMonitoringThrottleThreshold=value

メッセージ・スロットルを開始または停止する指定された時間間隔内にログ出力されるメッセージ数のしきい値。デフォルト値は1500です。

LogMonitoringThrottleMessageLength=value

スロットル期間中に評価されるログ・メッセージの最初の部分の長さ。デフォルト値は50です。

LogMonitoringMaxThrottleMessageSignatureCount=value

スロットル間隔中に監視される一意のメッセージ署名の最大数。この値は、内部キャッシュに格納される署名数のキャップを指定し、キャッシュが無制限に増大してOutOfMemoryErrorが発生するのを防ぎます。