--- /dev/null
+古橋
+ cedec awards 2012
+ fluentdで受賞
+
+ self-introduction
+ treasure data
+ hadoop, big data
+ logを入れる仕組みを誰も作っていなかった -> fluentd
+
+ video
+ 概要
+ logをjson形式で集めて蓄積する
+
+ 次のバージョンどうするか
+ アンケート
+ ログ解析に何を使っているか
+ 7割の方がfluentd
+ 保存先？
+ mongdb 46%くらい
+ RDBMS 40%強
+ 導入障壁
+ 検討中
+ ドキュメントが不足
+ 英語のDocが足りない、と思っている人は？ -> 12人ぐらい
+ 日本語のDoc欲しい人は？ -> 4人ぐらい(ほとんど居ない)
+ プラグインなど機能が少ない
+ 実績が…
+ なぜロギングするのか
+ error notify
+ new reric
+ performance monitor
+ 資源の仕様傾向をみて、あらかじめサーバを増強など
+ user segment analysis
+ ユーザの使用傾向
+ funnnel analysis
+ TOPページに来た人 -> サインアップしてくれた人はそのうち何%？
+ heatmap
+ 時刻と曜日の二軸グラフ化
+ なぜロギングにfluentdを？
+ alerting / analysis / archiving で様々な使い方をする
+ log sourceも様々な物がある
+ log sourceと蓄積先・alalysisをどうつなげるか
+ bash script? perl?
+ 悪魔的なスクリプトは…
+ メンテナンスできる人がいなくなると困る
+ スクリプト書く人と、フロントエンドを書く人が別
+ 期待するログのフォーマットが違う
+ logrotate
+ 最大24h待たされる
+ fluentd をhubに使えば上記の問題は解決する！
+ Input / Output / buffering
+ それぞれpluginになっている
+ input pluginですべてjsonにする
+ output pluginはjsonに対応すればよい
+ logの必須3要素
+ 時刻
+ タグ
+ jsonレコード
+ fluentdの特徴
+ 拡張可能な plugin 形式
+ json という統一フォーマット
+ インストールが楽
+
+ plugins一覧
+ DL人気順に並んでいる
+
+ 既存システムとの比較
+ scribe
+ 拡張可能ではない
+ 統一フォーマット無い
+ ....
+
+ 誰がfluentdを使っているのか
+ slide share
+ viki
+ context logic
+ nhn japan
+ cookpad
+ quora.com にどのように使われているのか、実績が書かれている
+
+ fluentdの次バージョンについて
+ filter pluginの導入
+ <source> に filterを書けるようにする予定
+ filter pluginによるpipelineが可能になる予定
+ <label>
+ デフォルトではマッチしない
+ 別のサーバでラベルを付けてからforwardされてくると、マッチするようになる
+ 設定ファイルは一緒だが、サーバごとに違う挙動をさせられる
+
+ MessagePack for Ruby v5
+
+ td-agent-lite
+ in_tail = out_forward in "single" binary
+
+ new process model & live restart
+ 現在は中央のプロセスを経由している
+
+ live restart
+ ログを取りこぼさずに再起動する
+
+ 後方互換性
+ fluentd::new
+ fluentd::old
+ の名前空間で対応
+
+ Q&A
+ 時刻の単位が秒なのだが、もっと細かくならないか
+ ミリ秒とかが欲しい
+ 互換性の問題があるので、変更は難しい
+
+ jsonで構造化されているのが売りだとのことだが、
+ テキストベースの製品もまだある。どちらが良いのか
+ Hadoopなどでパースするときに、jsonだと難しい
+ ただし、ログの構造を知らない人がテキストファイルをパースするのは無駄が大きい
+ なのでjsonにあらかじめ強制しておけば混乱がない
+
+ 日本語Docあるとうれしいので、お手伝いしたい
+ オフィシャルのリポジトリ以外で、どんどん翻訳するというのはむしろ歓迎する
+ どんどん広報して、力を合わせて欲しい
+ 公式Docと乖離してしまう問題はあるが、無いよりは全然良いので是非
+
+ coolioを捨てる計画はあるか
+ pluginとしては残すが、fluentd本体としてはthreadに移ろうと計画している
+
+佐々木 @yssk22 with ワリ @wallyqs
+ loggin infrastructure in PasS with fluentd
+
+ Cloud Foundry (tm)
+ VMware の PaaS
+ ruby
+ main points
+ open source
+ separation of concerns from IaaS
+ Scalable architecture
+ Easy to deploy applications
+ node.js の deploy 4行くらい
+ mission criticalなappはまだ難しい
+ ソースをいじりながら対応しようとしている
+ Cloud Foundry + Fluentd
+ $ vmc target api.cloudfoundry.com
+ $ ...
+ $ vmc push yssk22-myapp -n
+ $ ...
+ $ curl http:// ...
+ $ vmc logs yssk22-myapp
+ アプリケーションのupdateをするとログが消えてしまう
+ 現在の仕様
+ FileSystemが永続化されていない
+ 解析が不能
+
+ fluentd はrubyで書かれているので、cloudfoundryのエコシステムに組み込むのは優しい
+ droplet execution agent
+ どのようにログを蓄積するか
+ [ App -> fluentd ] -> log storage
+ log storageを外に用意する
+ fluentd側でファイルなどから自由にログを収集してくれるので、
+ app側でどのファイルにはき出すかなどを心配しなくて良くなる
+
+ [ appA -> fluentd ] -> [ another fluentd -> storage ]
+ ^
+ [ appB -> fluentd ] ---^
+
+ Fluentd Pros & Cons
+ Pros
+ Easy to include in CloudFoundry compared to other solutions
+ Easy to extend
+ Easy to change storage tech depending on scale
+ Cons
+ ....
+ NATS input plugin
+ adding new forwarding nodes dynamiccally through NATS
+
+ github:rakutentech/dea
+ https://github.com/rakutentech/dea
+ https://github.com/rakutentech/dea/commit/64d271904de1e195cc90ca1958eadf704f530d94
+
+ nginx + lua
+ luaのloggerがあるとうれしい
+ appをdeployするたびにfluentdが立ち上がる点がちょっと複雑
+
+ Q&A
+ ログの流量はどれくらい？
+ まだまだ全然
+ CloudFoundryの上で動くappの数に依存すると思われる
+
+Q&A
+ fluentという名前で最初は開始したが、既に同じ名前があったので、fluentdとした
+
+ プラグインのデバッグがとても難しい、どのようにやっているのか
+ test frameworkのできがとても良くない
+ rspecを次バージョンで入れる予定
+ input -> fluent cat or 出力に stdioを入れるなどの対応
+
+
+外道父@GedowFather
+Fluentdを優しく見守る監視事例
+ 自己紹介
+ ドリコム
+ インフラエンジニア
+
+ 動作環境について
+ IDCがいっぱいある環境
+ それぞれにfluent agentが入っている
+ Global IP/暗号化
+ vpnは使っていない
+ HDFSに保存
+ プラグイン
+ 改造したtail コマンドでagentへ
+ ローカルで保存ししつつforward
+ agent -> collector -> HDFS
+ collector
+ test / production のログ切り分けを tagによって行っている
+ Fluentd vs flume OG
+ flume OG
+ 十分な機能(暗号化は無かったので追加した)
+ Java
+ agentが数百台オーダーになるとメモリ不足
+ agentからのキュー再送が不安定
+ -> fluentdへ
+ flume NG -> 知識の引き継ぎが出来ない感じだった
+ td-agentにした
+ パッケージ管理は重要
+ Rubyエンジニア対応できる
+ ローカル監視
+ 必要な理由
+ プロセス操作はローカルでやるべき
+ サーバが社外にある場合
+ サーバを調査したり、煩瑣な設定変更 -> ローカルに無いと面倒
+ 注意点
+ ログの内容が正しいか・ちゃんと記録されているか
+ td-agentがきちんと起動・動作しているのか
+ HDFSへちゃんと送られているか
+ 監視にはmonitを使っている
+ CPUやメモリ、プロセス、ポート・プロトコルで監視できる
+ スクリプト実行の返値でアクション
+ 起動スクリプト実行、メール、etc
+ monit
+ td-agentの基本プロセスの監視
+ td-agentは常に動作している必要がある
+ 主に人災(操作ミス)対策
+ check process によるチェック
+ collectorに対しては Listen portもチェック
+ td-agentの重複デーモン監視
+ fluentdはtcp/udpごとに2プロセスが必要
+ psコマンドによってプロセス数が2つ見つからなかったらNG
+ プロセス名が ver 1.1.8 から変更になった
+ unicornなどのほかのrubyプロセスを除外
+ 瞬間的に出てくる特権モード [td-agent] を除外
+ もし重複して起動していたら
+ init.d/td-agent stop
+ pkill
+ td-agent start
+ 1.1.7までのtd-agentの起動スクリプトにはバグがある
+ confの内容によっては、service startの数だけプロセスが重複
+ mazgi事件
+ flumeはもうオワコンなので、fluentdだ！ プラグインよろしくー
+ 作ったプラグインを確認すると18/16倍くらいに増えてる
+ agent分よりHDFSが多くなっていた
+ あれ？4プロセス動いているサーバが2台有るぞ？
+ mazgi先生は濡れ衣だった
+ 結論: agentが重複するとログが増える！
+ flowcounterで転送状態監視
+ アプリがログを記録している証明
+ fluentdがログを拾って配送していること証明
+ 部分的な記録ミスなどは、無視
+ あまりやり過ぎるとアラート対象が増える
+ 問題点
+ copyなので、forwardに失敗してもflowcounterのカウント記録は成功したことになっている
+ collectorやHDFSが落ちたときは考慮していない
+ fluentd + monit十分な感じ
+ リモート監視
+ アラート・グラフ作成の集約と、状態の可視化
+ 特にCollectorのキャパシティ対策
+ nagios + nrpe-server
+ グラフはcactiとか
+ cacti <- snmpd
+ CPUとtrafficは必ず入れておかないと、fluentdを将来どうスケールするか読めなくなる
+ 一行350バイト程度・毎秒500行程度
+ traffic
+ 圧縮でagent -> collector (10秒おき)
+ 0.7Mbpsくらい
+ collector -> HDFS
+ 1.5Mbpsくらい
+ CPU
+ 25%くらい -> 秒間2000行くらいまではいけるかなぁ
+ ただし、ログのトラフィック量が変化しても、CPU負荷はあまり変化しない
+ agentの数や、agentからのflush間隔でCPU負荷が変わってくる？ (要調査)
+ CollectorでAgentを把握したい
+ Agentは様々な環境にたくさん配置される
+ Collectorの位置でまとめてAgentの状態を確認できるとうれしい
+ NATだと、source addressが一つになってしまって、IPで識別は出来ない
+ hostnameのprefixでグループ化？
+ 監視を設定することで安定した運用が望める
+
+ Q&A
+ agentの数は？
+ 300-400くらい
+
+ VPNを張らなかった理由は？
+ VPNは多様性と負荷分散性に弱い
+ 増やしたときにうまく分散するようにしたかった
+ サーバの管理が社外に出てしまうこともあったため、そうなるとVPNは難しい
+
+ 圧縮・暗号化はどうやったのか
+ forwardを改造した
+ gzip/growfish
+
+ 暗号化は認証が欲しいが、どのような方法の認証が良いのか悩んでいる by 古橋
+
+Q&A
+ forwardのソースを見ると、メッセージの送り方が三つあるが？
+ tag time record
+ 一番単純
+ ？
+ バッチで送る
+ packed forward
+ serialize/de serializeせずにforwardしたいとき
+
+ 公称対応限界は？
+ CPUの処理能力に単純に依存している
+ 6万message / 8coreくらい
+ forwardで受けて、flowcounterして、さらにforwardしているだけのノード
+ 1coreあたり8000くらい？
+ 次のバージョンでマルチプロセスで並列化出来るようにする予定
+
+ forward -> UDPでkeepalive, TCP -> data connectionとなっているが、
+ message数が増えてくると、UDPの方が落ちてくることがままあった
+ 次バージョンでheatbeatの改善を入れたい
+ TCPで接続が出来たら、heatbeatと見なすようにしたい
+
+ collectorでのCPU負荷とTrafficの量に関連性が薄かったが、どこがCPU負荷になっていると考えられるか
+ リクエストの回数にbindするはず
+ lockに処理を奪われている感じがある
+
+ Windows対応はどんな感じか？ F#実装の性能は？
+ ログの発生源がWindowsの場合は、td-agent-liteをWin対応にして、ログ集積はLinux
+ F# -> テストは通って、実験は成功したが、ログ収集先をWindowsにしようとしているので手間取っている感じ
+
+ 設定ファイルをDSL化(erb)する話はどうなった？
+ DSL化すると、Rubyist以外につらい
+ 設定ファイルは設定ファイルというままにした
+ 設定ファイルにプログラムを書き始めるのは負けだと思っている
+ mixin プラグイン側で対応するかも
+
+ 設定のDSL化が欲しいパターンはあまりなさそう
+ config expander
+
+池田 @mikeda
+ fluentd & TeasureDataでこっそり始めるログ集計
+
+ 自己紹介
+ 450台くらい
+
+ fluentd
+ データストリームを構造化するインフラとして認識している
+
+ アクセスログ
+ 2億/day くらい
+ アプリケーションエラーログ
+ メールログ(試験中)
+
+ 「ログとかそんなに頑張らなくても良いのでは？」
+ 実際どうだったか
+ 工数
+ ---これ以降はノートPCが電源切れたので記憶を頼りに書いている
+ 一人でやってもそうかからなかった(?)
+ ... とs... でadmin用簡易webUIを作った
+ 100行＋100行くらい
+ SQLっぽいクエリで結果をtableで得られる
projects / lab.git / commitdiff