何故、fluentdなのか？ - プログラマでありたい

　最近、fluentdという言葉を聞くことが多いと思います。fluentdは、それぞれのサーバからログを収集し集約する為のアプリケーションです。fluentdは「Log everything in JSON」を合言葉に、全てのログをJSON形式で扱います。また一緒に聞くキーワードとしては、大規模とかリアルタイムとかがあると思います。この時点で関係ないやと思って、興味を失った人も多いと思います。しかし、今後のログ管理は、fluentdが主流になるか解りませんが、同様の集約するフレームワークが中心になると思います。

何故、fluentdが必要か？

　まずはオンプレミスの世界から見て行きましょう。ログはサーバーにたまり、管理者はサーバにログインしてログを参照します。特に問題はありません。

　次にAutoScalingを使わないAWSの世界です。これも同様に、ログはサーバーにたまり、管理者はサーバにログインしてログを参照します。特に問題はありません。

　問題は、AutoScalingを使うケースです。サーバーは負荷に応じて増減します。負荷が下がると自動的にサーバはシャットダウンされます。その間のログはどこに行くのか？そこが問題です。

　そこでfluentdを導入すると、ログは一箇所に集約されます。管理者は、集約されたログを（直接or間接的に）見れば良いですね。

重要なのは、サーバーにログインしないこと

　ここまでは、一般的なfluentdのメリットです。俺、AutoScalingしないし、いーらねと思ったと思います。そんな人にfluentdで、もう１つ注目して欲しいことがあります。それは、管理者がログを見る時に直接サーバにログインしなくて良いことです。今までログを参照するためには、サーバにログインする必要がありました。そうなると運用の観点からは、管理者が誤操作をしてサーバの障害を起こさない為の仕組みや、情報漏えい対策に監査証跡など色々なことを考える必要がありました。fluentdでログを集約すれば、その参照の管理だけしておけば、基本的に安全です。楽ですね。

まとめ

　ということで、最近はchefと共にfluentdのノウハウ蓄積中です。chef-serverやknife-soloとfluentdを組み合わせれば、サーバにログインせずにサーバを管理出来る夢のような状態になれます。もちろん例外ケースもあるし、一筋縄ではないと思います。が、せっかくAWSのお陰でサーバの立ちあげまで自動化＆省力化して近代化したのだから、それ以降も部分も近代化したいですね。ということで、最近はfluentdで集約したログのビューワーが何が良いか検討中です。