一つのシステムには無数の機能が詰め込まれ、毎日様々なバッチが実行されています。その全てが滞りなく動けば良いのですが、中にはプログラムミスや、仕様段階では想定していなかったデータによって、突然システムエラーを起こしてしまうことがあります。
とにかく急いで対処しなければなりませんが、ログ出力機能の作り込みが甘いと、問題の解析だけでもかなりの時間を費やすことになってしまいますよね。
ログの出力時にはどんな点に注意すべきか、そのポイントについてご紹介します。

重要な情報を漏らさない

ログ出力において最も重要な点は、もちろん詳細なエラー内容です。エラーメッセージの他にも、そのエラーが発生したタイムスタンプ、データ名、ファイル操作をしていたならそのファイルパスを明記しましょう。
後々解析するため、フィルタリング用の情報を盛り込むことも重要です。例えば警告とエラーの区分を示す「エラーレベル」、エラーが発生したソースコードを示す「機能ID」などが挙げられますね。
また、各情報はエクセルなどでの取り込みをしやすいように、分かりやすい区切り文字を用いて連結するとなお良いでしょう。

ローテーション機能を搭載する

エラー解析しやすいように大量のログを出力していくと、今度はその出力量が問題になってきます。システムを長年使い続けるうちに、どんどんディスク容量を圧迫していき、気づけば数十ギガバイトという膨大な量になることもあります。
それを防ぐためには、一定期間、または一定サイズに達した時に、ログを待避する機能を用意しておくと良いでしょう。
期限に達したログは、そのまま削除してしまうか、圧縮し別ドライブに移動するのが一般的です。どちらにするかは、ログの重要性に応じて決めましょう。

32bitのOSは要注意

32bitのOSの場合、ログファイルのサイズには注意する必要があります。搭載されているメモリのサイズによっては、ファイルサイズに上限があるケースがあるのです。しかもその上限は意外と小さく、Windowsの場合は４ギガバイト、Linuxの場合は僅か２ギガバイトしかありません。
本番環境が64bitだとしても、いずれ32bitの開発環境を立ち上げることになる可能性もありますので、ファイルサイズはそれぞれの上限を越えないように作っておいた方が無難です。

inodeについても考慮する

Unix系のシステムの場合、気を付けなければならないのは、Disk容量だけではありません。一つ一つのログサイズが小さくとも、inodeの圧迫によって、Disik容量よりも先に機能がストップしてしまう可能性があるのです。
ログ出力機能を作成する時は、見た目のDisk容量だけではなく、inodeの容量についても調べた上で設計するようにしましょう。

後々苦労しないように、キッチリ作っておこう

ログに関する機能は、クライアントからすると必要な機能ではないので、業務要件に挙がることはまずありません。そのため工数を見積もることは難しく、短納期の仕事だと、ついついログの搭載を怠ってしまいがちです。
ですが、万が一バグが発生した時のことを考えると、それがどれほど恐ろしいことかは言うまでもありませんよね。後の苦労を少しでも減らすため、必ずログ機能は用意しておくべきでしょう。