fluentdとシステム設計の小ネタ

あるいは http://yugui.jp/articles/879 へのreply。

システム監視をfluentdに統合してしまうべきか否か

システム監視は分けておいた方がいいと思う。分けるべき、とまでは言わないけれど。

それらの仕組みには相応の必要な機能セットがあり、それらは長い歴史の中で比較的決まった機能セットに収斂してきており、その収集・モニタリング・可視化・アラート通知など決まりきったパターンを様々な項目について停止なく行う必要がある。

Fluentdの各種プラグインを用いることで同じような機能は実現できる。そのプラグインのうち数割は自分が書いものだったりする。とはいえ各ホストのシステム監視までそこで行うことを想定して書いたかというと、もうちょっと高いレイヤでの監視・集計、つまりサービス単位などを目的としたものが多い。サーバ単位で行おうとしたときに設定が雑多なものになるのはおそらく避けられないと思う。

またシステム管理はサービス単位の監視とは別に行ったほうがよい、というのが自分の考え。サービス全体の生き死に・エラー発生率監視などと、サーバ単位でのhttpd/database/application serverの生き死に・負荷監視などは分けておいたほうが、片方で何かあったときにクロスチェックにもなる。逆に3系統以上に増やすとカオス一直線なので、サーバ単位とサービス単位の2系統程度にしたほうがよいとも思う。

fluentdはなぜMQベースのアーキテクチャでないのか

ソフトウェアとしてそちらの方がシンプルだから。ではないのかなあ(まあ @frsyuki に確認したほうがよいんだろうけど。)。

単純に動作を追うにはひとつのプログラムとして完結していた方が見通しがよい。特にメッセージの伝達回りを外部に依存すると全く異なる複数のソフトウェアの信頼性・性能等を個別に評価する必要があり、これは一般にはソフトウェアの採用に関する判断においてはマイナス要因となる、と思う。*1

もうひとつ、外部のソフトウェアへの依存を増やすと必然的に開発・リリースがそちらに引っ張られる。Fluentd開発において開発リソースは必然的に限られており、外部ソフトウェアの状況をトラッキングして適切に取り込む、という作業に割ける時間はあまり無いと判断されても不思議はない。現実として、Fluentdが依存しているライブラリは実質的にはMessagePackとCool.ioだけで、前者は @frsyuki が開発者だし、後者の開発も @repeatedly が引き取って、もはや外部依存があるのか無いのかという状況である。

まあ自分で書くほうがコスト低いからっていうの、判断としてどうかと言われると、そうっすねえ、という感じはあるけど、でも実際そうなんじゃないかな。

*1:MQにメッセージ伝達を任せるからといって、その間にいるソフトウェアの信頼性を無視していいかというともちろんルーティング段階で欠落したりする可能性も考えられるので、評価しないでよいわけはない。