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