Loggie的诞生背景

为什么我们会选择研发Loggie,当时的背景和原因是什么?

一、那些年我们遇到的问题

在研发Loggie之前,我们的日志服务采集端都是使用Filebeat,当时为什么选择Filebeat呢?

Filebeat是Elastic公司的产品,主打轻量级,用于替换原有Logstash去实现日志采集的工作,相比他们自家基于JRuby语言的Logstash,Filebeat确实是相对轻量、资源占用少。和其他的开源日志采集Agent相比,基于Golang开发的Filebeat,也有很多优势。
例如,相比基于Java的Flume,性能更好,资源占用更少;相比基于Ruby的Fluentd,性能更好,二次开发更方便;相比基于C的Fluentd-bit,功能更完善,开发更友好。
所以,总体来说,Filebeat是一个相对比较平衡的日志采集Agent,这也是我们当初选择Filebeat作为默认日志采集Agent的原因。

但是随着我们对Filebeat更加深度的使用,在公司集团内部实践和外部客户的交付中,也碰到了一些问题。

由于Filebeat设计当初设计时,为了区分于Logstash,突出轻量级,牺牲了很多可扩展性的设计。
最明显的就是,Filebeat只有一个Queue和一个Output。这样也导致了:

隔离性弱

由于所有的服务日志都会发送到全局唯一的Queue里,导致服务日志数据混在一起,在异常场景发生时,无法有隔离性的保障。
比如Filebeat全局的Queue堆积,会导致节点的所有服务日志均无法发送,如果我们对不同服务的日志的级别和要求不一样,不管重要还是不重要的日志都会受到影响。

不支持多个Output

有一些场景下,我们可能需要将不同服务的不同类型日志发送至不同的后端,但Filebeat无法使用同一个Agent去发送到不同的Kafka集群,只能在节点上部署多个Agent,导致维护和资源成本上升。

可扩展性有限

相比Logstash/Flume等,Filebeat并非使用类似的input->queue->output的灵活多个pipeline设计,在对于日志数据的处理/过滤/增强上,依赖的是Filebeat有限的一些processor,可扩展性不足。
同时Filebeat也无法作为中转聚合使用,在使用场景下大大受限,需要额外引入其他组件。另外类似日志报警等场景,Filebeat也无法满足。
我们也尝试过定制化开发,但Filebeat本身的架构设计上难以实现更多的扩展能力,并且长期会带来升级与上游社区代码同步的问题。

日志排障运维困境

Filebeat的metrics比较有限,很多时候我们想要排查诸如常见的日志是否有采集、采集的日志是否完整、发送是否有延迟等等排障场景,Filebeat没有提供相应的功能,十分影响线上的问题排查效率。而且Filebeat未提供Prometheus格式的监控指标,需要额外注入exporter。

性能不够

虽然Filebeat性能尚可,但是在我们的实际使用时,遇到日志场景复杂、日志量大的情况时,存在吞吐量的瓶颈,无法满足实时性的需求。

二、为什么现有的其他开源日志项目不能满足需求?

Fluentd/Fluent-bit

Fluentd基于Ruby性能一般,单线程;Fluent-bit基于C,对于我们的技术栈来说,Ruby和C的维护和二次开发成本比较大。

Logstash

Logstash性能较差,基于JRuby的资源占用和损耗都比较大。

Flume

资源占用较大,性能一般,之前有内部部门使用过Flume,对比的压测结论证实确实不如Filebeat。

最重要的是,目前所有的开源Agent,均没有对K8s有很好的原生支持,个别支持的也只能采集stdout的日志。 正是由于目前开源的Agent存在一些问题,不能满足长期的需求,所以我们决定开始自研。

三、什么才是我们理想中的日志Agent?

整体的目标: 高性能、资源占用低、高可用、稳定性强、可扩展性强、更适合云原生。

性能与资源: 性能相同的情况下,CPU比社区Filebeat大大降低,吞吐量上限要远高于Filebeat。

高可用、稳定性强: 资源隔离,作为基础设施一定要稳定可靠,同时默认支持大量监控指标,对常见的运维类问题有良好的支撑,减少运维负担。

可扩展性:
整体设计上,方便用户扩展,实现过滤、路由、编码等能力。比如可以很快速的写一个处理逻辑,就可以进行数据处理。

总结一下,我们理想中的日志Agent是一个:

  1. 开箱即用:可快速部署容器化场景下的日志采集服务;有完善的文档与经验介绍;
  2. 高性能:比原生Filebeat性能高,资源占用少;
  3. 高可靠:隔离性稳定性更强;默认集成更多的监控指标,方便运维排障;
  4. 可扩展:基于微内核的架构,用户可方便快捷的写自己的插件,满足各种定制化需求;