Fluentd meetup in Japan #2 http://www.zusaar.com/event/355006 に行ってきたのでメモを載せます。
古橋さん(作者)による fluentd の紹介
fluentd の紹介
- 略
- slideshare, viki, contextlogic, nhn japan, cookpad, naver が使っている
fluentd の未来
- fliter plugin の導入。書きやすくなるよ。
-
の中に をかけるようになるよ - データをフックするのもめんどくさかった。filter plugin で楽になるよ
- messagepack v5 で性能あがるよ
- td-agent-lite も配布
- New process model & live restart
- ログを取りこぼさずに再起動できるようになる
- 後方互換性あるよ
質疑応答
- Q. JSONじゃないログ収集ツールが多いが、それはそれで利点があるのか。どう考えているか。
- ログを吐いたりするほうでJSONなどにするとそちらに負荷があがったりするので、収集のほうでやるべき、という考え方をしていると思う。ただ、ログを書く人と収集する人が違う場合、パースが難しい（フォーマットを知らない）ので、最初からJSONにしてしまおう、というのがfluentdのスタンス。
- Q. windowsは？
- coolio やめて thread にする。やります。
- Q. 秒単位でしかでないんだけど、ミリ秒ほしいなぁ
- 下位互換がなくなるので悩ましいけど、考えてみる
- Q. プラグインのデバッグ
- テストフレームワークは入っているが、出来が悪いので、次バージョンでは rspec ベースにしようとおもっている。
- fluentd-cat, stdout プラグインがちょっと確認する時にはよい
楽天 ささき(from Japan) ワリ(from Mexico)
- PaaS Operation Team
- CLOUD FOUNDRY by VMWare written by Ruby
- 社内に Heroku のような PaaS を用意したかった。唯一のオープンソースだった。
- デプロイがかなり楽
- vmc push yak22-myapp で終わり
- ミッションクリティカルなツールだとちょっと難しそう。だったので、ソースコードいじりながら改善している。
- 改善の一部としてロギング
- CLOUD FOUNDRY に新しくデプロイすると、ログが消えてしまう（ファイルシステムが永続化されていない）
- これじゃ、ビジネスには使えねー。ということで flutned を組み込んでみた。
ワリさんの英語タイム
- CLOUD FOUNDRY written in ruby, and fluentd is also written in ruby.
- Attach a fluentd collector to one application instance upon dispatch.
- fluentd を使って永続化されているログストレージにフォワードする。
- アプリ開発者は fluentd を使っていることすら知らずに cloud foundry を使う事になる。
- パッチ公開してます。git@github.com:rakutentech/dea
- これを cloud foundry の本体にいれたいと思っている
- 困ってる事. nginx のアクセスログをとれない
- nginx のなかに lua. lua のロガーとりたい => 会場から、今リリースする、との声
- flume のチームと仲良くやりたいと思っている
- Fluentd を優しく見守る監視事例 外道父@GedowFather DRECOM
- インフラエンジニア。Hadoop. データセンターの選定など
- データセンターが一杯。世界中に。それらすべてのサーバに agent をインストールしておき、一箇所に collector. 圧縮、暗号化、VPN. HBaseに保存
- collector で復号化、解答している。
- 本番の collector にテストのログが入る事故が以前あった。
- forest, webhdfs でデータを書き込んでいる。
- Fluentd の前は Flume で動かしていた。Flume について。
- 十分な機能（圧縮はなかった（
- 信頼のCDH付属
- エージェント数百台規模で master が不安定
- Agent のキューからの再送が不安定（タンス貯金現象）
- Java だからいじるのも面倒。ビルドいるし。
- td-agent にした。社内に rubyエンジニアいっぱい。機能不足はプラグインはなんとかなるだろう。
- 全機能満たせた
- インストールも簡単だった。
監視の話
ローカル監視
- アラートメール
- グラフ作成 => プライベートネットワークでやる
- プロセス操作（デーモン再スタート）=> ローカル監視必要
- サーバが社外管理の場合。サーバ調査。頻繁な設定変更。fluentd と一緒にローカルにぶちこむしかない。
監視内容
- ログを記録しているか
- ログの内容が正しいか
- td-agentが正しく起動しているか
- collectorに送っているか
- td-agentが正しく起動しているか
- hdfsに送っているか
- ローカル監視には monit 使ってます
- プロセスの監視やリソース監視
- HTTPリクエストのステータス条件
- スクリプト実行の帰り値条件
- 条件判定によるアクション実行
- スクリプト実行
- アラートメール
monit でやってる監視内容
1. td-agent 基本プロセス監視
- 常に起動しているように
- agent は check process によるチェック (run//pid ファイルのIDとプロセス
- collector は LISTEN ポート番号で
2. td-agent 重複デーモン対策
- UDP/TCPの２プロセスたちあがる。
- ps コマンドで２行あればOK。瞬間的に [td-agent] というプロセスが動くので除外している。
- 重複きどうしていたら kill して起動している
- v1.1.7 までの起動スクリプトにはバグがあり。start ２回やると２個立ち上がった。v1.1.8 では直ってる。
- 重複してしまうと、１つのサーバから２倍、３倍でログが送られる。重複チェック必須！
3. flowcounterで転送状態監視
- アプリがログを記録しているのか
- fluentdがログを拾って配送しているのか
- flowcounter １時間に１回。1月に１ファイル。flowcount ログ
- ２時間分のログに、１つでも１０以上のカウントがあればOK
おちた場合
- スクリプト内で原因をエラー出力してアラートを飛ばすように
問題点
- copyなので forward に失敗しても、flow counter のカウント記録は失敗する。
- collector が全部おちたり hdfs が落ちると flow counter どころじゃない
リモート監視
- アラート・グラフ作成の集約
- 状態の可視化
- 特に collector のキャパシティ管理
- agent にキャパシティの心配はほぼないが、collectorはagentが増えるにつれて対策する必要がある
- グラフは cacti とか snmpd (agent, collector サーバにいれる)
collectorの仕事
- in_forward 復号化/解凍
- flowcounter
- webhdfs
- 圧縮まえと、解凍後だと２倍ぐらい。10sでflushしているがもっと間隔ひろげればいける？
- 今CPU25%。何が最もCPU利用率に影響するのか？CPUとトラフィックの波形が一致しない。なんだろう？
こんなこといいな
- collectorでagentを把握したい
- 様々な環境に散らばった大量のagent
- なんのagentがどこにいてどうなっていると正常なのか => agent から hostname / private address を送っておくと、どの agent が生きていたか監視できたりしていいかもなぁ、と。
質疑・応答
- Q. 圧縮（暗号化）、解凍（復号）はどうやっているのか
- プラグインをgzip compress level 6, blowflishするように改造して使っている。
- pull request をもらっているので、そこから使える。outforward_compress なんかのようなプラグインを作ってもらえるとうれしい by 古橋さん
- Q. どのぐらい処理できる？ cyberagent の人
- CPUのHzに依存する。右から左に渡すだけ。８千メッセージ/CPU (え、何Hzで？) by tagomoris さん
- 今は１プロセスでしか動かないが、次のバージョンからマルチプロセス化いれようとしている。
- Q. UDPのheartbeatが失敗する現象にあっている。対策しようとしている？ by cyberagentの人
- heartbeatをTCPにするか、tcpの接続があったらheartbeatの１カウントにするか
- Q. collector の cpu 使用率はなにに依存している？
- in_forward / out_forward はほとんどCPUをくわないようにしている
- リクエストの数で（ロックで）CPUをくる。
- もう少し詳しくみてみないとわからない。
- Q. windows対応？発生源がwindows
- td-agent-lite だけ windows でも動くようにしようと思っている
- Q. F#実装 agent どれぐらいパフォーマンス出る. windowsから出る
- まだ何個かの転送はできたなー、ぐらいの出来
- Q. 設定ファイルをDSLにするという話があったが、v1.1から消えたようだが、どうなの？
- 設定ファイルの中にrubyコード書いたら負けだな
- plugin にサポートしてもらって(mix-in)、${hostname} で展開されるようにしようかと思っている。
- config-expander, mix-in など
Fluentd & TreasureData でこっそり始めるログ集計 @mikeda
fluentd -> データストリームを統合管理する基盤
人と工数
- 人 -> 自分だけ
- 工数 -> そんなに必要ないかも。案外簡単だった。設定もぐぐって tagomoris さんのブログからコピればいける
- サーバ -> 集約サーバ１台
- トラフィック -> 気にするほどじゃない
- 既存サーバへの負荷増加も無視できるレベル
- パッケージの依存関係ほぼなし (td-agent が専用 ruby, gem同梱)
- いれてもバレない！
既存アプリを絶対にいじらない方針でこっそりいれた
- exec_filter 外部プログラムでフィルタを作れるプラグイン
- au, softbank, docomo の UID をまとめちゃうフィルタ
簡単な管理画面を ruby & sinatora で作成
- 100行いかないぐらい
- HiveSQL で select した表を作ってみせてる。
Maillog は複数行で１単位。パースがつらい
- in_tail を継承して拡張したプラグインを作った
- 自作プラグインは /etc/td-agent/plugin/ に置くだけで動く
- in_tailは拡張を前提としたプラグインになっている
