# 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. 可扩展：基于微内核的架构，用户可方便快捷的写自己的插件，满足各种定制化需求；
