はじめに
Fluentdは、ログを収集し格納するためのログ収集基盤ソフトウェアです。Fluentdにインプットされた、すべてのログをJSONに変換し、アウトプットします。インプットとアウトプットはモジュール化されており、モジュールを追加することでインプット元とアウトプット先を追加できるようになっています。
Fluentdは急速に知名度を高め、多くのWebサービス会社で実際に使用されるようになりました。従来のログが抱えていた問題も、Fluentdが適切な解決策となっていると認知され、かつ簡単に導入・スモールスタートできるミドルウェアであったことが大きかったと思います。
本稿では、Fluentdの簡単な仕組みと導入方法、シンプルな動作事例について紹介します。
対象読者
- システム管理者
- データサイエンティスト
必要な環境
- UNIX系OS
- Ruby 1.9
ログを出力する理由
システム運用を始めると、ログを出力するようになります。ログを出力する目的には、システムの正常性チェックや性能ボトルネックの特定、システムのバグ調査、ユーザー行動の分析など、さまざまなものが考えられます。
目的を達成するために必要となるログは、それぞれに異なることが多いため、出力しなければならないログの種類も多くなります。出力するログには、システムログ、パフォーマンスログ、アクセスログ、アプリケーションログ、データベースログなどがあります。それらのログは、OS、データベース、アプリケーションフレームワーク、アプリケーション実行環境、ミドルウェア、プログラムといろいろな所から出力されます。
収集したログをbashやperlスクリプトなどで、直接データの集計を実施したり、mongodbやHadoopなどのデータストアに格納したり、Nagiosなどの監視ソフトに渡したりしてシステム運用に利用します。
従来のログ運用の問題点
Fluentdは、従来のログを活用するにあたって障壁となっていた問題点を解消するために開発されました。まずはFluentdを使用しない場合に生じていたログ活用の問題点について、振り返ってみましょう。
（1）ログの種類が多い
多くの目的を実現するために、いろいろな所からログを出力しています。出力元が異なると、出力されるログフォーマットも異なることが多くなります。CSV形式、タブ区切り、スペース区切り、人間が見やすいような独自フォーマットで出力され、出力される項目も順番も異なることがあります。それらをスクリプトなどで扱うために、パースをしてパース結果をどこかに格納して利用する必要があります。結果として、ログの種類だけスクリプトが存在する場合があります。
ログのフォーマットが何らかの理由で項目が増減したり、順番が変わったりした場合にスクリプトのメンテナンスが煩雑になります。ログごとにスクリプトを作りこむため、どのスクリプトが担当しているのか、どのように実装されているのかを改修時に調べなおす必要が生じることもあり、柔軟な対応がしにくいのです。
（2）ログを利用するまでの待ち時間が長い
システムの異常検知や性能監視などの一部のログを除くと、1日に1回夜間バッチで収集してデータストアに格納したり、分析スクリプトを実行するケースが多くなっています。リアルタイムに分析したい場合は、直接収集しているログを確認しなければならないシステム構成になっていることも珍しくありません。
（3）ログの活用が不十分
ログによっては、出力しているサーバー上に格納だけして普段は何もしていないことがあります。必要になった時に、サーバーから収集してきて、目視またはエディタの検索機能などを使用して必要な情報を探すという扱いになっているログがあります。
ログを有効に活用したい、有効活用するまでの手間を省くために、システム異常や性能監視などの必要最低限のログ以外は出力だけにとどまってしまっていることがあるのです。
Fluentdの役割を知ろう
Fluentdの役割を理解するには、Fluentdのメイン開発者であるTreasure Data社の古橋さんがFluentd meetup #2で使用したスライドが一番イメージしやすいので引用します（*1）。
図1が従来のログを活用するためのシステム構成概念です。それぞれのログに対して、個別にスクリプトが用意されている状態です。これが従来のログの問題点で説明した「ログの種類が多い」状態を表しています。
Fluentdを使用すると、図2のように個別に用意していたスクリプトをすべて置き換えて、Fluentdで一括して管理できるようになります。ログを収集し活用するための中心部分がFluentdのみになることで、構成がシンプルになります。
オリジナルのスライドは、slideshareで公開されている。
