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 httpport 4888bind 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 actionpattern ^logout$</exclude>
</filter>
```
然后重启fluentd。

注意：
- 左侧有三个请求，其中中间的请求在经过第三个filter的时候，被中断掉了，且每一个事件被新增了主机名称。所以三个请求，标准输出产生了5个记录。
- filter 匹配顺序与 match 相同，我们应该在之前放置
- Input -> filter 1 -> … -> filter N -> Output（Match tag）
label

当我们的规则变得复杂以后，文件开始会变得复杂，并且不易阅读。label是一种新的方式能够改善这个问题。我们对上述文件稍作修改。
```
<source>@type httpport 4888bind 0.0.0.0
</source><source>@type httpport 4887bind 0.0.0.0@label @ADD
</source><filter test.cycle>@type stdout
</filter>
<filter test.cycle>@type grep<exclude>key actionpattern ^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 filepath /Users/xialingming/fluentd/myapp<buffer>timekey 100timekey_use_utc truetimekey_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_A12: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 time12:00:00 - 12:59:59 |           0s |          13:00:0012:00:00 - 12:59:59 |     60s (1m) |          13:01:0012: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内部处理，任何事件都可能随时被过滤掉。

Fluentd的使用入门到熟练相关推荐

linux内核二当家,Linux PWN从入门到熟练（二）
前言上回说到,如何利用程序中system函数以及bin/sh字符串来进行pwn.这里我们会介绍,如何在栈可执行而system函数以及参数没有的情况下,如何自己布置payload进行pwn.此外,还提 ...
【github干货】主流深度学习开源框架从入门到熟练
文章首发于微信公众号<有三AI> [github干货]主流深度学习开源框架从入门到熟练今天送上有三AI学院第一个github项目 01项目背景目前深度学习框架呈百家争鸣之态势,光是为人 ...
matlab z变换离散化_MATLAB作图从入门到熟练
有同学说,靠网络上的文章,很难学到系统的知识,还得自己看书,这话不假.主要是因为网上文章篇幅过短,难免无法概括全面,加之同学们更关心一些高效的学习方法,更倾向于接受高密集信息的学习方式,节省时间和精力 ...
Linux PWN从入门到熟练
最近在复习pwn的一些知识.主要涉及到当堆栈开启了保护的时候,我们不能够直接将shellcode覆盖到堆栈中执行,而需要利用程序其他部分的可执行的小片段来连接成最终的shellcode.此小片段就是g ...
RESTful从入门到熟练，看完这篇就够了
学习要求良好的java基础, 熟悉SpringBoot框架,熟悉SpringMVC框架教学目标掌握RESTful接口设计视频教程 5小时带你入门到熟练RESTful接口设计铺垫先说明,本篇 ...
.Net Redis 入门到熟练
内存缓存主要有两种,一种是应用服务自己的memcache,类似于 webapi的session 其实都是服务自己的应用级内存,另外一种是分布式的缓存服务,此服务在另外的机器上,耗费的都是此机器的内存资 ...
大数据技术之Hadoop分布式文件系统HDFS系统知识整理（从入门到熟练操作）
系列博客 1.大数据技术之Hadoop完全分布式集群搭建+Centos7配置连通外网和主机 2.大数据技术之Hadoop编译源码 3.大数据技术之Hadoop分布式文件系统HDFS系统知识整理(从入门 ...
python的django框架从入门到熟练【保姆式教学】第一篇
当今,Python已成为最受欢迎的编程语言之一.而Django是一个基于Python的Web框架,它能够帮助你快速.高效地开发Web应用程序.如果你是一名初学者,学习Django框架可能会让你感到有些 ...
【软件开发底层知识修炼】十九 GDB调试从入门到熟练掌握超级详细实战教程学习目录
本文记录之前写过的5篇关于GDB快速学习的文章,从第一篇开始学习到最后一篇,保证可以从入门GDB调试到熟练掌握GDB调试的技巧. 学习交流加个人qq: 1126137994 个人微信: liu112 ...

Fluentd的使用入门到熟练

1. fluentd

2. fluentd helloword

3. fluent 的事件

4. 事件的处理

Fluentd的使用入门到熟练相关推荐

最新文章

热门文章