ログは、システムの障害解析(デバッグ)や運用モニタリングに使うことを想定して、コンピュータに発生したイベントの履歴を時系列に沿ってファイルに出力したものである。有用なデータではあるが、扱いにくい面がある。そのため、複数のログを突き合わせて分析するといった活用が難しく、従来はもっぱら一つのログを単独で利用するにとどまるケースが多かった。

 扱いにくい面とは、例えば「ログを一括して処理するには対象ログを各サーバーから収集しなければならない」「ログはサイズが大きくなりがちなので収集する場合は一部を抜き出すなどの加工が必要」といったことである。ログに新たなデータが書き込まれた際に、それを即座に取り出す手段が用意されていないこともそうだ。

 こうしたログの扱いにくさは、「ログ収集基盤」と呼ばれるソフトウエアを使うことで克服可能である。ログ収集基盤は、複数のログを結び付けて分析する際などに必要な、対象ログを収集して加工し、データベースに取り込むといった処理を簡便に実施可能にする目的で開発されたもの。

 この記事では、いま注目されている二つのログ収集基盤を取り上げ、よくあるケースでどちらの方が設定が容易で、適切な選択といえるのか探る。取り上げるのは、「Fluentd」(http://fluentd.org/)と「Flume NG*1」(https://cwiki.apache.org/FLUME/flume-ng.html)である(表1)。

*1 Apache Flumeはバージョン1.0.0を境にコードベースが大きく変更された。一般に、0.9.xまでの古いApache Flumeは「Flume OG (Original Generation)」、1.0.0以降の新しいApache Flumeは「Flume NG(New Generation)」と呼ばれる。
表1●FluentdとFlume NG
 FluentdFlume NG(Apache Flume)
開発米Treasure Dataの古橋貞之氏米Apache Software Foundation
実装言語RubyJava
データ構造内部ではJSON形式任意
スケーラビリティプラグインにて実現プラグインにて実現
プラグインの充実度○(プラグインが豊富)△(プラグインが少ない)

ログ収集基盤の三つの特徴

 FluentdやFlume NGは、いずれも次の三つの特徴を持つ。

 一つは、集計に必要なデータの入力、変換、転送、合成、出力といった一連の処理を「ストリーム(連続的な流れ)」としてモデル化していること。つまり、時々刻々発生するデータを始点(入力)から終点(出力)に向かって一方向に流れるものとして扱う。ログに新たなイベントが追記されたら、それをすぐに切り出して一連の処理を実施していくのである。ログには随時、イベントが追記されるので、その特性を素直に反映したアーキテクチャーといえるだろう。

 二つ目は、始点や終点、通過点などストリームの通り道となる「ノード」を自由に配置し、目的に合わせて経路を設定できること。ノードは、簡単にいうと一つの実行プログラムである。ノードには、例えば他のノードと通信してストリームを送受信する、障害に備えてデータをバックアップするといった基本機能が備わる。

 そして三つ目は、ユーザーが独自機能を追加できるように、プラグイン機構を備えること。本体を再ビルドすることなく、拡張機能を追加したり、修正したりできる。

検証テーマ&検証にご協力いただける方を募集しています。詳しくはこちらへ。

この先は会員の登録が必要です。今なら有料会員(月額プラン)が12月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら