はじめに
- 前回の続き
- td-agent(fluentd) と norikra を連携させて使ってみる
参考
引き続き、以下を参考にさせて頂いた。
準備
以下のような構成で試す。
環境の構築にあたってはこちらの Dockerfile を利用して環境構築を行った。git clone して手元の環境で docker build してコンテナイメージを作成すればすぐに試すことが出来る（はず）
fluent-plugin-norikra について
fluent-plugin-norikra は norikra に対して三つのプラグインが利用出来る。
- in_norikra
- out_norikra
- out_norikra_filter
詳細についてはこちら又は、こちらに詳しく記載、説明されている。ちなみに、今回は out_norikra を試してみる。
td-agent.conf
td-agent が既にインストールされていて、fluent-plugin-norikra もインストールされているという状態で下記のような td-agent.conf を作成した。
<source>
type tail
format nginx
path /var/log/nginx/access.log
tag nginx.access
pos_file /tmp/fluentd.pos
</source>
<match nginx.*>
type copy
<store>
type file
path /tmp/test.log
</store>
<store>
type norikra
norikra xxx.xxx.xxx.xxx:26571
target_map_tag yes
remove_tag_prefix nginx
</store>
</match>
<match norikra.**>
type stdout
</match>
type norikra の後の norikra xxx.xxx.xxx.xxx で norikra サーバーの IP アドレスを指定して td-agent を再起動する。
試す
ログを流してみる（norikra に event を流してみる）
nginx を起動させて適当にアクセスしてみると /var/log/td-agent/td-agent.log に以下のようなログが出力された。
2013-12-29 01:31:56 +0000 [warn]: temporarily failed to flush the buffer. next_retry=2013-12-29 01:31:57 +0000 error_class="RuntimeError" error="norikra server is not ready for this targets: access" instance=69934318184480 2013-12-29 01:31:56 +0000 [warn]: /usr/lib/fluent/ruby/lib/ruby/gems/1.9.1/gems/fluent-plugin-norikra-0.1.0/lib/fluent/plugin/norikra/output.rb:202:in `write' 2013-12-29 01:31:56 +0000 [warn]: /usr/lib/fluent/ruby/lib/ruby/gems/1.9.1/gems/fluentd-0.10.41/lib/fluent/buffer.rb:292:in `write_chunk' 2013-12-29 01:31:56 +0000 [warn]: /usr/lib/fluent/ruby/lib/ruby/gems/1.9.1/gems/fluentd-0.10.41/lib/fluent/buffer.rb:272:in `pop' 2013-12-29 01:31:56 +0000 [warn]: /usr/lib/fluent/ruby/lib/ruby/gems/1.9.1/gems/fluentd-0.10.41/lib/fluent/output.rb:305:in `try_flush' 2013-12-29 01:31:56 +0000 [warn]: /usr/lib/fluent/ruby/lib/ruby/gems/1.9.1/gems/fluentd-0.10.41/lib/fluent/output.rb:131:in `run' 2013-12-29 01:31:58 +0000 [warn]: retry succeeded. instance=69934318184480
これはおそらく norikra 側に access という名前で target が作成されていない為だと思われる。
2013-12-29 01:31:56 +0000 [INFO] : opening target, target:"access", fields:{}, auto_field:true
2013-12-29 01:31:58 +0000 [INFO] : opening lazy target, target:#<Norikra::Target:0x7b284266 @fields={}, @name="access", @auto_field=true>
同タイミングで norikra 側に以下のようなログが出力されていた。その後、WebUI を確認すると以下のように target が作成されていた。
フィールドのタイプを指定していない為、全てのフィールドが String となっている。
クエリーでログを処理する
以下のようなクエリーを WebUI から登録する。
select agent,path from access.win:time(60min)
クエリを登録してから改めて nginx でアクセスした後、WebUI で確認すると...
おお、クエリで処理された event が確認出来た。また、norikra-cli からも以下のようにして確認出来た。
norikra-client event fetch access-test
以下のような結果が出力された。
{"time":"2013/12/29 01:37:57","path":"/","agent":"curl/7.26.0"}
{"time":"2013/12/29 01:37:59","path":"/","agent":"curl/7.26.0"}
{"time":"2013/12/29 01:37:59","path":"/","agent":"curl/7.26.0"}
{"time":"2013/12/29 01:37:59","path":"/","agent":"curl/7.26.0"}
{"time":"2013/12/29 01:37:59","path":"/","agent":"curl/7.26.0"}
{"time":"2013/12/29 01:38:01","path":"/","agent":"curl/7.26.0"}
なるほど、なるほど、norikra を使えば単位時間のアクセス数とか特定の時間のアクセス数が SQL ライクなクエリで取得出来るな。（今頃実感として湧いてくる）
最後に
norikra単体で使っている時よりもtd-agentを合わせて利用することで、その利便性について強く実感することが出来た- 確かに
td-agentで流れてくるログを簡単にSQLライクに操作出来る環境はニーズがありそう！（弊社にて） - ちなみに
norikra本来の機能では無いがWebUIからクエリーの結果が全て閲覧出来る、もしくはCSVとしてダウンロード出来る機能があるといいなあと思ったり
