サーバの台数が多いほど、監視周りの機能が重要になる。 連鎖的にノードが落ちて性能的に破綻して、復旧に労力を費やすことになる前に予兆を掴まないとマズいケース。 内部の統計データを提供するインタフェースが必要そう。
ヤバい状態とヤバくない状態を整理しないといけないが、それはユースケースに依存するので、まずは基本機能だけサポートして他は拡張可能にしておき、プラグインにお任せする。
流れてきたログをローカルに保存し、HTTPか何かの要求に応えてデータを返すプラグインを導入する。
データは key, value, expire time の3値で保存する。expire time が経過したらデータを削除する。ずっとデータを提供させるためには、定期的にデータを入れること。
- BasicBuffer で統計情報を emit する機能。キューの長さを定期的に指定された tag で emit する。
- ログの流量を監視する filter プラグイン。秒間にいくつのレコードが通ったかをメモリ上で保持し、定期的に指定された tag で emit する。
ログは、アラートと監視と解析とサポートとデバッグと、その他諸々に使うし後で拡張もするから、それらを生成/収集するサーバ群は大量だし、その関係は複雑になるが、一方で疎結合化もしたい、という場合において、Fluentd は柔軟性が不足しているように見受けられる。
https://gist.github.com/3214251
ログを生成するサーバ群と、ログを収集/利用するシステムの疎結合化したい。
こういうケースでは pub/sub が定番。問題は耐障害性が問題で。耐障害性を考慮すると、おそらく pub/sub システムを別に作った方が良い程度に複雑化してしまう。だが可用性があれば良いという場合であれば大丈夫で、そういったケースも多いかも知れない（不明）。
流れてきたログをローカルに保存し、HTTPか何かの要求に応えてデータを返すプラグインを導入する。
「どこまでデータを返したか」もローカルに保持する。このあたりはKafkaを参考に。
耐障害性は考慮しない。
上記の監視用のプラグインのデータ構造を変更したもの。key,value,expire timeでデータを保持するのではなく、たぶん values, offset の2値。
Cool.ioを排除。JRuby で動かす。MessagePack を JRuby 向けに最適化する必要あり。
in/out_forward は Thread ベースに書き換える。in_tail は Thread と rb-inotify で書き直す。要気合い。