例えば、Apache commons-loggingであれば、
public class Sample {
private static final Log LOG = LogFactory.getLog(Sample.class);
/**
* 業務処理
*
* @throws Exception システム例外
*/
public void process() throw Exception {
}
}
これはとても最適なコードのように見えます。初めてSampleクラスが初期化された際に、たった一度だけログ出力用のインスタンスが生成されます。
ですが、これらが各業務プログラムに乱立すると、どのクラスだけをログ出力したいか、簡単かつ詳細に定義できないことが多いのです。
例えばこのクラスが共通クラスであり、APサーバ上の共通libに配置しなければならない場合、このクラスは全てのWebアプリケーションから透過的に扱われることになります。
では、AというWebアプリケーションサーバではこの機能はログ出力したいけれど、BというWebアプリケーションではこの機能はログ出力したくない場合はどうしましょうか？
そもそもそんな需要はない？
性能を測定したいとか、障害が発生したとか、そういうこともないシステムならいいのでしょうが、実際にはそんなことはありません。
ログの制御は、log4jやLogBackを普通に使うのではなく、多少コストがかかったとしてもフレームワークが担い、ログインスタンスを業務処理に引き渡すべきです。
そして、フレームワークはシステムをわざわざ停止させなくとも、あるタイミングから業務処理を呼び出す時に引き渡すロガーの内容を、性能計測用、障害検出用、通常運用用と動的に切り替えられる仕組みを持つべきです。
ある1プロセスで、EAIアプリケーションのように複数のデータ転送を行う場合、例えば複数のサイトにFTPやDB、MQに接続する複雑なシステムの場合、縮退運転でサービスを停止させられない場合、これらにおいて、フレームワークがログ出力を動的に制御する機構を備えていることはとても保守運用者を安心させます。
残念ながら、未だにログ運用まで考慮できたフレームワークは見たことがありません。あくまで作る側の視点での出力です。それは、NTTデータのフレームワークですらできていないと言えることなので、絵に描いた餅という意見と言われても仕方ないのかもしれません。。。
少なくとも私は過去の案件において、フレームワークでログ制御を実施したことがあります。その際は通常何も問題がなければ実は動作しているかどうかも分からないぐらい何もログを出力しないシステムでした。つまり、起動しましたというログしかでません。
でも、実行中フレームワークが呼び出した第一階層の業務プログラムはフレームワークがログ機能を完全に制御し、まだ業務プログラムが扱う値はセッションのように値を保存することを前提とさせたため、障害が発生した場合(つまり例外が発生した場合)、拡張したロガーがどのプログラムで、どこまで処理してどういう異常終了したか、またその時の持ち回り変数の値は何だったかを全てダンプ出力するようにしました。
通常、障害がなければ何も出ませんが、障害があるときだけ、メモリの内容をほぼ吐き出し、ロジック上のスタックトレースや例外メッセージだけでなく、フレームワークがどこまで制御していたかまで出力することを実装したことがあります。
これは有識者が見れば、すぐに原因が分かるレベルでしたが、さすがに運用保守の人間では難しすぎたため、今では反省しています。(とはいえ、運用保守の人間が見るログと解析する人間が見るログ、統合運用監視システムが見るログはそれぞれ別で、それぞれに応じて出力内容を制御したりしましたが。。。あと、出力順にも優先度があったりなど)
そして、フレームワークでログが出せない場合(OutOfMemoryなど)は、APサーバがログ出力します。よって、アプリ用の通知ログ、APサーバのログ、APサーバ自体のプロセス監視、あとは、JMXよりももっと簡単にHTTPでシステムやスレッド(スレッド名を機能名に変更し、問い合わせしやすくしたり)の状態を確認できるようにし、運用監視できるようにしたことがあります(もう2年も前か。。。)。
昨今、正常実行中に無駄にログが出る割に、障害では必要なログが出ないシステムが多いと思います。少しでもそのような状況を改善できないか、模索中です。
]]>