Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
ログの欠損をできるだけ避ける Fluentd の out_forward 設定サンプル cf. http://blog.livedoor.jp/sonots/archives/44690980.html
<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>
@sonots

This comment has been minimized.

Copy link
Owner Author

@sonots sonots commented Oct 16, 2015

動き

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