2 http://www.slideshare.net/treasure-data/fluentd-meetup-2
9 logを入れる仕組みを誰も作っていなかった -> fluentd
25 英語のDocが足りない、と思っている人は? -> 12人ぐらい
26 日本語のDoc欲しい人は? -> 4人ぐらい(ほとんど居ない)
33 資源の仕様傾向をみて、あらかじめサーバを増強など
37 TOPページに来た人 -> サインアップしてくれた人はそのうち何%?
41 alerting / analysis / archiving で様々な使い方をする
43 log sourceと蓄積先・alalysisをどうつなげるか
47 スクリプト書く人と、フロントエンドを書く人が別
51 fluentd をhubに使えば上記の問題は解決する!
52 Input / Output / buffering
54 input pluginですべてjsonにする
55 output pluginはjsonに対応すればよい
80 quora.com にどのように使われているのか、実績が書かれている
84 <source> に filterを書けるようにする予定
85 filter pluginによるpipelineが可能になる予定
88 別のサーバでラベルを付けてからforwardされてくると、マッチするようになる
89 設定ファイルは一緒だが、サーバごとに違う挙動をさせられる
91 MessagePack for Ruby v5
94 in_tail = out_forward in "single" binary
96 new process model & live restart
108 時刻の単位が秒なのだが、もっと細かくならないか
112 jsonで構造化されているのが売りだとのことだが、
113 テキストベースの製品もまだある。どちらが良いのか
114 Hadoopなどでパースするときに、jsonだと難しい
115 ただし、ログの構造を知らない人がテキストファイルをパースするのは無駄が大きい
116 なのでjsonにあらかじめ強制しておけば混乱がない
118 日本語Docあるとうれしいので、お手伝いしたい
119 オフィシャルのリポジトリ以外で、どんどん翻訳するというのはむしろ歓迎する
121 公式Docと乖離してしまう問題はあるが、無いよりは全然良いので是非
124 pluginとしては残すが、fluentd本体としてはthreadに移ろうと計画している
126 佐々木 @yssk22 with ワリ @wallyqs
127 http://www.slideshare.net/rakutentech/fluentd-meetup-logging-infrastructure-in-paa-s
128 loggin infrastructure in PasS with fluentd
135 separation of concerns from IaaS
136 Scalable architecture
137 Easy to deploy applications
138 node.js の deploy 4行くらい
139 mission criticalなappはまだ難しい
141 Cloud Foundry + Fluentd
142 $ vmc target api.cloudfoundry.com
144 $ vmc push yssk22-myapp -n
147 $ vmc logs yssk22-myapp
148 アプリケーションのupdateをするとログが消えてしまう
153 fluentd はrubyで書かれているので、cloudfoundryのエコシステムに組み込むのは優しい
154 droplet execution agent
156 [ App -> fluentd ] -> log storage
158 fluentd側でファイルなどから自由にログを収集してくれるので、
159 app側でどのファイルにはき出すかなどを心配しなくて良くなる
161 [ appA -> fluentd ] -> [ another fluentd -> storage ]
163 [ appB -> fluentd ] ---^
167 Easy to include in CloudFoundry compared to other solutions
169 Easy to change storage tech depending on scale
173 adding new forwarding nodes dynamiccally through NATS
175 github:rakutentech/dea
176 https://github.com/rakutentech/dea
177 https://github.com/rakutentech/dea/commit/64d271904de1e195cc90ca1958eadf704f530d94
181 appをdeployするたびにfluentdが立ち上がる点がちょっと複雑
186 CloudFoundryの上で動くappの数に依存すると思われる
189 fluentという名前で最初は開始したが、既に同じ名前があったので、fluentdとした
191 プラグインのデバッグがとても難しい、どのようにやっているのか
192 test frameworkのできがとても良くない
194 input -> fluent cat or 出力に stdioを入れるなどの対応
198 http://www.slideshare.net/GedowFather/fluentd-meetup-2-fluentd
206 それぞれにfluent agentが入っている
213 agent -> collector -> HDFS
215 test / production のログ切り分けを tagによって行っている
218 十分な機能(暗号化は無かったので追加した)
220 agentが数百台オーダーになるとメモリ不足
223 flume NG -> 知識の引き継ぎが出来ない感じだった
231 サーバを調査したり、煩瑣な設定変更 -> ローカルに無いと面倒
233 ログの内容が正しいか・ちゃんと記録されているか
234 td-agentがきちんと起動・動作しているのか
237 CPUやメモリ、プロセス、ポート・プロトコルで監視できる
242 td-agentは常に動作している必要がある
244 check process によるチェック
245 collectorに対しては Listen portもチェック
247 fluentdはtcp/udpごとに2プロセスが必要
248 psコマンドによってプロセス数が2つ見つからなかったらNG
249 プロセス名が ver 1.1.8 から変更になった
250 unicornなどのほかのrubyプロセスを除外
251 瞬間的に出てくる特権モード [td-agent] を除外
256 1.1.7までのtd-agentの起動スクリプトにはバグがある
257 confの内容によっては、service startの数だけプロセスが重複
259 flumeはもうオワコンなので、fluentdだ! プラグインよろしくー
260 作ったプラグインを確認すると18/16倍くらいに増えてる
262 あれ?4プロセス動いているサーバが2台有るぞ?
264 結論: agentが重複するとログが増える!
267 fluentdがログを拾って配送していること証明
271 copyなので、forwardに失敗してもflowcounterのカウント記録は成功したことになっている
272 collectorやHDFSが落ちたときは考慮していない
275 アラート・グラフ作成の集約と、状態の可視化
280 CPUとtrafficは必ず入れておかないと、fluentdを将来どうスケールするか読めなくなる
283 圧縮でagent -> collector (10秒おき)
288 25%くらい -> 秒間2000行くらいまではいけるかなぁ
289 ただし、ログのトラフィック量が変化しても、CPU負荷はあまり変化しない
290 agentの数や、agentからのflush間隔でCPU負荷が変わってくる? (要調査)
291 CollectorでAgentを把握したい
292 Agentは様々な環境にたくさん配置される
293 Collectorの位置でまとめてAgentの状態を確認できるとうれしい
294 NATだと、source addressが一つになってしまって、IPで識別は出来ない
295 hostnameのprefixでグループ化?
304 増やしたときにうまく分散するようにしたかった
305 サーバの管理が社外に出てしまうこともあったため、そうなるとVPNは難しい
311 暗号化は認証が欲しいが、どのような方法の認証が良いのか悩んでいる by 古橋
314 forwardのソースを見ると、メッセージの送り方が三つあるが?
320 serialize/de serializeせずにforwardしたいとき
325 forwardで受けて、flowcounterして、さらにforwardしているだけのノード
327 次のバージョンでマルチプロセスで並列化出来るようにする予定
329 forward -> UDPでkeepalive, TCP -> data connectionとなっているが、
330 message数が増えてくると、UDPの方が落ちてくることがままあった
331 次バージョンでheatbeatの改善を入れたい
332 TCPで接続が出来たら、heatbeatと見なすようにしたい
334 collectorでのCPU負荷とTrafficの量に関連性が薄かったが、どこがCPU負荷になっていると考えられるか
338 Windows対応はどんな感じか? F#実装の性能は?
339 ログの発生源がWindowsの場合は、td-agent-liteをWin対応にして、ログ集積はLinux
340 F# -> テストは通って、実験は成功したが、ログ収集先をWindowsにしようとしているので手間取っている感じ
342 設定ファイルをDSL化(erb)する話はどうなった?
343 DSL化すると、Rubyist以外につらい
344 設定ファイルは設定ファイルというままにした
345 設定ファイルにプログラムを書き始めるのは負けだと思っている
348 設定のDSL化が欲しいパターンはあまりなさそう
352 http://www.slideshare.net/baguzy/fluentd-meetup-2-14073930
353 fluentd & TeasureDataでこっそり始めるログ集計
359 データストリームを構造化するインフラとして認識している
366 「ログとかそんなに頑張らなくても良いのでは?」
369 ---これ以降はノートPCが電源切れたので記憶を頼りに書いている
371 ... とs... でadmin用簡易webUIを作った
373 SQLっぽいクエリで結果をtableで得られる