ログレベルとメッセージコード体系の調和

久しぶりにアーキテクトっぽい話題としてログの話をします。その中でもログレベルとメッセージコードの設計にまつわる失敗談をお伝えしたいと思います。ログまたはロギングは情報システムにとって主要な機能でないにも拘らず、おざなりな設計をすれば後で痛い目に遭うという曲者です。

ログレベルというのはエラーレベルとも言いますが、ログに記録する事象の重要度(あるいは緊急度)を示しており、大別すると3種類で故障・警告・情報です。ただ、ログレベルの種類はそのレベルの定義も含めて運用設計に関わってくるので、一般化しようと思ってできるものではありません。ですので、ここではログレベルそのものの話題ではなく、メッセージコードの体系との兼ね合いについてお話しすることにしましょう。

メッセージ設計の観点

まず考えることとして、メッセージコードにログレベルを持たせるかどうかという点があります。それはつまりメッセージコードを見ただけで、ログのレベルを判断できるようにするかどうかということです。故障ならErrorの頭文字を取ってE001、警告ならWarningの頭文字を取ってW001などとするのはこの考え方です。

次に考えることとして、発生したメッセージのログレベルに応じた制御があります。例えばバッチプログラムではジョブストリームの制御、Webアプリなどのオンラインプログラムでは画面遷移の制御を切り替えるということ。それらに加えてログ監視によるエラー検知と警報(エラー通知)を行うことも最近ではごく一般的なことだと思います。

ログ出力の方式の失敗

さて、そのログ出力処理ですが、あるシステムでは、ログ出力処理にログレベルとメッセージコードの両方を渡していました。これは愚直な方法ですがシステム全体において両者の整合性を保つ必要があるため、正直しんどい方式です。

そこで、私がアーキテクチャを担当した別のシステムでは、メッセージコードだけを渡す方式を採用しました。ログ出力処理の中で渡されたメッセージコードからログレベルを判別して以降の制御を行うというものです。これはほとんどの場合においてうまく行きましたが、ログレベルの変更に弱いということが分かりました。ある事象についてのログレベルを変更したいという場合、ログ出力処理を呼び出している個所のメッセージコードも併せて変更する必要があるということです。

また、ログレベルと画面遷移が必ずしも対応してないケース、つまり、同じレベルのエラーでもエラー画面に遷移すれば良い時もあれば、前の画面に戻したい時もあり、そういったケースでは単純な共通コードでは実現できないため少々苦労しました。それに、ログレベルが変わっただけで画面遷移(あるいはジョブ制御)が変わってしまうと不都合もあるでしょうし、バグになりやすいのです。

ログレベルとメッセージの現実的なアイデア

そこで、現実的にはログレベルと制御を分離した上で、ログレベルの変更に強いログ出力方式を考案する必要があります。前提として、メッセージの文言は定義ファイルに設定されており、メッセージコードから一意に引当てることができるものとします。

いくつか考えられると思いますが、ログに記録するメッセージコードの体系は、既に運用設計の中で定められており自由に決められない場合があります。そういう場合でも対応できるようにログに記録するメッセージコードとは別に内部のメッセージコードを定義すると良いのではないかと考えています。

この方式では内部のメッセージコードにはログレベルを表す文字を含めず連番(とその他の記号)のみとし、ログレベルはメッセージ定義ファイルの中に文言と一緒に定義しておきます。ログを出力する時は内部メッセージコードをログ出力処理に渡します。するとメッセージ定義ファイルからログレベルと文言を引当ててログに記録します。

こうしておくと、ログレベルを変更するにはメッセージ定義のみを変更すればよく、ログ出力処理を呼び出しているコードの修正を行う必要がありません。ログレベルの変更で悩まされたという方は是非一度試してみてはいかがでしょうか。

創業10周年の感謝

おかげさまで昨日9月1日に創業して満10周年を迎え、11年目がスタートしました。また、法人としても第4期がスタートしました。ここまでやって来れたのも周りの皆様の温かいご支援があればこそであると感謝しています。

こういうスタイルで仕事をしていると、よく「独立のきっかけは何だったんですか?」という質問を受けます。私はつい、その質問の意図を確認もせずに答えてしまうのですが、きっかけは勤務していたソフトハウスの解散です。私は中途で入社したのですが、その頃に随分と大きな赤字を出していたようです。

同僚や先輩のほとんどは新たな勤務先を見つけて転職しました。一部の同僚が独立しましたが会社員に戻ったと聞いています。私は元々いつかは独立して仕事をしたいと願っていましたので、ちょっと早いなとは思ったけれども一旦会社に就職してしまうと独立し難いかもしれないと考え、その会社の役員方の後押しもあり、思い切って独立の道を選びました。

解散当時は私はあるソフトハウスにアウトソーサーとして常駐していましたが、その契約を法人間から個人との契約に切り替えるという形で最初の仕事を頂くことが出来ました。そこからは現場で知り合った方の紹介を受けたり、元上司に呼ばれたり、エージェントを利用したりとギリギリ仕事をつないできました。

本当にあの時は全く何も解っていなかったと思います。多少なりとも解っていたら独立していなかったでしょう。もちろん今だって解っていると言うつもりは全くありません。むしろ独立したからこそ可能になった経験や出会いがあったのは確かです。

例えば、資格もそうです。会社員時代には資格には全く興味がありませんでした。でも独立してやっていくには資格が必要だと認識し、中でも上級システムアドミニストレータを取得した際には合格者のコミュニティである通称JSDGにも参加しました。また、独立事業者が集まるインディペンデント・コントラクター協会(IC協会)にも加入しました。独立するといわゆる同僚とか先輩といった概念がありませんので、外に出て様々なコミュニティに顔を出すしか人脈を拡げる方法が無いんですよね。それらのコミュニティを通しての出会いは自分にとって財産だと思います。

ところで、独立当初はずっとフリーのエンジニアとして個人事業主を貫くつもりでいましたが、一方でこのままで良いのだろうかという漠然とした不安や焦りのような感覚を覚えるようになりました。ちょうどその頃、いつもお世話になっているIC協会のセミナー等で、活躍されている諸先輩方の話を聴く機会が何度かあり、徐々に自分も法人化しようかなと考えるようになりました。

法人設立当初は大丈夫かなと思う局面もありましたが、結果的に主体的に考えることも多くなったし、ビジネスという観点では動きやすくなったと思います。なにより個人の時と比べて信頼されやすくなったという実感もあります。私にとっては第二創業ともいうべき法人化がまだ軌道に乗ったとは言えないものの、以前より展望が開けてきました。

今後とも引き続きどうぞよろしくお願いいたします。