概要

世間では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のクエリやリクエストパラメータを出したり事細かな情報を取得するのに使います。

ログの出力設計について

ログを出力するときの注意点
- 必要な情報を出力する。
  - エラーログなどは原因となった入力値などを出力するようにする必要があります。
- 出しちゃまずいものは出力しない。
  - 監査ログとして入力内容などを出す場合でも氏名やパスワードといった考慮が必要な情報は●で置き換えるなどしてログに残さないようにする必要があります。そうしないとログからパスワードなどが漏れたり個人情報保護法に引っかかったりします。