BufferedOutput of Fluentd

fluentd
https://pixabay.com/images/id-1885352/
この記事は約4分で読めます。

fluentdのBufferedOutputについて理解が浅かった。。

fluentdでアプリケーションサーバーからのログを集約するAggregatorノードの設定をメモリ容量をもとに見直していたところ,出力先に何らかの障害が発生し出力不可になった場合,Aggregatorノード上のfluentdが再送上限回数に到達する前に物理メモリを食い潰し詰まってしまいそうだった。

BufferedOuputを継承するクラス(ObjectBufferedOutput やTimeSlicedOutputはこのクラスを継承している)は,出力先に何らかの障害が発生し,転送不可になった場合でも,データをバッファリングすることで極力データをロストしないような仕組みになっており,BufferedOutputクラスは以下のような動作をする。以下,備忘録を兼ねて記載しておく(間違ってたらごめんなさい。v0.10.39より)

  • 出力に失敗し,失敗回数がretry_limitより小さい場合,BufferedOutput#calc_retry_waitで計算される時間後までwaitする。
  • secondaryが設定されていないかつ出力に失敗した場合,失敗回数がretry_limitに達すると,キューに溜まったチャンクは破棄され,失敗履歴もクリアされる。
  • secondaryが設定されているかつ出力に失敗した場合,失敗回数がretry_limitに達すると,即座にretryされ(BefferedOutput#try_flushのbegin…end),next_rety_time後にsecondaryへflushされる。secondaryへの出力にも失敗しsecondary_limitを超えると,キューに溜まったチャンクは破棄され,失敗履歴もクリアされる。
  • キュー内のチャンク数がbuffer_queue_limitに達していて,新たにキューにチャンクを追加しようとするとBufferQueueLimitErrorが投げられ新たなチャンクは拒否される。
  • キュー内のチャンク数がbuffer_queue_limit以下で,”現在のチャンクのサイズ+emitされるデータのサイズ”がbuffer_chunk_limitを超えた場合,新しいチャンクが生成される。
  • リトライに成功した場合で,キュー内に複数のチャンクが蓄積されていた場合は,queued_chunk_flush_intervalの間隔でflushされる。

secondaryの指定は,ドキュメントではforwardout_fileを指定する例が紹介されているけれど,参考リンクでも言及されているように,なんでも指定可能なようである。ただし,secondaryを指定した場合,primaryとクラスが異なるとconfigtestやfluentdの起動時に警告が表示される(Output#secondary_init)。しかし,out_fileではsecondary_initがオーバーライドされており,具体的な処理は定義されていないため警告は表示されない。

僕の場合は,お世話になっているout_fileと互換のfile_alternativeプラグインをsecondaryに設定したが,out_fileのようにsecondary_initがオーバーライドされていないため警告が表示されてしまう(組み込みのOutputプラグインでないため,あえてそのようになっているものだと勝手に推測している。。)。しかし,少し様子を見てみるが,処理自体は正常に動作しているようだった。

この設定では,失敗回数が13回に達し,次のリトライ時間(約2時間強くらい?)になった時に即座にsecondaryへflushされる。

正しく扱えるようになるには,やはり細部を知る必要があると改めて実感。

参考

コメント

タイトルとURLをコピーしました