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是一个：
- 开箱即用：可快速部署容器化场景下的日志采集服务；有完善的文档与经验介绍；
- 高性能：比原生Filebeat性能高，资源占用少；
- 高可靠：隔离性稳定性更强；默认集成更多的监控指标，方便运维排障；
- 可扩展：基于微内核的架构，用户可方便快捷的写自己的插件，满足各种定制化需求；