fluentdの運用周りについて書いておく

fluentdは基本的には安定して動くソフトウェアだけど規模が大きくなってユースケースが増えてくるとトラブルに遭遇することもある。今回は運用周り、例えばトラブルシューティングとかモニタリング周りについてちょっと書いてみたい。

前提として僕の環境ではtd-agentは使わず素のfluentd 0.12系を使っており、xbuildでrubyをインストールし、supervisordでプロセス管理している。

また僕はfluentdクラスタを運用する立場であり、このクラスタに対して社内のメンバーが自由にfluentdを使ってログを送信するという形になっている。

なので末端のfluentdの管理は僕ではなく各自でやってもらうということになっているのだが、そこで問題が出ることもある。


fluentdのバージョン管理問題

例えば、とあるfluent pluginをインストール or アップデートしたらfluentd本体が0.14になってしまってエラーになるケースがある。

fluent-plugin-ping-messageの例だと最新の1.0.0は0.14系で0.2.1が0.12系
fluentd 0.14系だとtimestampとしてナノ秒をサポートしていることもあり受信側の0.12系だとmsgpackで下記のようなエラーが出た。

out_ping_message_checker: invalid byte MessagePack::MalformedFormatError 

これはfluentd 0.14がまだexperimentalであり、0.12と0.14が両方ある過渡期だから起こる問題なのだが、普段JavaでWebアプリ書いていてfluentdを片手間で触っているような人(これはまさに2年以上前の僕なのだけど)だとちょっと混乱すると思う。


余談だが、fluentd 0.10系から0.12系への移行に関しては、そこまで劇的に変化していないのでこういう問題は少なかったと思う。ただ最新状況をキャッチアップしていないとfilterやlabelのような新機能を使いこなせないということはあるかもしれない。


バージョン問題に関する解決策はGemfileでプラグインをちゃんとバージョン管理しろって話なのだけれど、それを負担に感じる人もいるだろう。rubyを読み書きできるインフラエンジニアなら問題ないと思うけど。

なお僕のfluentdクラスタ環境ではGemfileでバージョン管理している。全部じゃなかった気がするけど。。。

本家のドキュメントだと下記にこの辺が書かれている。
Plugin Management | Fluentd


ruby環境に関わる問題

僕は幸運にして遭遇したことないのですが、下記のようなエラーが出て突然fluentdが落ちるという話を聞いたことがあります。

fluentd main process died unexpectedly. restarting.

これは
fluentd main process died unexpectedly. restarting. · Issue #1026 · fluent/fluentd · GitHub
だったり
Troubleshooting Fluentd | Fluentd
にも書かれているようにfluentdというよりruby環境の問題です。
なので対策としてはrubyを最新化するとかdaemon化しないでログをstderrにはく状態にして再現待ちするとかになると思います。

この辺はrubyだけでなくLinuxスキルも問われるので、片手間だとちょっと厳しいかもしれない。

なおこういうケースだとtd-agent使っているとやりづらいと思うので、素のfluentdをsupervisord管理するほうが良いかもしれません。

ただsupervisord管理する場合はstopwaitsecsを延ばして二重起動を回避するようにした方がいいかもしれません。厳密には二重起動をチェックしたほうがいい。そうしないと下記のように止めたつもりのfluentdプロセスが止まっていない問題に遭遇する可能性があります。
fluentd restart "error on output thread error="No such file or directory" · Issue #448 · fluent/fluentd · GitHub


モニタリング、プロファイリング
モニタリング周りは本家ドキュメントでは下記に書かれています。
Monitoring Fluentd | Fluentd

fluentdのモニタリングというとバッファ周りの話は出てきますが、CPU使用率についての話をあまり聞きません。個人的にはCPU使用率の方が重要なのではと思うぐらいです。バッファだけ見ていてもその原因がなんなのかわからないと対応できないと思うので。

うちの環境ではfluentdのCPU使用率、メモリ使用量をfluentd_exporter経由でprometheusにメトリクスを格納してgrafanaで可視化しています。

CPU使用率が高い場合は基本的にはプロセスを増やすことになるかと思います。

ただfluent-stackprofでプロファイリングして問題ある箇所をいじって改善するパターンもあります。
td-agentのprofiling - wyukawa’s blog
fluent-plugin-uri_decoderをpatchしてCPU使用率を下げた話 - wyukawa’s blog


fluentdの性能
Frequently Asked Questions | Fluentdによれば秒間18,000msgぐらいまではいけるそうですが、この辺は使っているプラグインや設定にもよるかと思います。うちの環境だと秒間5,000msgぐらい基準に考えています。