帰ったらブログ書いてね、って発表者が言ってたので、律儀に書く。
Fluentd meetup in Fukuoka
http://www.zusaar.com/event/501053
fluentdってのは、ログ取りのためのプロダクト。
ログ取りには必ず目的がある。それは、取ったログを元に何かを把握するってこと。
通常、以下の様な流れになる。
情報源→収集→貯蔵→処理→可視化→報告書
さて、この中でfluentdがやってるのは収集の部分。
他の部分に関しては、他のツールがあるだろうから、ノータッチ。
まぁ一口に収集って言っても、世の中には色々な情報源がありますから、
情報源ごとに情報を切り出すコード書かなきゃいけないよねー ってのはfluentdがあってもなくても同じ。
誰かが書いたコードを拾ってこれたら良いねー、、、ってのも、fluentdがあってもなくても同じ。
じゃあfluentd無くて良いじゃん？ んなこたない。
違うんですよ。違うんです。
確かに情報源から情報を切り出すコードは個別に書かなきゃいけない。
でも、切り出した後の情報って、どうなるんです？ 切り出して終わりじゃないよね？
切り出した後の情報には、その後のだいたい共通になるプロセスがあるんですよ。
それをパッケージ化致しやしょう、ってのがfluentd。
ん、違う？ そうですよね、それだけがfluentdではない。
結局、切り出した情報を保存したい先ってのも、その時々でケースバイケースなんです。
だから、MySQLに突っ込みたいときは、MySQLに突っ込むコードを自分で書くか、どこかから拾ってこなきゃいけない。
だから、MongoDBに突っ込みたいときは、MongoDBに突っ込むコードを自分で書くか、どこかから拾ってこなきゃいけない。
だから、ツイッターに突っ込みたいときは、ツイッターに突っ込むコードを自分で書くか、どこかから拾ってこなきゃいけない。
……ええと、それもプラグインとして扱いやしょう！
情報源がN個あって、突っ込み先がM個ある時に、実装がN×M個もあったら大変だよね。
実装はN+M個にしようよ。間にfluentdを挟んでさ！
（NとMが100ずつなら、N×Mは10000になってしまうけど、N+Mなら200で済む！）
っていう、コード再利用の仕組みがfluentdなわけです。
プラグインを個人個人で公開するための場所も用意されているので、自分の書いたコードを他人に再利用してもらうのも簡単だよねー
っていう風に、使う側と作る側の両方をつなぐ再利用の仕組みがfluentdなわけです。
再利用し易いために、ログをJSON形式でやり取りしているのかもしれません。
そんなコードの再利用性を高めた先で出来る様になったことっていうのは、個別の収集コードを書いてた頃よりもずっとずっと豪華な機能達ですよ、と。
そんな豪華な環境に皆が集まって来た結果として、情報源からの情報切り出しプラグインも、貯蔵先へのデータ突っ込みプラグインも、かなりの種類が揃っている。
かなり細かな部分まで、既存のコードがあるから、新しいの書かなくて良いよ、そんな環境が整ってしまった。
こっちの水は甘いから、飲んでみろ！
……以上、fluentdの勉強会の参加リポートでした。
コメントを残す