td-agent版Fluentdを大量に導入してみて、かなり快適に動いています。
ただ、若干不安定な部分があり、対応が必要だったので記しておきます。
導入したOS
今のところtd-agentを入れたOSはtd-agentデーモン（プロセス）の特徴
プロセス数
netstatやlsofで見たらわかりますが、tcp, udp用2つで1セットとなっています。重複起動する
/etc/init.d/td-agent start を実行したら実行した分だけ起動していきます。これはCentOSでもDebianでも確認しました。これをやると、/var/run/td-agent/td-agent.pid には新しいTCPプロセスのPIDが記録されていますが、古い方のプロセスも通常通り動作しているため、という状態になります。
もちろん古い方のプロセスは kill か pkill td-agent でしか消せません。
/etc/init.d/td-agent stop で正常に停止しないことがある
restart における stop も同様の話ですが、それなりの頻度で、stopしても2プロセスとも落ちなかったり、1プロセスだけ残ったりします。bufferにわざと溜めて、吐き出すためにstopが遅くなることも試したことがありますが、そうではなく健康な状態で起こります。そのため、restartを打つと知らないうちにプロセスが重複してログが重複していることがあります。
(不確か)pidが勝手に変わる？瞬間的に3プロセスになる？
これはほぼlenny版でのみ起きているようですが、プロセスを監視していると、pidが突然変わったことや、ps -C td-agent が瞬間的に3プロセスになることを確認しています。プロセス数はまだしも、td-agent.log には特に何も残らずに pid が変わっていたりするので結構不気味です。reload的な動作をしているのか、何かのプラグインが影響しているのか・・・ただ、対策もできてlennyの台数が少ないのもあり、あまり深追いはしていません。
デーモンの監視
以上のようなクセがあり、特に重複起動の状態だけは避けなくてはいけません。Fluentdに限らず、どのようなログ配送システムを利用するとしても、正常な状態であるかの監視とその自動修正は必須だと思います。たとえデーモンがある程度しっかりしていても、OS起動時や、手動restart時に監視による自動起動が重なったり…いろんな局面で全て上手くいく保証はないからです。ということで今のところこんな感じで平和に稼働しています。
そもそも、全サーバでログの過不足が全く無しに、というのは無理な話なので、ポリシーとしては、ログのロストは可能な限りゼロを目指し、ログの重複はもし起きても解析処理の途中でカットすることで耐性をつけています。ただ、重複を許容するシステムにしたとしても、元から断ち、安定させることは重要なので今回のようにしています。
localhostでの監視と自動実行、外側からの監視など色々できますが、この辺は足りなすぎず、やりすぎず のバランスが大事なのでこのくらいがちょいどよいかと思っていますが、まだどうなるかはわかりません！
