今回はDataSpiderを他のツールとの組み合わせて使用する方法を紹介しようと思います。
ということで、ログの転送・収集を簡単に行うことができるOSSツール、Fluentdを用いて、DataSpiderのアクセスログを収集する方法を紹介します。
FluentdとDataSpiderの組み合わせることで、DataSpiderのログを簡単に転送・集約することができ、柔軟な運用システムを構築することが可能です。

(※) DataSpiderのアクセスログについては、 以前の記事でも紹介していますのでご参照ください。

Fluentdとは

Fluentdとは、さまざまなデータソースからログを収集し、ファイルやリモートサーバに転送/集約することができるOSSのツールです。
Fluentdの主な特徴は以下のとおりです。

・さまざまなデータソースからログを収集、転送、集約できる
・ログメッセージはJSON形式で構造化される
・プラグインアーキテクチャの採用によりログの入力元や出力先を容易に追加できる
・障害検出機能やフェールオーバー機能により高い可用性を実現できる

Fluentdのほとんどの機能は、Input、Buffer、Outputの3つのプラグインで実現されていて、それぞれ以下の特徴があります。

・Inputプラグイン
指定した場所からログの受け取り、取り寄せを行います。ソケットを待ち受けてログを受け取ったり、データソースから定期的にログを取り寄せたりします。
例) HTTP、ファイル(tail)、外部プログラムなど。
・Bufferプラグイン
Inputプラグインから受け取ったログをバッファリングし、Outputプラグインで書き出しが成功するまでログを保存する機能を備えています。Bufferプラグインにはメモリとファイルの2種類があります。
・Outputプラグイン
指定した場所(ファイル、サーバなど)にログの書き出しを行います。書き出しに失敗してもBufferプラグインが保存してくれている間は再度書き込みを試みます。
例) HTTP、ファイル(tail)、Amazon S3、MongoDB、Hadoopなど。

さらに、独自にプラグインを開発することも可能で、開発したプラグインはRubyのパッケージ管理ツール(RubyGems)を使って配布することもできます。

 

Fluentdのインストール

Fluentdのインストールは、RubyGemsでできるほか、Fluentdの安定版パッケージであるtd-agentがrpmやdebで配布されています。今回はCentOSにtd-agentをインストールしてみます。

以下のコマンドでシェルスクリプトを実行し、td-agentをyumでインストール可能にするところからtd-agentをインストールするところまでを行います。

$ curl -L http://toolbelt.treasure-data.com/sh/install-redhat.sh | sh

インストール後は次のコマンドでtd-agentの起動/停止/再起動が行えます。

# /etc/init.d/td-agent start

# /etc/init.d/td-agent stop

# /etc/init.d/td-agent restart

Fluentdの設定

ログの収集元、転送先の設定は以下のファイルに記述します。

/etc/td-agent/td-agent.conf

上記ファイルにログの収集元、今回はDataSpiderのアクセスログを収集元として設定します。記述内容は以下のとおりです。

<source>
  type tail
  format /^(?<time>.*)\|(?<user>.*)\|(?<host>.*)\|(?<client>.*)\|(?<target>.*)\|
(?<operation>.*)\|(?<message>.*)$/
  time_format %m/%d %H:%M:%S
  path /opt/dataspider/DataSpiderServista30SP2/server/logs/access.log
  tag ds.access
  pos_file /var/log/td-agent/tmp/ds.access.log.pos
</source>

type：tailを指定すると、pathで指定したログファイルを「tail -f」コマンドと同じような振る舞いで読み取りログを収集します。
format：DataSpiderのアクセスログのフォーマットを指定します。
time_format：formatパラメータでtimeを指定した場合、その日時フォーマットを指定します。
path：DataSpiderのアクセスログのパスを指定します。
tag：ログの種類を表す文字列を指定します。
pos_file：読み取ったログの位置を記録するファイルのパスを指定します。

次に、転送先を記述します。内容は以下のとおりです。

<match ds.access>
  type file
  path /var/log/td-agent/ds.access
</match>

match要素の開始要素内には、収集元で定義したタグ文字列にマッチする正規表現を指定します。今回は「ds.access」を指定します。それ以外の設定は以下のとおりです。

type:fileを指定すると、収集したログをpathで指定したファイルに出力します。
path:収集したログの出力先となるログファイルのパスを指定します。

td-agent.confファイルに設定を記述し保存したら、以下のコマンドを実行してtd-agent.confファイルを再読み込みします。

sudo /etc/init.d/td-agent reload

td-agentが起動していない場合、上記コマンドではなくtd-agentの起動を実行してください。

これでFluentdの設定が完了しました。次は実際は動作を確認してみましょう。

 

動作確認

今回、DataSpiderのバージョンは3.0 SP2を使用しています。

DataSpiderのアクセスログを有効にしてDataSpiderServerを起動し、Studioでログインします。
ログイン後、DataSpiderのアクセスログを見てみましょう。

$ cd /opt/dataspider/DataSpiderServista30SP2/server/logs

$ cat access.log

11/26 10:09:09|root|192.168.100.34|Studio|SESSION|LOGIN|08p22ogqk59dfaa4r2qih8osgernc01n

上記のとおり、ログインのログが出力されています。

次に、/var/log/td-agentディレクトリ以下を見てみましょう。

$ cd /var/log/td-agent

$ ls

buffer  ds.access.20121126.b4cf5b94cd338f388  td-agent.log  tmp

ds.access.20121126.b4cf5b94cd338f388 というファイルが生成されているのが確認できます。ではこのファイルの中身を見てみましょう。

$ cat ds.access.20121126.b4cf5b94cd338f388 

2012-11-26T10:09:12+09:00	ds.access	{"user":"root","host":"192.168.100.34","client":"Studio","target":"SESSION","operation":"LOGIN","message":"08p22ogqk59dfaa4r2qih8osgernc01n"}

上記のようにDataSpiderのアクセスログがJSON形式で出力されていれば成功です。

 

まとめ

DataSpiderのアクセスログをFluentdで収集してローカルのファイルに出力するという簡単な動作確認をしてみましたが、Fluentdの導入のしやすさやプラグインアーキテクチャによる拡張のしやすさなどがお分かりいただけたのではないでしょうか？

また、今回はアクセスログで試してみましたが、DataSpiderの他のログでも使えそうです。
たとえば、ログ出力処理でリモートに書き込む場合、ローカルとリモートのファイルシステムをマウントさせることで実現できますが、ネットワークの瞬断によるログロストや大量のトラフィックによるログ出力処理の遅延などが考えられます。
この場合、ローカルとリモートそれぞれのサーバにFluentdを導入し、リモートへの転送はFluentd任せることで、これらの問題の解消が図れるのではと考えています。
具体的には、ログ出力処理ではローカルファイルにログを出力させ、そのファイルに出力されるログをFluentdで収集、リモートのFluentdに転送し、転送されたログをリモートファイルに出力させる、というイメージです。

DataSpiderとFluentdを組み合わせてできることはまだまだあると思っています。皆さまからのご意見・ご感想お待ちしております。