ログの欠損をできるだけ避ける Fluentd の out_forward 設定サンプル cf. http://blog.livedoor.jp/sonots/archives/44690980.html

out_forward.conf

<source>
  type in_tail
  # ...
  tag raw.eventlog
</source>

<match raw.**>
  type forward
  log_level "#{ENV['DEBUG'] ? 'debug' : 'info'}"

  buffer_type file
  buffer_path /var/log/fluentd-sender/buffer/buffer
  buffer_queue_limit 9999999999999 # DO NOT discard new incoming data anyway
  buffer_chunk_limit 4m

  flush_interval 30s # default: 60
  try_flush_interval 1 # default: 1
  queued_chunk_flush_interval 1 # default: 1
  num_threads 2 # 64Mbps (2 * 4m / 1 sec) at maximum

  retry_wait 30s # default: 1.0
  max_retry_wait 1h # default: inifinity
  disable_retry_limit true # DO NOT discard buffer anyway

  require_ack_response true
  send_timeout 60s # default: 60s
  ack_response_timeout 61s # default: 190s

  heartbeat_type tcp
  recover_wait 10s # default: 10s
  phi_threshold 16 # default: 16
  hard_timeout 60s # default: equals to send_timeout

  <server>
    host foobar
    port 24224
  </server>
</match>

動き

• 30sec ごとに chunk を送信します
  • in_tail から１行ずつ受け取ったデータは 30sec 間 file に buffer され(追記され)、１つの chunk という塊として扱われます。
  • chunk の最大サイズは 4M bytes に設定しており、30sec 間にそれを超えた場合は、buffer ファイルが分割され、chunk が複数個になりえます。
  • buffer ファイルは /var/log/fluentd-sender/buffer に生成します
• リトライが必要な場合は、最初のリトライは 30 sec 後に行い、倍々でリトライ時間は延びていきます。
  • 最大リトライ時間は 1 hour に設定してあるので、collector サーバ復旧後、最悪１時間後にデータ送信が再開されます
  • その際、buffer が溜まっていた場合は、4M バイト(chunk)ごと、1 sec (queued_chunk_flush_interval) おきに送信されます。
  • num_threads を 2 にして、２並列にしているので、最大でも 4M * 2 / sec == 64Mbps になるようにコントロールしています。
• require_ack_response true にしています
  • 受けて側の fluentd が file buffer であればファイル書き込みが確定してから、NonBuffered な Output プラグインであれば送信が終わってから ack が返ってくるので、データ転送を確定できます。
  • 代わりにスループットは落ちます