Commentary/Fluentd/fluentd.#2.log

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