久しぶりにアーキテクトっぽい話題としてログの話をします。その中でもログレベルとメッセージコードの設計にまつわる失敗談をお伝えしたいと思います。ログまたはロギングは情報システムにとって主要な機能でないにも拘らず、おざなりな設計をすれば後で痛い目に遭うという曲者です。
ログレベルというのはエラーレベルとも言いますが、ログに記録する事象の重要度（あるいは緊急度）を示しており、大別すると3種類で故障・警告・情報です。ただ、ログレベルの種類はそのレベルの定義も含めて運用設計に関わってくるので、一般化しようと思ってできるものではありません。ですので、ここではログレベルそのものの話題ではなく、メッセージコードの体系との兼ね合いについてお話しすることにしましょう。
メッセージ設計の観点
まず考えることとして、メッセージコードにログレベルを持たせるかどうかという点があります。それはつまりメッセージコードを見ただけで、ログのレベルを判断できるようにするかどうかということです。故障ならErrorの頭文字を取ってE001、警告ならWarningの頭文字を取ってW001などとするのはこの考え方です。
次に考えることとして、発生したメッセージのログレベルに応じた制御があります。例えばバッチプログラムではジョブストリームの制御、Webアプリなどのオンラインプログラムでは画面遷移の制御を切り替えるということ。それらに加えてログ監視によるエラー検知と警報（エラー通知）を行うことも最近ではごく一般的なことだと思います。
ログ出力の方式の失敗
さて、そのログ出力処理ですが、あるシステムでは、ログ出力処理にログレベルとメッセージコードの両方を渡していました。これは愚直な方法ですがシステム全体において両者の整合性を保つ必要があるため、正直しんどい方式です。
そこで、私がアーキテクチャを担当した別のシステムでは、メッセージコードだけを渡す方式を採用しました。ログ出力処理の中で渡されたメッセージコードからログレベルを判別して以降の制御を行うというものです。これはほとんどの場合においてうまく行きましたが、ログレベルの変更に弱いということが分かりました。ある事象についてのログレベルを変更したいという場合、ログ出力処理を呼び出している個所のメッセージコードも併せて変更する必要があるということです。
また、ログレベルと画面遷移が必ずしも対応してないケース、つまり、同じレベルのエラーでもエラー画面に遷移すれば良い時もあれば、前の画面に戻したい時もあり、そういったケースでは単純な共通コードでは実現できないため少々苦労しました。それに、ログレベルが変わっただけで画面遷移（あるいはジョブ制御）が変わってしまうと不都合もあるでしょうし、バグになりやすいのです。
ログレベルとメッセージの現実的なアイデア
そこで、現実的にはログレベルと制御を分離した上で、ログレベルの変更に強いログ出力方式を考案する必要があります。前提として、メッセージの文言は定義ファイルに設定されており、メッセージコードから一意に引当てることができるものとします。
いくつか考えられると思いますが、ログに記録するメッセージコードの体系は、既に運用設計の中で定められており自由に決められない場合があります。そういう場合でも対応できるようにログに記録するメッセージコードとは別に内部のメッセージコードを定義すると良いのではないかと考えています。
この方式では内部のメッセージコードにはログレベルを表す文字を含めず連番（とその他の記号）のみとし、ログレベルはメッセージ定義ファイルの中に文言と一緒に定義しておきます。ログを出力する時は内部メッセージコードをログ出力処理に渡します。するとメッセージ定義ファイルからログレベルと文言を引当ててログに記録します。
こうしておくと、ログレベルを変更するにはメッセージ定義のみを変更すればよく、ログ出力処理を呼び出しているコードの修正を行う必要がありません。ログレベルの変更で悩まされたという方は是非一度試してみてはいかがでしょうか。
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。