柔軟なログ収集を可能にする「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つの要素にマッチする |
たとえば「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)。
プラグイン名 | 説明 |
---|---|
in_forward | TCP/IPを使ってイベントを受け取る。主にほかのfluentdや各言語向けのロギングモジュールからイベントを受け取るのに使われる |
in_http | HTTPのPOSTリクエスト経由でイベントを受け取る |
in_tail | テキストファイルを監視し、そこに書き込まれたテキストをイベントとして受け取る |
in_exec | 指定された外部プログラムを実行し、その出力をイベントとして受け取る。指定されたプログラムは永続的、もしくは指定された時間間隔で定期的に実行される |
in_syslog | UDPのsyslogプロトコル経由でイベントを受け取る |
in_scribe | Facebookが開発したログ収集サービス「Scribe」のプロトコル経由でイベントを受け取る |
入力プラグインに関する詳しい説明は、公式ドキュメントで提供されている。
また、出力プラグインについては次の12個が公式プラグインという位置付けだ(表3)。それぞれの詳細は公式ドキュメントで説明されているので、詳しくはそちらを参照して欲しい。
プラグイン名 | 種別 | 説明 |
---|---|---|
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に記録する