イベントログ収集ツール fluent リリース!

こんにちは。Treasure Data の古橋です^^;
先日の Treasure Data, Inc. 壮行会 で、イベントログ収集ツール fluent をリリースしました!

Fluent event collector


fluentsyslogd のようなツールで、イベントログの転送や集約をするためのコンパクトなツールです。
ただ syslogd とは異なり、ログメッセージに テキストではなく JSON オブジェクト を使います。また プラグインアーキテクチャ を採用しており、ログの入力元や出力先を簡単に追加できます。


Twitterでも話題沸騰中です:イベントログ収集ツール #fluent 周りの最近の話題

背景

「ログの解析」は、Webサービスの品質向上のために非常に重要です。Apacheのアクセスログだけに限らず、アプリケーションからユーザの性別や年齢などの詳しい情報を集めることで、価値ある情報を数多く抽出することができます。

しかし、これらの イベントログをどうやって集めるか? という問題があります。ログを吐き出すアプリケーションは、複数のサーバに分散しています。それらのログを1箇所に集約してくる必要があります(とはいえ SPOF になってしまうのはイヤですね)
あるいは Amazon S3 や HDFS に書き出したくなります。その他にも Cassandra や MongoDB などに書き出したいケースもあります。ファイルに書き出すなら日付ごとにファイルを分けて欲しいし、当然圧縮もして欲しい。できればプラグインで拡張できると非常に嬉しいところです。


fluent は、これらの問題をシンプルに解決するイベントログ収集ツールです。

イベントログの転送とHA構成

fluent を使うと、↓このようにイベントログを転送したり、ルーティングすることができます。

fluent routing
fluent forwarding

転送先のサーバがダウンしていたら、バックアップサーバに切り替える機能もあります:

fluent HA forwarding


ちなみにラウンドロビンで負荷分散することもできます。これらの機能はすべてプラグインで拡張することができます:Fluent plugins

アーキテクチャ

fluent は全面的にプラグインアーキテクチャを採用しています。コア部分は小さいプログラムで、その他はすべてプラグインで成り立っています。

fluent plugin architecture


プラグインには次の3種類があります:

Input plugin
アプリケーションや他のサーバからログの受け取ったり、様々なデータソースから定期的にログを取り寄せてきます。
Buffer plugin
ログをバッファリングし、スループットを向上させたり、信頼性を向上させる役割を担います。
Output plugin
ログをストレージに書き出したり、他のサーバに転送したりします。


Input plugin や Output plugin は、Rubyを使って簡単に書くことができます:Writing plugins

また、RubyGemsでプラグインを配布・インストールすることができます。↓このコマンドで、現在リリースされているプラグインの一覧を見られます:

$ gem search -rd fluent-plugin


まだリリースから数日しか経っていませんが、実は既に MongoDB プラグインや S3 プラグインが公開されています^^; 非常に簡単に書けるようになっているので、バシバシと拡張してみて下さい。

fluent のリポジトリは github にあります:http://github.com/fluent

構造化ロガー

多くのアプリケーションでは、人間が読むことを前提としたテキスト形式のログを書き出していることが多いと思いますが、今後はプログラムで処理しやすくするために、構造化されたログに移行していく必要があるでしょう。
テキスト形式のログをパースして構造化する*1という方法もまだまだ必要そうですが、アプリケーションが直接構造化されたログを書き出す方がずっとシンプルです。

そこで、各種のプログラミング言語向けに、構造化されたログを書き出せるライブラリが欲しくなります。標準的なテキスト形式のロガーを拡張する方法や、別に作って両方使う方法など、色々な実装手段がありそうです(腕の見せ所ですね)


というわけで、Ruby で fluent 向けの構造化ロガーを実装しました。fluent 向けと言っても、設定次第でファイルやsyslogに書き出すこともできます。

fluent/fluent-logger-ruby - GitHub


「こんなAPIの方が使いやすい」「それは俺が昔通った道」「PHP版作った」などのコメントをお待ちしています^^;

*1:[http://twitter.com/#!/doryokujin:title=@doryokujin]さんや[http://twitter.com/#!/tagomoris:title=@tagomoris]さんをフォローしていると、このパースする処理のメンテナンスがどれだけ大変かを窺い知ることができます…