Fluentdの現実装のPros/Cons - Go ahead!

TODO: 必要なら図を足す 他に書いた方が良いPros/Consのリクエストがあったら追記 内部のイベントストリームの扱い Pros: Inputがスケーラブルに実装しやすく，データストリームを正常時/エラー時で切り替えやすい Cons: エラーハンドリングがブロッキングモデルよりも複雑になりやすい 以下長々と理由書きます． Fluentdはイベントストリームを効率良く，またロバストに扱うことを目的に設計されています．そのため，独自の転送プロトコル(forwardプラグイン)を実装していますし，内部のイベントのハンドリングもそれに沿うようになっています．ただ，それによって相性の悪い操作とかもあります． Fluentdはバッファ機能を提供しており，これによって転送の効率化とエラー時のデータロスを防ぐ設計になっています．が，あまりにも書き込み先が遅いなどの問題があると，バッファの制限を超えて

[bootJP]

“はい”

[kent-where-the-light-is]

“今だとEmbulkがあるので，大量データの一括転送はそちらを使ってくださいという流れになりますが，ブロックする挙動があっても損はないとは思うので，うまくバッファのAPIが整備出来れば，back-pressureっぽい機能は入れ

[tak4hir0]

Fluentdの現実装のPros/Cons

[toyama0919]

fluent-plugin-elasticsearchはある意味爆弾

[katzchang]

やったやった。セカンダリの設定は必要。

[bopperjp]

バックプレッシャー

[sonots]

うまいかんじに flow control 入れたいすなー

[Jxck]

back-pressure で止めるとなると全てのプラグインがそういう前提で作られてないと全体が止まらなそうだから、ちゃんとやろうとすると難しそう。

[iekusup]

ほー。

[kosaki]

りぴが真面目な文章を書いているというだけで背中がもぞもぞする現象に名前をつけたい

[nishitki]

Fluentdの現実装のPros/Cons - Go ahead!