アプリケーションログは次の2つのことを守ること
- ログは目的ごとに適切に分けること
- 必要な情報を過不足なく出力すること
ログを目的ごとに分けること
アプリケーションログはアプリケーションがどのような動作を行ったかを過不足なく記録するべきだ。
アプリケーションから出力できる情報は実に様々なものだ。 例えば、リクエストの開始と終了、ユーザーID、リクエストヘッダー、処理結果、etc… ユーザーがどのブラウザからアクセスしたかを解析するためにユーザーエージェントを出力するかもしれんし、レスポンスタイムを記録したいかもしれん。 そしてアプケーションログに過剰な情報があふれ、混沌が訪れるのだ。
どのようなアクセスがあったかはアクセスログに出力するべきだし、アプリケーションログはアプリケーションがどのような動作を行ったかを記録するべきだ。
必要な情報を過不足なく出力すること
では何が必要な情報で、何が不要な情報なのか？
まず、アプリケーションがどのような動作をしたのかを出力するべきだ。 リクエスト処理がいつ始まり、いつ終わったのか、リクエストの結果としてどのような処理をしたか(正常終了か、異常終了か)、リソースに対してどのような処理をしたのかを出力するべきだ。
また、マルチスレッド・マルチユーザ環境では、どのスレッドで、どのユーザーに対する処理かを記載せねばならない。
そして、その詳細度はログレベルに従って出力せねばならない。
ERROR
システムが(あるいは処理ロジックが)予期していないエラーに関する情報を出力する。 処理の継続が難しく、リカバリーできない状況を想定する。 OutOfMemoryErrorとか、DBのコネクションが切断されたとか、ネットワークが繋がらんとかな
WARN
正常な処理ができない予期している問題に関しての情報を出力する。 入力のバリデーションエラーや、権限のないアクセスなど、業務的に正常な動作ができない場合の原因等を出力する。 通常は適切なレスポンスを返すことで問題とならないが、WARNが連続する場合は外部からの攻撃やUIに問題があるなど大砲が必要となる。
INFO
システムがどのような動作を行ったかを出力する。 例えば、リクエストの最初と最後、正常処理の結果として何をしたかを記載する。
DEBUG
処理の詳細な情報を出力する。INFOで出力する情報は、外部設計レベルの話だったが、こちらは内部設計レベルの、各メソッドがどのように動いたかを出力する。
TRACE
完全な処理の詳細を出力するために使う。 メソッドのパラメータの値や変数の値、ロジック終了後の変数の値など、かなり細かい情報を出力する
参考リンク
