fluentd の buffer あふれ改善議論

2
SKS rep @repeatedly

あふれたらbuf_fileになるというの,一つのチャンクがflushされたらfileで保存されているチャンクはメモリにロードされるのか?

2014-04-02 01:32:33
tagomoris @tagomoris

fluent-plugin-buffer-lightening は buffer plugin のAPIについてうっかりしていたところがあって、所定の目的を達成できない中途半端な機能になってしまったのが残念である、さっさとbuffer/outputまわりの内部APIを作り直したい

2014-04-02 01:32:39
tagomoris @tagomoris

@repeatedly streaming mode(on memory mode)とtroubling/recovery mode(file mode)を切り替えながら動くとか? scribedはそういう動作

2014-04-02 01:33:27
SKS rep @repeatedly

@tagomoris ほー.それはチャンクがメモリとファイルが混ざっているという感じなんですかね?

2014-04-02 01:34:32
tagomoris @tagomoris

@repeatedly いや、基本的には読み込み→出力が同期的に行われる(メモリ上にしかない)、出力が失敗したらファイルチャンクに書くモードに遷移する、リカバリが開始されてファイルチャンクがなくなったらまた同期モードに戻る、という感じ

2014-04-02 01:35:29
SKS rep @repeatedly

@tagomoris クラッシュはそもそも諦めるというスタイルですか.出力失敗時にはメモリにあるのを全てファイルに書き出して,リカバリ時には全てまたオンメモリに戻すか…それはそれでコスト掛かりそうな予感

2014-04-02 01:37:37
SKS rep @repeatedly

なるべくシーケンシャルに書けるのであれば,RubyのFluentdでもそこはそんなに問題にならないかな…?

2014-04-02 01:38:22
そのっつ (Naotoshi Seo) @sonots

たしかにコストはかかりそうだけど、ログがなくなるとか、メモリもりもり増えるとかよりはうれしい

2014-04-02 01:38:39
Sadayuki Furuhashi @frsyuki

@repeatedly @tagomoris @sonots クラッシュ時は諦めて良いと思います。出力失敗時も、buffer_chunk_limitが溢れるまではオンメモリモードでも良さそうな気がしますが、シグナルで強制flushを受信したが出力に失敗した場合は書き出すとか、

2014-04-02 01:39:37
tagomoris @tagomoris

@repeatedly ん? いや通常は転送はすべて同期転送だから、自分がクラッシュしたときはクライアント(かファイル)にある、という想定なのでscribedは諦めてないですね

2014-04-02 01:40:18
Sadayuki Furuhashi @frsyuki

@repeatedly @tagomoris @sonots シャットダウン時には最優先で(他のプラグインの終了を待たずに)ファイルに書き出すとか、手動で対応できる方法が一応あると良い感じはありますね。

2014-04-02 01:40:28
tagomoris @tagomoris

@frsyuki @repeatedly @sonots 個人的にはいまのfluentdの耐障害想定はそう悪くないと思いますけどね。ファイルチャンクのフォーマットがプラグイン任せなことと、それを後から手動で読み出してリカバリする手段が提供されてないのが問題だと思うくらいかな。

2014-04-02 01:41:29
SKS rep @repeatedly

@tagomoris あああ,scribedってfluent-agent-liteみたいな設計?

2014-04-02 01:41:48
Sadayuki Furuhashi @frsyuki

@tagomoris あれ、例えばOOM killerで殺されたとか、SIGKILLで死んだような場合は、バッファには入っているが未送信のデータはオンメモリなので失われるのでは?

2014-04-02 01:41:56
tagomoris @tagomoris

@frsyuki その場合はそのノードに送ってきたクライアントにはまだOKが返ってないので、クライアントが再送可能(他のノードが生きてれば

2014-04-02 01:43:14
そのっつ (Naotoshi Seo) @sonots

手動で buf_file 先を読み込んで、新たに送り直すのって、fluentd 再起動すればやってくれるかんじ?

2014-04-02 01:43:24
SKS rep @repeatedly

scribed,前ソース読んだけど結構前だから細かいところ覚えてないな…

2014-04-02 01:43:29
そのっつ (Naotoshi Seo) @sonots

確かに fluentd で失敗したのだから、外から別のバッチで再送信しやすいように、buf_file を読み込むなにかが提供されているとうれしいのかも?

2014-04-02 01:44:37
tagomoris @tagomoris

fluentdにactorが実装されたら1週間くらいつかってでもv11風のbuffer/output/input plugin APIを作り直して提案してみるつもりはある

2014-04-02 01:44:45
tagomoris @tagomoris

のでactorはやめにおねがいしますね ^^

2014-04-02 01:45:06
Sadayuki Furuhashi @frsyuki

@tagomoris ファイルチャンクのフォーマットは、統一した方がいいですかね?前に内部フォーマットがmsgpack固定の方が良いのでは?という話をしたときに、writeメソッドでフォーマットの変換が走って遅くなる、という話になった覚えがありますが。

2014-04-02 01:45:29
そのっつ (Naotoshi Seo) @sonots

buf_file からの復旧とはちょっとずれるけど、<secondary>type file</secondary> でとりあえずファイルに吐いておいた場合に、復旧できるコマンドが欲しいって誰か言ってた

2014-04-02 01:46:32
tagomoris @tagomoris

@frsyuki そうですね。なんで、ふたつくらい(出力先にそのまま渡せる形式 or msgpack)とかに縛る感じでAPI作るのがたぶんいいんじゃないかと思います

2014-04-02 01:46:41
tagomoris @tagomoris

secondaryに出力して後から頑張るより、決まった形式のchunk fileが残ってるほうが嬉しいよなあ、という気はしている

2014-04-02 01:48:06