hatone/Fluentd & Treasure Data でこっそり始めるログ集計

## Fluentd & Treasure Data でこっそり始めるログ集計
「Fluentd & Treasure Data でこっそり始めるログ集計」
CROOZ 株式会社
池田 朋大（ @mikeda ）

FluentdとTreasureDataプラットフォームを使って、1インフラエンジニアが勢いでログ集計システムを作ってみたお話です
---
■発表の人
インフラエンジニア
fluentd 歴3ヶ月

■グラフ＆保存
アクセスログ: 2億/day
アプリケーションエラーログ:グラフ化

設定は @tagomoris さんのブログを参照すると良い

■簡単な管理画面
もっと細かいのはtreasure data有料プラン

■in_tail拡張
結構いける。

## Fluentdの現在と未来
「Fluentdの現在と未来」Treasure Data, Inc.
古橋　貞之 (@frsyuki)
Cloud Foundry を使って Platform as a Service を作る方法を説明しつつ，fluentd をどのように活用したのかを紹介します。
---------------------------------------------------------
■なぜロギングするか
-行動の分析
・どれだけの人がページを見るか
・どれだけの人がユーザ登録するか
-曜日別の可視化
-マーケットの予測

■なぜfluentdか
-ログにもいっぱい種類がある
ひとつひとつのログをスクリプトを書いてパースする場合
ログの量が増えると、タスク量が爆発する

-ファイルが出来上がるのを待たなければならない
-単一の方法でログを集めるソリューションがこれまでなかった


■fluentdについて
-簡単にデプロイ可能

■fluentdの導入実績の少なさについて
NHN,quora,NAVER,slideshare
あたりで使われてる。

■次回予告
sourceの中に、filterを書けるようになる≒トップレベルを汚さずにもジューラブルにかける
ラベリング機能で、更に柔軟なルーティングができるようになる
- td-agent light
単一のバイナリでtailとforwordができる

■まとめ
-fluentdはロギング特化
-jsonでまとまってる
-OSSコミュニティの活動が活発

■Q＆A
Q.時刻の精度はミリまでいけないか?  A.互換性の問題がある。議論をして考えたい

## Fluentdを優しく見守る監視事例
「Fluentdを優しく見守る監視事例」
株式会社ドリコム

外道父 ( @GedowFather )
Fluentdをより穏やかに安定稼働させるための監視項目と自動処理
について。また，その実運用における障害例なども紹介したいと思います。
----------------------------
■発表の人
-ドリコム
-インフラエンジニア
- ブログ（http://blog.father.gedow.net/）

■アレンジした運用
tail(改: pathに*,tagにbase name)
copy
forward(改:圧縮/暗号化)
forward(改:復号化/解凍，特定hostnameのtag改変)
copy

■Fluentd vs Flume OG
-Flume OG
十分な機能（暗号化以外）
数百台規模で、MASTERが不安定、メモリ不足
Agentのキューから再送が不安定
→Fluentd一択

■管理の方針
パッケージ管理は大切
社内のRubyエンジニアだらけ
機能不足はプラグインでなんとかなる？

全機能を満たせた
インストール簡単でした

■ローカル監視
-ローカル監視が必要な理由
アラートメール、グラフ作成→プライベートネットワークでやる
プロセス操作→ローカルでやる

■ログ配送の注意点
（ジョブで確認）
・ログを記録しているか？
・ログの内容が正しいか？

td-agentが正しく起動しているか
Collectorに送っているか

td-agentが正しく起動しているか
HDFSに送っているか

（ジョブで確認）
HDFSに記録されているか

■ローカル監視はmonit
td-agentの基本プロセス監視、重複デーモン対策、flowcounterで帯域監視

-td-agentの基本プロセス監視
checkpoint
Agentはcheck processによるチェック
run/pidプロファイル

-td-agent重複デーモン対策
fluentdはUDP/TCPの2プロセス必要

checkpoint
ps -w -C ruby -C td-agent --no-heading
hoge
hoge

プロセス数のカウントが2か。
2じゃなかったらとりあえずstop
pkill -KILL -f td-agent
td-agent v1,1,8まではrubyで、それ以降はtd-agentのプロセス名

v1.1.7までは起動スクリプトにバグあり、startを実行した回数だけデーモン起動
ファイルのIDが誤った値に変わる
デーモンの正確性は大切。
プロセスの重複怖い。

-flowcounterで転送状態監視
アプリがログを記録している証明
1時間に一回。月1ファイルで十分。
2時間分のログに1つでも10以上のカウントがあればOK

■グラフ
-Cacti+snmpd
Collecter必須。

■Collector
in_forward
暗号化、解凍
flowcounter
webhdfs


圧縮でつけとって、平文でHDFSへ

■CPU利用率のキャパシティ
秒間500行で25％

## Logging Infrastructure in PaaS by Fluentd
「Logging Infrastructure in PaaS by Fluentd」
Rakuten, Inc.
Yohei Sasaki (@yssk22), Waldemar Quevedo (@wallyqs)

Cloud Foundry を使って Platform as a Service を作る方法を説明
しつつ，fluentd をどのように活用したのかを紹介します。
----------------------------
■登壇者の人々
- PaaS作ってる

■Cloud Foundry（#herokuのクローン）
デプロイが結構楽
まだまだ発展途上で、ミッションクリティカルなアプリケーションは載せられない
Cloud Foundryの説明。

#「デプロイ簡単」を謳っているらしいが、独自コマンドを入れているのが微妙。

■fluentdとCloud Foundry
PaaSのリソースプール上をアプリケーションがログを移動すると消える
→cloud foundryだとログが永続化されないから、fluentdで収集して永続化
	「Fluentd & Treasure Data でこっそり始めるログ集計」
	CROOZ 株式会社
	池田朋大（ @mikeda ）

	FluentdとTreasureDataプラットフォームを使って、1インフラエンジニアが勢いでログ集計システムを作ってみたお話です
	---
	■発表の人
	インフラエンジニア
	fluentd 歴3ヶ月

	■グラフ＆保存
	アクセスログ: 2億/day
	アプリケーションエラーログ:グラフ化

	設定は @tagomoris さんのブログを参照すると良い

	■簡単な管理画面
	もっと細かいのはtreasure data有料プラン

	■in_tail拡張
	結構いける。
	「Fluentdの現在と未来」Treasure Data, Inc.
	古橋　貞之 (@frsyuki)
	Cloud Foundry を使って Platform as a Service を作る方法を説明しつつ，fluentd をどのように活用したのかを紹介します。
	---------------------------------------------------------
	■なぜロギングするか
	-行動の分析
	・どれだけの人がページを見るか
	・どれだけの人がユーザ登録するか
	-曜日別の可視化
	-マーケットの予測

	■なぜfluentdか
	-ログにもいっぱい種類がある
	ひとつひとつのログをスクリプトを書いてパースする場合
	ログの量が増えると、タスク量が爆発する

	-ファイルが出来上がるのを待たなければならない
	-単一の方法でログを集めるソリューションがこれまでなかった


	■fluentdについて
	-簡単にデプロイ可能

	■fluentdの導入実績の少なさについて
	NHN,quora,NAVER,slideshare
	あたりで使われてる。

	■次回予告
	sourceの中に、filterを書けるようになる≒トップレベルを汚さずにもジューラブルにかける
	ラベリング機能で、更に柔軟なルーティングができるようになる
	- td-agent light
	単一のバイナリでtailとforwordができる

	■まとめ
	-fluentdはロギング特化
	-jsonでまとまってる
	-OSSコミュニティの活動が活発

	■Q＆A
	Q.時刻の精度はミリまでいけないか? A.互換性の問題がある。議論をして考えたい
	「Fluentdを優しく見守る監視事例」
	株式会社ドリコム

	外道父 ( @GedowFather )
	Fluentdをより穏やかに安定稼働させるための監視項目と自動処理
	について。また，その実運用における障害例なども紹介したいと思います。
	----------------------------
	■発表の人
	-ドリコム
	-インフラエンジニア
	- ブログ（http://blog.father.gedow.net/）

	■アレンジした運用
	tail(改: pathに*,tagにbase name)
	copy
	forward(改:圧縮/暗号化)
	forward(改:復号化/解凍，特定hostnameのtag改変)
	copy

	■Fluentd vs Flume OG
	-Flume OG
	十分な機能（暗号化以外）
	数百台規模で、MASTERが不安定、メモリ不足
	Agentのキューから再送が不安定
	→Fluentd一択

	■管理の方針
	パッケージ管理は大切
	社内のRubyエンジニアだらけ
	機能不足はプラグインでなんとかなる？

	全機能を満たせた
	インストール簡単でした

	■ローカル監視
	-ローカル監視が必要な理由
	アラートメール、グラフ作成→プライベートネットワークでやる
	プロセス操作→ローカルでやる

	■ログ配送の注意点
	（ジョブで確認）
	・ログを記録しているか？
	・ログの内容が正しいか？

	td-agentが正しく起動しているか
	Collectorに送っているか

	td-agentが正しく起動しているか
	HDFSに送っているか

	（ジョブで確認）
	HDFSに記録されているか

	■ローカル監視はmonit
	td-agentの基本プロセス監視、重複デーモン対策、flowcounterで帯域監視

	-td-agentの基本プロセス監視
	checkpoint
	Agentはcheck processによるチェック
	run/pidプロファイル

	-td-agent重複デーモン対策
	fluentdはUDP/TCPの2プロセス必要

	checkpoint
	ps -w -C ruby -C td-agent --no-heading
	hoge
	hoge

	プロセス数のカウントが2か。
	2じゃなかったらとりあえずstop
	pkill -KILL -f td-agent
	td-agent v1,1,8まではrubyで、それ以降はtd-agentのプロセス名

	v1.1.7までは起動スクリプトにバグあり、startを実行した回数だけデーモン起動
	ファイルのIDが誤った値に変わる
	デーモンの正確性は大切。
	プロセスの重複怖い。

	-flowcounterで転送状態監視
	アプリがログを記録している証明
	1時間に一回。月1ファイルで十分。
	2時間分のログに1つでも10以上のカウントがあればOK

	■グラフ
	-Cacti+snmpd
	Collecter必須。

	■Collector
	in_forward
	暗号化、解凍
	flowcounter
	webhdfs


	圧縮でつけとって、平文でHDFSへ

	■CPU利用率のキャパシティ
	秒間500行で25％
	「Logging Infrastructure in PaaS by Fluentd」
	Rakuten, Inc.
	Yohei Sasaki (@yssk22), Waldemar Quevedo (@wallyqs)

	Cloud Foundry を使って Platform as a Service を作る方法を説明
	しつつ，fluentd をどのように活用したのかを紹介します。
	----------------------------
	■登壇者の人々
	- PaaS作ってる

	■Cloud Foundry（#herokuのクローン）
	デプロイが結構楽
	まだまだ発展途上で、ミッションクリティカルなアプリケーションは載せられない
	Cloud Foundryの説明。

	#「デプロイ簡単」を謳っているらしいが、独自コマンドを入れているのが微妙。

	■fluentdとCloud Foundry
	PaaSのリソースプール上をアプリケーションがログを移動すると消える
	→cloud foundryだとログが永続化されないから、fluentdで収集して永続化