source: lab.git/Commentary/Fluentd/fluentd.#2.log @ e59cf50

trunk
Last change on this file since e59cf50 was e59cf50, checked in by mitty <mitty@…>, 12 years ago

git-svn-id: https://lab.mitty.jp/svn/lab/trunk@157 7d2118f6-f56c-43e7-95a2-4bb3031d96e7

  • Property mode set to 100644
File size: 13.4 KB
Line 
1古橋
2    cedec awards 2012
3        fluentdで受賞
4   
5    self-introduction
6        treasure data
7            hadoop, big data
8            logを入れる仕組みを誰も作っていなかった -> fluentd
9           
10    video
11        概要
12            logをjson形式で集めて蓄積する
13   
14    次のバージョンどうするか
15    アンケート
16        ログ解析に何を使っているか
17            7割の方がfluentd
18        保存先?
19            mongdb 46%くらい
20            RDBMS 40%強
21    導入障壁
22        検討中
23        ドキュメントが不足
24            英語のDocが足りない、と思っている人は? -> 12人ぐらい
25            日本語のDoc欲しい人は? -> 4人ぐらい(ほとんど居ない)
26        プラグインなど機能が少ない
27        実績が…
28    なぜロギングするのか
29        error notify
30            new reric
31        performance monitor
32            資源の仕様傾向をみて、あらかじめサーバを増強など
33        user segment analysis
34            ユーザの使用傾向
35        funnnel analysis
36            TOPページに来た人 -> サインアップしてくれた人はそのうち何%?
37        heatmap
38            時刻と曜日の二軸グラフ化
39    なぜロギングにfluentdを?
40        alerting / analysis / archiving で様々な使い方をする
41        log sourceも様々な物がある
42        log sourceと蓄積先・alalysisをどうつなげるか
43            bash script? perl?
44            悪魔的なスクリプトは…
45            メンテナンスできる人がいなくなると困る
46            スクリプト書く人と、フロントエンドを書く人が別
47                期待するログのフォーマットが違う
48        logrotate
49            最大24h待たされる
50        fluentd をhubに使えば上記の問題は解決する!
51    Input / Output / buffering
52        それぞれpluginになっている
53    input pluginですべてjsonにする
54        output pluginはjsonに対応すればよい
55    logの必須3要素
56        時刻
57        タグ
58        jsonレコード
59    fluentdの特徴
60        拡張可能な plugin 形式
61        json という統一フォーマット
62        インストールが楽
63   
64    plugins一覧
65        DL人気順に並んでいる
66   
67    既存システムとの比較
68        scribe
69            拡張可能ではない
70            統一フォーマット無い
71            ....
72   
73    誰がfluentdを使っているのか
74        slide share
75        viki
76        context logic
77        nhn japan
78        cookpad
79        quora.com にどのように使われているのか、実績が書かれている
80   
81    fluentdの次バージョンについて
82        filter pluginの導入
83        <source> に filterを書けるようにする予定
84        filter pluginによるpipelineが可能になる予定
85        <label>
86            デフォルトではマッチしない
87            別のサーバでラベルを付けてからforwardされてくると、マッチするようになる
88            設定ファイルは一緒だが、サーバごとに違う挙動をさせられる
89   
90    MessagePack for Ruby v5
91   
92    td-agent-lite
93        in_tail = out_forward in "single" binary
94   
95    new process model & live restart
96        現在は中央のプロセスを経由している
97       
98        live restart
99            ログを取りこぼさずに再起動する
100   
101    後方互換性
102        fluentd::new
103        fluentd::old
104        の名前空間で対応
105   
106    Q&A
107        時刻の単位が秒なのだが、もっと細かくならないか
108            ミリ秒とかが欲しい
109        互換性の問題があるので、変更は難しい
110       
111        jsonで構造化されているのが売りだとのことだが、
112            テキストベースの製品もまだある。どちらが良いのか
113        Hadoopなどでパースするときに、jsonだと難しい
114            ただし、ログの構造を知らない人がテキストファイルをパースするのは無駄が大きい
115            なのでjsonにあらかじめ強制しておけば混乱がない
116       
117        日本語Docあるとうれしいので、お手伝いしたい
118        オフィシャルのリポジトリ以外で、どんどん翻訳するというのはむしろ歓迎する
119            どんどん広報して、力を合わせて欲しい
120            公式Docと乖離してしまう問題はあるが、無いよりは全然良いので是非
121       
122        coolioを捨てる計画はあるか
123        pluginとしては残すが、fluentd本体としてはthreadに移ろうと計画している
124   
125佐々木 @yssk22 with ワリ @wallyqs
126    loggin infrastructure in PasS with fluentd
127   
128    Cloud Foundry (tm)
129        VMware の PaaS
130        ruby
131        main points
132            open source
133            separation of concerns from IaaS
134            Scalable architecture
135        Easy to deploy applications
136            node.js の deploy 4行くらい
137        mission criticalなappはまだ難しい
138            ソースをいじりながら対応しようとしている
139    Cloud Foundry + Fluentd
140        $ vmc target api.cloudfoundry.com
141        $ ...
142        $ vmc push yssk22-myapp -n
143        $ ...
144        $ curl http:// ...
145        $ vmc logs yssk22-myapp
146        アプリケーションのupdateをするとログが消えてしまう
147            現在の仕様
148            FileSystemが永続化されていない
149            解析が不能
150   
151    fluentd はrubyで書かれているので、cloudfoundryのエコシステムに組み込むのは優しい
152    droplet execution agent
153    どのようにログを蓄積するか
154        [ App -> fluentd ] -> log storage
155            log storageを外に用意する
156            fluentd側でファイルなどから自由にログを収集してくれるので、
157            app側でどのファイルにはき出すかなどを心配しなくて良くなる
158       
159        [ appA -> fluentd ] -> [ another fluentd -> storage ]
160                               ^
161        [ appB -> fluentd ] ---^
162   
163    Fluentd Pros & Cons
164        Pros
165            Easy to include in CloudFoundry compared to other solutions
166            Easy to extend
167            Easy to change storage tech depending on scale
168        Cons
169            ....
170    NATS input plugin
171        adding new forwarding nodes dynamiccally through NATS
172   
173    github:rakutentech/dea
174        https://github.com/rakutentech/dea
175        https://github.com/rakutentech/dea/commit/64d271904de1e195cc90ca1958eadf704f530d94
176   
177    nginx + lua
178        luaのloggerがあるとうれしい
179    appをdeployするたびにfluentdが立ち上がる点がちょっと複雑
180   
181    Q&A
182        ログの流量はどれくらい?
183        まだまだ全然
184            CloudFoundryの上で動くappの数に依存すると思われる
185
186Q&A
187    fluentという名前で最初は開始したが、既に同じ名前があったので、fluentdとした
188   
189    プラグインのデバッグがとても難しい、どのようにやっているのか
190    test frameworkのできがとても良くない
191    rspecを次バージョンで入れる予定
192    input -> fluent cat or 出力に stdioを入れるなどの対応
193
194
195外道父@GedowFather
196Fluentdを優しく見守る監視事例
197    自己紹介
198        ドリコム
199        インフラエンジニア
200       
201    動作環境について
202        IDCがいっぱいある環境
203            それぞれにfluent agentが入っている
204            Global IP/暗号化
205            vpnは使っていない
206            HDFSに保存
207    プラグイン
208        改造したtail コマンドでagentへ
209        ローカルで保存ししつつforward
210        agent -> collector -> HDFS
211    collector
212        test / production のログ切り分けを tagによって行っている
213    Fluentd vs flume OG
214        flume OG
215            十分な機能(暗号化は無かったので追加した)
216            Java
217            agentが数百台オーダーになるとメモリ不足
218            agentからのキュー再送が不安定
219            -> fluentdへ
220            flume NG -> 知識の引き継ぎが出来ない感じだった
221        td-agentにした
222            パッケージ管理は重要
223            Rubyエンジニア対応できる
224    ローカル監視
225        必要な理由
226            プロセス操作はローカルでやるべき
227            サーバが社外にある場合
228                サーバを調査したり、煩瑣な設定変更 -> ローカルに無いと面倒
229        注意点
230            ログの内容が正しいか・ちゃんと記録されているか
231            td-agentがきちんと起動・動作しているのか
232            HDFSへちゃんと送られているか
233        監視にはmonitを使っている
234            CPUやメモリ、プロセス、ポート・プロトコルで監視できる
235            スクリプト実行の返値でアクション
236                起動スクリプト実行、メール、etc
237        monit
238            td-agentの基本プロセスの監視
239                td-agentは常に動作している必要がある
240                    主に人災(操作ミス)対策
241                    check process によるチェック
242                    collectorに対しては Listen portもチェック
243            td-agentの重複デーモン監視
244                fluentdはtcp/udpごとに2プロセスが必要
245                psコマンドによってプロセス数が2つ見つからなかったらNG
246                プロセス名が ver 1.1.8 から変更になった
247                unicornなどのほかのrubyプロセスを除外
248                瞬間的に出てくる特権モード [td-agent] を除外
249                もし重複して起動していたら
250                    init.d/td-agent stop
251                    pkill
252                    td-agent start
253                1.1.7までのtd-agentの起動スクリプトにはバグがある
254                    confの内容によっては、service startの数だけプロセスが重複
255                mazgi事件
256                    flumeはもうオワコンなので、fluentdだ! プラグインよろしくー
257                    作ったプラグインを確認すると18/16倍くらいに増えてる
258                    agent分よりHDFSが多くなっていた
259                    あれ?4プロセス動いているサーバが2台有るぞ?
260                    mazgi先生は濡れ衣だった
261                    結論: agentが重複するとログが増える!
262            flowcounterで転送状態監視
263                アプリがログを記録している証明
264                fluentdがログを拾って配送していること証明
265                部分的な記録ミスなどは、無視
266                あまりやり過ぎるとアラート対象が増える
267                問題点
268                    copyなので、forwardに失敗してもflowcounterのカウント記録は成功したことになっている
269                    collectorやHDFSが落ちたときは考慮していない
270        fluentd + monit十分な感じ
271    リモート監視
272        アラート・グラフ作成の集約と、状態の可視化
273        特にCollectorのキャパシティ対策
274        nagios + nrpe-server
275        グラフはcactiとか
276            cacti <- snmpd
277            CPUとtrafficは必ず入れておかないと、fluentdを将来どうスケールするか読めなくなる
278        一行350バイト程度・毎秒500行程度
279        traffic
280            圧縮でagent -> collector (10秒おき)
281                0.7Mbpsくらい
282            collector -> HDFS
283                1.5Mbpsくらい
284        CPU
285            25%くらい -> 秒間2000行くらいまではいけるかなぁ
286            ただし、ログのトラフィック量が変化しても、CPU負荷はあまり変化しない
287                agentの数や、agentからのflush間隔でCPU負荷が変わってくる? (要調査)
288        CollectorでAgentを把握したい
289            Agentは様々な環境にたくさん配置される
290            Collectorの位置でまとめてAgentの状態を確認できるとうれしい
291            NATだと、source addressが一つになってしまって、IPで識別は出来ない
292            hostnameのprefixでグループ化?
293    監視を設定することで安定した運用が望める
294
295    Q&A
296        agentの数は?
297        300-400くらい
298       
299        VPNを張らなかった理由は?
300        VPNは多様性と負荷分散性に弱い
301        増やしたときにうまく分散するようにしたかった
302        サーバの管理が社外に出てしまうこともあったため、そうなるとVPNは難しい
303       
304        圧縮・暗号化はどうやったのか
305        forwardを改造した
306        gzip/growfish
307       
308        暗号化は認証が欲しいが、どのような方法の認証が良いのか悩んでいる by 古橋
309
310Q&A
311    forwardのソースを見ると、メッセージの送り方が三つあるが?
312    tag time record
313        一番単純
314    ?
315        バッチで送る
316    packed forward
317        serialize/de serializeせずにforwardしたいとき
318   
319    公称対応限界は?
320    CPUの処理能力に単純に依存している
321    6万message / 8coreくらい
322        forwardで受けて、flowcounterして、さらにforwardしているだけのノード
323        1coreあたり8000くらい?
324    次のバージョンでマルチプロセスで並列化出来るようにする予定
325
326    forward -> UDPでkeepalive, TCP -> data connectionとなっているが、
327    message数が増えてくると、UDPの方が落ちてくることがままあった
328    次バージョンでheatbeatの改善を入れたい
329    TCPで接続が出来たら、heatbeatと見なすようにしたい
330   
331    collectorでのCPU負荷とTrafficの量に関連性が薄かったが、どこがCPU負荷になっていると考えられるか
332    リクエストの回数にbindするはず
333    lockに処理を奪われている感じがある
334   
335    Windows対応はどんな感じか? F#実装の性能は?
336    ログの発生源がWindowsの場合は、td-agent-liteをWin対応にして、ログ集積はLinux
337    F# -> テストは通って、実験は成功したが、ログ収集先をWindowsにしようとしているので手間取っている感じ
338   
339    設定ファイルをDSL化(erb)する話はどうなった?
340    DSL化すると、Rubyist以外につらい
341    設定ファイルは設定ファイルというままにした
342        設定ファイルにプログラムを書き始めるのは負けだと思っている
343    mixin プラグイン側で対応するかも
344   
345    設定のDSL化が欲しいパターンはあまりなさそう
346    config expander
347   
348池田 @mikeda
349    fluentd & TeasureDataでこっそり始めるログ集計
350   
351    自己紹介
352        450台くらい
353   
354    fluentd
355        データストリームを構造化するインフラとして認識している
356   
357    アクセスログ
358        2億/day くらい
359    アプリケーションエラーログ
360    メールログ(試験中)
361   
362    「ログとかそんなに頑張らなくても良いのでは?」
363        実際どうだったか
364        工数
365                    ---これ以降はノートPCが電源切れたので記憶を頼りに書いている
366            一人でやってもそうかからなかった(?)
367            ... とs... でadmin用簡易webUIを作った
368                100行+100行くらい
369                SQLっぽいクエリで結果をtableで得られる
Note: See TracBrowser for help on using the repository browser.