ログを設計する上で重要だと思ったことについてまとめておこうと思います。
ログ設計の基本指針
ログレベルの設計
まずはレベル分けですね。
DEBUG
- 一番詳細な情報
- SQL、テキストエリアの文言、リクエストパラメーターなど
- 詳細な調査をしたい時に見る情報
- 全て見ると情報が多すぎて追い切れないレベル
INFO
- メソッドの開始、終了など
- 処理がどこまで進んだか、どこで止まったかがわかるもの
- 開発時にはこれが指針となる
- SQLやパラメータは重要度によってINFOに格上げしてもよい
WARNING
- 非推奨のメソッドやエラーではないが直しておきたい部分
- 処理は止めないが、警告として知らせたい情報
- 処理が完全ではない場合など
ERROR
- 明らかにエラー、状態がおかしい時
- if文などでキャッチできるエラー
- 異常終了する際の告知
- メールや別のチャネルなどで知らせる必要があるかも
FATAL
- 例外エラーやExceptionなどの予期しないエラー
必須情報
レベル以外に入れておいた方が良い情報など。
入れておくと便利な情報：
- ファイル行数（取得できる場合）
- クラス名、メソッド名（追跡のため）
- requestID、sessionID(一連のリクエストの流れをみるときにこれないとつらい)
- リクエストパラメーター（メソッドの引数）
- キー系のID情報 (伝票系だったら伝票番号など)
- エラーメッセージ (エラーはstacktraceまで含めて詳細に)
- InパラメータのJSONパラメータ（デバッグが楽になる）
ログ出力先の設計
開発時
- INFO以上を標準出力
- デバッグ情報も必要に応じて標準出力
運用時
- ERROR以上を標準出力
- それ以下はファイル出力
- 常時見る場所と調査をしたい場所を使い分ける
実践的なログ設計のベストプラクティス
ログ出力時の注意点
- 改行を避ける：特にSQLなど、不必要に改行を入れると非常に見にくい
- 記号+番号を入れる：ログが出た場所をすぐに特定できるため（例：LOG001、ERR002など）
- 文字制限を考慮：HTMLデータやパラメータが多すぎる場合は文字制限を入れる(いれないとログが汚くなりすぎる)
- stackTraceの確認：エラーメッセージでstackTraceなどがはっきりと出ることを確認
- 共通メソッドの注意：共通度が高いメソッドはログが大量に出て他の部分を邪魔することがある
運用上の注意点
ログレベルの調整
実際に開発をしたり、運用をしていく上で、レベルを調整していくことが重要です。
開発時の重点
- DEBUGとINFOの使い分けが重要
- 全レベルのログを出力（リリースまでは特に重要）
運用時の重点
- ERRORの設計（漏れがないか）が重要
- 本番環境では一定レベル以上のログ出力に制限
パフォーマンスへの配慮
- ログ出力によるパフォーマンス影響を考慮
- 必要に応じてログレベルでの出し分け
まとめ
ログ設計は開発の初期段階から計画的に行うことが重要です。適切なログ設計により：
- 開発効率の向上：問題の早期発見と迅速な解決
- 運用品質の向上：システムの健全性監視と問題予防
- 保守性の向上：過去の問題への迅速な対応
これらの指針を参考に、プロジェクトの特性に合わせてログ戦略を構築することを推奨します。