fluentdのrequire_ack_response設定は、やっぱり必須設定だと再認識したときの検証メモ

1.検証背景

参考記事

Fluentd v0.12のAt-least-once Semanticsを試す
fluentdでログが欠損する可能性を考える

などで、fluentd v0.12を使ったときに、「require_ack_responseを必ず設定しておくように」というノウハウは、大分浸透するようになったと思われる。
ただ、fluentdを運用する中で、require_ack_responseの設定漏れに気付かず、受信側のfluentdをreloadしてしまうケースも考えられる。
ということで、実際の運用下でこの設定がどれぐらいの効果を発揮するのかを検証してみた。

2.検証環境

2-1.構成図

図にするほどでもないが、fluentdの送信側と受信側のEC2を準備する。
OSとfluentdのバージョンは以下の通り。

2-2.検証環境

環境	バージョン
OS	Ubuntu14.04
fluentd(td-agent)	0.12.20

インストールが楽なので、td-agentを利用した。

2-3.設定ファイル

送信側と受信側の設定ファイルは以下の通り。

送信側のtd-agent.conf

<source>
  type forward
  @label @raw
</source>

<label @raw>
  <match test.**>
    buffer_type file
    buffer_path /tmp/hoge.buffer
    flush_interval 1s

    type forward

    require_ack_response #ここの設定をコメントアウトしたりする
    flush_at_shutdown true

    <server>
       host [受信側のホスト]
       port 24224
    </server>
  </match>
</label>

受信側のtd-agent.conf

<source>
  type forward
  @label @raw
</source>

<label @raw>
  <match test.**>
    buffer_type file
    buffer_path /tmp/hoge.buffer

    type file
    path /tmp/hoge.log
  </match>
</label>

3.検証結果

fluent-catを使って、1,000件のデータを送信しながら、10secごとにreloadするパターンとlogrotateするパターンの2ケースを検証してみる。

送信側

for i in `seq 1 1000`;do echo "{\"test\":\"$i\"}" | /opt/td-agent/embedded/bin/fluent-cat test.1;done

受信側

3-1.td-agentをreloadしたときのケース

for i in `seq 1 10`;do /etc/init.d/td-agent reload;sleep 10;done

実行後のログ受信結果は、以下の通り

require_ack_responseなし

試行回数	recieverに届いたログの件数
1回目	946
2回目	951
3回目	970
4回目	960
5回目	947

大体54~30件ぐらいのログのロストが見られた。

require_ack_responseあり

試行回数	recieverに届いたログの件数
1回目	1,000
2回目	1,000
3回目	1,000
4回目	1,000
5回目	1,000

ログのロストなし。

3-2.td-agentがlogrotateしたときのケース

for i in `seq 1 10`;do pid=/var/run/td-agent/td-agent.pid;test -s $pid && kill -USR1 "$(cat $pid)" ;sleep 10;done

実行後のログ受信結果は、以下の通り

require_ack_responseなし

試行回数	recieverに届いたログの件数
1回目	1,000
2回目	1,000
3回目	1,000
4回目	1,000
5回目	1,000

ログのロストなし。

require_ack_responseあり

試行回数	recieverに届いたログの件数
1回目	1,000
2回目	1,000
3回目	1,000
4回目	1,000
5回目	1,000

ログのロストなし。

4.まとめ

日々のlogrotate時ではログの欠損は見られないが、設定ファイルの変更などでreloadしたりするときにはログの欠損が見られた。本番環境など、今回のケースよりさらにログ流量が多い環境では、かなりのログを欠損することがあると考えられる。

AWSとはいえど、ネットワークの瞬断などの不調なときは発生するし、EC2インスタンスも再起動するときがあるので、やっぱりrequire_ack_responseは確実に設定しておくことが必要かと。
あと、fluentdがまだv0.10環境下のシステムは、やっぱりアップデートしておきましょう^^;