記事を書くきっかけ
個人開発しているアプリで、エラー処理時にはとりあえずconsole.logでエラー出力をするようにしていた。
フロントエンドのテストコードを書いて、ログ出力についてテストコードを書いていたがふと疑問。
テストケースとしてやるべきか、だけでなくそもそもログ出力の必要性、出力内容について深く考えてなかったのでこれを機に調べることにした。
結論
- 出力する主なケース
- プログラムに例外が発生した場合
- データベースに存在すべき適切なデータがなかった場合
- セキュリティ保護の観点から、必要な情報のやり取りが行われたとき（顧客情報など）
- 出力内容
- 出力された理由（どこで出力されたかなど）
- 例外時に出力されるログの場合は対応につながる情報
ログレベルについて
適切なログレベルを設定することができれば、「開発者」や「運用者」を意識してログを出力させることができる。
一般的な例
- Fatal→システムの継続が不可能になるレベルのトラブルが起こった場合
- Error→システムのある機能の実行ができない状態になる場合
- Warn→システムのトラブルの中でも、想定内かつ軽微なもので、復帰が可能な場合
以下は運用者も閲覧可能なログとする。
- Info→システム処理が正常に行われているのを確認する場合（起動情報、ユーザーID）
以下は開発環境や、検証環境においてデバックのために使う。
- Debug→デバッグするために使用（セッション内部の情報やユーザーHTTPリクエスト、レスポンス情報）
- Trace→メソッドに渡された引数等、アプリの開発時のデバッグ情報
優先度
Fatal > Error > Warn > Info > Debug > Trace
ログに必要な情報
問題が起きた時にその問題を特定するために必要な情報
- 問題が起きた個所
- 受け付けた情報(リクエスト、プログラム引数)
- 変数(オブジェクトが持つメンバ/フィールド、できればローカル変数も)
- 関数(メソッド)の引数
- 外部連携の要求と結果(DBのクエリログや外部通信のリクエスト/レスポンス)
問題が起きた箇所自体ではなく、原因は他にあったりすることもよくあるため本来は関係しうる導線上全てでログを出すべきかもしれないが、さすがに量が多すぎて現実的ではない気がする。
所感
運用するうえでは、対応が求められるレベルの例外発生時のログだけでもよいような気がする。
ただし、セキュリティの観点から、異常アクセスやデータの持ち出し時のログやログインした人のユーザー情報などは出力するようにしておくべきと感じた。
また、ログの内容については、保守側が適切な対応をできるような情報を厳選して盛り込む必要があり、当該アプリの性質やチームの習熟度などから総合的に判断すべきと感じた。
瞬時に問題の大枠を予想し、対応ができないのであれば、ログ出力する意味がないと思うからである。
参考
http://www.code-magagine.com/?p=2215
https://ryozi.hatenadiary.jp/entry/20150201/1422727151