ログメッセージの管理方法
業務アプリケーションのログメッセージは何で管理していますか？
たとえば、データベースや XML といったものが考えられると思います。
結局は、メリットデメリットとシステム構成や要件の兼ね合いなのですが、整理してみます。
データベースで管理する場合
テーブル構造を自由に定義できるので、ログ ID やログレベルやログメッセージなどを柔軟に管理できます。
アプリケーションがログを出力する機会は多いので、データベースへのアクセスを少なくするために、サーバー起動時にログメッセージ定義を読み込んでメモリに保持するケースが多いのではないかと思います。
XML で管理する場合
データ構造を自由に定義できるので、柔軟に管理できます。
ディスクアクセスを減らすため、サーバー起動時にログメッセージ定義を読み込んでメモリに保持するケースが多いのではないかと思います。
また、通常、システムは冗長構成にしてあると思います。よって、XML ファイルをローカルディスクに置く場合はそれぞれのアプリケーション配備サーバーに XML ファイルを置く必要があり、さらにファイル内容については同期をとる必要があります。ネットワーク上の共有ディスクに置く場合はその限りではありません。
オンライン中に変更する可能性がある場合
ここで業務オンライン中にメッセージを自由に変更したいという要件が発生した場合を考えてみます。
アプリケーションが何らかの方法でメッセージの変更を検知する必要が生じます。
データベースの場合
運用者が直接 SQL を使ってメッセージを変更する方法では、アプリケーション側からはデータベースをポーリングでもしないかぎり、メッセージ定義の変更を検知できません。このため、アプリケーション起動時にログメッセージ定義をメモリに全部とってきて、メッセージ定義に変更があった場合だけメッセージ定義をデータベースに取りに行くという運用が難しくなります*1。
XML の場合
アプリケーションの実装言語によっては、アプリケーション側から監視して変更を検知することは難しくないと思います。変更を検知したら、ファイルを読みなおしてメモリ上の情報を上書きします。
XML の場合、運用者が XML を修正したときに XML データ構造を破壊する可能性があるため、読み込み時に XML の解析に失敗した場合、エラーを検知できる仕組み (発報など) も織り込んでいく必要があると思います。
実装について
データベースを使った実装は、一般的な SQL による実装と変わらないので割愛します。
次回、XML でログメッセージを管理する方法を Java のサンプルを交えて紹介したいと思います。
XML の読み込みは JAXB 行い、Java 7 で追加された WatchService や、Java 8 で採用された Stream も使っていきます。Java の標準 API 以外は利用しない想定です。
