ログには何を出力するのが良いだろうか

12月を迎え、1年のふりかえりをする季節だ。
成長した点もあったと思うし、失敗したことももちろんたくさんあって、中には「あの情報をログに出力しておけばもっと早く気付ける事象だったかもしれない」といったこともあった。

そんなこんなでシステムのログにはどんな情報が必要か、どんなことに気を付けるべきか考えてみたい。

出力するもの

エラーと例外情報

ログが一番役立つときといえばトラブルシューティングだ。
エラーメッセージとスタックトレースを出力して問題個所を突き止められるようにしておきたい。

アクセス情報

誰が、いつ、どこから、どのようなアクセスを行ったかがわかるようにしておく。
認証時のエラーも記録することでセキュリティ的な視点からも運用改善に役立てたい。

各サービスとのやりとり

リクエスト内容、レスポンス内容を記録する。
データが各箇所を回るときは、そのポイントごとにデータ欠損がないか確認できるようにしておきたい。
サービス間の通信エラーも判断できるようにしておく。

サービス特有のイベント発生時

ログは適切に設定すれば使用しているシステムがある程度自動で出してくれることが多いが、それ以外にサービス特有のイベント発生時と実行結果は意図してログメッセージを挿入しておくと目印になる。

時刻

時刻を記録することは言わずもがなだが、JSTとするかUTCとするか等、サーバの設定と併せて適切に出力する。

Prefix

必要に応じてJobのIDなど、処理のキーとなる値をPrefixにつけておくとその値で一連のログを検索できる。

セキュリティ上気をつけること

パスワードや個人を特定できるような情報は各プロジェクトの方針に応じてマスク処理を施す。

通知設定

ログレベル（FATAL、ERROR、WARN、INFO、DEBUG、TRACE）を適切に設定し、内容に応じて通知を出す。
通知は多すぎると形骸化して重要な情報を見逃す原因となるため、必要な情報のみに留める。

残しておくべき期間

セキュリティ的な観点からも、肥大化を防ぐ目的からも、出力場所やログローテーションを適切に設定し、期間を過ぎたログは速やかに削除されるようにしておく。

さいごに

トラブルシュート時に重要な役割をもつログ。
誰が、どんな時に見るのか考え、開発時だけでなく運用時の観点も含めて設計する必要がある。
そうすると見やすさも重要になってくるのでログフォーマットについてもぜひ皆で考えていきたい。