Index: Commentary/Fluentd/fluentd.#2.log
===================================================================
--- Commentary/Fluentd/fluentd.#2.log	(revision e59cf50fcb1201b336afabf39713977031b4e4bd)
+++ Commentary/Fluentd/fluentd.#2.log	(revision e59cf50fcb1201b336afabf39713977031b4e4bd)
@@ -0,0 +1,369 @@
+古橋
+	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で得られる