buffer plugin 概要
公式の翻訳しながら理解を進める
buffer の構造
buffer は Chunk の集合
Chunk は 1 つの blob に連結されたイベントの集合
それぞれの Chunk は file か memory で管理される
buffer は Chunk を 2 つの場所に分けて管理
- stage と呼ばれる Chunk を入力ソース(Event)で埋めていく場所
- queue と呼ばれる送信前のチャンクが待機している場所
新しく作成された全てのチャンクは
stage に入れられ、時間内に queue に移動される (その後転送される)
retry の振る舞い
受信側が何かしらのエラーで届けられなくなっても
送信側で障害を正常に処理するメカニズムが入っている
デフォルトでリトライの試行間隔を指数的に増やしていく
(最初の待機時間が 1 の場合の例)
1 2 4 8 16
x-x---x-------x---------------x-------------------------
│ │ │ │ └─ 4th retry (wait = 8s)
│ │ │ └───────────────── 3th retry (wait = 4s)
│ │ └───────────────────────── 2th retry (wait = 2s)
│ └───────────────────────────── 1th retry (wait = 1s)
└─────────────────────────────── FAIL
fluentd は 上記アルゴリズムを調整している点がある
待機間隔の分散
計算された秒数に0.875 ~ 1.125をランダムにかける
retry_randomize を false にすれば無効になる
最大待機時間の設定
例えばretry_max_intervalを5sにした場合
上記の例で 8s 待つことはなくなる
そもそも指数関数的なリトライ処理をさせたくない場合は
retry_typeをperiodicにする
リトライの終了判定(書き込み成功以外)
デフォルトで次の条件で再試行のループを抜ける
-
retry_max_timesに達した。(default: none なので 無制限) - 最初の再試行から経過した時間が
retry_timeoutに達した(default: 72h)
これらのイベントが発生した場合、出力 queue 内の全てのチャンクは破棄されてしまう
破棄したくない場合は、retry_foreverを有効にする
参考
公式
https://docs.fluentd.org/v1.0/articles/buffer-plugin-overview
buffer option 詳細
https://docs.fluentd.org/v1.0/articles/buffer-section#retries-parameters
forward protocol v1
https://github.com/fluent/fluentd/wiki/Forward-Protocol-Specification-v1