fluentdを触ってみたのでメモ

ログ収集・配送ツールfluentdをしばらくぶりに触ってみた感じをメモ。

組み込みのバッファが便利

fluentdコア側で各プラグイン毎にスレッドを起動し、バッファ管理とスレッド間のログの受け渡し処理を担うことで、プラグインは逐次的に書くことが出来る。

スレッドより細かい並列化・非同期化はプラグインが各自で行う。主なinputプラグインはcool.ioを使ったサーバーとして動作し、outputプラグインは単にスレッド毎にコネクションを持つか独自のコネクションプールを使っているようだ。

後段のoutputプラグインで部分的な失敗やACK相当の部分が失われたりしてもロールバックのような機構はない（かプラグインが自前で実装する）。トランザクションIDのようなものも無く、リトライによる重複が困るならログにUUIDを含めるなどユーザー側で対応する。

通常のBufferedOutputプラグインならバッファ管理は全てfluentd側がよきに計らってくれるので、基本プラグインは逐次処理するだけで十分実用になる。単にIOでブロックしているならスレッドを増やして対応できる。

ただ（UnBufferedな）Outputプラグインの場合inputプラグインから直接呼ばれているようで、inputプラグインのスレッドがブロックしてしまうとのこと。 out_stdoutのようなデバッグ向けか、filterプラグイン導入以前にバッファのオーバーヘッドなしに多段output出力をするためだったみたい。今は軽い処理はfilterプラグインに書けばいいのでほぼ不要。

設定はDSLで

標準の設定ファイルのパーサは独自書式。以前クオート中の"#"がコメント開始と認識されててハマったりした。 tagを変えないfilterが追加されたので記述順序も意味をもつようになった。

その後rubyのDSLで書けるようになっていた http://qiita.com/toyama0919/items/10616cb9025cb9cecd69 ので結構楽に。 これで正規表現のエスケープに悩む必要も無くなった。

外部ライブラリを使いにくい

内部エンコードEncoding.default_internalをなぜかASCII-8BITに強制していて、文字列としてASCII互換エンコードを期待するライブラリが壊れてしまう。 いちいちfluentd用に書き直す必要があるので、複雑な処理をしようとすると苦行になりそう。

サーバなのでdefault_externalはいいとして、なんでinternalを設定しているのかは導入したコミットをみてもよく分からない。rubyの経験不足。

セキュアな転送が面倒

APIは平文。セキュアなログ転送手法は（ベンダのAPIへの送信オンリーを除いて）提供されていない。

ほかにもインストール手段がセキュアで無かったり、ちょっとセキュリティ意識が弱く見える。 そもそも外部に持ち出せるログなのだからセキュアである必要はあまり無いと考えているのかも？

素直にローカルバインドしたin_forwardにSSHなりstunnelなりでトンネルするのがよさそう。 out_forwardの再接続時にトンネルも再起動できるようにしたい。TODO

secure_forwardは使うな。あれは罠だ。

追記： 5/22に確認した所、インストールスクリプトと鍵はHTTPS化されている。以前は全部httpだったはず

雑感

面倒なログ管理が簡単に書け、要るのがrubyだけというのがいい。（というかlogstashはなんでjavaまで要求するんだ……）

私企業が開発主導なので仕方ないけど、ロックインさせたい感じがちらほら見えてちょっと不安。

http://qiita.com/tatsu-yam/items/bd7006e483f3b3c64309 https://gist.github.com/sonots/c54882f73e3e747f4b20