1. fluentd
fluentd是一个针对日志的收集、处理、转发系统。通过丰富的插件系统，可以收集来自于各种系统或应用的日志，转化为用户指定的格式后，转发到用户所指定的日志存储系统之中。
fluentd 常常被拿来和Logstash比较，我们常说ELK，L就是这个agent。fluentd 是随着Docker，GCP 和es一起流行起来的agent。
这篇文章里概括一下的话，有以下区别：
- fluentd 比 logstash 更省资源；
- 更轻量级的 fluent-bid 对应 filebeat，作为部署在结点上的日志收集器；
- fluentd 有更多强大、开放的插件数量和社区。插件列表这一点值得多说，插件太多了，也非常灵活，规则也不复杂。
安装的话。mac 自带gem。 sudo gem install fluentd即可完成安装。
2. fluentd helloword
Fluent 配置文件
<source>
@type http
port 4888
bind 0.0.0.0
</source>
<match test.cycle>
@type stdout
</match>
启动fluentd： fluentd -c in_http.conf
发起http请求：curl -i -X POST -d ‘json={“action”:“login”,“user”:2}’ http://localhost:4888/test.cycle
3. fluent 的事件
-
tag： 事件来自何处，是如何被路由的依据。
-
time： 时间戳
-
record：消息体，也就是具体的日志内容，json格式。
事件是由input plugin 负责去产生的，例如 in_tail 这个plugin，从文件末尾读取文本行
192.168.0.1 - - [28/Feb/2013:12:00:00 +0900] "GET / HTTP/1.1" 200 777事件的内容将会是：
tag: apache.access # set by configuration time: 1362020400 # 28/Feb/2013:12:00:00 +0900 record: {"user":"-","method":"GET","code":200,"size":777,"host":"192.168.0.1","path":"/"}
4. 事件的处理
-
match
以上述为例，match 就是通过 tag 匹配 source，然后执行指定的命令来分发日志，最常见的用法就是将 source 收集的日志转存到数据库。上例中的
test.cycle就是 tag，tag 有好几种匹配模式：*：匹配任意一个 tag；**：匹配任意数量个 tag；a b：匹配 a 或 b；{X,Y,Z}：匹配 X, Y, Z 中的一个。
Match 的匹配顺序：
match 是从上往下依次匹配的，一旦一个日志流被匹配上，就不会再继续匹配剩下的 match 了。 所以如果有
<match **>这样的全匹配，一定要放到配置文件的最后。match 不仅仅用来处理输出，还有一些高级功能，比如日志事件进行一些处理后重新抛出，当成一个新的事件从新走一遍流程。
-
filter
filter 和 match 的语法几乎一样，但是 多个filter 可以串联成 pipeline，对数据进行串行处理，最终再交给 match 输出。
我们对上述的 in_http.conf 作下修改，增加：
<filter test.cycle> @type record_transformer <record> host "#{Socket.gethostname}" </record> </filter> <filter test.cycle> @type stdout </filter> <filter test.cycle> @type grep <exclude> key action pattern ^logout$ </exclude> </filter>然后重启fluentd。
注意：
-
左侧有三个请求，其中中间的请求在经过第三个filter的时候，被中断掉了，且每一个事件被新增了主机名称。所以三个请求，标准输出产生了5个记录。
-
filter 匹配顺序与 match 相同，我们应该在 之前放置
-
Input -> filter 1 -> … -> filter N -> Output（Match tag）
-
-
label
当我们的规则变得复杂以后，文件开始会变得复杂，并且不易阅读。label是一种新的方式能够改善这个问题。我们对上述文件稍作修改。
<source> @type http port 4888 bind 0.0.0.0 </source> <source> @type http port 4887 bind 0.0.0.0 @label @ADD </source> <filter test.cycle> @type stdout </filter> <filter test.cycle> @type grep <exclude> key action pattern ^logout$ </exclude> </filter> <label @ADD> <filter test.cycle> @type record_transformer <record> host "#{Socket.gethostname}" </record> </filter> <match test.cycle> @type stdout </match> </label> <match test.cycle> @type stdout </match>很快会发现区别在哪儿：
第二个请求，我们请求的是4887端口，它打了一个label，叫做@ADD，那么这个 source 所触发的事件就会被发送给指定的 ADD label 所包含的任务，而跳过被其紧跟其后的其他任务。
-
buffers
上边的例子，我们使用了非-buffered 的stdout 输出。但在生产中，你可以在buffered模式下使用输出，例如 es，forward，mongodb，s3等。buffered模式下的输出插件首先将接收到的事件存储到缓冲区中（“内存”或“file”）当满足刷新条件时才将缓冲区写入目的地址。 因此，使用缓冲输出，与stdout非缓冲输出不同，我们不会立即看到接收到的事件。
这个插件不好演示，我不演示了。
算了，还是演示下吧。修改下，label @ADD的部分。
<label @ADD> <filter test.cycle> @type record_transformer <record> host "#{Socket.gethostname}" </record> </filter> <match test.cycle> @type file path /Users/xialingming/fluentd/myapp <buffer> timekey 100 timekey_use_utc true timekey_wait 1m </buffer> </match> </label>这里的含义是，把发给4887的日志，经过filter组成的pipeline以后，最终会输出到file类型里，path是必须的。如果你啥不配置的话，就每天的0:10左右，刷进去文件里。所以，你配置了file的时候，会发现没有马上看到文件。
-
timekey： 100 （单位是秒），指定的是多久会产生一个chunk。把时间轴按照100s去分割。
timekey 60: ["12:00:00", ..., "12:00:59"], ["12:01:00", ..., "12:01:59"], ... timekey 180: ["12:00:00", ..., "12:02:59"], ["12:03:00", ..., "12:05:59"], ... timekey 3600: ["12:00:00", ..., "12:59:59"], ["13:00:00", ..., "13:59:59"], ...假如配置了 timekey = 1h， 那么CHUNK分别这么如下产生。 11:59:30 web.access {"key1":"yay","key2":100} ------> CHUNK_A 12:00:01 web.access {"key1":"foo","key2":200} --| |---> CHUNK_B 12:00:25 ssh.login {"key1":"yay","key2":100} --| -
timekey_wait: 1m 是指当前chunk 结束了以后，延迟1m，才把该chunk flush到文件里。比如，当你配置了，timekey: 3600以后，那么啥时候产生最终落地的文件呢？如下图所示。
timekey: 3600 ------------------------------------------------------- time range for chunk | timekey_wait | actual flush time 12:00:00 - 12:59:59 | 0s | 13:00:00 12:00:00 - 12:59:59 | 60s (1m) | 13:01:00 12:00:00 - 12:59:59 | 600s (10m) | 13:10:00
-
Buffer 的保存路径最终是这样的：
$ tree /tmp/logs/
/tmp/logs/
├── ${tag}
│ ├── buffer.b57fb1dd96306dd0b308e094f7ec2228f.log
│ ├── buffer.b57fb1dd96306dd0b308e094f7ec2228f.log.meta
│ ├── buffer.b57fb1dd96339a870530991d4871cfe11.log
│ └── buffer.b57fb1dd96339a870530991d4871cfe11.log.meta
├── current-dummy1 -> /tmp/logs/${tag}/buffer.b57fb1dd96339a870530991d4871cfe11.log
└── current-dummy2 -> /tmp/logs/${tag}/buffer.b57fb1dd96306dd0b308e094f7ec2228f.log
#5.总结：
除了玲琅满目官方插件之外，我们还可以自己去编写灵活的插件。@type指定即可。
一旦事件由Fluentd 配置的Source产生，就可以一步步被瀑布流般地处理或在引用的Label内部处理，任何事件都可能随时被过滤掉。
515
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
