最近fluentd界隈でご活躍の@tagomorisさんが書いた、「尊重されたいすべてのソフトウェアエンジニアへ」という記事が大人気のようだ。 大人気のものには便乗するのがquippedのやり方なので、ぼくの個人的な意見を少し書いてみたい。 結論から言ってしまえば、ぼくは@tagomorisさんの意見に同意だ。失礼を承知で言うと、彼の言っていることは至極当たり前で、 仕事の外でも頑張れ。 せっかく頑張ったんだから発信しろ。 ソフトウェアの世界では1+2の費用対効果がデカい（はず） という3点だと思う。ぼくが興味深く感じたのは、彼が努力だけではなく、ある種の自己PRを促していることだ。これは大人になってわかったことだが、「実力さえあれば誰かが見いだしてくれる」なんてのは傲慢はなはだしく、黙っていては誰にも気づかれずに終わる場合がほとんどだ。ソフトウェアに限ったことではないけれど、日本人は相対

RRDなどにメトリクスを書き込んでグラフを生成している場合、標準的なサーバだとCPUかHDDがボトルネックになって、Nagiosサーバ1台あたり持てるクライアントは、300台〜700台くらいが限度といったところでしょう。 数万台のサーバを管理する様な環境では、Nagiosサーバ単位で情報が分断されてしまうので、関連するシステム（特に他部署が管理している様な）の状況が把握しづらいことがよくあります。 全サーバの状況を横断して検索、リスティングができると、障害時の対応時間を短縮できるし、統計情報の取得ができるとメトリクスdrivenな運用＆開発もしやすくなり、プロダクトの質も向上するだろうということでfluentdでやってみました。とは言ってもまだ始まったばかりなのですが、下の図の様な構成で、Nagios上のイベントログをfluentdがtailし、必要なイベントログをfluentd serv