source: lab/trunk/Commentary/Fluentd/fluentd.#2.log @ 158

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