2014/06/15

便りが無いのは良い便り

完全に個人の日記レベルの話ですが、コンピュータのログと通知の話を書きます。

ログといってもまぁいろいろあるわけですが、何のためにログ取ってるかというと、異常なことが起こったことが分かるように、とか異常が発生したときに原因が分かるように、とかもっと進んだ考え方でいえば異常の予兆をとらえるとか、そんな感じかと思います。

なので最初はとりあえず異常なことが起こったら分かるようにログに記録するというのが最初に一歩になります。それが出来たら異常が発生したときの原因究明がすぐできるように詳細な情報をログに残すようにして、最後に正常な処理もログに残していけば危険な予兆をとらえることができるようになるかなと。なんか書いてみたら至極当たり前っぽい感じになりました。おそらく運用をやっているエンジニアはみんな気をつけていることだと思います。

ログというのは大量に存在して価値があるものなので、記録することに価値があるといっても過言ではありません。というのも、後からログを取ることはできないからです。過去にデータが欲しいと言われたときに「いやーそのデータはログに残ってないんすよねー」って申し訳ない感じで答えたことがある人も多いのではないでしょうか。

今だとビッグデータ分析みたいなところで価値が埋まっている大量のログを分析することでさらなる価値を生み出すようなことがビジネス上重要になってきているので、ビジネス的にもインフラ的にもログをきっちり取ることは重要になってきています。

さて、次に考えることは通知です。

なんかあってログに記録していても気付かないんじゃしかたない。過去の経験においても「システムは異常を検知できていたけど人間がそれに気付かなかった」というところから来る悲劇を見たり聞いたりしてきました。

例えばインフラであれば冗長システムで片方止まってる/故障してることに気付かないまま使い続けて両系ダウンしたとか、あるあるですよね。たいていそういうシステムって両系ダウンすることを前提にしていないので、非冗長システムよりも復旧がやたら大変だったりします。ビジネス的にも「なんか一昨日うちのサービスバズってたの? やたら新規登録来てたみたいだよ」「へ〜でももうまた通常な感じになっちゃってますねー、人が来たときに施策を打てばよかったなぁ」とかいう話、あるのではないでしょうか。

そんなわけでそういったことをちゃんと気づけるように、通知手段をいろいろ考えるわけです。メールとか、SMSとか、パトランプとか、IRCとかHipchatとかslackとかまぁいろいろありますね。

ぼくはいずれも通知を受けるというのは通知を受けたい人がその情報源を購読(subscribe)する行為だと思っています。push型pull型、情報の取得方法はそれぞれですが、行為としては購読であると。ログを書き込む行為とはちょっと違うわけです。本当に欲しい情報(異常およびその予兆)だけほしいわけですね。

なんでこんなことを書いたかっていうと、社内のIRCにbatch処理の結果などが成功失敗を問わず流れてくるチャンネルがあって、それに対してなんかずっとモヤモヤした違和感があったからなんです。通知チャンネルなので、まぁたしかに成功したことを通知してくれるのは最初は嬉しいんだけど、基本的に成功するのが当たり前の世界なのでそのチャンネルのログを見なくなるんですよね。

なんでこういう違和感が生まれたのかなーと考えてみると、そこが通知チャンネルではなくログ垂れ流しチャンネルの様相になっていたからなんだなと。IRCで特定のチャンネルに入る行為はどちらかというと購読の概念になるので、99.5%以上成功する処理が成功したというメッセージは情報量として非常に薄っぺらく、IRCログが埋まってしまうとログを遡って読むのが億劫になります。

同様に、毎時のログイン者数みたいなスナップショット的情報が頻繁に流れ続けても大きな動きが無い限りは情報量が薄っぺらいものでログが埋まってしまうことになります。まぁその辺はサービスの性質的なものにもよるので毎時流す意味がないと言い切ってしまうのは少々乱暴ですが、購読の概念を持っているところに薄っぺらい情報を流し続けるメリットはあまり大きくありません。

そう考えると成功ログのような情報量のほとんどないメッセージは流さないのがいいのかなーと。便りが無いのは良い便りといいますが、まさにそれではないのかなと。失敗したときや、メトリクスに大きな動きが出たときだけ何かが流れて、すぐ異変に気づける。それで十分なのではないかと思います。

こういう話をすると「バッチの成功が流れないとそもそも処理が開始されたか(走ったか)が分からないじゃないか!」みたいな話も出てくるのですが、じゃあ逆に聞くけど1時間ごとに数個〜数十個のバッチ処理が走ったかどうかをちゃんと毎日毎時間漏れなく確認してるのかなーと。

そういう設定をした直後の最初の頃は当然すべきだと思いますし、その時はちゃんと定期実行出来ているということが情報として価値のあるものなので、IRC等の購読機構に流れてくると安心できます。しかし、cronとかで定期実行するのが安定したらたぶん確認しなくなるのではないかと思います。その時点で定期実行出来ている、という情報の価値は一気に落ちているからです。

とはいえ本来走っているべきものが走っていないというのは非常に困ります。でもそれってcronのログを監視して走ってなかったらアラートにするというなどの方法である程度カバーできるはずで、そこまで対策が難しいわけではないかなと思います。/var/log/cronは普通rootしか読めないのでそこが面倒な感じはするので、処理を行ったら特定のファイルを更新するようにしてそのファイルが特定の時間以上更新がなかったらアラートとかそういう感じでもよいでしょう。

まぁそんな感じで、ログを取るってことと通知を受ける/購読するってことは別者です。そこを間違えると通知手段を一つ潰してしまうことになってもったいなくなってしまうので注意が必要だな、と思ったという話でした。