［アーキテクチャ編］構築メンバーの目線だけでログ出力を設計してはいけない

　一般に，稼働しているアプリケーションのエラー・ログに関心を寄せるのは，運用担当者と保守開発担当者である。運用担当者はエラー・ログからエラーの内容や重要度などを読み取ろうとし，また保守開発担当者はエラー発生時のアプリケーションの状態把握に役立つ情報を取得しようする。立場の違いによって，エラー・ログから得たい情報には差異があることに注意が必要だ。

　アーキテクトは，エラー・ログ情報の参照者がカットオーバーを機に構築メンバーから運用保守メンバーに切り替わることを念頭に，特に運用担当者や保守開発担当者の目線で，ログ出力について適切に設計する必要がある。スケジュールが窮屈なプロジェクトでは，ログに関する設計が後回しになり，配慮が行き届かないことが多いので，注意が必要だ。

記録内容の不足と表現に注意

　運用担当者の目線では，ログ・ファイルや監視コンソールへの出力内容が不足していないか，出力内容に誤解を招く表現がないかなどに配慮するとよい。アプリケーションにエラーが発生したら，ログ・ファイルへの出力と併せ，監視コンソールに警告を出力するのが普通だ。監視コンソールの警告を見た監視者は，そこからエラーの概要を読み取って運用担当者に連絡する。監視コンソールに表示すべき内容は，エラー・メッセージIDやエラー発生日時，重要度などだ。

　連絡を受けた運用担当者は，エラー発生時のログ・ファイルを参照し，エラーの内容を子細に調べ，エラーが起きた原因を探る。そして，アプリケーションの稼働を継続するか，サービスを停止するかについて判断する。ログ・ファイルへの出力が不足していたり，誤解を招く表現があったりすると，的確な判断が下せなくなってしまう。

状態解析に役立つ情報を記録

　また，保守開発担当者の目線では，アプリケーションにエラーが発生した際の状態解析に役立つ情報が記録されるように配慮したい。例えば，ある関数やメソッドでパラメータのエラーを検出した場合，「パラメータ・エラー」とだけ出力したのでは，意味がない。「どこで，どのパラメータが，どのような状態であったか」といった重要な情報が保守開発担当者に伝わらないからだ。次のような情報が保守開発者に伝わるよう，配慮することが大切である。

●発生個所を特定できる情報（ソース・ファイル名や行番号など）
●問題となったデータ項目やパラメータの情報とその状態
●エラー発生時の要求データや，関連データの特定に必要なキーなど

ログ肥大化を問題視する前にエラー根絶

　こうした情報をすべてアプリケーション・エラーのログ・ファイルに出力すると，ファイルの肥大化が問題になったり，ディスク・アクセスが頻発して性能劣化が起きたりするのではないかと，懸念を持たれるかもしれない。しかし，そこまで頻繁にエラーが発生するとしたら，エラーの根絶が最優先の作業となる。通常，アプリケーション・エラーのログ・ファイルでサイズやアクセス頻度が問題になることはあり得ない。

　なお，ログに出力する内容を決める際には，各プロジェクトのセキュリティ・ポリシーと照らし合わせる必要がある。例えば，個人情報などをログに含めてはいけないことがある。