14 - Logs - 挖掘系统内部发生的状况 (2/4) - 使用 Filebeat 应该要了解的设计细节与原理

Logs - 挖掘系统内部发生的状况 系列文章

• (1/4) - Logs 与 Filebeat 的基本介绍
• (2/4) - 使用 Filebeat 应该要了解的设计细节与原理
• (3/4) - 透过 Filebeat 收集 Elastic Stack 中各种服务的细节资讯
• (4/4) - 透过 Filebeat 收集 Infrastructure 中各种服务的细节资讯

本篇学习重点

• Filebeat 的设计架构与底层运作原理
• Filebeat Config 配置的一些建议与需注意的设定

Filebeat 的运作架构与原理

由於实务上的使用情境有许多种变化，透过了解 Filebeat 运作运作架构与原理，能帮助我们在自己所需要的情境之下，能进行比较好的配置及使用，避免效能的浪费或甚至是因为误用而造成非预期的结果。

Filebeat 的运作原理

这是在上一篇文章我们有介绍到的 Filebeat 运作架构，接下来我们先深入的了解里面的组成元素与运作细节。[1]

Harvesters (收集器)

Harvester 的职责与运作特性如下：

• 每个档案都会有专门负责的 Harvester 进行处理，并且将新增加的资料读出，并且交给 libbeat 进行後续处理，最终透过 Outputs 的定义将资料往外传送。
• 读取档案时，以 行 (Line) 为单位。
• Harvester 会负责实体档案的 open 与 close，也就是说只要 Harvester 还在运作时，所负责读取的档案的 File descriptor (档案描述器) 会一直保持 open 的状态，因此如果 Harvester 在保持运作时，若某个档案被移动或改名後，这个档案後续增加的内容，依然会被 Harvester 读取出来，也因此如果档案被删除的话，磁碟空间还是会一直被占用着，直到 Harvester close 档案之後，才会被释放。
• 要让 Harvester close 档案的话，会依照 close_inactive 所设定的值，等到档案持续指定的时间长度没有写入新资料之後，才会被关闭，而触发检查这个设定值会是依照 scan_frequency 所指定的时间周期。
• 被 close 的档案，若是又有新的资料写入，会等到 scan_frequency 下次执行的时间周期检查到档案时，才会继续 open 并且读取档案。

Inputs (输入端)

而 Inputs 的职责与运作特性如下：

• Inputs 负责管理需要被读取的档案或资料来源。
• Inputs 将要读取的档案及资料交给 Harvester 进行处理，也就是说 Harvesters 其实就是由 Inputs 在管理的。
• 当有设定多组 Inputs 时，每个 Input 拥有自己的执行绪 (Thread)，会并发进行处理。
• 以 log Input 为例，若是有指定多个 paths ，每个 paths 指定的档案都会由 Input 负责找出来，并且每一个档会交给一个 Harvester 去处理。
• 同一种类型的 Input 可以重覆被定义很多次，但要留意同一个档案不应该被重覆指定，这样可能会发生非预期的行为。
• Input 目前 Filebeat 有支援 20 几种服务的实作，有兴趣的可以参考 官方文件 - Filebeat Inputs [2]。

早期叫 prospector ，6.3 版之後将 prospector 改成 input

Spooler (缓冲处理器)

Spooler 其实指的是 Queue，也就是 libbeat 里面所实作的机制，由 harvesters 所读取出的资料，会以 events 的方式，透过 events channel 传送给 libbeat ，并且在 libbeat 当中透过各种 Pipeline 的方式进行後续的处理，像是如果有定义 processors 就会在 pipelineProcessors 面进行指定的处理，而 libbeat 里的 Publisher ，就负责将 event 最後透过 Output 的定义所往後传送的机制，这边是以 At Least Once 的方式来实作，也就是会确保资料有被正确的传送出去，如果没有收到正确传送出去的回覆，就会不断的重试，最终会透过 Registrar 将结果写入到 Registry 档案之中。

有兴趣了解 Filebeat 与 libbeat 底层实作的，可以参考 Filebeat 原始码浅析 [3]。

Outputs (输出)

Output 这边是针对 Filebeat 所支援的对外接口种类有各别的实作，目前 Filebeat 的 Output 有提供 6 种 (Elasticsearch, Logstash, Kafka, Redis, File, Console)，如果有定义要批次处理，例如 Elasticsearch Output 会使用 bulk API，这个处理就会实作在 Output 当中，另外如果 Filebeat 在关闭时，还没有成功取得 Output 所发送出去的回应时，Filebeat 不会等待，会直接关闭，一但 Filebeat 重新启动时，这个 events 就会被重新传送。

Filebeat 如何记录及处理要传送的档案

Filebeat 会将每个处理过的档案，记录在他的 Registry 档里面，预设是存放在 ${path.data}/registry/ 的目录里。

里面会有个 json 格式的档案，记录每一个曾被读取过的档案，而如果是保持在 open 的档案，会另外独立存在一个 active 的档案之中，同时会记录 inode 等实体 disk 的资讯，Filebeat 会持续在记忆体更新每个档案被读取过的位置，并且等到资料成功透过 Output 传送出去之後，便会将记忆体中的记录写到 Disk 中，而如果 Filebeat 程序异常中止的话，也会在重新启动的时候，从 Registry 里将记录读出，就能够知道要继续从档案的哪个位置往後读取。

由於 log 档名可能会被修改，档案也可能会搬位置，因此 Filebeat 会以 Disk inode 资讯产生另外的 Unique ID 并记录在 Registry 之中，用以评估档案是否在先前有被处理过，以防止档案改名或搬位置之後，被重覆的读取。

Filebeat 如何确保需传送的资料不会漏掉

Filebeat 能确保资料 At Least Once 的使命必达，不会漏掉，是因为他会将传送的状态记录在 Registry 档案里，所以发生错误没办法成功的传送，就会透过前面所介绍的 libbeat 里的 Registrar 进行重送，同样的如果 Filebeat 非正常的关闭，也会在重新启动的时候，透过 Registry 将档案处理的状态给恢复。

Filebeat 的 Config 配置方式

这边会将一些 Config 配置上，实务上会需要留意及较常会使用到的部份与大家进行介绍。

一般设定

这部份是设定在 filebeat.yml 当中：

• retistry.flush ：预设是 0s，也就是只要 output 成功写出，就会执行 flush 。如果有非常多的 Logs 同时在处理很大量的资料的情境下，太过频繁的写入 Registry 档案会拖慢整个执行的速度，这时就应该将 registry.flush 设定 >0s。
• shutdown_timeout：预设 Filebeat 在关闭程序时，不会等待 publisher 确认 Output 的结果，这样在大量资料不断处理的情况下，会常有机会发生关闭 Filebeat 当下的资料，在重新启动时重覆发送的情况，我们可以设定这个值，让关闭的时候稍微多等待 Output 的结果，以减少重送的情况发生。
• tags 与 fields：这两个值能够有效的帮我们分类资料的来源，善用资料来源的标示与分类，可以帮助我们在後续的资料分析。
• processors：这个功能能让我们透过 Filebeat 所收集的资料，在往後送之前，进行一些简单的加工处理，例如我们想要依照一些条件删掉不需要的 event、使用我们自订义的 ID 栏位，让重覆的资料进入 Elasticsearch 时能够被 deduplicate (去重覆)、把某个 JSON 的字串解析出来并取得当中的值…等。
• queue.disk：如果你透过 Filebeat 在处理的资料量很大，并且希望能够在 Spooler 当中先将较大量的资料进行汇总再往後传送，预设在 memory 当 queue 的配置，可能承受不了太量的资料汇总，这时就可以考虑将 queue 写在 disk 中。又或着是我们透过 Filebeat 要往後传送的资料，非常重视资料的可靠性，同时我们又有指定 flush.min_events 和 flush.timeout 要使用较大量的 queue，这时也会要考虑将 queue 指定到实体的 disk 之中。[4]

实务上的配置技巧 - 切分设定档

由於实务布署上，我们有多台的机器时，相同性质的机器的 filebeat 的配置会是一样的，这时候我们可以将 config 切分出来，也能够让我们在做组态管理时更容易，至於 filebeat 能切分的设定档主要有以下两种：

Input Config

filebeat.config.inputs:
  enabled: true
  path: inputs.d/*.yml

存放在 inputs.d 里面的 yml 档案格式，会定义如下方的例子：

- type: log
  paths:
    - /var/log/mysql.log
  scan_frequency: 10s

- type: log
  paths:
    - /var/log/apache.log
  scan_frequency: 5s

Module Config

filebeat.config.modules:
  enabled: true
  path: ${path.config}/modules.d/*.yml

这里面的档案格式如下：

- module: apache
  access:
    enabled: true
    var.paths: [/var/log/apache2/access.log*]
  error:
    enabled: true
    var.paths: [/var/log/apache2/error.log*]

而建议的 Config 档案管理方式，一般有二种做法：

• 如预设的配置，以 module 名称来切分档案，不同的 module 有各自的 yml 设定档。
• 以服务角色来切分，例如 web server、backend service、DB server…等，并在档案中定义所有该服务使用到的 modules。

其他 Input, Output, Module 的配置

在其他 Input, Output Module 的配置上，在不同的情境下，也都有不同的配置建议设定，由於所支援的部份太多，这边无法一一细谈，会建议大家在使用之前，一定要先阅读过官方文件的资讯，至少先把有哪些设定值看过一遍，再依照情境去判断可能会需要调整的部份。

如果你也是使用 Filebeat 在读取实体的 Log 档案，至少 官方文件 Input - Log 这份的设定你应该要看过，要知道 close_*、scan_frequency、harvester_limit 等配置是做什麽用的，对於效能的调效也会有所帮助。

参考资料

1. 官方文件 - How Filebeat Works
2. 官方文件 - Filebeat Inputs
3. Filebeat 原始码浅析
4. 官方文件 - Filebeat Internal Queue

查看最新 Elasticsearch 或是 Elastic Stack 教育训练资讯: https://training.onedoggo.com
欢迎追踪我的 FB 粉丝页: 乔叔 - Elastic Stack 技术交流
不论是技术分享的文章、公开线上分享、或是实体课程资讯，都会在粉丝页通知大家哦！