-
- いいね！0
methane
@methane
fluentdのfoward久しぶりに見たけどちょっと嫌すぎるのであのブログシリーズ終わったらまともにリトライできる新forwardプロトコル欲しい
2014-06-12 13:48:58
methane
@methane
forwardはストリーミングできるんだけど、受信確認が無いから際接続時にどっから再送したらいいのか全く分からない。 なのでout_forwardはチャンク毎に切断してるんだけど、接続コスト考えたらチャンクはある程度大きくないといけない
2014-06-12 13:52:03
methane
@methane
切断中にエラーになったら、そのチャンク丸ごと成功したのか失敗したのか分からないから、再送するなら大きいチャンク丸ごと重複するし、しないなら丸ごとロストする
2014-06-12 13:53:46
methane
@methane
まじめにやるならシステム全体で冪等にするしかないんだけど、今の設計でも受信確認さえあれば、ストリーミングでログ転送ずっとやりやすくなるのに
2014-06-12 13:56:30
tagomoris
@tagomoris
@methane 小さい単位でackを待ちながら送信するプロトコルにするとスループットがだいぶ落ちると思いますが、それは？
2014-06-12 13:57:20
tagomoris
@tagomoris
@methane JVMならそれでいいけどRubyだとスレッドが排他だから並列にしてもあまりスループット上がらない＆ack返信用に割り込んでくるスレッドが増えてCPU使用率激増するんじゃないかなという気が
2014-06-12 13:59:31
tagomoris
@tagomoris
@methane それも結構難しくて、チャンク送信時に中身に何レコードあるかは必ずスキャンされているとは限らない……というか、それをやるとそれはそれでパフォーマンスがだいぶ落ちる
2014-06-12 14:06:09
methane
@methane
たぶんfluentdの初期の設計思想はsyslogと同じで欠損は気にせず、分からないものは捨てる。copy使わない限り重複しない。というものだったと思うけど、やっぱりロストしたかもしれないとき再送したいじゃん？
2014-06-12 14:09:28
SKS rep
@repeatedly
基本的に，パフォーマンスは落ちるけど信頼性のあるforwardはあっても良いと思うので，欲しい人が作れば良いと思いますね
2014-06-12 14:10:43
SKS rep
@repeatedly
初期の思想は欠損は気にしないのではなくて，重複はTD側で無視されるので，とりあえずガンガン送る．データ加工もTDで出来るので，フィルタとかはとりあえず後，的な感じに見える
2014-06-12 14:11:56
SKS rep
@repeatedly
@methane chunk毎にIDが振られるので，そのIDがすでに来たものだったら捨てられますね．もちろんものすごい時間が空いた後に同じIDのチャンクが来たら困りますが…
2014-06-12 14:15:39
SKS rep
@repeatedly
@methane あ，その段階ではつかないですね．今だと各チャンクが生成される時につけられるので，なんかそれをプロトコルに含めようみたいなのは，以前話題に上がったとは思いますが…
2014-06-12 14:19:03
SKS rep
@repeatedly
in/out_java_forwardを作って，forwardの中でJVMを起動して送受信を行い，そこからFluentdにチャンクを送信する仕組みを作れば…
2014-06-12 14:19:26
Sadayuki Furuhashi
@frsyuki
in/out_forwardの再送管理はテキトーですよ…改良の余地は大いにある。現状の実装は単にシンプル。
2014-06-12 14:19:42
SKS rep
@repeatedly
forward，forward2，keep_forward，secure-forward，次に生まれてくるforwardプラグインは何になるのか…
2014-06-12 14:20:05