ログデータを活用してビジネスに役立てようという最近のトレンドは理解できる。
しかし、なぜログ収集ソフトウェアのFluentdがこれほどまで話題になるのか、不思議に感じている方もいるのではないだろうか。単にログデータを収集するならばsyslog-ngやrsyslogで十分ではないかという意見もあるだろう。
それらは既存のログシステムを置き換えるプロダクトであり、Fluentdのそれとは根本的に異なる。Fluentdは、既存のログシステムに手を入れることなく新たにログの収集を行い、ストリームデータ処理を実現するプロダクトなのである。
一般的にログデータはサーバの数だけ分散しており、それを定期実行処理で収集するということだけでも、なかなか骨の折れる仕事である。さらに集めるだけでなく、日々増え続けるログデータを活用できる形に加工してしかるべきデータストアに保管するということに挫折した方もいるのではないだろうか。
明らかにこれはどの企業でも行う車輪の再発明であるため、Fluentdを早々に導入することで本来行いたかったログの活用フェーズへ移るべきである。
もちろんFluentdは万能では無いため、要件によっては向き不向きは存在するのは事実だ。
そこで今回、Fluentd周りの機能の紹介の後に、現実的な各種ユースケースを紹介する。
なお、詳しい設定例は紙面の都合上、割愛するがご了承頂きたい。
Fluentdコアとプラグインが提供する主な機能
Fluentdのコア機能では、実にシンプルでログデータの収集と、他Fluentdサーバへの転送程度しか機能は無い。有志によるプラグインで、その他の機能は実現していると言っても過言では無い。
実際にどのような機能があるのか、大まかにまとめると次の通りである。
入力プラグイン
- ログファイルを吸い上げてJSON形式にする（アクセスログ、エラーログ、アプリログ等）
- Fluentdデーモンが直接JSONメッセージを受け取る（Syslog, HTTP等）
- システム稼働状況等の定期収集を行う（dstat, munin等）
出力プラグイン（フィルタ的な役割）
- リアルタイム集計
- タグの書き換え
- レコードの書き換え
出力プラグイン
- ストレージへの保存（ローカルファイル, Amazon S3, WebHFDS等）
- RDBデータベースへの保存（PostgreSQL, MySQL, RedShift等）
- NoSQLデータベースへの保存（MongoDB, TreasureData, CouchDB, ElasticSearch, Solr等）
- グラフ化（GrowthForecast, HRForecasts, Graphite, CloudWatch, Cacti, MetricSense, Librato Metrics等）
- メッセージ通知・電話通知（HipChat, Growl, Jabber(XMPP), Twilio, Twitter等）
こんな事をしたいという要望はあっても、どのプラグインと組み合わせて使うべきか悩んだ際には、Fluentd MLでの質問のほか、#fluentdハッシュタグをつけてツイートすれば、暖かくコメントしてくれる人がいるはずである。
10の逆引きユースケース集
多数のプラグインと組み合わせることで便利なことが出来ると聞くが、それがどう嬉しいのかは私も触るまで分からなかったのは事実だ。そこで、具体的にどのような用途に向いているのか、ユースケース集として次に紹介する。
いずれも基本的にサーバさえあれば、追加費用が発生することなく実現が可能だ。（Amazon S3を除く）
アクセスログを収集して、サイト(ドメイン)毎にファイル名を分けて、gzip圧縮したログのアーカイブをAmazon S3に行う。
単位時間毎のアクセス量やステータスコード別の集計結果を、サイト毎にGrowthForecastでグラフ化する。
超高速な自前Webビーコンを作る。QUERY_STRINGにパラメータを渡して、NginxのアクセスログからFluentdへ取り込み、クエリパラメータを展開し、それを非同期にデータベースに保存する。
ログ量のスパイク等、異常値を検出をしたらチャットツール、例えばHipChatやiChatに通知する。
muninやdstat、シリアルポートから取得したシステム稼働状況をデータベースに保存する。
アプリログ/アクセスログを収集し、ヒストグラム化や完全/部分一致での検索が出来るダッシュボードをElasticSearch+Kibanaで作る。
- IPアドレスを元にGeoIPを用いた緯度経度情報を付与し、地図にプロット
- エラーログの俯瞰（WEBサーバやDBサーバのエラーログ）
- ページの応答速度の推移（アクセスログの応答時間）
- n秒以上応答に掛かるページの推移（アクセスログの応答時間）
- HTTPステータスコードが404・500エラーとなった推移
- Googlebot等からのクロール状況
- ログイン成功数/ログイン失敗数
- ボタンの効果測定を行うA/Bテスト
- 自社広告の露出回数・クリック回数の推移
- MySQLのスロークエリの可視化
メールの配信履歴を収集して、メアドを難読化（SHA1）した上で保存し、それを検索出来るダッシュボードをElasticSearch+Kibanaで作る。
CEPエンジンと呼ばれるストリームデータのリアルタイム集計処理をSQLで実現するEsperを利用する機能をNorikraで作る。
まとめ
Fluentdを活用することで、ストリームデータのリアルタイム処理が容易となる。
しかし、1つのfluentd(td-agent)にあまり機能を詰め込まず、適宜機能分割を行い、シンプルな構成を維持できるよう心掛る事を忘れてはならない。企業組織で利用するシステムであるからには、保守及び運用できるミドルウェアという枠に収めることが重要であるからだ。
なお、保守サポートが必要であれば、Fluentdの開発元であるTreasureDataに問い合わせると良いだろう。サイトは英語だが、日本語でのやりとりも可能だ。
このエントリは「Fluentd Advent Calendar 2013」の4日目でした。明日は u-ichi さんです！ http://qiita.com/advent-calendar/2013/fluentd/participants
なお、12月13日(金)には「Fluentd Casual Talks #3」が開催されます。私も参加予定で、Fluentdの応用プロダクトについてお話しする予定です。 http://atnd.org/events/45386
PlanetMySQL Voting: Vote UP / Vote DOWN