【システム開発】ログ出力の意義

Webアプリや、スタンドアロンアプリ等、アプリに問わずですが、必ずログは出力させますよね。

そんなログについて情報を整理していきます。

ログ出力の意義

システムは、作って終わりではなくそのご運用、保守をし続ける必要があります。システム障害もつきものです。

その際に、原因究明の足がかりとなるのが「ログ」になります。

ログを出力させるケース

プログラムに例外が発生した場合

データベースに適切なデータがなかった場合

ログをどこに出力させるか？

画面（標準エラー出力）、ファイル等考えられますが、「ログファイル」等の簡単には消えない媒体に保存するのが望ましいです。

ログ出力の内容

情報が少なすぎても、解決することができないですし、多すぎても情報を読み取るのが大変になってしまいます。

また、「開発時に必要なログ」と、「運用時に必要なログ」では、情報が異なるので、その辺も考慮が必要になるでしょう。

ログレベルについて

そこで、重要なのが「ログレベル」を意識して実装することです。適切なログレベルを設定することができれば、「開発者」や「運用者」を意識してログを出力させることができます。

一般的には下記の6種類に分かれるでしょう。

• Fatal
• Error
• Warn
• Info
• Debug
• Trace

Fatal

システムの継続が不可能になるレベルのトラブルが起こった場合にこれを出力します。

システム管理者に即メールを飛ばすレベルですが、普通の例外ではまず起こることはないでしょう。

Error

システムのある機能の実行ができない状態になる場合に出力します。

システム運用者が原因究明できるレベルの情報が出力されているのが望ましいです。

Warn

システムのトラブルの中でも、軽微なもので、復帰が可能な場合に出力します。

緊急対応が必要なくても、システム運用者に警告する必要がある情報を出力しておきます。

Info

システム処理が正常に行われているのを確認する場合に、出力します。

ただ、やたらと出力すると、ログを吐きまくって、容量の逼迫や、情報を探すのが困難になりかねないので、必要な情報に絞って出力させます。

基本的に、システム稼動時に、運用者に見せるログとしてはここまでです。

Debug

開発環境や、検証環境でデバッグするために使用します。システム稼動時は、Debugログ以下は、運用字は出力させません。

Trace

メソッドに渡された引数等、アプリの開発時のデバッグ情報として必要な情報は徹底的に盛り込みます。

開発者が必要だと思う限り、自由に出力してもかまいません。

ログレベル設計は非常に大事！

ログレベル設計は、非常に重要です。個々人で、基準を任せるのではなく、最初の設計段階で、どのような基準でログ出力するのかを明確にする必要があります。

なぜなら、運用監視時に、ログ出力されたログレベルに応じて、監視ツールでアラートをあげたりする場合もあるので、その基準が明確でないと適切な運用監視ができなくなってしまうためです。