ログは、システムの障害解析（デバッグ）や運用モニタリングに使うことを想定して、コンピュータに発生したイベントの履歴を時系列に沿ってファイルに出力したものである。有用なデータではあるが、扱いにくい面がある。そのため、複数のログを突き合わせて分析するといった活用が難しく、従来はもっぱら一つのログを単独で利用するにとどまるケースが多かった。
扱いにくい面とは、例えば「ログを一括して処理するには対象ログを各サーバーから収集しなければならない」「ログはサイズが大きくなりがちなので収集する場合は一部を抜き出すなどの加工が必要」といったことである。ログに新たなデータが書き込まれた際に、それを即座に取り出す手段が用意されていないこともそうだ。
こうしたログの扱いにくさは、「ログ収集基盤」と呼ばれるソフトウエアを使うことで克服可能である。ログ収集基盤は、複数のログを結び付けて分析する際などに必要な、対象ログを収集して加工し、データベースに取り込むといった処理を簡便に実施可能にする目的で開発されたもの。
この記事では、いま注目されている二つのログ収集基盤を取り上げ、よくあるケースでどちらの方が設定が容易で、適切な選択といえるのか探る。取り上げるのは、「Fluentd」（http://fluentd.org/）と「Flume NG*1」（https://cwiki.apache.org/FLUME/flume-ng.html）である（表1）。
| Fluentd | Flume NG（Apache Flume） | |
|---|---|---|
| 開発 | 米Treasure Dataの古橋貞之氏 | 米Apache Software Foundation |
| 実装言語 | Ruby | Java |
| データ構造 | 内部ではJSON形式 | 任意 |
| スケーラビリティ | プラグインにて実現 | プラグインにて実現 |
| プラグインの充実度 | ○（プラグインが豊富） | △（プラグインが少ない） |
ログ収集基盤の三つの特徴
FluentdやFlume NGは、いずれも次の三つの特徴を持つ。
一つは、集計に必要なデータの入力、変換、転送、合成、出力といった一連の処理を「ストリーム（連続的な流れ）」としてモデル化していること。つまり、時々刻々発生するデータを始点（入力）から終点（出力）に向かって一方向に流れるものとして扱う。ログに新たなイベントが追記されたら、それをすぐに切り出して一連の処理を実施していくのである。ログには随時、イベントが追記されるので、その特性を素直に反映したアーキテクチャーといえるだろう。
二つ目は、始点や終点、通過点などストリームの通り道となる「ノード」を自由に配置し、目的に合わせて経路を設定できること。ノードは、簡単にいうと一つの実行プログラムである。ノードには、例えば他のノードと通信してストリームを送受信する、障害に備えてデータをバックアップするといった基本機能が備わる。
そして三つ目は、ユーザーが独自機能を追加できるように、プラグイン機構を備えること。本体を再ビルドすることなく、拡張機能を追加したり、修正したりできる。
