sonots:blog

out_forward => in_forward の通信においてログが欠損する可能性を考える。

前提としてまともに動いている分にはまず欠損しないはず。TCPだし。=> 実験例あり🙏 http://qiita.com/shibacow/items/199a17f07c525d3dbb2d

• Too many open files エラーなどが出たら、あきらめて入力を捨てざるを得ないので欠損する
  • ulimit 調節したりマシン台数増やしたりすれば回避可能な問題
• buffer_queue_limit 超えたら、そこで捨てるロジックになってるので欠損する
  • file バッファにして十分大きな値にすれば回避可能な問題
  • (補足) file バッファは、chunk サイズが buffer_chunk_limit を超えるかフラッシュ時間がくるまでは buffer ファイル(便宜上、chunk bufffer ファイルと呼ぶ)に書き込む。送信ができず、buffer をクリアできない場合、さらに buffer ファイルが作られる (便宜上、queue buffer ファイルと呼ぶ)。これは buffer_queue_limit を超えるまで作られるが、超えたら古いものから破棄される新しいイベントは破棄される。
• retry_limit (リトライ最大回数)を超えたら諦めるので欠損する
  • secondary でどこかに保存しておき、そこから手動で送れるようにしておけば回避可能な問題。これが手間ではある
  • disable_retry_limit true とすることにより、永遠に諦めないようにできる。file buffer の場合、(ディスク容量が潤沢であれば)こちらのオプションを利用するのが良いだろう。
• ネットワークが不安定でパケット落ちした場合は、エラーが検出されてリトライするので欠損しない。受信側が一瞬ダウンした場合なども同様
  • 逆にこの機構により、受信側は受け取ったのに送信側が失敗したと判断して、重複送信してしまう危険性は発生する。
  • Fluentd 的には chunk に uuid 振って重複排除する仕組みを実装すべき (ToDo)
  • 運用で回避する場合、全てのログ行に uuid を追加して、保存先データベース(BigQueryなど)で unique 制約つけて弾くことで回避可能。
  • uuid じゃなくて、ログ時間を含めた(時間を含めないとたまたま同じログが出た場合に排除してしまう) md5 ハッシュとかでも、十分 checksum として機能しそう
• ネットワーク障害でTCPレイヤでは送れたように見えて、実は受信側が受け取っていない可能性があり、その場合欠損する => http://ogibayashi.github.io/blog/2014/12/16/try-fluentd-v0-dot-12-at-least-once/
  • require_ack_response が入ったので回避可能な問題。
  • (補足) いまの ack 実装は同期待ち受けなので、スループット低下する。問題にならない所まで num_threads 増やせば回避できるはず。
• 受信側が、受信してからどこかに書き込んだり(chunk buffer 含む)利用したりしている間(filter プラグインとか)に、マシンが落ちたりすると欠損する
  • require_ack_response の ack は Output プラグインの処理が終わってから返すので、受信側で file buffer な BufferedOutput プラグインを利用しているのであれば、chunk buffer ファイルに書き込みされて ack が返ってきてから、送信側のファイルを消せるので回避可能な問題。

まとめ：全部回避可能かと思われます。

追記(2015/10/17): 設定サンプルをおきました > https://gist.github.com/sonots/02de35a18b21dad0b1f3