天天看点

日志客户端(Logstash,Fluentd, Logtail)横评日志收集的场景三款日志收集工具日志文件收集场景 - 功能对比日志文件收集场景 - 性能对比总结

dt时代,数以亿万计的服务器、移动终端、网络设备每天产生海量的日志。

中心化的日志处理方案有效地解决了在完整生命周期内对日志的消费需求,而日志从设备采集上云是始于足下的第一步。

日志客户端(Logstash,Fluentd, Logtail)横评日志收集的场景三款日志收集工具日志文件收集场景 - 功能对比日志文件收集场景 - 性能对比总结

开源界鼎鼎大名elk stack中的"l",社区活跃,生态圈提供大量插件支持。

logstash基于jruby实现,可以跨平台运行在jvm上。

模块化设计,有很强的扩展性和互操作性。

开源社区中流行的日志收集工具,td-agent是其商业化版本,由treasure data公司维护,是本文选用的评测版本。

fluentd基于cruby实现,并对性能表现关键的一些组件用c语言重新实现,整体性能不错。

fluentd设计简洁,pipeline内数据传递可靠性高。相较于logstash,其插件支持相对少一些。

阿里云日志服务的生产者,目前在阿里集团内部机器上运行,经过3年多时间的考验,目前为阿里公有云用户提供日志收集服务。

采用c++语言实现,对稳定性、资源控制、管理等下过很大的功夫,性能良好。相比于logstash、fluentd的社区支持,logtail功能较为单一,专注日志收集功能。

功能项

logstash

fluentd

logtail

日志读取

轮询

事件触发

文件轮转

支持

failover处理 (本地checkpoint)

通用日志解析

支持grok(基于正则表达式)解析

支持正则表达式解析

特定日志类型

支持delimiter、key-value、json等主流格式

支持key-value格式

数据发送压缩

插件支持

lz4

数据过滤

数据buffer发送

发送异常处理

运行环境

jruby实现,依赖jvm环境

cruby、c实现,依赖ruby环境

c++实现,无特殊要求

线程支持

支持多线程

多线程受gil限制

热升级

不支持

中心化配置管理

运行状态自检

支持cpu/内存阈值保护

以nginx的access log为样例,如下一条日志365字节,结构化成14个字段:

日志客户端(Logstash,Fluentd, Logtail)横评日志收集的场景三款日志收集工具日志文件收集场景 - 功能对比日志文件收集场景 - 性能对比总结

在接下来的测试中,将模拟不同的压力将该日志重复写入文件,每条日志的time字段取当前系统时间,其它13个字段相同。

相比于实际场景,模拟场景在日志解析上并无差异,有一点区别是:较高的数据压缩率会减少网络写出流量。

logstash-2.0.0版本,通过grok解析日志并写出到kafka(内置插件,开启gzip压缩)。

日志解析配置:

测试结果:

写入tps

写入流量 (kb/s)

cpu使用率 (%)

内存使用 (mb)

500

178.22

22.4

427

1000

356.45

46.6

431

5000

1782.23

221.1

440

10000

3564.45

483.7

450

td-agent-2.2.1版本,通过正则表达式解析日志并写入kafka(第三方插件fluent-plugin-kafka,开启gzip压缩)。

13.5

61

23.4

94.3

103

注:受gil限制,fluentd单进程最多使用1个cpu核心,可以使用插件multiprocess以多进程的形式支持更大的日志吞吐。

logtail 0.9.4版本,设置正则表达式进行日志结构化,数据lz4压缩后以http协议写到阿里云日志服务,设置batch_size为4000条。

1.7

13

3

15

15.3

23

31.6

25

日志客户端(Logstash,Fluentd, Logtail)横评日志收集的场景三款日志收集工具日志文件收集场景 - 功能对比日志文件收集场景 - 性能对比总结

可以看到三款日志工具各有特点:

logstash支持所有主流日志类型,插件支持最丰富,可以灵活diy,但性能较差,jvm容易导致内存使用量高。

fluentd支持所有主流日志类型,插件支持较多,性能表现较好。

logtail占用机器cpu、内存资源最少,结合阿里云日志服务的e2e体验良好,但目前对特定日志类型解析的支持较弱,后续需要把这一块补起来。