| 1 | 古橋 |
|---|
| 2 | cedec awards 2012 |
|---|
| 3 | fluentdで受賞 |
|---|
| 4 | |
|---|
| 5 | self-introduction |
|---|
| 6 | treasure data |
|---|
| 7 | hadoop, big data |
|---|
| 8 | logを入れる仕組みを誰も作っていなかった -> fluentd |
|---|
| 9 | |
|---|
| 10 | video |
|---|
| 11 | 概要 |
|---|
| 12 | logをjson形式で集めて蓄積する |
|---|
| 13 | |
|---|
| 14 | 次のバージョンどうするか |
|---|
| 15 | アンケート |
|---|
| 16 | ログ解析に何を使っているか |
|---|
| 17 | 7割の方がfluentd |
|---|
| 18 | 保存先？ |
|---|
| 19 | mongdb 46%くらい |
|---|
| 20 | RDBMS 40%強 |
|---|
| 21 | 導入障壁 |
|---|
| 22 | 検討中 |
|---|
| 23 | ドキュメントが不足 |
|---|
| 24 | 英語のDocが足りない、と思っている人は？ -> 12人ぐらい |
|---|
| 25 | 日本語のDoc欲しい人は？ -> 4人ぐらい(ほとんど居ない) |
|---|
| 26 | プラグインなど機能が少ない |
|---|
| 27 | 実績が… |
|---|
| 28 | なぜロギングするのか |
|---|
| 29 | error notify |
|---|
| 30 | new reric |
|---|
| 31 | performance monitor |
|---|
| 32 | 資源の仕様傾向をみて、あらかじめサーバを増強など |
|---|
| 33 | user segment analysis |
|---|
| 34 | ユーザの使用傾向 |
|---|
| 35 | funnnel analysis |
|---|
| 36 | TOPページに来た人 -> サインアップしてくれた人はそのうち何%？ |
|---|
| 37 | heatmap |
|---|
| 38 | 時刻と曜日の二軸グラフ化 |
|---|
| 39 | なぜロギングにfluentdを？ |
|---|
| 40 | alerting / analysis / archiving で様々な使い方をする |
|---|
| 41 | log sourceも様々な物がある |
|---|
| 42 | log sourceと蓄積先・alalysisをどうつなげるか |
|---|
| 43 | bash script? perl? |
|---|
| 44 | 悪魔的なスクリプトは… |
|---|
| 45 | メンテナンスできる人がいなくなると困る |
|---|
| 46 | スクリプト書く人と、フロントエンドを書く人が別 |
|---|
| 47 | 期待するログのフォーマットが違う |
|---|
| 48 | logrotate |
|---|
| 49 | 最大24h待たされる |
|---|
| 50 | fluentd をhubに使えば上記の問題は解決する！ |
|---|
| 51 | Input / Output / buffering |
|---|
| 52 | それぞれpluginになっている |
|---|
| 53 | input pluginですべてjsonにする |
|---|
| 54 | output pluginはjsonに対応すればよい |
|---|
| 55 | logの必須3要素 |
|---|
| 56 | 時刻 |
|---|
| 57 | タグ |
|---|
| 58 | jsonレコード |
|---|
| 59 | fluentdの特徴 |
|---|
| 60 | 拡張可能な plugin 形式 |
|---|
| 61 | json という統一フォーマット |
|---|
| 62 | インストールが楽 |
|---|
| 63 | |
|---|
| 64 | plugins一覧 |
|---|
| 65 | DL人気順に並んでいる |
|---|
| 66 | |
|---|
| 67 | 既存システムとの比較 |
|---|
| 68 | scribe |
|---|
| 69 | 拡張可能ではない |
|---|
| 70 | 統一フォーマット無い |
|---|
| 71 | .... |
|---|
| 72 | |
|---|
| 73 | 誰がfluentdを使っているのか |
|---|
| 74 | slide share |
|---|
| 75 | viki |
|---|
| 76 | context logic |
|---|
| 77 | nhn japan |
|---|
| 78 | cookpad |
|---|
| 79 | quora.com にどのように使われているのか、実績が書かれている |
|---|
| 80 | |
|---|
| 81 | fluentdの次バージョンについて |
|---|
| 82 | filter pluginの導入 |
|---|
| 83 | <source> に filterを書けるようにする予定 |
|---|
| 84 | filter pluginによるpipelineが可能になる予定 |
|---|
| 85 | <label> |
|---|
| 86 | デフォルトではマッチしない |
|---|
| 87 | 別のサーバでラベルを付けてからforwardされてくると、マッチするようになる |
|---|
| 88 | 設定ファイルは一緒だが、サーバごとに違う挙動をさせられる |
|---|
| 89 | |
|---|
| 90 | MessagePack for Ruby v5 |
|---|
| 91 | |
|---|
| 92 | td-agent-lite |
|---|
| 93 | in_tail = out_forward in "single" binary |
|---|
| 94 | |
|---|
| 95 | new process model & live restart |
|---|
| 96 | 現在は中央のプロセスを経由している |
|---|
| 97 | |
|---|
| 98 | live restart |
|---|
| 99 | ログを取りこぼさずに再起動する |
|---|
| 100 | |
|---|
| 101 | 後方互換性 |
|---|
| 102 | fluentd::new |
|---|
| 103 | fluentd::old |
|---|
| 104 | の名前空間で対応 |
|---|
| 105 | |
|---|
| 106 | Q&A |
|---|
| 107 | 時刻の単位が秒なのだが、もっと細かくならないか |
|---|
| 108 | ミリ秒とかが欲しい |
|---|
| 109 | 互換性の問題があるので、変更は難しい |
|---|
| 110 | |
|---|
| 111 | jsonで構造化されているのが売りだとのことだが、 |
|---|
| 112 | テキストベースの製品もまだある。どちらが良いのか |
|---|
| 113 | Hadoopなどでパースするときに、jsonだと難しい |
|---|
| 114 | ただし、ログの構造を知らない人がテキストファイルをパースするのは無駄が大きい |
|---|
| 115 | なのでjsonにあらかじめ強制しておけば混乱がない |
|---|
| 116 | |
|---|
| 117 | 日本語Docあるとうれしいので、お手伝いしたい |
|---|
| 118 | オフィシャルのリポジトリ以外で、どんどん翻訳するというのはむしろ歓迎する |
|---|
| 119 | どんどん広報して、力を合わせて欲しい |
|---|
| 120 | 公式Docと乖離してしまう問題はあるが、無いよりは全然良いので是非 |
|---|
| 121 | |
|---|
| 122 | coolioを捨てる計画はあるか |
|---|
| 123 | pluginとしては残すが、fluentd本体としてはthreadに移ろうと計画している |
|---|
| 124 | |
|---|
| 125 | 佐々木 @yssk22 with ワリ @wallyqs |
|---|
| 126 | loggin infrastructure in PasS with fluentd |
|---|
| 127 | |
|---|
| 128 | Cloud Foundry (tm) |
|---|
| 129 | VMware の PaaS |
|---|
| 130 | ruby |
|---|
| 131 | main points |
|---|
| 132 | open source |
|---|
| 133 | separation of concerns from IaaS |
|---|
| 134 | Scalable architecture |
|---|
| 135 | Easy to deploy applications |
|---|
| 136 | node.js の deploy 4行くらい |
|---|
| 137 | mission criticalなappはまだ難しい |
|---|
| 138 | ソースをいじりながら対応しようとしている |
|---|
| 139 | Cloud Foundry + Fluentd |
|---|
| 140 | $ vmc target api.cloudfoundry.com |
|---|
| 141 | $ ... |
|---|
| 142 | $ vmc push yssk22-myapp -n |
|---|
| 143 | $ ... |
|---|
| 144 | $ curl http:// ... |
|---|
| 145 | $ vmc logs yssk22-myapp |
|---|
| 146 | アプリケーションのupdateをするとログが消えてしまう |
|---|
| 147 | 現在の仕様 |
|---|
| 148 | FileSystemが永続化されていない |
|---|
| 149 | 解析が不能 |
|---|
| 150 | |
|---|
| 151 | fluentd はrubyで書かれているので、cloudfoundryのエコシステムに組み込むのは優しい |
|---|
| 152 | droplet execution agent |
|---|
| 153 | どのようにログを蓄積するか |
|---|
| 154 | [ App -> fluentd ] -> log storage |
|---|
| 155 | log storageを外に用意する |
|---|
| 156 | fluentd側でファイルなどから自由にログを収集してくれるので、 |
|---|
| 157 | app側でどのファイルにはき出すかなどを心配しなくて良くなる |
|---|
| 158 | |
|---|
| 159 | [ appA -> fluentd ] -> [ another fluentd -> storage ] |
|---|
| 160 | ^ |
|---|
| 161 | [ appB -> fluentd ] ---^ |
|---|
| 162 | |
|---|
| 163 | Fluentd Pros & Cons |
|---|
| 164 | Pros |
|---|
| 165 | Easy to include in CloudFoundry compared to other solutions |
|---|
| 166 | Easy to extend |
|---|
| 167 | Easy to change storage tech depending on scale |
|---|
| 168 | Cons |
|---|
| 169 | .... |
|---|
| 170 | NATS input plugin |
|---|
| 171 | adding new forwarding nodes dynamiccally through NATS |
|---|
| 172 | |
|---|
| 173 | github:rakutentech/dea |
|---|
| 174 | https://github.com/rakutentech/dea |
|---|
| 175 | https://github.com/rakutentech/dea/commit/64d271904de1e195cc90ca1958eadf704f530d94 |
|---|
| 176 | |
|---|
| 177 | nginx + lua |
|---|
| 178 | luaのloggerがあるとうれしい |
|---|
| 179 | appをdeployするたびにfluentdが立ち上がる点がちょっと複雑 |
|---|
| 180 | |
|---|
| 181 | Q&A |
|---|
| 182 | ログの流量はどれくらい？ |
|---|
| 183 | まだまだ全然 |
|---|
| 184 | CloudFoundryの上で動くappの数に依存すると思われる |
|---|
| 185 | |
|---|
| 186 | Q&A |
|---|
| 187 | fluentという名前で最初は開始したが、既に同じ名前があったので、fluentdとした |
|---|
| 188 | |
|---|
| 189 | プラグインのデバッグがとても難しい、どのようにやっているのか |
|---|
| 190 | test frameworkのできがとても良くない |
|---|
| 191 | rspecを次バージョンで入れる予定 |
|---|
| 192 | input -> fluent cat or 出力に stdioを入れるなどの対応 |
|---|
| 193 | |
|---|
| 194 | |
|---|
| 195 | 外道父@GedowFather |
|---|
| 196 | Fluentdを優しく見守る監視事例 |
|---|
| 197 | 自己紹介 |
|---|
| 198 | ドリコム |
|---|
| 199 | インフラエンジニア |
|---|
| 200 | |
|---|
| 201 | 動作環境について |
|---|
| 202 | IDCがいっぱいある環境 |
|---|
| 203 | それぞれにfluent agentが入っている |
|---|
| 204 | Global IP/暗号化 |
|---|
| 205 | vpnは使っていない |
|---|
| 206 | HDFSに保存 |
|---|
| 207 | プラグイン |
|---|
| 208 | 改造したtail コマンドでagentへ |
|---|
| 209 | ローカルで保存ししつつforward |
|---|
| 210 | agent -> collector -> HDFS |
|---|
| 211 | collector |
|---|
| 212 | test / production のログ切り分けを tagによって行っている |
|---|
| 213 | Fluentd vs flume OG |
|---|
| 214 | flume OG |
|---|
| 215 | 十分な機能(暗号化は無かったので追加した) |
|---|
| 216 | Java |
|---|
| 217 | agentが数百台オーダーになるとメモリ不足 |
|---|
| 218 | agentからのキュー再送が不安定 |
|---|
| 219 | -> fluentdへ |
|---|
| 220 | flume NG -> 知識の引き継ぎが出来ない感じだった |
|---|
| 221 | td-agentにした |
|---|
| 222 | パッケージ管理は重要 |
|---|
| 223 | Rubyエンジニア対応できる |
|---|
| 224 | ローカル監視 |
|---|
| 225 | 必要な理由 |
|---|
| 226 | プロセス操作はローカルでやるべき |
|---|
| 227 | サーバが社外にある場合 |
|---|
| 228 | サーバを調査したり、煩瑣な設定変更 -> ローカルに無いと面倒 |
|---|
| 229 | 注意点 |
|---|
| 230 | ログの内容が正しいか・ちゃんと記録されているか |
|---|
| 231 | td-agentがきちんと起動・動作しているのか |
|---|
| 232 | HDFSへちゃんと送られているか |
|---|
| 233 | 監視にはmonitを使っている |
|---|
| 234 | CPUやメモリ、プロセス、ポート・プロトコルで監視できる |
|---|
| 235 | スクリプト実行の返値でアクション |
|---|
| 236 | 起動スクリプト実行、メール、etc |
|---|
| 237 | monit |
|---|
| 238 | td-agentの基本プロセスの監視 |
|---|
| 239 | td-agentは常に動作している必要がある |
|---|
| 240 | 主に人災(操作ミス)対策 |
|---|
| 241 | check process によるチェック |
|---|
| 242 | collectorに対しては Listen portもチェック |
|---|
| 243 | td-agentの重複デーモン監視 |
|---|
| 244 | fluentdはtcp/udpごとに2プロセスが必要 |
|---|
| 245 | psコマンドによってプロセス数が2つ見つからなかったらNG |
|---|
| 246 | プロセス名が ver 1.1.8 から変更になった |
|---|
| 247 | unicornなどのほかのrubyプロセスを除外 |
|---|
| 248 | 瞬間的に出てくる特権モード [td-agent] を除外 |
|---|
| 249 | もし重複して起動していたら |
|---|
| 250 | init.d/td-agent stop |
|---|
| 251 | pkill |
|---|
| 252 | td-agent start |
|---|
| 253 | 1.1.7までのtd-agentの起動スクリプトにはバグがある |
|---|
| 254 | confの内容によっては、service startの数だけプロセスが重複 |
|---|
| 255 | mazgi事件 |
|---|
| 256 | flumeはもうオワコンなので、fluentdだ！ プラグインよろしくー |
|---|
| 257 | 作ったプラグインを確認すると18/16倍くらいに増えてる |
|---|
| 258 | agent分よりHDFSが多くなっていた |
|---|
| 259 | あれ？4プロセス動いているサーバが2台有るぞ？ |
|---|
| 260 | mazgi先生は濡れ衣だった |
|---|
| 261 | 結論: agentが重複するとログが増える！ |
|---|
| 262 | flowcounterで転送状態監視 |
|---|
| 263 | アプリがログを記録している証明 |
|---|
| 264 | fluentdがログを拾って配送していること証明 |
|---|
| 265 | 部分的な記録ミスなどは、無視 |
|---|
| 266 | あまりやり過ぎるとアラート対象が増える |
|---|
| 267 | 問題点 |
|---|
| 268 | copyなので、forwardに失敗してもflowcounterのカウント記録は成功したことになっている |
|---|
| 269 | collectorやHDFSが落ちたときは考慮していない |
|---|
| 270 | fluentd + monit十分な感じ |
|---|
| 271 | リモート監視 |
|---|
| 272 | アラート・グラフ作成の集約と、状態の可視化 |
|---|
| 273 | 特にCollectorのキャパシティ対策 |
|---|
| 274 | nagios + nrpe-server |
|---|
| 275 | グラフはcactiとか |
|---|
| 276 | cacti <- snmpd |
|---|
| 277 | CPUとtrafficは必ず入れておかないと、fluentdを将来どうスケールするか読めなくなる |
|---|
| 278 | 一行350バイト程度・毎秒500行程度 |
|---|
| 279 | traffic |
|---|
| 280 | 圧縮でagent -> collector (10秒おき) |
|---|
| 281 | 0.7Mbpsくらい |
|---|
| 282 | collector -> HDFS |
|---|
| 283 | 1.5Mbpsくらい |
|---|
| 284 | CPU |
|---|
| 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でグループ化？ |
|---|
| 293 | 監視を設定することで安定した運用が望める |
|---|
| 294 | |
|---|
| 295 | Q&A |
|---|
| 296 | agentの数は？ |
|---|
| 297 | 300-400くらい |
|---|
| 298 | |
|---|
| 299 | VPNを張らなかった理由は？ |
|---|
| 300 | VPNは多様性と負荷分散性に弱い |
|---|
| 301 | 増やしたときにうまく分散するようにしたかった |
|---|
| 302 | サーバの管理が社外に出てしまうこともあったため、そうなるとVPNは難しい |
|---|
| 303 | |
|---|
| 304 | 圧縮・暗号化はどうやったのか |
|---|
| 305 | forwardを改造した |
|---|
| 306 | gzip/growfish |
|---|
| 307 | |
|---|
| 308 | 暗号化は認証が欲しいが、どのような方法の認証が良いのか悩んでいる by 古橋 |
|---|
| 309 | |
|---|
| 310 | Q&A |
|---|
| 311 | forwardのソースを見ると、メッセージの送り方が三つあるが？ |
|---|
| 312 | tag time record |
|---|
| 313 | 一番単純 |
|---|
| 314 | ？ |
|---|
| 315 | バッチで送る |
|---|
| 316 | packed forward |
|---|
| 317 | serialize/de serializeせずにforwardしたいとき |
|---|
| 318 | |
|---|
| 319 | 公称対応限界は？ |
|---|
| 320 | CPUの処理能力に単純に依存している |
|---|
| 321 | 6万message / 8coreくらい |
|---|
| 322 | forwardで受けて、flowcounterして、さらにforwardしているだけのノード |
|---|
| 323 | 1coreあたり8000くらい？ |
|---|
| 324 | 次のバージョンでマルチプロセスで並列化出来るようにする予定 |
|---|
| 325 | |
|---|
| 326 | forward -> UDPでkeepalive, TCP -> data connectionとなっているが、 |
|---|
| 327 | message数が増えてくると、UDPの方が落ちてくることがままあった |
|---|
| 328 | 次バージョンでheatbeatの改善を入れたい |
|---|
| 329 | TCPで接続が出来たら、heatbeatと見なすようにしたい |
|---|
| 330 | |
|---|
| 331 | collectorでのCPU負荷とTrafficの量に関連性が薄かったが、どこがCPU負荷になっていると考えられるか |
|---|
| 332 | リクエストの回数にbindするはず |
|---|
| 333 | lockに処理を奪われている感じがある |
|---|
| 334 | |
|---|
| 335 | Windows対応はどんな感じか？ F#実装の性能は？ |
|---|
| 336 | ログの発生源がWindowsの場合は、td-agent-liteをWin対応にして、ログ集積はLinux |
|---|
| 337 | F# -> テストは通って、実験は成功したが、ログ収集先をWindowsにしようとしているので手間取っている感じ |
|---|
| 338 | |
|---|
| 339 | 設定ファイルをDSL化(erb)する話はどうなった？ |
|---|
| 340 | DSL化すると、Rubyist以外につらい |
|---|
| 341 | 設定ファイルは設定ファイルというままにした |
|---|
| 342 | 設定ファイルにプログラムを書き始めるのは負けだと思っている |
|---|
| 343 | mixin プラグイン側で対応するかも |
|---|
| 344 | |
|---|
| 345 | 設定のDSL化が欲しいパターンはあまりなさそう |
|---|
| 346 | config expander |
|---|
| 347 | |
|---|
| 348 | 池田 @mikeda |
|---|
| 349 | fluentd & TeasureDataでこっそり始めるログ集計 |
|---|
| 350 | |
|---|
| 351 | 自己紹介 |
|---|
| 352 | 450台くらい |
|---|
| 353 | |
|---|
| 354 | fluentd |
|---|
| 355 | データストリームを構造化するインフラとして認識している |
|---|
| 356 | |
|---|
| 357 | アクセスログ |
|---|
| 358 | 2億/day くらい |
|---|
| 359 | アプリケーションエラーログ |
|---|
| 360 | メールログ(試験中) |
|---|
| 361 | |
|---|
| 362 | 「ログとかそんなに頑張らなくても良いのでは？」 |
|---|
| 363 | 実際どうだったか |
|---|
| 364 | 工数 |
|---|
| 365 | ---これ以降はノートPCが電源切れたので記憶を頼りに書いている |
|---|
| 366 | 一人でやってもそうかからなかった(?) |
|---|
| 367 | ... とs... でadmin用簡易webUIを作った |
|---|
| 368 | 100行＋100行くらい |
|---|
| 369 | SQLっぽいクエリで結果をtableで得られる |
|---|
