Commentary/Fluentd/fluentd.#2.log

   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で得られる