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