d*******r
发帖数: 3299 | 1 fluentd 用过, 设计和可靠性比 logstash 这个垃圾好很多.
不过流量大了，我记得 fluentd 扛不住, 应该不如 kafka.
fluentd 和 kafka 这2个使用场景不一样. |
|
d*******r
发帖数: 3299 | 2 fluentd 是 log parser and collector
kafka 是 big message queue
比如, 你把 fluentd 安装在你要搜集 log 的 server 机器上.
每个 fluentd 搜集的 log 可以一股脑扔到 kafka 里面.
kafka 扛住大流量后，再扔到各种下游的 service, 比如 elasticsearch. |
|
d*******r
发帖数: 3299 | 3 fluentd 不是朝ui去的, 就是搜集分析log的,
竞争的是 ELK stack 里面的 logstash (也是Ruby写的) |
|
d*******r
发帖数: 3299 | 4 你说这个我有体会，就是采集 log 的时候，如果不加入很重要的一些 fields, 就会
information loss。后面的分析，是后面的事情, 但是开始采集的时候，该加的 field
一定要加, 不然后面分析功能再fancy，也会缺信息.
这个主要看采集的模块，logstash(Ruby, JRuby, Go), fluentd(Ruby), 还有 Heka(Go
).
大概2年以前我用过 logstash, fluentd. logstash 乱糟糟的，filter/modifier功能
多，你按照写入的 log 加点 fields 问题不大. fluentd 我感觉用着舒服很多，
filter/modifier 少一点. 但是我是2年前用的，现在 logstash 跟着 ElasticSearch
有过一次大升级，质量应该好不少.
如果我现在做log采集，应该会试 Heka. 看着还挺不错的.
你可以回来分享下，后续的经验.
了)
Tag |
|
m***h
发帖数: 77 | 5 我有这么一个问题拿不定主意。
在一个team/group/organization里sell这个big data最好的方式就是在不动
production或用最小的cost的前提下提供现系统不能提供的feature。譬如，我们一个
大app，一堆API，一堆server，每个API都写很多（大部分是垃圾）到本地的log files
。可以想象一个login API，当一个user login后，一个thread会产生如下的log （实
际的log各种花样没这么简单）
［2015-10-11 02:00:00］ TP－123 com.xyz.api.login INFO BEGIN
［2015-10-111 02:00:00］ TP－123 com.xyz.api.login INFO user abcd is in
［2015-10-11 02:00:00］ TP－123 com.xyz.api.login INFO use is from IP 1.2.3
.4
［2015-10-11 02:00:00］ TP－123 com.xyz.api.login INFO user has ... 阅读全帖 |
|
|
d*******r
发帖数: 3299 | 7 我的实际经验是，ES还不错，lostash比较业余
我现在在用 EFK，F 是 fluentd |
|
m***h
发帖数: 77 | 8 是的，我的问题不是关于架构，拿轮子搭积木不难。在log处理这方面，syslog,
access log之类都很简单，因为都是one liner，well defined format。application
log，或user activity log就不同，因为有用的数据往往分散在很多message里 (像我
上面的例子)，不管你是用什么message broker, 在consumer这端需要从新group，经常
需要把来自同一个request乃至同一个user的message数据合在一起，这才是我需要解决
的，因为我不像想在app端大改，所以选择用server name做message tag，和kafka
partition key (我用的是fluentd)，这样同一个server的message就能被同一个
consumer处理。 |
|
|
|
|
d****n
发帖数: 12461 | 11 ruby写的，data format用的json，看着是朝ui用户去的。 |
|
s*********y
发帖数: 6151 | 12 logstash是ruby吗 一直以为是java |
|
|
