#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環境下のシステムは、やっぱりアップデートしておきましょう^^;