8 logを入れる仕組みを誰も作っていなかった -> fluentd
24 英語のDocが足りない、と思っている人は? -> 12人ぐらい
25 日本語のDoc欲しい人は? -> 4人ぐらい(ほとんど居ない)
32 資源の仕様傾向をみて、あらかじめサーバを増強など
36 TOPページに来た人 -> サインアップしてくれた人はそのうち何%?
40 alerting / analysis / archiving で様々な使い方をする
42 log sourceと蓄積先・alalysisをどうつなげるか
46 スクリプト書く人と、フロントエンドを書く人が別
50 fluentd をhubに使えば上記の問題は解決する!
51 Input / Output / buffering
53 input pluginですべてjsonにする
54 output pluginはjsonに対応すればよい
79 quora.com にどのように使われているのか、実績が書かれている
83 <source> に filterを書けるようにする予定
84 filter pluginによるpipelineが可能になる予定
87 別のサーバでラベルを付けてからforwardされてくると、マッチするようになる
88 設定ファイルは一緒だが、サーバごとに違う挙動をさせられる
90 MessagePack for Ruby v5
93 in_tail = out_forward in "single" binary
95 new process model & live restart
107 時刻の単位が秒なのだが、もっと細かくならないか
111 jsonで構造化されているのが売りだとのことだが、
112 テキストベースの製品もまだある。どちらが良いのか
113 Hadoopなどでパースするときに、jsonだと難しい
114 ただし、ログの構造を知らない人がテキストファイルをパースするのは無駄が大きい
115 なのでjsonにあらかじめ強制しておけば混乱がない
117 日本語Docあるとうれしいので、お手伝いしたい
118 オフィシャルのリポジトリ以外で、どんどん翻訳するというのはむしろ歓迎する
120 公式Docと乖離してしまう問題はあるが、無いよりは全然良いので是非
123 pluginとしては残すが、fluentd本体としてはthreadに移ろうと計画している
125 佐々木 @yssk22 with ワリ @wallyqs
126 loggin infrastructure in PasS with fluentd
133 separation of concerns from IaaS
134 Scalable architecture
135 Easy to deploy applications
136 node.js の deploy 4行くらい
137 mission criticalなappはまだ難しい
139 Cloud Foundry + Fluentd
140 $ vmc target api.cloudfoundry.com
142 $ vmc push yssk22-myapp -n
145 $ vmc logs yssk22-myapp
146 アプリケーションのupdateをするとログが消えてしまう
151 fluentd はrubyで書かれているので、cloudfoundryのエコシステムに組み込むのは優しい
152 droplet execution agent
154 [ App -> fluentd ] -> log storage
156 fluentd側でファイルなどから自由にログを収集してくれるので、
157 app側でどのファイルにはき出すかなどを心配しなくて良くなる
159 [ appA -> fluentd ] -> [ another fluentd -> storage ]
161 [ appB -> fluentd ] ---^
165 Easy to include in CloudFoundry compared to other solutions
167 Easy to change storage tech depending on scale
171 adding new forwarding nodes dynamiccally through NATS
173 github:rakutentech/dea
174 https://github.com/rakutentech/dea
175 https://github.com/rakutentech/dea/commit/64d271904de1e195cc90ca1958eadf704f530d94
179 appをdeployするたびにfluentdが立ち上がる点がちょっと複雑
184 CloudFoundryの上で動くappの数に依存すると思われる
187 fluentという名前で最初は開始したが、既に同じ名前があったので、fluentdとした
189 プラグインのデバッグがとても難しい、どのようにやっているのか
190 test frameworkのできがとても良くない
192 input -> fluent cat or 出力に stdioを入れるなどの対応
203 それぞれにfluent agentが入っている
210 agent -> collector -> HDFS
212 test / production のログ切り分けを tagによって行っている
215 十分な機能(暗号化は無かったので追加した)
217 agentが数百台オーダーになるとメモリ不足
220 flume NG -> 知識の引き継ぎが出来ない感じだった
228 サーバを調査したり、煩瑣な設定変更 -> ローカルに無いと面倒
230 ログの内容が正しいか・ちゃんと記録されているか
231 td-agentがきちんと起動・動作しているのか
234 CPUやメモリ、プロセス、ポート・プロトコルで監視できる
239 td-agentは常に動作している必要がある
241 check process によるチェック
242 collectorに対しては Listen portもチェック
244 fluentdはtcp/udpごとに2プロセスが必要
245 psコマンドによってプロセス数が2つ見つからなかったらNG
246 プロセス名が ver 1.1.8 から変更になった
247 unicornなどのほかのrubyプロセスを除外
248 瞬間的に出てくる特権モード [td-agent] を除外
253 1.1.7までのtd-agentの起動スクリプトにはバグがある
254 confの内容によっては、service startの数だけプロセスが重複
256 flumeはもうオワコンなので、fluentdだ! プラグインよろしくー
257 作ったプラグインを確認すると18/16倍くらいに増えてる
259 あれ?4プロセス動いているサーバが2台有るぞ?
261 結論: agentが重複するとログが増える!
264 fluentdがログを拾って配送していること証明
268 copyなので、forwardに失敗してもflowcounterのカウント記録は成功したことになっている
269 collectorやHDFSが落ちたときは考慮していない
272 アラート・グラフ作成の集約と、状態の可視化
277 CPUとtrafficは必ず入れておかないと、fluentdを将来どうスケールするか読めなくなる
280 圧縮でagent -> collector (10秒おき)
285 25%くらい -> 秒間2000行くらいまではいけるかなぁ
286 ただし、ログのトラフィック量が変化しても、CPU負荷はあまり変化しない
287 agentの数や、agentからのflush間隔でCPU負荷が変わってくる? (要調査)
288 CollectorでAgentを把握したい
289 Agentは様々な環境にたくさん配置される
290 Collectorの位置でまとめてAgentの状態を確認できるとうれしい
291 NATだと、source addressが一つになってしまって、IPで識別は出来ない
292 hostnameのprefixでグループ化?
301 増やしたときにうまく分散するようにしたかった
302 サーバの管理が社外に出てしまうこともあったため、そうなるとVPNは難しい
308 暗号化は認証が欲しいが、どのような方法の認証が良いのか悩んでいる by 古橋
311 forwardのソースを見ると、メッセージの送り方が三つあるが?
317 serialize/de serializeせずにforwardしたいとき
322 forwardで受けて、flowcounterして、さらにforwardしているだけのノード
324 次のバージョンでマルチプロセスで並列化出来るようにする予定
326 forward -> UDPでkeepalive, TCP -> data connectionとなっているが、
327 message数が増えてくると、UDPの方が落ちてくることがままあった
328 次バージョンでheatbeatの改善を入れたい
329 TCPで接続が出来たら、heatbeatと見なすようにしたい
331 collectorでのCPU負荷とTrafficの量に関連性が薄かったが、どこがCPU負荷になっていると考えられるか
335 Windows対応はどんな感じか? F#実装の性能は?
336 ログの発生源がWindowsの場合は、td-agent-liteをWin対応にして、ログ集積はLinux
337 F# -> テストは通って、実験は成功したが、ログ収集先をWindowsにしようとしているので手間取っている感じ
339 設定ファイルをDSL化(erb)する話はどうなった?
340 DSL化すると、Rubyist以外につらい
341 設定ファイルは設定ファイルというままにした
342 設定ファイルにプログラムを書き始めるのは負けだと思っている
345 設定のDSL化が欲しいパターンはあまりなさそう
349 fluentd & TeasureDataでこっそり始めるログ集計
355 データストリームを構造化するインフラとして認識している
362 「ログとかそんなに頑張らなくても良いのでは?」
365 ---これ以降はノートPCが電源切れたので記憶を頼りに書いている
367 ... とs... でadmin用簡易webUIを作った
369 SQLっぽいクエリで結果をtableで得られる