柔軟なログ収集を可能にする「fluentd」入門

fluentdの設定手順

続いては実際にfluentdを利用するために必要な設定手順などを紹介しておこう。以下では、Red Hat Enterprise Linux 6.3互換であるCent OS 6.3上に、fluentdの開発しているTreasure Dataが提供しているRPMパッケージを使ってfluentdをインストールする例を解説する。

fluentdのインストール

fluentdのソースコードはGitHubで公開されている。ただ、通常はソースコードからではなく、RPMやDeb形式のパッケージ、もしくはRuby Gemを利用してインストールするほうが一般的だ。なお、Ruby Gemで(もしくはソースコードから)インストールを行う場合はRuby 1.9.2が必要となるが、fluentdの開発元であるTreasure Dataが提供しているRPM/DebパッケージにはRuby 1.9系があらかじめ含まれているので、こちらを利用する場合は別途Rubyをインストールする必要はない。Red Hat Enterprise Linux(RHEL) 6やその互換ディストリビューションなど、まだRuby 1.9系を公式にサポートしていない環境ではRPM/Debパッケージを利用することをおすすめする。

それ以外の環境でのインストール方法については、ドキュメントが用意されているので、そちらを参照してほしい。

RPMパッケージを使ったインストール

fluentdの開発元であるTreasure Dataでは、RHEL互換環境に簡単にfluentdをインストールできるシェルスクリプト(http://toolbelt.treasuredata.com/sh/install-redhat.sh)を公開している。これをダウンロードして実行すれば、それだけでfluentdのインストール作業が完了する。

もしくは、手動でTreasure Dataが提供するyumリポジトリを利用する設定を追加し、yumコマンドでtd-agentパッケージをインストールすることでもインストールが可能だ。Treasure Dataのリポジトリを利用するには、/etc/yum.repos.dディレクトリに「td.repo」というファイル名で以下の設定を記述すれば良い。

[treasuredata]
name=TreasureData
baseurl=http://packages.treasure-data.com/redhat/baseurl=http://packages.treasure-data.com/redhat/$basearch
gpgcheck=0

この設定ファイルを用意すると、yumコマンドでtd-agentパッケージがインストール可能になる。

# yum install td-agent

なお、この場合fluentdの設定ファイルは/etc/td-agent以下に、ログは/var/log/td-agent/以下に保存される。

fluentdの起動や停止は、/etc/init.dディレクトリ以下に格納されるtd-agentスクリプトで行える。起動するには以下のように「start」引数付きでこのスクリプトを実行すれば良い。

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

また、fluentdを停止させるには以下のようにする。

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

もちろん、RHEL互換ディストリビューションで使われているserviceコマンドやchkconfigコマンドでの制御も可能だ。

# service td-agent
Usage: td-agent {start|stop|reload|restart|condrestart|status|configtest}
# service td-agent status
td-agent は停止しています
# chkconfig td-agent --list
td-agent        0:off   1:off   2:off   3:off   4:off   5:off   6:off

なお、fluentdのドキュメントではインストール前の作業として、NTPを使ったサーバーの時刻設定や、ファイルディスクリプタの上限数の設定、カーネルパラメータの最適化などが提示されている。これらは必須ではないが、問題の原因となる可能性もあるので、確認したうえで必要に応じて適用しておくと良いだろう。

fluentdの設定ファイル

RPMパッケージを利用してfluentdをインストールした場合、設定ファイルは/etc/td-agent/td-agnet.confとなる。この設定ファイルに収集したいイベントやログの出力先などを記述することで、ログの記録が可能になる仕組みだ。

デフォルトではいくつかの設定が記載されている(リスト1)が、そこで記載されているものは必ずしも必要であるわけではないので、設定内容をすべて破棄し、一から設定項目を記述していったほうが良いだろう。

リスト1 td-agentパッケージに含まれているデフォルトの設定ファイル(抜粋)



## match tag=debug.** and dump to console
<match debug.**>
type stdout
</match>

####
## Source descriptions:
##

## built-in TCP input
## @see http://docs.fluentd.org/articles/in_forward
<source>
type forward
</source>

## built-in UNIX socket input
#<source>
# type unix
#</source>

# HTTP input
# POST http://localhost:8888/<tag>?json=<json>
# POST http://localhost:8888/td.myapp.login?json={"user"%3A"me"}
# @see http://docs.fluentd.org/articles/in_http
<source>
type http
port 8888
</source>

設定ファイルに記述するのは、「source」および「match」、「include」という3つの設定項目(ディレクティブ)だ。

まず、sourceディレクティブはイベントの受信方法を指定するものだ。「type」キーワードで使用する入力プラグインを指定し、さらに続けてプラグインごとの設定項目を記述していく。

<source>
  type <使用するプラグイン>
  <設定項目1> <設定値1>
  <設定項目2> <設定値2>
  
  
</source>

matchディレクティブは、受信したイベントをどのように処理するかを条件文とともに指定するものだ。イベントに付加されたタグが指定したた条件文にマッチした場合、指定したプラグインにそのイベントが渡される。書式はsourceディレクトリとほぼ同じだが、matchのあとに条件文を指定する点が異なる。

<match <条件文>>
  type <使用するプラグイン>
  <設定項目1> <設定値1>
  <設定項目2> <設定値2>
  
  
</match>

条件文内では「*」や「**」といったワイルドカードや、{}を使って複数の条件を指定することができる(表1)。

表1 matchディレクトリの条件文で利用できる特殊記号
記号 説明
* 任意の単一要素にマッチする
** 任意の要素にマッチする。その要素が存在しない場合でもマッチする
{} 括弧内の少なくとも1つの要素にマッチする

たとえば「a.*」という条件文を指定した場合、「a.b」というタグにはマッチするが、「a」や「a.b.c」というタグにはマッチしない。また、「a.**」というタグは「a」や「a.b」、「a.b.c」といったタグにマッチする。

{}はor演算子のような役割をするもので、{}内でカンマで区切られた複数のタグのどれか1つにマッチすれば条件が成立する。たとえば「{a, b, c}」という条件文は、「a」や「b」、「c」というタグに対してマッチする。

これらのワイルドカードや演算子は組み合わせて使うことが可能だ。たとえば、「a.{b, c}.*」は「a.b.*」もしくは「a.c.*」のどちらかにマッチすれば条件が成立する。

最後の「include」ディレクティブは、別の設定ファイルに記述されている内容を読み込むものだ。書式は次のようになる。

include <読み込む設定ファイル>

読み込む設定ファイルの指定では絶対パスおよび相対パスの両方が使用可能だ。また、ワイルドカード「*」も利用できる。さらに、URLを指定することでネットワーク越しに設定ファイルを取得することも可能だ。

入力プラグインと出力プラグイン

前述のとおり、fluentdではイベントの入力やログの出力などはすべてプラグインという形で実装されている。

まず入力プラグインだが、公式で用意されている(fluentdに同梱されている)のは、以下の6つだ(表2)。

表2 fluentdが標準で提供する入力プラグイン
プラグイン名 説明
in_forward TCP/IPを使ってイベントを受け取る。主にほかのfluentdや各言語向けのロギングモジュールからイベントを受け取るのに使われる
in_http HTTPのPOSTリクエスト経由でイベントを受け取る
in_tail テキストファイルを監視し、そこに書き込まれたテキストをイベントとして受け取る
in_exec 指定された外部プログラムを実行し、その出力をイベントとして受け取る。指定されたプログラムは永続的、もしくは指定された時間間隔で定期的に実行される
in_syslog UDPのsyslogプロトコル経由でイベントを受け取る
in_scribe Facebookが開発したログ収集サービス「Scribe」のプロトコル経由でイベントを受け取る

入力プラグインに関する詳しい説明は、公式ドキュメントで提供されている。

また、出力プラグインについては次の12個が公式プラグインという位置付けだ(表3)。それぞれの詳細は公式ドキュメントで説明されているので、詳しくはそちらを参照して欲しい。

表3 fluentdが標準で提供する出力プラグイン
プラグイン名 種別 説明
out_copy Non-Buffered 1つ以上の出力先にログを転送する
out_null Non-Buffered なにも出力しない
out_roundrobin Non-Buffered 指定した1つ以上の出力先にラウンドロビンアルゴリズムを使ってログを転送する
out_stdout Non-Buffered 標準出力にログを出力する
out_exec_filter Buffered 引数としてログを与えて外部プログラムを実行し、その入力をイベントとして受け取る
out_forward Buffered ほかのfluentdにネットワーク経由でログを転送する
out_mongo Buffered MongoDBにログを記録する
out_mongo_replset MongoDBにログを記録する
out_exec Time Sliced 引数としてログを与えて外部プログラムを実行する
out_file Time Sliced 指定したファイルにログを記録する
out_s3 Time Sliced Amazon S3ストレージにログを記録する
out_webhdfsQ Time Sliced HDFS(Hadoop Distributed File System)にログを記録する

なお、出力プラグインについてはイベントを受け取ったら即座に出力する「Non-Buffered」型プラグインと、イベントを一定量蓄積してから出力する「Buffered」型プラグイン、そして一定の時間間隔で出力を行う「Time Sliced」型のプラグインがある。Buffered型プラグインの場合、Bufferとして使うデバイスをプラグインで指定することが可能だ。

fluentdにはプリセットのBufferプラグインとしてメモリ内にログをバッファリングする「memory」とディスク上のファイルをバッファとして使う「file」が用意されており、どのBufferプラグインを利用するかは各プラグインの設定で指定できる。

>>次ページ:設定例:Apacheのアクセスログを記録する / ログをMongoDBに記録する

おしらせ