概要
世間ではDevOpsが話題になり、運用を考慮した開発を行うことになっていると思います。
そこでまずはログの設計について自分なりの考えをまとめていこうかと思います。
* 最近はあまりそういった開発にかかわっていませんが昔は ERROR,WARNINGの区別がついていなかったり、ログはERRORだけでいいじゃんなんて言われて何とも言えない気持ちになったので・・・
* 今後追記するかも
ログの出力レベル
ログの出力レベルは以下のものがあるかと思います。(個人の見解です)
| レベル | 用途 |
|---|---|
| FATAL | DBへのアクセスエラーなどアプリ以外の要因のケース |
| ERROR | アプリケーション内でのエラー時のログ 何等かの処理で失敗した場合など |
| WARNING | エラーではないが注意が必要な場合 特殊なパターンが発生したときなど |
| INFO | 情報としてログに残したいもの 監査ログやバッチ処理の件数など |
| DEBUG | 普段は出力はしないが設定を変更して詳細なログを出力したいとき用 |
各ログの使い方
- 各ログの使い方について見解を記載していきます。
- FATAL
- あまり使ったことがないですが、前提条件が整っていないときなどに使われている印象があります。
- ERROR
- ログを設定するときに必ず使うことになるかなと思います。
- 最近というほど最近ではないですが、AWS のCloudWatch Logs などで監視もできますこの辺参照 Lambdaなどでは特に設定しなくてもログが見られます。
- CloudWatch Events でログの監視を行いアラートの通知など行うようにする場合は
エラーが発生しました。の一文でメッセージを切るのではなく発生したExceptionの情報も同じ行に出力させる方がよさそうです。 - Exceptionのスタックトレースだけでなく可能であれば入力パラメータも出してあげると調査が楽になるかと思います。
- 注意するべき点は障害が発生した際に何が起こったか？を調査できるようなログを出せるようにしておくことかなと思います。
- WARNING
- エラーほどではないが注意が必要な状況がある場合に出力させます。
- 例としては以下のようなケースかなと
- 連番を発行する処理でエラーで再度連番を発行する場合
- 注意が必要なデータが来たパターン(エラーデータではないが、通常想定されていないようなデータ)
- INFO
- 処理の状況などを知らせるために使用します。
- WEB系の場合画面遷移の状況などを把握するために出力するときに使用します。
- 誰の操作かわかるようにセッションIDやユーザIDなどと合わせて出力させないとただのゴミになってしまいます。
- バッチ処理などで処理件数などを表示させて処理時間を計算させるように出力させます。
- DEBUG
- 普段は出力させず開発中や、本番で何かあったときに設定を変更して出力される時に使います。
- SQLのクエリやリクエストパラメータを出したり事細かな情報を取得するのに使います。
- FATAL
ログの出力設計について
- ログを出力するときの注意点
- 必要な情報を出力する。
- エラーログなどは原因となった入力値などを出力するようにする必要があります。
- 出しちゃまずいものは出力しない。
- 監査ログとして入力内容などを出す場合でも氏名やパスワードといった考慮が必要な情報は●で置き換えるなどしてログに残さないようにする必要があります。そうしないとログからパスワードなどが漏れたり個人情報保護法に引っかかったりします。
- 必要な情報を出力する。