Posted at

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

More than 3 years have passed since last update.


1.検証背景


参考記事

Fluentd v0.12のAt-least-once Semanticsを試す

fluentdでログが欠損する可能性を考える

などで、fluentd v0.12を使ったときに、「require_ack_responseを必ず設定しておくように」というノウハウは、大分浸透するようになったと思われる。

ただ、fluentdを運用する中で、require_ack_responseの設定漏れに気付かず、受信側のfluentdをreloadしてしまうケースも考えられる。

ということで、実際の運用下でこの設定がどれぐらいの効果を発揮するのかを検証してみた。


2.検証環境


2-1.構成図

td-agent ack.png

図にするほどでもないが、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環境下のシステムは、やっぱりアップデートしておきましょう^^;