oranie's blog

旧:iをgに変えると・・・なんだっけ・・・

#fluentd fluentdでログ集約する際にwarnが多発した件

とりあえず題名そのまま。ログの送信種類を増やして行ったら受信する側のwarnが多発して、途方に暮れたという話です。

状況について

Verはtd-agent-1.1.5.1-0.i386(Webサーバ側)と/td-agent-1.1.5.1-0.x86_64(中間fluentd、いろいろ処理するfluentd)

各Webサーバ(in_tail)→中間fluentd→いろいろ処理するfluentd(各fluentd間は全てfowardを使用)という形で構成をしており、ここの「中間fluentd」の性能問題?で

上記のログが出力された。ログについてはid:tagomorisさんから

との解説を頂きました>< ありがとうございます!


で、実際に挙動でどういう影響があったかというと、今まで問題が無かったログの集約については、各Webサーバで頻繁にアクティブ・スタンバイ設定の中間fluentdへのスイッチ+また元に戻るという動きのログが出まくり、ログ送信に影響が出ていた。
OSレベルで見ると、今回の問題が出る負荷については30Mbps程度のIn/Outが発生するレベルで、NIC、Diskは問題無し、メモリもスワップするレベルでは全く無い、CPUは使用率が全体で1CPU4Coreで30〜40%程度。但し、ps auxで見るとfluentdプロセスで80%くらいになっている奴はあった。そういう意味では最も負荷の高いプロセスはコア的に処理限界だったのかも知れない。この辺は1台のサーバ上でも受信するプロセスを分けて起動するとかで負荷分散する必要があるのかな。

ちなみに、そもそも送信側でin_tail→out_fowardの限界だったかというと、同じ設定を2週間くらい先行して設定しているサーバがあり全く問題無かった。残りのサーバを同様の設定にした時に発生した為、単体であれば問題無いレベルだと考えている。

で、どうしたらいいの?

現在鋭意調査中でございます>< むしろ、何か回避されている方は教えて下さい!><
というメモ書きでした。

5/9追記

とりあえず既存の処理と新しい設定を別々のプロセスで起動するように変更した。で、目的の半分くらいのログ量を流し込んでいるけど、今の所問題無し。もし新しい設定の方がバーストしても、既存設定の方はスカスカでOSも余力を残しているので、多分大丈夫。

なので1プロセスの性能限界が来たけどOSレベルではリソースに余力がある場合、手動マルチプロセスを行えば、とりあえずOSレベルの限界くるまではスケールしますね。
あとは投げる側が上手いことそれぞれのプロセスに投げるように設定してあげれば良いんでは無いでしょうか。

ちなみに、複数起動する方法はtd-agent使っていたので、/etc/init.d/td-agent内のstop処理で

killproc $proc
→
killproc -p ${PIDFILE} || killproc $proc

と変更し、あとは新しい設定で起動する方の起動スクリプトで既存の奴とかぶったらまずい所(pidファイル名、ログファイル名、configファイルの指定ぐらいかな?)を書き換えてやればとりあえず無事起動&停止しました。