Fluentd meetup in Japanに参加してきました。
今日は
Fluentd meetup in Japan
>http://www.zusaar.com/event/193104
に参加してきました。
そのメモを少し書き換えて、感想を書かせていただきます。
※かなり雑ですみません。
※あと私のフィルタがかかってしまい、メモし切れていない箇所が多分にあります。
ご容赦ください。。。
======================================================
「What's Fluentd? - The missing log collector」
http://www.slideshare.net/treasure-data/fluentd-meetup-in-japan-11410514
Treasure Data, Inc.
古橋 貞之 (@frsyuki)
======================================================
●fluentdとは…
一言で言うとsyslogd not TEXT but JSON
●特徴（売り）として、
・1イベントはtime & tag & recordで構成される
・入力、出力をpluginで開発可能
・ClientLibrariesを多く提供
Ruby、Perl、PHP、Python、Java... etc
・fluentdでリアルタイムにログ収集ができる！
→ストレージに突っ込んで解析可能。
●設定ファイルについて、
sourceとmatchで構成されます。
○source
役割は入力：typeで指定します。
例）
http:httpでデータ受信
tail:ファイルのtail
○match
役割は出力：タグでマッチング、該当データを指定先に出力します。
●ほかのログ収集アーキテクトとの比較
vs scribe
・ログのパースが必要
・インストールが面倒
・C++で書かれているので、pluginが作りにくい
・gemでインストールできるので、インストール/plugin拡張可能
vs Flume
・JVMはメモリ食うので、FrontEndに突っ込む怖さがある。
●構成
input,Buffer,Outputからなります。
Bufferは書き出せないときchunkとして保存します。
例）
out_forward
・ほかのfluendに転送する
・転送先とheardbeat通信
・2：3など負荷の振り分けできる。
buf_file
・出力先が死んでしまっても、ファイルに書き出し、
データを保存
・その後再送（2のべき乗後に）
in_tail
・ApacheParserでログを構造化できる。
●TestDriverあります。
・pluginの試験可能が容易です。
●性能
・秒間数万イベント裁けます。
●その他（Q&A）
chunkのあるサイズになったら次に移ります。
かつ順序は保存されます。
再送はパフォーマンス優先で順序保障しないです。
Flumeとの比較において、Flumeは大規模分散環境に有利ではないかとのこと。
クラスタ上での監視はfluentdではなく、別に仕組みを用意する必要があります。
フェイルオーバは今のところなし
buffer（デフォルト256MB,キューサイズ制限なり）あふれた場合、
ログはセカンダリに送られる、それでもダメならログは失われます。
直接話を伺わせていただきましたが、
古橋さん自身、fluentdは
・messagepackを有効活用し、効率よくログ収集を行う
・多種多様なニーズに合わせ、pluginを作成できる
ことを念頭に置き、開発されたそうです。
ログが失われることに関して、反応してしまったのですが、
しばらく（6時間）転送できなくても、後に再送してくれるし、
セカンダリという設定もありで、
容易なpluginでの拡張や運用でカバーするのがよさそうですね。
======================================================
「Dive into Fluent Plugin」
http://www.slideshare.net/repeatedly/fluentd-meetup-dive-into-fluent-plugin
Preferred Infrastructure, Inc.
Masahiro Nakagawa (@repeatedly)
======================================================
検索エンジン会社にお勤めだそうです。
●Fluentdのフレキシブルなplugin機能
pluginの名前は「fluentd-plugin-xxx」
インストールは fluent-gem install xxx
●Cool.io、messagePackを使用している。
●rubyはシングルスレッド、シングルプロセスだが、
Mixin によりプロセスで起動してinput,outputなどがそれぞれ動いてくれる
→パフォーマンス対策です。
inputはとくにeventloopもしくはスレッド分割が必要
Time.nowは使えないので、Engine.nowを使用する
●Bufferは作るのが難しいが、memoryとFileで事足りる
●outputは多く作られている。
formatメソッドとwirteメソッドをoverride
formatでシリアライズ→buffer→wirteでデシリアライズ、出力
mapにchunkがあるので、時刻指定すれば、その時刻のchunkにinsert
●その他（Q&A）
複数行のログを１eventとして扱う場合はin_tailを拡張?
→tailをoverrideしてparserLineを実装する。複数行のparserは難しいけどね。
railsの中のログを集めてというplugin をTD社の中では既に作っています。
======================================================
「fluent を使った大規模ウェブサービスのロギング」
http://www.slideshare.net/hotchpotch/20120204fluent-logging
COOKPAD, Inc.
舘野 祐一 (id:secondlife, @hotchpotch)
======================================================
CookPadの開発基盤部だそうです。
●PVログは超巨大
→一日分はMySQLをオンメモリで高速に処理
ところがそれ以上はオンメモリ使えず遅い
blackholeエンジンで保存速度は速いけど、遅いときもある。
ほかのログはJSONでシリアライズor createtable
→insertコストがかかるし、手軽に取れない
●だからfluentd
構造化ログができてない時代だと、様々なところに気を使う。
たとえば新しい集計をしたくなったら、サービスを落とさない・サービスに影響の少ない時間帯のメンテが必要になる。
あるいはメンテコスト・開発コストが必要になるので「そもそもやらなくなる」
●パフォーマンス
ローカルにfluentd,定期的に転送
本体は安定している。エラーはプラグインで発生する
再送があり、6時間とめてもちゃんとmongodbに保存された。
●管理
Centosなのでrpmインストール
td-agentにはruby1.9.2入り
puppetで構成管理
リトライ2の16乗＝1日ぐらい失敗し続けてからはつらい。retry_limitは覚えておこう。
中央の転送用サーバ
・RVM（Ruby1．9.2）
・gitで設定ファイル管理
・Gemfile
バッファをすぐに処理する方法あり
かつシグナル送って設定再読み込みできる。
●はまり
設定でルーティングミスってもエラーにならない（反映後の再起動漏れ）
●要望
設定ファイルの柔軟化
・正規表現、フィルタなどでpluginを管理したい
・変数使いたい
●まとめ：ログはこれから重要になる
・ログをとるのがfluentdで簡単になる
・きちんと統計を考えられるエンジニアとなる
→巨大データ処理ができるので、
どのデータに何の価値があるのか、それを仕事に結び付けられるか？
●その他（Q&A）
限界性能は
→1台集約して40Mbps裁けた
もうここまでやっていたんですね。はやいなぁ。
アプリケーションのログを収集してきた人たちが
fluetndを使って、こうやって置き換えていくのかなと感じました。
fluentdの運用に関しても、
集中制御する機構をもたなくても、
puppetなどのほかのツールでカバーしています。
また、fluentdがもつ構造化ログを扱う強みがすごく生きてますね。
JSONで統一されるので、その後の取り回しがやりやすそう。
======================================================
「fluentをサービスで使ってみた」
http://www.slideshare.net/naverjapan/20120204fluent-public
NHN Japan株式会社
Tetsuya Ohira (@just_do_neet)
======================================================
●fluentdを使った理由
解析処理より転送・コピー処理でこける
ファイル数が多い
既存システムに影響与えたくない
もっと安心できr氏間に実施したい
定期的に細かい単位で処理したい
●社内向けログ解析
access_logを使用してデータを収集する
ブログ参照
旧来の解析システムを置き換え
fluentdが直接投入せず、HDFSには定期的にアップロードする
●効果
fluentdによりログコピー処理の高速化
MapReduceで処理するときにはHDFS上にログがある!
●耐障害性
App上の生access_logを使って復旧
復旧時は途中まで書いたログは破棄して、再転送
書き込み失敗した場合はfluentd再書き込み
本体は安定、pluginでエラーになるが、自分で直せる安心さ。要ruby力
●使い勝手
JSONで統一できているので、fluentd+mongoDB+node.jsがイケてる
●相談ポイント
・動的に設定ファイルの内容を変更したい
例）ログファイル名に日付が入っている
・必要な情報だけ送信したい
・fluentdのメトリクス情報がほしい
======================================================
「Distributed message stream processing on fluentd」
http://www.slideshare.net/tagomoris/distributed-stream-processing-on-fluentd-fluentd
NHN Japan株式会社 ウェブサービス本部
Tagomori Satoshi (@tagomoris)
======================================================
●用途
Hiveへデータを収集→集計
会社的にJavaでのビルド、デプロイは避けたい
→rubyがいい
TimeslicedOutput
時間単位でログを扱ってくれるのはうれしい
●性能
127台146のログストリーム
毎秒7万メッセージ 120Mbps
89インスタンス（12台fluentd専用node)
タブ区切りでログ出力→あとあとの読み込みで楽になる
ログローテートに頼ると1，2秒ずれる（誤差10万行!）
→ログ内容見てローテート
●fluentd導入効果
いままでは
・生ログのままHDFSに書き込み
→コンバートして別のHDFS上のパスに保存
→aggregate（ログの解析）
結果ログ収集は2，3時間遅延する
今は
・fluentdでストリーム処理
→来た順番に変換していく
結果HDFSにかけた時点ですぐにHiveに登録できるので、
集計が早くなった
●耐障害性
いつでもバッチを再実行できるようにしたい
バッチ処理とストリーム処理は同一コードだから、再実行できる
具体的には、
out_exec_filter
fluentd→標準入力→外部プログラム処理→標準出力→fluentd
●構成
・deliver（二重化：hotstanby）送り先を考えてくれる
コンバートするworkerのロードバランスする
・worker
ログをコンバートする。（タブ区切り）
・serializer
workerからのデータを受け取り、HDFSにデータを書き込む
同じパス（ディレクトリ）に書き込む人を少なくするため、
バッファリングしてくれる
・watcher
監視のために用意
deliverとserializerからデータを受け取る
deliverの場合 ：生ログから解析
serializerの場合 ：コンバートされたデータから解析
●fluentdを使う理由
scribeはログを転送するだけには重い
scribeで使えるプログラムがあるから
●サーバ内部の動き
・deliverサーバ内部
roundrobin
56のあて先（7台×８worker）に順序送れる箇所へ送信
・workerサーバ内部
8つのworkerと1つのserializer
ここでout_exec_filterが発動
→整形してfluentdのpluginにデータを渡してくれる
●各サーバの性能
・deliver性能
deliver2台あわせて120Mbps
動画配信のログは頭打ちになる
→agentが待たされた
CPUはscribeが重たいから？
・worker性能
30台
入力120Mbps
出力の性能がギザギザのグラフとなったのはHoopの性能
CPUは40％程度
out_foward でのラウンドロビンだとバッファやフラッシュ時間設定に依存するので粒度が大きすぎるが、
roundrobin 経由で out_foward するとメッセージ単位でのラウンドロビンが出来る
今日の勉強会で一番気になっていたセッションでした。
Hiveへ突っ込む前の中間処理をストリームで流しながら、fluentdでやらせている点、
先進的に感じました。
かつ性能もかなり詳細に数字を出していただけたので、
いろんな人がfluentdでのリアルタイム処理の夢を描いたと思いました。
やりたいですよね。
【LT】
======================================================
* @shun0102: 「fluent-plugin-dstatを使ったリアルタイムクラスタモニタリング」
http://www.slideshare.net/shun0102/fluent-plugindstat
======================================================
dstat
vmstatやnetstatの内容を1つのコマンドで実行できる
fluent-plugin-dstat
dstatの内容をparse→性能データを転送できるようにする
これらを使い、
mongoDBにデータを集約、node.jsで結果を表示する
======================================================
* @chobi_e: 「Fluentd & PHP」
http://www.slideshare.net/shuheitanuma/fluentd-and-php
======================================================
FluentLoggerの紹介
fluent-plugin-delayed
未来の日付のデータを時間差おいて出力する
======================================================
* @railute:「Fluent Output Plugin for Cassandra」
https://skydrive.live.com/view.aspx?cid=D105615A0F594518&resid=D105615A0F594518%21333
======================================================
書き込みが早いCassandra
データ設計が大事なCassandra
ゆえに
動的Columnマッピングができるようにしたいなぁ
======================================================
* @choplin: 「Write Parser with fun!」
http://www.slideshare.net/choplin/write-parse-with-fun-11414130
======================================================
fluentdなどの新しいOSS導入には、
・非構造
・会社ポリシー
の障害がある。
お勧めしたいポイント：parsar書いてはどうか？
Tail inputを拡張すれば簡単にできる→障壁クリア
parseLineをoverrideすればOK
======================================================
* @ixixi: 「fluent-plugin-couch」
http://www.slideshare.net/ixixi/fluent-plugins-for-couchdbamazon-sqssns
======================================================
・fluent-plugin-couchdb
CouchDBはHTTP&JSONを持つので相性がよい
バルクインポートできるので、内部で使用した。
今後はサーバの状態遷移を収集できるかな
・fluent-plugin-sqs
送信側と受信側を疎結合にしたい
→queueが必要
→そこでAmazonSQS
バルクインサートあるので、内部で使用した
かつこの方が安上がり
今後はinput_pluginかな
・fluent-plugin-sns
マルチプロトコル（e-mail(JSON),http(s),SMS,SQS）
で通知可能
配信者がfluentdを使用する
→SNSが適切なプロトコルで通知を行う
※配信者が通知先を管理しない
フォーマットの指定、複数指定をやりたい
======================================================
●出版の紹介
======================================================
niftyクラウドに関する本で
fluentdをTipsで紹介します
dailyでログ収集する記事
2/22出版予定
Openクラスドで100冊用意するそうです。
======================================================
●fluentdのAnalizeからみた視点
======================================================
@doryokujinさんから総纏めのLTです。
1．EventCollection
2．DataStorage
3．DataFiltering、Aggrecation
------------------------ ↑Hadoopでもてはやされた部分
↓まだまだ
4．DataMining/Visualization
上記すべてを1つのサービスと考えれば、
EventCollection（fluentd）は重要
課題点
・ユーザごとのアクセスログ取得・最適化
・短い単位（毎時・毎分）での解析
・データの構造化→収集する時点で戦略が必要になる
fluentdならば、、、
Web3.0で必要とされるログの構造化（JSON）が行える
リアルタイムに収集できる
必要なものをすべて収集する
======================================================
======================================================最後に、
今日の勉強会に参加できて本当によかったと思いました。
正直、ログ収集だけでこんなに濃密な内容になるとは思いませんでした。
耐障害性や性能、運用まで
実績を積みつつあるんでしょうね。
かつ黄金のパターン
fluentd + mongoDB + node.js
ができちゃってますね。
相性がいいのはわかっていましたが、ここまで普及しているとは。。。
さらにplugin作成の魅力が多くの人に伝わったと思いした。
これから先、さまざまなプロトコルに対応したpluginが作られ、
その点で、ほかのログ収集アーキテクト（Flume,scribeなど）を圧倒すると思います。
「目指せ、ApacheCamel並みのインターフェース」でしょうか。
本当に最後になりましたが、
講師、運営の皆さんありがとうございました。
