Fluentd meetup in Japan #2に行ってきた
Fluentd meetup in Japan #2 に行った時のメモ
補足、訂正等があれば@ka_nipanまでご連絡ください。
あと、発表者さんのスライドのURLご存じでしたら教えていただけると嬉しいです。
http://www.zusaar.com/event/355006
■Fluentdの現在と未来
http://www.slideshare.net/treasure-data/fluentd-meetup-2
なぜロギングするか
エラー検知
user segmentで分析したい
ファンネル分析
ヒートマップ分析
マーケット予測
ロギングでなぜfluentか
いろんな解析、エラー検知等々をしたい
ログのソースもさまざま(DB,apache、アプリログ。。。。)
ログを出す人と回収して解析する人が違う
→解析がしにくい
fluentdならfluentにログを集めてさまざまなところに吐ける
必ずtime,tag,中身が入る
pluginで拡張可能
inputが必ずjsonなのですぐ解析できる
インストールが簡単rpm,debパッケージ
だれがfluentdを使ってるのか
slideshare,NHNJapan,NAVER,cookpad.....etc
filterプラグインをリリース予定
同じ設定ファイルを使っていても、サーバの種類に応じた処理が可能
詳しくはスライドの設定を見た方がわかりやすい
messagepack4開発中
シリアライズの速度がかなり上がるようだ
新しいプロセスのモデル
現状、プロセスを分けたとしても中央のエンジンを通る
再起動時にプロセスを残したまま新しいプロセスを起動
ログを落とさずに、td-agentを止めずに再起動できる
質疑応答
Q.時刻の精度はミリまでいけないか? A.互換性の問題がある。議論をして考えたい
Cool.ioが消えて、threadになる予定
弊社の@mazgiがfluentのドキュメントを日本語化するって宣言してました。
■Logging Infrastructure in PaaS by Fluentd
Cloud Foundry を使って Platform as a Service を作る方法を説明しつつ,fluentd をどのように活用したのか
Cloud Foundry
vm wareが作ってるPaaSのオープンソース
デプロイが簡単
ノードがダイナミックに変わるので、システム上ログがどっかに行ってしまう
デプロイされるたびにfluentdを軌道している
これである程度問題解決している
Cloud fundry fluent
アプリからfluentd agentを使ってlog strageにログをためる
ログの流量
cloud foundry自体まだまだ普及していないので全然
https:/github.com/rakutentech/
luaプラグインありませんか?の声に、「会場でリリースされました」
http://lab.motionbeat.com/blog/archives/112
■Fluentdを優しく見守る監視事例
http://www.slideshare.net/GedowFather/fluentd-meetup-2-fluentd
不幸だったエンジニア@mazgiさん....
次の発表者待ちの間の質疑応答
・テストフレームワークは次バージョンからはRspecにする予定
・agent-collector間でのメッセージ通信量で一番重要になるのは
リクエストとの回数
ロックが一番CPUを食う
flash-intervalを減らすとCPU使用率が下がるかも
・windowsサーバ対応
発生源がwindowsだけなら td-agent liteだけwindows対応するという方向で行くかも
・設定ファイルをDSL化しないのか
DSL化するとrubist以外がつらくなる
設定ファイルにコードを入れると負けだと思う
DSL化は先延ばしになりそう
設定ファイルの中にホスト名を入れたいときは、いくつか実現できるプラグインがある
■Fluentd & Treasure Data でこっそり始めるログ集計
http://d.hatena.ne.jp/mikeda/20120826/1345972294
fluentほとんど使ったことない人向け
fluentd→データストリームを統合管理する基盤だと思っている
アクセスログ
アプリのエラーログ
メールログ
傾向分析と詳細分析が簡単にできるように
アプリケーション系の会社だとログ系は優先度が低くなりがち
人員
自分一人だけ
工数
導入、展開は超簡単
費用
最初は1台 2億/dayのアクセスログ
→冗長化
実質1台でも捌けてる
in
out
パッケージの依存関係
ほぼなし
ある程度の規模なら
超簡単にできる
プラグイン
exec_fileter
目的
UIDカラムを作る
クエリストリング抜出
携帯端末ID等のカラムを統合 等
かゆいところに手が届く便利ツールとして使っている
管理画面
ジョブの一覧がみれる
tresuredata集計例
tresuredataは500Gまでは無料
SQLチックに簡単に集計クエリをかける
UIDごとにリクエストURLごとにレスポンスタイムを計測
自作プラグインは/etc/td-agent/plugin/に置くだけで動く
とりあえずmogoDBにつっこんでいる
質疑応答
in_tailは利用者が拡張できるように書いている
td-agentの次以降のバージョン
TCPで接続が成功したらハートビート成功と判定するかもしれない
次のバージョンでマルチプロセス化するらしい
現状1プロセスしか使えないので、並列化しようとすると別ポートで複数プロセスを起動する必要がある