容器日志采集利器：Filebeat深度剖析与实践

在云原生时代和容器化浪潮中，容器的日志采集是一个看起来不起眼却又无法忽视的重要议题。对于容器日志采集我们常用的工具有Filebeat和Fluentd，两者对比各有优劣，相比基于Ruby的Fluentd，考虑到可定制性，我们一般默认选择Golang技术栈的Filbeat作为主力的日志采集Agent。
相比较传统的日志采集方式，容器化下单节点会运行更多的服务，负载也会有更短的生命周期，而这些更容易对日志采集Agent造成压力，虽然Filebeat足够轻量级和高性能，但如果不了解Filebeat的机制，不合理的配置Filebeat，实际的生产环境使用中可能也会给我们带来意想不到的麻烦和难题。
整体架构

日志采集的功能看起来不复杂，主要功能无非就是找到配置的日志文件，然后读取并处理，发送至相应的后端如Elasticsearch、Kafka等。
Filebeat官网有张示意图，如下所示：

针对每个日志文件，Filebeat都会启动一个harvester协程，即一个goroutine，在该goroutine中不停的读取日志文件，直到文件的EOF末尾。一个最简单的表示采集目录的input配置大概如下所示：

1. filebeat.inputs:

2. - type: log

3. # Paths that should be crawled and fetched. Glob based paths.

4. paths:

5. - /var/log/*.log

不同的harvester goroutine采集到的日志数据都会发送至一个全局的队列queue中，queue的实现有两种：基于内存和基于磁盘的队列，目前基于磁盘的队列还是处于alpha阶段，Filebeat默认启用的是基于内存的缓存队列。
每当队列中的数据缓存到一定的大小或者超过了定时的时间（默认1s），会被注册的client从队列中消费，发送至配置的后端。目前可以设置的client有Kafka、Elasticsearch、Redis等。
虽然这一切看着挺简单，但在实际使用中，我们还是需要考虑更多的问题，例如：

• 日志文件是如何被Filbebeat发现又是如何被采集的？

• Filebeat是如何确保日志采集发送到远程的存储中，不丢失一条数据的？

• 如果Filebeat挂掉，下次采集如何确保从上次的状态开始而不会重新采集所有日志？

• Filebeat的内存或者CPU占用过多，该如何分析解决？

• Filebeat如何支持Docker和Kubernetes，如何配置容器化下的日志采集？

• 想让Filebeat采集的日志发送至的后端存储，如果原生不支持，怎样定制化开发？

这些均需要对Filebeat有更深入的理解，下面让我们跟随Filebeat的源码一起探究其中的实现机制。
一条日志是如何被采集的

Filebeat源码归属于beats项目，而beats项目的设计初衷是为了采集各类的数据，所以beats抽象出了一个Libbeat库，基于Libbeat我们可以快速的开发实现一个采集的工具，除了Filebeat，还有像Metricbeat、Packetbeat等官方的项目也是在beats工程中。
如果我们大致看一下代码就会发现，Libbeat已经实现了内存缓存队列MemQueue、几种output日志发送客户端，数据的过滤处理processor等通用功能，而Filebeat只需要实现日志文件的读取等和日志相关的逻辑即可。
从代码的实现角度来看，Filebeat大概可以分以下几个模块：

• input：找到配置的日志文件，启动harvester

• harvester：读取文件，发送至spooler

• spooler：缓存日志数据，直到可以发送至publisher

• publisher：发送日志至后端，同时通知registrar

• registrar：记录日志文件被采集的状态

找到日志文件
对于日志文件的采集和生命周期管理，Filebeat抽象出一个Crawler的结构体，在Filebeat启动后，crawler会根据配置创建，然后遍历并运行每个input：

1. for _, inputConfig := range c.inputConfigs {

2. err := c.startInput(pipeline, inputConfig, r.GetStates())

3. }

在每个input运行的逻辑里，首先会根据配置获取匹配的日志文件，需要注意的是，这里的匹配方式并非正则，而是采用linux glob的规则，和正则还是有一些区别。

1. matches, err := filepath.Glob(path)

获取到了所有匹配的日志文件之后，会经过一些复杂的过滤，例如如果配置了excludefiles则会忽略这类文件，同时还会查询文件的状态，如果文件的最近一次修改时间大于ignoreolder的配置，也会不去采集该文件。
读取日志文件
匹配到最终需要采集的日志文件之后，Filebeat会对每个文件启动harvester goroutine，在该goroutine中不停的读取日志，并发送给内存缓存队列MemQueue。
在(h *Harvester) Run()方法中，我们可以看到这么一个无限循环，省略了一些逻辑的代码如下所示：

1. for {

2. message, err := h.reader.Next()

3. if err != nil {

4. switch err {

5. case ErrFileTruncate:

6. logp.Info("File was truncated. Begin reading file from offset 0: %s", h.state.Source)

7. h.state.Offset = 0

8. filesTruncated.Add(1)

9. case ErrRemoved:

10. logp.Info("File was removed: %s. Closing because close_removed is enabled.", h.state.Source)

11. case ErrRenamed:

12. logp.Info("File was renamed: %s. Closing because close_renamed is enabled.", h.state.Source)

13. case ErrClosed:

14. logp.Info("Reader was closed: %s. Closing.", h.state.Source)

15. case io.EOF:

16. logp.Info("End of file reached: %s. Closing because close_eof is enabled.", h.state.Source)

17. case ErrInactive:

18. logp.Info("File is inactive: %s. Closing because close_inactive of %v reached.", h.state.Source, h.config.CloseInactive)

19. default:

20. logp.Err("Read line error: %v; File: %v", err, h.state.Source)

21. }

22. return nil

23. }

24. ...

25. if !h.sendEvent(data, forwarder) {

26. return nil

27. }

28. }

可以看到，reader.Next()方法会不停的读取日志，如果没有返回异常，则发送日志数据到缓存队列中。
返回的异常有几种类型，除了读取到EOF外，还会有例如文件一段时间不活跃等情况发生会使harvester goroutine退出，不再采集该文件，并关闭文件句柄。
Filebeat为了防止占据过多的采集日志文件的文件句柄，默认的close_inactive参数为5min，如果日志文件5min内没有被修改，上面代码会进入ErrInactive的case，之后该harvester goroutine会被关闭。
这种场景下还需要注意的是，如果某个文件日志采集中被移除了，但是由于此时被Filebeat保持着文件句柄，文件占据的磁盘空间会被保留直到harvester goroutine结束。
缓存队列
在MemQueue被初始化时，Filebeat会根据配置min_event是否大于1创建BufferingEventLoop或者DirectEventLoop，一般默认都是BufferingEventLoop，即带缓冲的队列。

1. type bufferingEventLoop struct {

2. broker *Broker

3. 
   

4. buf *batchBuffer

5. flushList flushList

6. eventCount int

7. 
   

8. minEvents int

9. maxEvents int

10. flushTimeout time.Duration

11. 
    

12. // active broker API channels

13. events chan pushRequest

14. get chan getRequest

15. pubCancel chan producerCancelRequest

16. 
    

17. // ack handling

18. acks chan int // ackloop -> eventloop : total number of events ACKed by outputs

19. schedACKS chan chanList // eventloop -> ackloop : active list of batches to be acked

20. pendingACKs chanList // ordered list of active batches to be send to the ackloop

21. ackSeq uint // ack batch sequence number to validate ordering

22. 
    

23. // buffer flush timer state

24. timer *time.Timer

25. idleC <-chan time.Time

26. }

BufferingEventLoop是一个实现了Broker、带有各种channel的结构，主要用于将日志发送至consumer消费。
BufferingEventLoop的run方法中，同样是一个无限循环，这里可以认为是一个日志事件的调度中心。

1. for {

2. select {

3. case <-broker.done:

4. return

5. case req := <-l.events: // producer pushing new event

6. l.handleInsert(&req)

7. case req := <-l.get: // consumer asking for next batch

8. l.handleConsumer(&req)

9. case count := <-l.acks:

10. l.handleACK(count)

11. case <-l.idleC:

12. l.idleC = nil

13. l.timer.Stop()

14. if l.buf.length() > 0 {

15. l.flushBuffer()

16. }

17. }

18. }

上文中harvester goroutine每次读取到日志数据之后，最终会被发送至bufferingEventLoop中的events chan pushRequest channel，然后触发上面req := <-l.events的case，handleInsert方法会把数据添加至bufferingEventLoop的buf中，buf即MemQueue实际缓存日志数据的队列，如果buf长度超过配置的最大值或者bufferingEventLoop中的timer定时器触发了case <-l.idleC，均会调用flushBuffer()方法。
flushBuffer()又会触发req := <-l.get的case，然后运行handleConsumer方法，该方法中最重要的是这一句代码：

1. req.resp <- getResponse{ackChan, events}

这里获取到了Consumer消费者的response channel，然后发送数据给这个channel。真正到这，才会触发Consumer对MemQueue的消费。所以，其实MemQueue并非一直不停的在被Consumer消费，而是在MemQueue通知Consumer的时候才被消费，我们可以理解为一种脉冲式的发送。
消费队列
实际上，早在Filebeat初始化的时候，就已经创建了一个eventConsumer并在loop无限循环方法里试图从Broker中获取日志数据。
如果把新消费与新零售这两股潮流结合到一块儿聊下怎么样？做一个规模不大的封闭沙龙，定向邀请一些业内玩家在一起聊个半天？

1. for {

2. if !paused && c.out != nil && consumer != nil && batch == nil {

3. out = c.out.workQueue

4. queueBatch, err := consumer.Get(c.out.batchSize)

5. ...

6. batch = newBatch(c.ctx, queueBatch, c.out.timeToLive)

7. }

8. ...

9. select {

10. case <-c.done:

11. return

12. case sig := <-c.sig:

13. handleSignal(sig)

14. case out <- batch:

15. batch = nil

16. }

17. }

上面consumer.Get就是消费者Consumer从Broker中获取日志数据，然后发送至out的channel中被output client发送，我们看一下Get方法里的核心代码：

1. select {

2. case c.broker.requests <- getRequest{sz: sz, resp: c.resp}:

3. case <-c.done:

4. return nil, io.EOF

5. }

6. 
   

7. // if request has been send, we do have to wait for a response

8. resp := <-c.resp

9. return &batch{

10. consumer: c,

11. events: resp.buf,

12. ack: resp.ack,

13. state: batchActive,

14. }, nil

getRequest的结构如下：

1. type getRequest struct {

2. sz int // request sz events from the broker

3. resp chan getResponse // channel to send response to

4. }

getResponse的结构：

1. type getResponse struct {

2. ack *ackChan

3. buf []publisher.Event

4. }

getResponse里包含了日志的数据，而getRequest包含了一个发送至消费者的channel。
在上文bufferingEventLoop缓冲队列的handleConsumer方法里接收到的参数为getRequest，里面包含了Consumer请求的getResponse channel。如果handleConsumer不发送数据，consumer.Get方法会一直阻塞在select中，直到flushBuffer，Consumer的getResponse channel才会接收到日志数据。
发送日志
在创建beats时，会创建一个clientWorker，clientWorker的run方法中，会不停的从Consumer发送的channel里读取日志数据，然后调用client.Publish批量发送日志。

1. func (w *clientWorker) run() {

2. for !w.closed.Load() {

3. for batch := range w.qu {

4. if err := w.client.Publish(batch); err != nil {

5. return

6. }

7. }

8. }

9. }

Libbeats库中包含了Kafka、Elasticsearch、Logstash等几种client，它们均实现了client接口：

1. type Client interface {

2. Close() error

3. Publish(publisher.Batch) error

4. String() string

5. }

当然最重要的是实现Publish接口，然后将日志发送出去。
实际上，Filebeat中日志数据在各种channel里流转的设计还是比较复杂和繁琐的，笔者也是研究了好久、画了很长的架构图才理清楚其中的逻辑。
这里抽出了一个简化后的图以供参考：

如何保证At Least Once

Filebeat维护了一个registry文件在本地的磁盘，该registry文件维护了所有已经采集的日志文件的状态。
实际上，每当日志数据发送至后端成功后，会返回ack事件。Filebeat启动了一个独立的registry协程负责监听该事件，接收到ack事件后会将日志文件的State状态更新至registry文件中，State中的Offset表示读取到的文件偏移量，所以Filebeat会保证Offset记录之前的日志数据肯定被后端的日志存储接收到。
State结构如下所示：

1. type State struct {

2. Id string `json:"-"` // local unique id to make comparison more efficient

3. Finished bool `json:"-"` // harvester state

4. Fileinfo os.FileInfo `json:"-"` // the file info

5. Source string `json:"source"`

6. Offset int64 `json:"offset"`

7. Timestamp time.Time `json:"timestamp"`

8. TTL time.Duration `json:"ttl"`

9. Type string `json:"type"`

10. Meta map[string]string `json:"meta"`

11. FileStateOS file.StateOS

12. }

记录在registry文件中的数据大致如下所示：

1. [{"source":"/tmp/aa.log","offset":48,"timestamp":"2019-07-03T13:54:01.298995+08:00","ttl":-1,"type":"log","meta":null,"FileStateOS":{"inode":7048952,"device":16777220}}]

由于文件可能会被改名或移动，Filebeat会根据inode和设备号来标志每个日志文件。
如果Filebeat异常重启，每次采集harvester启动的时候都会读取registry文件，从上次记录的状态继续采集，确保不会从头开始重复发送所有的日志文件。
当然，如果日志发送过程中，还没来得及返回ack，Filebeat就挂掉，registry文件肯定不会更新至最新的状态，那么下次采集的时候，这部分的日志就会重复发送，所以这意味着Filebeat只能保证at least once，无法保证不重复发送。
还有一个比较异常的情况是，Linux下如果老文件被移除，新文件马上创建，很有可能它们有相同的inode，而由于Filebeat根据inode来标志文件记录采集的偏移，会导致registry里记录的其实是被移除的文件State状态，这样新的文件采集却从老的文件Offset开始，从而会遗漏日志数据。
为了尽量避免inode被复用的情况，同时防止registry文件随着时间增长越来越大，建议使用cleaninactive和cleanremove配置将长时间未更新或者被删除的文件State从registry中移除。
同时我们可以发现在harvester读取日志中，会更新registry的状态处理一些异常场景。例如，如果一个日志文件被清空，Filebeat会在下一次Reader.Next方法中返回ErrFileTruncate异常，将inode标志文件的Offset置为0，结束这次harvester，重新启动新的harvester，虽然文件不变，但是registry中的Offset为0，采集会从头开始。
特别注意的是，如果使用容器部署Filebeat，需要将registry文件挂载到宿主机上，否则容器重启后registry文件丢失，会使Filebeat从头开始重复采集日志文件。
Filebeat自动reload更新

目前Filebeat支持reload input配置，module配置，但reload的机制只有定时更新。
在配置中打开reload.enable之后，还可以配置reload.period表示自动reload配置的时间间隔。
Filebeat在启动时，会创建一个专门用于reload的协程。对于每个正在运行的harvester，Filebeat会将其加入一个全局的Runner列表，每次到了定时的间隔后，会触发一次配置文件的diff判断，如果是需要停止的加入stopRunner列表，然后逐个关闭，新的则加入startRunner列表，启动新的Runner。
Filebeat对Kubernetes的支持

Filebeat官方文档提供了在Kubernetes下基于DaemonSet的部署方式，最主要的一个配置如下所示：

1. - type: docker

2. containers.ids:

3. - "*"

4. processors:

5. - add_kubernetes_metadata:

6. in_cluster: true

即设置输入input为Docker类型。由于所有的容器的标准输出日志默认都在节点的/var/lib/docker/containers//*-json.log路径，所以本质上采集的是这类日志文件。
和传统的部署方式有所区别的是，如果服务部署在Kubernetes上，我们查看和检索日志的维度不能仅仅局限于节点和服务，还需要有podName，containerName等，所以每条日志我们都需要打标增加Kubernetes的元信息才发送至后端。
Filebeat会在配置中增加了addkubernetesmetadata的processor的情况下，启动监听Kubernetes的watch服务，监听所有Kubernetes Pod的变更，然后将归属本节点的Pod最新的事件同步至本地的缓存中。
节点上一旦发生容器的销毁创建，/var/lib/docker/containers/下会有目录的变动，Filebeat根据路径提取出containerId，再根据containerId从本地的缓存中找到Pod信息，从而可以获取到podName、label等数据，并加到日志的元信息fields中。
Filebeat还有一个beta版的功能Autodiscover，Autodiscover的目的是把分散到不同节点上的Filebeat配置文件集中管理。目前也支持Kubernetes作为provider，本质上还是监听Kubernetes事件然后采集Docker的标准输出文件。
大致架构如下所示：

但是在实际生产环境使用中，仅采集容器的标准输出日志还是远远不够，我们往往还需要采集容器挂载出来的自定义日志目录，还需要控制每个服务的日志采集方式以及更多的定制化功能。
在轻舟容器云上，我们自研了一个监听Kubernetes事件自动生成Filebeat配置的Agent，通过CRD的方式，支持自定义容器内部日志目录、支持自定义fields、支持多行读取等功能。同时可在Kubernetes上统一管理各种日志配置，而且无需用户感知Pod的创建销毁和迁移，自动完成各种场景下的日志配置生成和更新。
性能分析与调优

虽然beats系列主打轻量级，虽然用Golang写的Filebeat的内存占用确实比较基于JVM的Logstash等好太多，但是事实告诉我们其实没那么简单。正常启动Filebeat，一般确实只会占用3、40MB内存，但是在轻舟容器云上偶发性的我们也会发现某些节点上的Filebeat容器内存占用超过配置的Pod Limit限制（一般设置为200MB），并且不停的触发的OOM。
究其原因，一般容器化环境中，特别是裸机上运行的容器个数可能会比较多，导致创建大量的harvester去采集日志。如果没有很好的配置Filebeat，会有较大概率导致内存急剧上升。
当然，Filebeat内存占据较大的部分还是MemQueue，所有采集到的日志都会先发送至MemQueue聚集，再通过output发送出去。每条日志的数据在Filebeat中都被组装为event结构，Filebeat默认配置的MemQueue缓存的event个数为4096，可通过queue.mem.events设置。默认最大的一条日志的event大小限制为10MB，可通过max_bytes设置。4096 * 10MB = 40GB，可以想象，极端场景下，Filebeat至少占据40GB的内存。特别是配置了multiline多行模式的情况下，如果MultiLine配置有误，单个event误采集为上千条日志的数据，很可能导致MemQueue占据了大量内存，致使内存爆炸。
所以，合理的配置日志文件的匹配规则，限制单行日志大小，根据实际情况配置MemQueue缓存的个数，才能在实际使用中规避Filebeat的内存占用过大的问题。
如何对Filebeat进行扩展开发

一般情况下Filebeat可满足大部分的日志采集需求，但是仍然避免不了一些特殊的场景需要我们对Filebeat进行定制化开发，当然Filebeat本身的设计也提供了良好的扩展性。
beats目前只提供了像Elasticsearch、Kafka、Logstash等几类output客户端，如果我们想要Filebeat直接发送至其他后端，需要定制化开发自己的output。同样，如果需要对日志做过滤处理或者增加元信息，也可以自制processor插件。
无论是增加output还是写个processor，Filebeat提供的大体思路基本相同。一般来讲有3种方式：

• 直接fork filebeat，在现有的源码上开发。output或者processor都提供了类似Run、Stop等的接口，只需要实现该类接口，然后在init方法中注册相应的插件初始化方法即可。当然，由于Golang中init方法是在import包时才被调用，所以需要在初始化Filebeat的代码中手动import。

• 复制一份Filebeat的main.go，import我们自研的插件库，然后重新编译。本质上和方式1区别不大。

• Filebeat还提供了基于Golang Plugin的插件机制，需要把自研的插件编译成.so共享链接库，然后在Filebeat启动参数中通过-plugin指定库所在路径。不过实际上一方面Golang Plugin还不够成熟稳定，一方面自研的插件依然需要依赖相同版本的Libbeat库，而且还需要相同的Golang版本编译，坑可能更多，不太推荐。

原文链接：https://juejin.im/post/5d29376ae51d45507022702e

Kubernetes企业级实战训练营

Kubernetes企业级实战训练营将于2019年8月30日在北京举办，3天时间带你系统掌握Kubernetes，学习效果不好可以继续学习。本次培训包括：Docker基础、容器技术、Docker镜像、数据共享与持久化、Docker三驾马车、Docker实践、Kubernetes基础、Pod基础与进阶、常用对象操作、服务发现、Helm、Kubernetes核心组件原理分析、Kubernetes服务质量保证、调度详解与应用场景、网络、基于Kubernetes的CI/CD、基于Kubernetes的配置管理等， 点击下方图片或者阅读原文链接查看详情。