プログラマが知るべき97のこと/冗長なログは眠りを妨げる
開発中のシステム、あるいは製品としてすでに稼働中のシステムがあるとします。そのシステムに、すぐに目につく問題があるとすれば、それはまず「ログが汚い」ということではないでしょうか。 思い当たることがある人も多いでしょう。たとえば、あるWebページをごく普通に見ていて、リンクを1つクリックしただけなのに、システムの提供する唯一のログに大量のメッセージが記録されている、というようなことがあるのです。 ログの情報があまりに大量だと、ログが無いのと同じくらいに役に立ちません。
私たちプログラマが開発するシステムは、開発が終われば、その後は誰か別の人が使うことになります。 プログラマとしては、開発したシステムはできるだけ長く残って欲しい、長く使われ、その間ずっとユーザの役に立つ存在であって欲しいと望むのが普通でしょう。 しかし、システムが製品として稼働し始めてから問題が起きることもあり得ます。 それを私たちはどのようにして察知すればいいのでしょうか。 また、その問題にどう対処すればいいのでしょうか。
誰かがシステム監視をするかもしれません。 開発に携わったプログラマが自らシステム監視をすることもあるでしょう。 いずれにせよ、監視をするとすれば、その中でログが必ず一定の役割を果たすことになります。 ログに何か不穏なメッセージが記録されていれば、場合によってはたとえ寝ていてもすぐに起きて対応しなくてはならないでしょう。調べてみれば深刻な問題ではないかもしれませんが、どんなものかまだ分からないうちは対処せざるを得ません。 もちろん、システムに本当に重大な問題が発生していて、今にも止まりそうだというのなら、それが察知できないのでは困るでしょう。 しかし、本当はさほど大きな問題でもないのに、寝ているところを起こされるのではたまりません。
システムに何か問題がある場合、ログに残ったメッセージで最初に知ることになります。 多くの場合、そのログはエラーログです。 あらかじめ、そう認識しておくことは大事です。 開発の初日、あるいは稼働の初日から、エラーログに何かが記録されたら確認すべきです。 自分が現場にいない時にエラーログに何かが記録されていることがわかったら、たとえそれが真夜中で自分が寝ていたとしても、即時に知らせてもらうようにしても良いでしょう。 実際の稼働時の負荷をシミュレートしたシステムテストが実施でき、その際、エラーログに問題を示すようなメッセージが何もなければ、システムの堅牢さがまずは一定以上には達しているとみなせるでしょう。 もしそうでなければ、警戒して早めに対策をする必要があります。
分散システムの場合は事情がより複雑になります。 外部との依存関係に問題が生じる可能性がどのくらいあるかを見極めなくてはならないからです。 分散化の度合いが高い場合には、依存関係に問題が起きる頻度も高くなるでしょう。 ロギングポリシーもそれを考慮したものにする必要があります。
一般に、全てが上手くいっているときには、優先度の低いメッセージがログに定期的に出ていることでしょう。 参考程度に見た方が良いINFOレベルのメッセージなら、重要なアプリケーションイベント1つにつき1つ出れば十分です。
ログに、不要なものも含め、あまりに多くの情報が記録されると、システムの監視には役立たなくなってしまいます。 本当に重大な問題が起きた場合以外、基本的にエラーログには何も記録されない、というくらいの方が良いと言えます。 その場合は、エラーログにメッセージがあるというだけで、システムに重大な問題が発生しているとすぐ判断できるからです。