Japan [変更]

目次:
	万が一、知らなかった人のために
	良いプログラムは、プログラムの間違いを教えてくれる
	ロギングとトレーシングの基本
	正しいログ、トレースAPIの選択
	JULをコードに組み込む
	WebSphere Application ServerとJULを統合する
	結論
	参考文献
	著者について
	記事の評価

関連リンク
	WebSphere 記事一覧

developerWorks Japan > WebSphere >

サポート通信: 開発者のためのWebSphere Application Serverロギング・ガイド

ページオプション

JavaScript を要するドキュメントオプションは表示されません

原文はこちら

レベル: 初級

Don Bourne, WebSphere Serviceability Architect, IBM
Keys Botzum, Senior Technical Staff Member, IBM
Daniel Julin, Senior Technical Staff Member, IBM

2008年 02月 27日

ログ・メッセージとトレース情報は、問題判別の初期段階で、時間削減の重要な要素となります。また、しばしば、トラブルシュートするため問題を再現する必要性を軽減します。この記事では、IBM® WebSphere® Application Serverのログとトレースに焦点を当て、それらの違いを説明し、アプリケーション内でどのように活用するかを記述します。

IBM WebSphere Developer Technical Journalより.

サポート通信の各コラムでは、IBMテクニカル・サポートによって提供されるWebSphere 製品群向けのリソース、ツール、その他の要素について説明するのに加え、IBMサポートのエクスペリエンスをさらに高めることができる手法や新しい考え方について説明します。

万が一、知らなかった人のために

いつものように、まずWebSphere®コミュニティー全体にとっての新たな関心事項から始めることにします。

今月、IBMは新しいソフトウェア・サポート・ポリシー(US)を発表しました。多くの製品の古いバージョンが利用できるテクニカル・サポートの最小の期間が5年に拡張されました。これは、主要な製品リリースに追いつくのにあまりに頻繁にアップグレードしなければならないお客様の負担に関して答えるものです。
ibm.comの様々なソフトウェア・サポートのリソースの使いやすさや、構成の機能強化も継続しています。今週、我々は、IBM WebSphere Application Serverを含む多くの個々の製品サポート・ページの新しいデザイン(US) を発表しています。こちら(US)をチェックください。
IBM Education Assistant(US)ウェブ・サイトもまた、いくつか機能拡張しています、特に新しい教育用モジュールについて、学習するのに役立つRSSフィード (各製品のフロント・ページに) があります。ちなみに、2008年に100を超える新しい教育用モジュールが既にリリースされています。それらの多くは、トラブルシューティングに関連するトピックをカバーしています。
IBM Support Assistant(US)のいくつかの問題判別ツールが、更新されています。毎月アップデートや新しいツールが発表されますが、特にこれらに触れておきます。
- Visual Configuration Explorerが新しい機能(US)が追加されました。以前のサポート通信(US)で触れられています。
- Log Analyzerに関連するSymptom Editor(US) が利用可能です。新バージョンでは、新しい機能とLinuxをサポートしています。
- 以前、Extensible Verbose Toolkit (Java™のガベージ・コレクションと関連する問題を分析するツール) として知られていたツールが更新され、IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer(US)(あるいは、短くGCMV) と名称が変更されました。この名称変更は、実際、Javaレベルの診断に役立つツールの簡素化のための広範なプログラムの一部です。ツールに関する更なる更新情報は来月調べてください。
alphaWorks(US)内のいくつかのツールもまた、大部分、新しいJavaのバージョンとプラットフォームをサポートするため新しくなりました。特に以下のツールです。
WebSphere Technical Exchange Webcasts(US)シリーズは、すばらしい情報源です。そして特に、これから数ヶ月に問題判別に関連するトピックが豊富に予定されています。我々はここに全てのトピックをリストしませんが、特に興味深いと思われるいくつかをご紹介します。「Guided troubleshooting using the IBM Guided Activity Assistant (IGAA)」、「IBM Support Assistant Diagnostic Tools Overview」、「Debugging OutOfMemory errors on WebSphere AppServer z/OS」、「Resource starvation in Java and its diagnosis」、「Automating problem identification using IBM Autonomic Computing Technology」

今後もサポート関連のさまざまなWebサイトやこのコラムで、随時レポートされる他のツールに関するニュースも注視してください。

では、本題に入ることにしましょう。

上に戻る

良いプログラムは、プログラムの間違いを教えてくれる

開発者として最初に学ぶことの一つは、コンソールにメッセージをどのように出力するかです。その後、特に気に入った開発ツールを見つける前の早い段階に、デバッグ時に価値のある情報を出力する方法を学びます。コードの流れを追い、変数内の値の変更に気づく能力を得ると、コード内の問題をすばやく見つけるために明確なデバッグ・メッセージの値に気づけるようになります。メソッドをデバッグする際には、コードの次のセクションに焦点を当てやすいようにメッセージ出力を取り除いていきます。デバッグが終わる際に、コードが使用できる状態となり、最後のメッセージ出力を削除します。

重要なプログラムにとって、診断用のコードは単体テスト以上に重要です。ある状況では、診断用のコードの助けなしに問題判別可能ですが、上手にログ、トレース情報を使用すると、問題判別の時間を大いに削減できます。ロギング・コードは、最初の問題判別に重要な役割をもっており、そして、問題判別するために問題を再現する必要性をしばしば軽減できます。IBM WebSphere Application Serverは、ユーザー自身のアプリケーション内で利用可能な、有益なログとトレース機能を持っています。この記事では、開発者としてWebSphere Application Serverで動くアプリケーションに効果的なログとトレースを出力するために何を知っておく必要があるのかを説明します。

上に戻る

ロギングとトレーシングの基本

ロギングとトレーシングの違いは何か？

ロギング は一般的に、ユーザーがログ・ファイルに書き留めておきたい重要なイベントに使用されます。ロギングは、状態の重要な変更を知らせる (例えば、サービスを開始、停止する場合)、警告を知らせる (例えば、出力しているディスクが容量不足の場合)、エラーを知らせる場合 (例えば、期待したサービスが利用できないため、コードの実行が出来ない場合) によく使用されます。ロギングは、一般的にいつでも出力します。そのため、ロギング・コードは必然的にかなり低ボリュームで、概して重要で、注意を払わなければならないものになります。その他重要な特徴は、ロギングはアプリケーション管理者に役立つということです。ログに記録されたメッセージは管理者向けのため、アプリケーション・サーバーによってログに記録されたメッセージは、サーバー・プロセスが構成された言語に訳されログに出力されます。(アプリケーションもまた、メッセージの現地語化を利用できますが、これは普通必要ではありません。) ログ・メッセージが、コードを使用する誰にでも簡単に理解されることを保証するため、ログ・メッセージを作るのに慎重さも必要です。そのため、大抵、トレース・ステートメントを追加するのに比べて、ロギング・ステートメントをコードに追加するのに、多くの時間がかかります。
トレーシングは一般的に、コードの問題をデバッグするのに役立つ情報を記録するために使われます。トレーシングは、どのメソッドが呼ばれたか、どんなデータがメソッドに渡されたか (あるいは、どんな値がメソッドから戻されたか)、メソッドの呼び出しから自身のコードでない外部のメソッド呼び出しからどんなデータが戻されたか、といったことを知らせるためによく使用されます。トレース・イベントは、大量になり、そのため、問題判別を行うときのみ有効にします。トレース・イベントはとても詳細で、技術的内容のため、トレースはアプリケーションを実装した人には価値があります。トレーシングをオンにすると、コード内で起こった問題は理解できるようにすべきです。トレース計測がうまく行かない場合、問題発生時に、デバッグ用のコード (もっとトレースを追加した) をユーザーに用意する必要があるかもしれません。これは現実的でない (あるいは望ましくない) かもしれませんし、一般的にコードをユーザーに提供する前に十分に注意し、避けた方が良いです。

ログとトレースに重要な内容とは？

ログやトレース・ファイルに正しい内容があれば、問題をすばやく診断するのに役立ちます。最低限、ログとトレースは以下の内容を明確にすべきです。

メッセージが出力された正確なタイムスタンプを示す
メッセージの出力元の、クラス名とメソッド名
メッセージを出力したスレッドID
イベントの重大度
どのメッセージを有効/無効にするか制御するログ/トレース・レベルをセットする目的として、メッセージを出力するロガーを特定する名前
明確なメッセージ

ロギングやトレーシングのランタイムの重要な機能とは？

ログとトレース・イベントの中に正しい情報があるのに加えて、ロギングとトレーシングのランタイムに必要なものは以下です。

メッセージの有効/無効の十分にきめ細やかなコントロールが可能
サーバーの再起動なしに、ログ、トレースのレベルを変更可能
ログ、トレースが大きくなり過ぎないように、ログ、トレースをサーバーの再起動なしに自動的にアーカイブあるいは削除する手段を提供する
ログをリモートで監視する手段を提供する

上に戻る

正しいログ、トレースAPIの選択

どんなロギングAPIが最も一般的か？

WebSphere Application Server上のアプリケーションで使える多くのロギングAPIがあります。もっとも一般的な候補を表1に示します。

表 1. ロギングAPI

ロギングAPI	WebSphere Application Serverログと統合できるか？	WebSphere Application Server上のアプリケーションで使用が推奨されるか？
java.util.logging (JUL)	はい (V6.0から)	はい (V6.0以降)
JRAS	はい	はい (V6.0より前のバージョンのみ)
Log4J	いいえ	いいえ
Jakarta Commons Logging (JCL)	はい	いいえ
System.out.println and System.err.println	はい	いいえ

java.util.logging (JUL)

2002年のJ2SE 1.4リリース以来、JULは、Java SDKの標準の一部です。アーキテクチャー上、Log4Jと似ています。JUL APIには、5つの主要概念として logger, handler, filter, formatter, LogRecord があります。JULの重要な強みは、J2SE 1.4以上を基盤とする全てのランタイムの一部であり、ログの設定を容易にする柔軟なアーキテクチャーを提供しており、カスタマイズが容易であることです。

JULは、WebSphere Application Serverにおいて推奨のログ実装で、WebSphere Application Server自身の実装でも用いられています。JULのログAPIは、使いやすく、ログのニーズに対応するのに十分にカスタマイズ可能です。JULはWebSphere Application Serverとよく一体化されており、JUL Logger APIを使ったリクエスト (アプリケーション・コードからでさえ) は、WebSphere Application Serverのログ・インフラストラクチャーによって扱われます。WebSphere Application Server内で実行される、どんな新しいアプリケーション・コードでも、JULの使用を強くお勧めします。
JRAS

JRASは、WebSphere Application Server V3.5から提供されている公開されたAPIです。JRASのAPIと基盤としているAPIは、Log4J、JUL 以前にあったものです。JUL APIを利用するWebSphere Application Server V6.0で、JRAS APIは、非推奨となりました。そのため、新しいコードでは、JRASは使用しないでください。
Log4J

Log4Jは、柔軟で強力なログ実装を提供することを目的としたApacheプロジェクトです。Log4Jは、1999年に初版が公開され、アーキテクチャーはJULと類似しています。JULは、logger, handler, filter, formatter, LogRecord を持ちますが、Log4Jは、logger, appender, layout, LoggingEventを持ちます。Log4Jには、多くのappenderとlayoutが付属されています。

Log4Jは、Apacheからオープン・ソース・プロジェクトとして利用できますが、Java言語の標準の一部ではありません。Log4Jの重要な強みは、JULと類似の機能を提供し、事前に用意されたappenderとlayoutの実装があることです。

JULとアーキテクチャーは似通っていますが、Log4JはWebSphere Application Serverのログ・インフラストラクチャーとは統合されていません。一般に、Log4Jのappenderや、layoutの拡張された機能をオーバーライドする必要がない場合、WebSphere Application ServerでLog4Jを使わないでください。WebSphere Application ServerでLog4Jを使うことを決め、とてもうまくいくかもしれませんが、JULに活用されている統合から利益は得られません。
Jakarta Commons Logging (JCL)

JCLは、ラッパーAPIを提供することを目的としたApacheプロジェクトです。他のロギングAPIとは違って、JCLは実行時のログ呼び出しを、環境内の適切なログ実装に委譲します。それゆえ、例えば、WebSphere Application Serverでは、JCLからのイベントは、WebSphere Application Serverのログ、トレース機能に送られます。他の環境では、JCLの出力がLog4Jに送られるのは、珍しくありません。ここでのキーポイントは、JCLは標準に準拠したAPIではなく、開発者にトレース出力がどこに出るか全く意識させないフレームワークということです。JCLは標準API以前より存在しています。

JCLの重要な強みは、ランタイムのロギング機能や、コードを最終的に実行するランタイムについて考慮することなくログの呼び出しをコードに実装できることです。

JCLはWebSphere Application Serverと統合され、まとめられています。コピーしたJCLのJARをバンドルし、IBMが提供するデフォルト以外に出力したいアプリケーションは、アプリケーション・サーバー・ランタイムに含まれるJCLのバージョンとクラスのロードで衝突しない様、十分に注意する必要があります。通常は、適切に設定するのは難しく、それゆえ、推奨されません。

J2SE 1.4以降の全てのJVMにおいて、JULが一般的に使用できるため、移動可能なログのラッパーとしてのJCLの必要性は、減少しました。このため、新しいアプリケーション・コードでは、JCLは使用しないでください。
System.out.printlnとSystem.err.println

実際には、ログあるいはトレースのAPIではありませんが、多くの開発者がコードに組み込むのに System.out.printlnを使用するのが大好きです。WebSphere Application Serverは、System.outとSystem.errに渡すデータを増やします。コンソールにSystem.outとSystem.errを出力するというよりも、WebSphere Application Serverは以下を行います。
- ログ・イベント内の各ストリームに渡されたデータを変換する (不正確なプロセス)
- イベントの作成時間を見つける
- イベント発信スレッドIDを見つける
- 管理しているログ・ファイルに、上記の情報を含め、イベントを出力する
残念なことに、System.outとSystem.errでは、アプリケーション・サーバーは、メッセージの正確なソース (クラスやメソッド) は特定できませんし、メッセージの深刻度を伝えることができません。また、これらのメッセージの出力をコントロールするための基本のON/OFF機能 (サーバー全体の) 以上のものを提供できません。たぶん、もっとも重要なことには、高容量のトレース出力をSystem.outに送ることは高くつき、重大なパフォーマンス問題をもたらします (そして出力量を減らす圧力がかかります)。　これら機能の欠如のため、大規模使用において、System.outとSystem.errを実用的ではありません。それゆえ、アプリケーション・コード内で、System.out.printlnとSystem.err.printlnは使用しないでください。

WebSphere Application ServerでどのログAPIを使用すべきか

上記のように、選択する多様なログAPIがあります。ここでは、WebSphere Application Server保守サービス・チームがあなたのアプリケーション・コードにお勧めを紹介します。

WebSphere Application Server V6.0以降で動く新しいコードには、JULを使用してください
JULの普遍性と、アプリケーション・サーバーのログとトレース機能との密接な統合により、JULは、新しいWebSphere Application Serverのアプリケーション・コードを利用する場合、一番のAPIです。あなたのアプリケーションが動く必要のあるすべてのランタイムでJULが利用できない場合にのみ、他のログAPIを考慮すべきです。
適切にJULをサポートしていない環境をサポートする必要がある場合 (この場合に限り)、新しいコードに既存のロギング・フレームワークを継続使用してください
一般的に、J2SE 1.4以前の環境にデプロイし続けるなら、あなたは他のアプリケーションや、定評のあるログAPIを持っているでしょう。あたなには、既存のログAPIを使用し続ける、あるいは、他のログを見つけるという2つの選択肢があります。今や、JULにログ標準があり、どんな投資もおそらく一時的なものとなるため、新しいログ・インフラストラクチャーに投資することはありません。
単一のログAPIにするために、何千ものテスト済みのログやトレースの実装を置き換えないでください
JULをサポートしているアプリケーション・サーバーに移行する場合、既存のログやトレースの実装を作り変えたいと思うものです。一つのログAPIに標準化するために何万ものトレース・コードを書き換える (再テストする) ことは、普通、開発リソースの上手な使い方ではありません。可能ならば、JULに出力するため、既存のログAPIをブリッジする方法を考えましょう。JUL経由のログ・イベントを統合できないなら、ログ確認時に、アプリケーション・サーバーのログとアプリケーションのログをマージするためLog Analyzerのようなツールを使用できます。

上に戻る

JULをコードに組み込む

Loggers は、ログやトレースが必要な箇所にコード内で使用されます。通常、Loggerの命名は、使用されるJavaクラスあるいはパッケージに基づいて行われます。(例えば、com.acme.birdtrap.PurchaseOrder)。Loggerは、シングルトンのLogManagerオブジェクトにより、親Loggerから特長を継承させることが可能な名前空間内に格納されます。各Loggerの名前は、Loggerがどの階層に属しているかによって決まり、各Loggerの親はその子供と同じ名前を持っており、子供の名前の最後の部分から一部差し引いて始まります。(例えば、com.acmeは、com.acme.birdtrapの親であり、com.acme.birdtrapは、com.acme.birdtrap.PurchaseOrderの親になります。)　各Loggerは、レベルを持っています。これは、捨てずにログしなければならない最小のイベント (LogRecordで知られる)を制御する設定可能なレベルです。Loggerのレベルを明確にセットしなければ、Loggerは親からレベルを継承します。Loggerは任意でFilterを持てます、Filterは、LogRecordの中身に基づいたログ・リクエストを発行するかどうかを決定するために使用されるクラスです。
Handlersは、LogRecordを出力装置に出力するのにLoggerにより使用されるクラスです。Handlerは、LogRecord自身を初期設定するか、LogRecordを文字列に変換するため、Formatterを使用します。Handlerはまたレベル設定ができ、レベルはLoggerと同様の役割を果たします。Handlerはまた、LoggerのFilterと同様の役割のFilterも持っています。一般的に、HandlerはLogRecordの情報を元に、フォーマットされた結果をログ・ファイルに出力しますが、インメモリー・バッファー、ソケット、インスタント・メッセージの送付先、あるいは、有効ないかなる場所に出力するよう設計される可能性があります。JULは、基本的ニーズを満たす多くのHandler、Formatterを標準で用意しています。

図1. JULのログ・リクエスト処理のキー・コンポーネント

リスト1に、JULを使用する場合の慣例を示したサンプル・コードがあります。これらの慣例を以降で説明します。

リスト1. JULの使用を示すサンプル・コード

                
1  package com.acme;

2  import java.util.logging.Level;
3  import java.util.logging.Logger;

4  public class JULExample {

5  	// define a Logger for use by this class
6  	static String className = JULExample.class.getName();
7  	public static Logger logger = Logger.getLogger(className);

8  	public String lookupContactPhoneNumber(String contactName) {
9  		String methodName = "lookupContactPhoneNumber";
10  		logger.entering(className, methodName);

11  		// connect to contact repository
12  		ContactRepository cr = ContactRepository.connect();

13  		if (cr == null) {
14  			// LOGGING
15  			logger.logp(Level.WARNING, className, methodName,
16  						"Contact repository not available");
17  			return "";
18  		}

19  		// lookup the contact phone number
20  		String contactPhoneNumber = cr.getContactPhoneNumber(contactName);

21  		// TRACE
22  		if (logger.isLoggable(Level.FINEST)) {
23  			// use isLoggable so we don't concatenate strings
24  			// below unless trace is enabled
25  			String traceString = "name    " + contactName + "number: "
26  					+ contactPhoneNumber;

27  			logger.logp(Level.FINEST, className, methodName,       
28             	            traceString);
29		}

30		logger.exiting(className, methodName, contactPhoneNumber);
31		return contactPhoneNumber;
32	}

33	public String getSomeString() {
34		return "SomeString";
35	}

36  }

JUL APIを使用したアプリケーションにログやトレースのコードを追加することは、アプリケーションの保守性を大いに改善します。ここで役立つ経験則をいくつか提案します。

Logger.getLoggerを繰り返し呼ばずに、Loggerインスタンスを保持する
リスト1では、Logger.getLogger()メソッドは、Loggerクラス取得のために一度しか呼び出されていません。Loggerはスレッドセーフのため、いかなるクラス・インスタンスからも使用できるよう安全にstatic変数に保持できます。これにより、クラス内のどこからでも、Logger.getLogger()メソッドを再び呼び出すことなく使用することができます。これは、コードのパフォーマンスを改善します。
Loggerの名前として、完全修飾名を使用する
Loggerのレベル (例えば、管理コンソール内で) を変更する必要がある場合、Loggerの名前は、Loggerを特定するのに使用されます。Loggerを完全修飾名で指定しておくと、ユーザーから必要とされるトレースを取得するために、どのLoggerのレベルを調整する必要があるのか特定しやすいです。

ログとトレースの項目から、コードを特定できるようにする
ログとトレースの項目内に、クラス名、メソッド名を特定することにより、イベントが発生したコード内の場所をすぐに特定できます。

また、メソッド開始を明らかにするため、entering()メソッドの呼び出しを使用できますが、entering()メソッドの呼び出しは、FINERレベルのイベントで、FINERレベルのイベントは、WebSphere Application Serverのデフォルトでは出力されないようになっています。

JULのいくつかの実装は、コード特定可能な項目が指定されていない場合、イベントが発生したメソッドとクラスを予測しようとします。しかし、これは好ましくないパフォーマンス結果を招きます。そして、JITがスタックを削除している場合、正しくさえないかもしれません。WebSphere Application Server内では、呼び出し側 (とても非効率と思われる任意の機能として) に代わって、メソッドとクラス名を予測することはありません。自分でクラスとメソッド名を用意する場合には、JUL Loggerメソッドを使用したほうが良いです。

表2．クラス名とメソッド名を特定するLoggerメソッド

Loggerメソッド
`entering(String sourceClass, String sourceMethod)`
`entering(String sourceClass, String sourceMethod, Object param1)`
`entering(String sourceClass, String sourceMethod, Object[] params)`
`exiting(String sourceClass, String sourceMethod)`
`exiting(String sourceClass, String sourceMethod, Object result)`
`Logp(Level level, String sourceClass, String sourceMethod, String msg)`
`Logp(Level level, String sourceClass, String sourceMethod, String msg, Object param1)`
`logp(Level level, String sourceClass, String sourceMethod, String msg, Object[] params)`
`logp(Level level, String sourceClass, String sourceMethod, String msg, Throwable thrown)`
`throwing(String sourceClass, String sourceMethod, Throwable thrown)`

ログとトレースのレベルに関してアプリケーション・サーバーの表現に従う
WebSphere Application Serverのデフォルト構成は、初期設定によりLeve.INFO以上のJULのレベルが可能です。アプリケーション・サーバーは、管理者に役立つことを目的としたログ・イベントのレベルとして、Level.CONFIG から Level.SEVERE のJULのすべてのレベルを扱います。

表3．Loggingレベル

Loggingレベル
`Level.SEVERE`
`Level.WARNING`
`Level.INFO`
`Level.CONFIG`

アプリケーション・サーバーは、トレース・レベル (コードの著者がデバッグするのに役立つイベントに用いられるレベルです。) としてLevel.FINE から Level.FINEST に至るまで取り扱います。

表4．Traceレベル

Traceレベル
`Level.FINE`
`Level.FINER`
`Level.FINEST`

コード内のこれらの同じ表現に従い、一連のイベントが初期設定でログされます。

コード内でLoggerのレベルを設定しないJUL Loggerは、関連したレベルを持っています。このレベルは、Loggerが無視するイベント、ログするイベントを制御します。Loggerのレベルは、アプリケーション・サーバー起動時に、アプリケーション・サーバー構成ファイルのデータからセットされます。管理者は、Loggerのレベルを、スクリプトを通じた (wsadminを使用した) 管理コンソール経由、あるいはプログラム (JMX Mbeanクライアントを使用した) で変更可能です。アプリケーション・サーバーは、Loggerのレベルを管理しています。

LoggerのsetLevel()メソッドの直接呼出しによる、Loggerのレベル設定変更は、アプリケーション・サーバー中枢のログ構成の設定を変更しません。そして、setLevel()メソッド経由で設定されたLoggerのレベルは、管理コンソール内に反映されず、ロギング・インフラストラクチャーが、管理者の変更による新しいログの設定を適用する際に、無視されます。このため、setLevel(Level newLevel)メソッドの使用は避けてください。サーバー中枢のLogger構成に変更がなされた場合、影響を受ける全てのLoggerに反映されます。これは、LoggerのgetLevel()メソッドの呼び出しが期待通り働くことを意味します。
entering()とexiting()メソッドは、重要なメソッドのみに利用する
JULは、メソッドの開始と終わりに使用が推奨されるLogger.entering()とLogger.exiting()メソッドを提供しています。コード内の全てのメソッドにトレース・ポイントを追加するのは度を越えており、アプリケーションの保守性を増すことにはなりません。一般に、取るに足らないメソッド (getterやsetterのような単純なメソッド) 内にentering()とexiting()メソッドの使用は避けてください。
アプリケーションのログ、トレースをアプリケーション・サーバー・ログに出力する
JULは、最小のコードや構成で新しいログ・ファイル (Handler) を追加できる機能を提供していますが、普通そうすることに利点はありません。デバッグする際に、アプリケーションのログとトレースを、アプリケーション・サーバーのログとトレースと織り交ぜると効果的です。同じログ・ファイルにログ出力できない場合、あるいは多数のシステムが関連している場合、Log Analyzer (IBM Support AssistantのPlug-inとして利用できます) のようなツールが、アプリケーションのログ・ファイルをまとめるのに役立ちます。
適切な箇所でLogger.isLoggable()を使用する
WebSphere Application Serverはデフォルトで、トレースは使用不可で動作するので、使用不可のトレース・メッセージはできるだけ効果的に実行させることが重要です。トレース・メソッドのパラメーターを用意するのにパフォーマンス負荷をかけるのを避けるため、JULは、Logger.isLoggable()メソッドを用意しています。このメソッドは、指定されたレベルが、ロガーに設定されているレベルかそれ以上かチェックします。ロガーは同じチェックを行うことを頭に入れておき、ログとトレースのパラメーターの用意にパフォーマンス負荷を受ける場合、ログやトレース文をLogger.isLoggable()の条件文で囲むと良いです。

上に戻る

WebSphere Application ServerとJULを統合する

WebSphere Application ServerはV6より全てのバージョンで、JULを活用しています。JULをコードに組み込むことで、いくつかの追加のメリットが得られます。

内蔵のログおよびトレース・ファイル
WebSphere Application Serverは、ログとトレース・イベントの形式をあわせ、適切なアプリケーション・サーバーのログ・ファイルに出力します。(Windows®、Linux®、HP/UX, Solaris™、AIX®、そしてi5/OS オペレーティング・システムでは、SystemOut.log、trace.log、activity.logファイルがあります。System Z™では、プラットフォームのログ機能があります。) アプリケーション・サーバーは、これらのログ・ファイルを管理し、簡単に構成可能なアーカイブ・ポリシーを提供しています。アプリケーション・サーバーのログ・ファイルと連携するツール (IBM Rational® Application DeveloperやIBM Support AssistantのLog Analyzerのような)、ログの中身と連携できる様々なIBM Tivoli® ツールを使用できます。
内蔵のアプリケーションLoggerレベル管理
WebSphere Application Serverは、名前をつけられたJUL Loggerのレベルを設定する方法を提供しています。これは、アプリケーションの中で作成したLoggerも含みます。JUL Loggerレベルは、管理コンソール、wsadmin、JMX構成を使用して設定できます。

図2. WebSphere Application Serverのログ詳細レベルの変更パネルにJUL Loggerを表示
アプリケーションのイベントと、アプリケーション・サーバーのイベントの特有の関係
アプリケーション・サーバーのログとトレースのイベントは、アプリケーションのログとトレースのイベントが交互に出力されます。それゆえ、これらの分かれたイベントを関連付ける必要性が除けます。ログやトレースで問題判別する場合、これは時間を節約します。この交互の出力が望ましくない場合、アプリケーション固有のログ・ファイルを作成することもできます。(将来の記事で詳細については触れます)
WebSphere Application ServerのJUL拡張
WebSphere Application Serverは、Loggerの多数の役立つ属性を関連付ける手段(Logger.propertiesファイルを経由) を提供しています。これらの属性により、Loggerをグループに追加したり、地域対応のためにリソースバンドルを使用しパフォーマンスを改善できます。
エンタープライズ・レベルの構成
WebSphere Application Serverは、JRE/libディレクトリー内 (JULのデフォルト) のJUL logging.properties設定を使用するのではなく、サーバー構成設定に基づいて、ログ環境を初期化します。この利点は、ログ設定がサーバーと関連づいていることです。サーバーをクラスターに追加した場合、ログの振る舞いは全てのサーバーで一貫したものとなりますし、J2EE™環境と関連付けられた設定にのみ依存します。

上に戻る

結論

ロギングとトレーシングは、アプリケーション・コードの重要な要素です。ベスト・プラクティスに従うと、あなたの保守性のあるコードにより、使用されるランタイムと統合でき、デバッグに必要な情報を提供し、コードのパフォーマンスをほとんど下げることがないことを確信できるでしょう。

将来のコラムで、以下のようなより先進的なログとトレースのトピックを用意する予定です。

アプリケーション・サーバーで、Log4JあるいはJCLを使用しているコードを持っている場合、どうすれば良いか？
JULを使用している場合、アプリケーションのログ・ファイルの追加方法
JULで、地域対応のためリソースバンドルを使用する方法

参考文献

学ぶために

「アプリケーションへのロギングおよびトレースの追加 (US)」WebSphere Application Serverインフォメーション・センターを読んでください。
java.util.logging JavaDoc (US)をご覧ください
「The Support Authority: Getting help from the IBM Support Assistant (US)」を読んでください。
「The Support Authority: If you need help with WebSphere products, there are many ways to get it (US)」を読んでください。
「IBM Software Support Web site (US)」のサイトを訪れてください。
「IBM Guided Activity Assistant (US)」のサイトを訪れてください。
「IBM developerWorks」のサイトを訪れてください。
IBM Redbooks (US)をご覧ください。

製品や技術を入手するために

IBM Support Assistant (US)をご利用ください。

議論するために

フォーラムやニュースグループ (US)に参加してください。

著者について


		Don Bourne は、IBM Toronto Labに所属する、WebSphere Serviceability Architectです。Donは、1996年にIBMに入社し、WebSphere Application Serverチームに2003年に加わって以来、Serviceabilityのエリアを専門としています。現在、Donは、IBM Support Assistantチームと共に、ユーザーが問題を迅速に解決するのに役立つ将来のソリューションを設計しています。


		Keys Botzum は、IBM Software Services for WebSphrere (US)のSenior Technical Staffメンバーです。Botzum氏は、大規模分散系システムのデザインの経験が10年以上あり、加えてセキュリティを専門としています。Botzum氏は、Sun RPC、DCE、CORBA、AFS、DFSを含む様々な分散テクノロジーを扱っています。最近は、J2EEや関連するテクノロジーに取り組んでいます。彼は、スタンフォード大学のコンピューター・サイエンスの修士号と、カーネギー・メロン大学の数学/コンピューター・サイエンスの学士を取得しました。Botzum氏は、WebSphereとWebSphereセキュリティに関する多くの論文を発表しています。さらに、Keys Botzumによる記事やプレゼンテーションは、http://www.keysbotzum.com (US)や、同様に IBM developerWorks WebSphereで見つけることができます。彼はまた、IBM WebSphere: Deployment and Advanced Configuration (US)の共著者です。


		Daniel Julin は、複雑なオンライン・システムの開発、トラブルシューティングの経験が20年あります。WebSphere Serviceabilityチームの助けとなる技術的エリアとして、彼は現在、WebSphere Application Serverの問題判別に役立つツールやテクニックをチームが定義、実装することや、IBMサポートの効率性を最大化することに役立つ仕事に注力しています。彼はまた、様々な重大な顧客サポートの状況において、直接支援も行っています。

記事の評価

この記事を共有する


del.icio.us	newsing	FC2ブックマーク

Choix！	ニフティクリップ	Yahoo!ブックマーク

MM/memo	CZブックマーク	livedoorクリップ

はてなブックマーク	Buzzurl（バザール）

上に戻る

日本IBMについて

プライバシー

お問い合わせ