最近、開発業務でログの実装をちらほらやってます。
その際に悩むネタがあったので備忘録的にまとめます。
色々書いてはいるけど、最終的にはプロダクトの性質、方針の方に強く依存すると思います。
前提
- web系のコンポーネントの話です
- 今回対象とするログは、syslogやlog4jで取得するユーザーに直接見せないログです
- とりあえずLog4jを参考としてますが、昔からあるロギングライブラリは似たようなログレベルを持ちます
ログレベル、細分化しすぎ問題
一般にログ取得のライブラリはログレベルを指定することができます。
例えばLog4JだとFATAL, ERROR , WARN , INFO , DEBUG , TRACE などにログは分類されます。
ログは環境に応じて出力するログレベルを選択することができます。
このような仕組みにより、開発環境では全てのログを出力し、運用環境ではINFO以上のログを出力するようにしたり、と言った制御が可能になります。
ログレベルって、本当にこんなに種類必要・・・?
ログのポリシー設計をしていた時、思ったことです。
あれ、こんなにログレベルって必要なくない・・・?
ということで、設計時に考えたことをまとめてみます。
ログレベル | Log4Jで説明された役割 | 検討内容 |
---|---|---|
FATAL | 致命的なエラー。プログラムの異常終了を伴うようなもの。 | 不要。プログラムの実行時エラーはERRORレベルで取得すべき。 プログラム異常が発生するのであれば監視システムなどからアラートを発行させるべき。 |
ERROR | エラー。予期しないその他の実行時エラー。 | 必要。問題になった要因、解決方法を調査可能なように出力する。 |
WARN | 警告。廃要素となったAPIの使用、APIの不適切な使用、エラーに近い事象など、実行時に生じた異常とは言い切れないが正常とも異なる何らかの予期しない問題。 | 不要。サービスが継続可能であれば、確認する必要がない。 ユーザー入力・操作などの問題であればUIで通知すべき。 |
INFO | 情報。実行時の何らかの注目すべき事象(開始や終了など)。従ってメッセージ内容は簡潔に止めるべき | 不要。実行時に注目すべき動作はUIで通知すべき。 |
DEBUG | システムの動作状況に関する詳細な情報 | 必要。開発時、検証時に正しく動いているかを確認しやすくできる。運用時は出力する必要がない。 |
TRACE | トレース情報。更に詳細な情報。 | 不要。DEBUGと同じで良い (syslogとかだとそもそもTRACE存在しないし) あと、カバレッジテストやスタックトレースで開発時に担保する方が幸せになれそう |
ということで、今回はログポリシーを下記のようにまとめてみました。
ログレベル | 内容 |
---|---|
ERROR | エラー。処理が継続できない時に出力する。 エラーの原因を具体的に記述する。 リソース確保に失敗したなら、どのリソースが取れなかったかなどを明確にするなど。 復旧できない内容や、認証失敗など通知が必要なERRORはAlert通知を伴う |
DEBUG | 検証時に必要な情報。トレースログなども必要に応じて取得する。 |
上記に加えて、UIに通知領域を追加。
大体下記のような内容を出力するようにする。
通知タイプ | 内容 |
---|---|
Info | 処理の実行状況や処理の終了など、システム的にユーザーが知りたそうなことを淡々と通知する |
Alert | エラー発生時にユーザーに問題が発生したことを通知する。 |
Announce | メンテナンス情報など、運用側からユーザーに連絡したい内容を通知する |
ひとまずこんな感じで実装して不都合起きないか試してみようと思います。