Webアプリケーションにおけるログレベルの設計

Webアプリケーションのログ設計を考えるとき、考慮すべきことの一つとして
ログレベルの設計が存在する。

今回は、個人的なログレベルの判断基準を紹介する。

概要

まず、私が使うログレベルは3種類だ。

より細かい分類をすることは可能であるが、チーム開発で管理や共通認識が取りにくくなるので
細かく分けすぎないように設計している。

ログレベル	基準
ERROR(もしくはCRIT)	1発アウトのログであり、基本的に発生してはいけないもの。これが発生した場合は即時対応する。
WARN	n分以内にn回発生したときに対応するログ。即座に対応は必要ないが、異常の前兆や問題の可能性があるもの。
INFO	正常系のログ。後で集計したい情報や、問い合わせがあったときに追跡したい情報を出力する。
DEBUG	デバッグ用のログ。本番環境では出力せず、開発環境のみで出力する。

これは、基本的に本番環境で一度も発生しないことが望まれるログである。

例えば以下のようなケースであり、発生したら即時対応する。

少し発生したくらいではさほど問題ないが、連続して発生していたり、発生頻度が高い場合に問題があるログである。

例えば以下のようなケースであり、閾値はそれぞれ個別で設定する。

ケース	備考
外部のAPIリクエストでエラーが発生した（ただし、その後リトライが実装されているので大丈夫）	APIタイムアウトの発生頻度が多い場合は、タイムアウトの設定値を見直したりAPIのパフォーマンスを改善すべき。 APIによっては5XXエラーは稀に発生する場合があるので、一時的なエラーとしては問題ない扱いとするが発生頻度が高い場合は要調査。
404 or 400が発生した	たまに発生するのは問題ないが、あまりにも連続して発生している場合デッドリンクや不正アクセスの可能性がある
認証失敗	単発なら問題ないが、立て続けに発生する場合は不正アクセスの可能性あり

基本的にはERRORやWARNに該当しないログを出力する。

主に利用状況の集計をしたい場合や、問い合わせ時の追跡に必要な情報を出力する。

ケース	目的
ログイン成功、ログアウト、パスワード変更など	利用状況の集計、問い合わせの事実確認に使う
データの登録や更新、削除	問い合わせがよく発生する観点
外部APIリクエストにかかった時間	あとからボトルネックの分析で使う
「リトライした」というログ	パフォーマンス劣化の兆候であるため、モニタリングしておく
処理開始、終了	バッチの場合は、起動時刻や実行にかかった時間を確認するため APIの場合は、パフォーマンス改善につなげたり、問い合わせ内容の特定に利用
【バッチ】処理対象データのID	どのIDが処理対象として選択されたのか追跡可能
【バッチ】処理件数	何件のデータを処理したのかを確認する

INFOでデバッグ用のログを仕込んでしまうと、万が一そのままmainにマージされたとき、個人情報がログに出力されるリスクがある。

開発時にデバッグしたいときはDEBUGレベルのログを仕込むことによって
このようなリスクを低減させる目的で使っている。

基本的にプルリクエストがマージされるタイミングで削除しているので、
ソースコードにこのDEBUGログが残ったままになることは少ない。