-
- いいね！0
Sadayuki Furuhashi
@frsyuki
bufferのレベルではチャンクごとにIDが振られて、同じチャンクならリトライされても同じIDになるようになって、out_fileならプロセスの再起動後でも維持されるようになっているけど、ほとんどのプラグインはそれを使っていないはず。
2014-06-12 14:21:15
SKS rep
@repeatedly
emit_with_idみたいなので，送られてきたchunkにidがあったら，それをそのまま流用してchunkを作って，そこに入ったchunkにはもう追記はされない，みたいな感じになるのかな．もっとスマートな感じにしたくもある
2014-06-12 14:24:58
Sadayuki Furuhashi
@frsyuki
思うには、pull型のforwardが良いと思うんだな。kafkaみたいなアーキテクチャ。冪等性の維持も簡単だし、過負荷になりにくい。副産物的にpull型のAPIが見えるようになるので、アプリケーションの幅も広がる。
2014-06-12 14:25:17
SKS rep
@repeatedly
@frsyuki それやりだすとpullを待つ側のforwardが結構めんどうになって，結局他のキューを挟んだ方が良いという感じになるのでは？
2014-06-12 14:26:23
Sadayuki Furuhashi
@frsyuki
@repeatedly その「他のキュー」がfluentdプラグインとして実装されていてもいいんでは？ 要するにそれがpull型のforwardということになるけど。
2014-06-12 14:28:03
SKS rep
@repeatedly
まーお手軽なセットアップがFluentdの売りでもあるので，他のキューを間に挟むと他のログフォーワーダーみたいに面倒くさいと言われるので，やるならプラグインで実装することになりそうではある
2014-06-12 14:29:29
Sadayuki Furuhashi
@frsyuki
@repeatedly 仮に名前をpfとすれば、out_pfは、emitされたチャンクをファイルかメモリに保存する。加えて「どこまでpullされたか」というインデックスも保存が必要かな。それから、configに書かれた送信先のサーバにTCPで定期的にheartbeatを送る。
2014-06-12 14:30:47
Sadayuki Furuhashi
@frsyuki
@repeatedly in_pfは、heartbeatのコネクションを逆サイドから使ってデータをpull。heartbeatのコネクションは、張りっぱなしにするか、1回張ったら1秒待つみたいなテキトーな実装でもOKかと。
2014-06-12 14:31:23
Sadayuki Furuhashi
@frsyuki
@repeatedly out_pf内でheartbeatの送信/pullリクエストの受信を、各ソケットごとにスレッドで実装するとロック管理が若干複雑になり、イベント駆動で実装すると状態管理が複雑になるというお決まりの話を何とかすれば、
2014-06-12 14:32:29
Sadayuki Furuhashi
@frsyuki
@methane @repeatedly 分からないですね。pullをRPC1回のテキトー実装にしても良いし、1回目でデータを引っ張って2回目でオフセットを移動させる2回仕様にしても良いですが、いずれにしても確実には分からないです。実装は複雑になりますが後者の方がずっと堅牢ですね
2014-06-12 14:35:40
Sadayuki Furuhashi
@frsyuki
@repeatedly まぁそれは必要な人が実装するとして、ラベルとエラーストリームが急がれるって話ですね。
2014-06-12 14:37:04
methane
@methane
@moriyoshit input <> router <> output <> 実際の出力先 で、2箇所以上にバッファが入るのは良くない気がするので、 input と router の間はバッファなしchanかなぁ。
2014-06-12 14:37:15
methane
@methane
ik の out_forward を使ってみようと思ってるんだけど、とりあえず現状は fluentd の out_forward と同じく毎回コネクションクローズしてチャンクサイズを微調整するのが現実的かなぁ。
2014-06-12 14:38:52
methane
@methane
@moriyoshit スループットを求めようとすると、真っ先に思いつくのは *input -> *router -> output でバッファありチャンネル使うことですが、バッファが多段になるとデータロストしないために気をつける部分が増えてしまうので、
2014-06-12 14:41:04
Moriyoshi Koizumi
@moriyoshit
@methane 実際のところchannelを介すまでもない処理をプラグインがする場合もあるので、channelを前提せず、普通のmethod dispatchにしたという背景があります (その方がオリジナルにも近いし)
2014-06-12 14:41:32