ログの出力内容は意外と設計時に考慮不足で、コーディング時にプログラマのスキルに依存する事が良くあります。
何も問題がなければそれでもよいのですが、エラーメッセージが表示された場合に、どこで何が起きているのか？探すのにログが適切出ないと時間がかかり、利用者への迷惑だけではなく、担当者の作業時間も大きく関係してきます。
そんな背景もあり「６Ｗ２Ｈ」の観点で、設計段階で考えるログ設計の考慮事項を整理してみました。
Index
６Ｗの項目
出力日時 – [When]
・年月日時分
・秒やミリ秒の出力は必要か検討
・出力時間はUTCかそれとも日本時間か検討
補足:
年月日時分はログとして当たり前の項目ですね。秒・ミリ行はシステムの性質から必要可否を選ぶと思いますが、基本は出しても良いと自分は思います。
意外と見落としなのは基準時間をUTCにするのか、それとも日本などの地域時間にするのかです。グローバルなシステムの場合はUTCで出力し、さらに対象言語（Who項目）も出力するのが良いと思います。
出力箇所 – [Where]
・モジュール名
・パッケージ名・クラス名
・行番号
・スタックトレース
補足：
出力箇所はエラー時やデバッグによるトラッキング時がほとんどだと思います。これら項目がしっかり出力しているかが、エラー箇所の特定の時間に大きく左右されます。
また、スタックトレースはエラー発生時の処理手順を確認する大きな手がかりとなるので、例外エラー時には必ず出力した方が良いと思います。
メッセージ内容 - [Why]
・システム的なメッセージ（例：Exceptionなどのシステム・開発言語固有のメッセージ）
・アプリ的なメッセージ（例：表示メッセージや入力値などのアプリ固有のメッセージ）
補足：
エラーの場合など上記で記載したスタックトレースに加えてExceptionのエラーメッセージもあるとわかりやすいです。これに加えてお勧めする出力項目としては、画面に表示されるメッセージやエラーの原因となった項目及び値です。表示メッセージは「やりすぎ」と思われるかもしれませんが、意外と出ていると問い合わせの時など、エラー箇所を早く見つける事が出来ます。
また、値出力の注意事項は後ほど記述します。
出力者 – [Who]
・IPアドレス
・プロセスID
・セッションID
・ログインID（ログイン済みの場合など）
・ユーザエージェント（OSや端末情報など）
補足：
Webなどの場合はひとつのログに複数ユーザの処理内容が出力されます。
そうした場合に、「誰のログか？」を特定する必要があります。特定と言っても調査時にグループ化できれば良いです。とくにアクセスログの時は「どんな操作をしたのか？」を把握するためにも、この項目が重要になってきます。
ログレベル – [What]
・種類（Info・Worning・Error・Debugなど）
補足：
出力されているログが情報なのかエラーなのかをグループ化するために設定します。
設計の段階では種類をあげて、それぞれの種類にはどんな時にどういった内容を出力するのか、明確にしておく事が重要です。これが出来ていないと、本番環境などの出力レベルの設定などで、必要な情報が出なくなったり、ログが肥大化してしまうなどの問題が発生します。
処理元 - [Whom]
・ホスト名
・IPアドレス
補足
最近は複数台のサーバで分散して処理する事が多くなってきました。そういった場合、サーバ毎にログを分ける場合は問題ないのですが、一つのファイルにそれぞれのサーバが出力する場合は、「どのサーバが出力したのか？」を明確にする必要があります。
インフラ構成やログ出力方法にもよるため必須とは言えませんが、頭の隅に止めてもらえればと思います。
２Ｈ＋１Ｗの項目
出力方法 - [How to]
・モジュール（例：log4jなど）
・出力先（例：テキストファイル、データベースなど）
・種類（例：アクセスログ、エラーログなど）
・フィルタリング（例：エラー＋警告のみ出力など）
補足
出力先やエラーレベルなどでのフィルタリングはログ出力用のモジュールには機能として既にある場合が多いです。
それを知らずに機能作ってしまったりと、無駄にならないよう設計時にも機能は把握しておきたいものです。
出力するタイミング - [When]
・例外発生時（Exception）
・処理（メソッドなど）結果のエラー
・処理（プロセス・トランザクション・メソッドなど）の開始・終了時
・アクセスの開始・返却時
補足
処理後と役割（アクセス、ロジック、メール送信など）ごとにログを分けるのは一般的ですが、SaaS（最近この単語聞かなくなってきたな・・・）提供の場合、契約者単位でのログ出力も考慮する必要があります。
出力する量 - [How mach]
・ローテーション（サイズ・日付・世代数）
・過去ログの保管（圧縮・退避）
補足
最後にファイルサイズが肥大していくと、ディスク圧迫だけではなく、ログを見るのに時間がかかったり、最悪の場合は開くこともままならなくなります。設計時にファイルサイズや用途からローテーションや保管方法の検討は大切です。
まとめ
ログというのはトラブルがあったときすぐに調べられて解決出きるだけではなく、ログから予兆を見つけ事前にトラブルを回避することも出きるようになると思います。
そういった意味で、ここに記載したのは設計段階でログ設計するための元ネタになれば幸いです。
また、６Ｗ２Ｈで整理した内容を設計書へまとめて、コーディング時にはプログラマへしっかりログの必要性含めログ設計の説明をするようにしてください。
意外とプログラマは開発する上で自分に必要なログしか組み込まなかったりする物なのです・・・自分か（笑）
「こういった観点でもログ設計考えた方がよい！」と意見がございましたら、ぜひコメントいただければうれしいです！
出力する量 - [How mach] ⇒ How much
・種類（Info・Worning・Error・Debugなど） ⇒ Warning
綴り間違いが気になりました・・・