FileBeat原理与实践指南

一、FileBeat原理

日志采集器有很多，比如Logstash,功能虽然强大，但是它依赖java、在数据量大的时候，Logstash进程会消耗过多的系统资源，这将严重影响业务系统的性能，而filebeat就是一个完美的替代者，它基于Go语言没有任何依赖，配置文件简单，格式明了，同时，filebeat比logstash更加轻量级，所以占用系统资源极少，非常适合安装在生产机器上。这就是推荐使用filebeat来作为日志收集软件的原因。Filebeat可以直接（或者通过Logstash）将数据发送到Elasticsearch、Kafka或者Redis，在那里可以进一步处理和增强数据，然后在Kibana中将其可视化，目前来说Filebeat是 ELK 日志系统在Agent上的第一选择。

Filebeat主要由两个组件构成：prospector（探测器）和harvester（收集器），这两类组件一起协作完成Filebeat的工作。

Filebeat的工作流程如下：当开启Filebeat程序的时候，它会启动一个或多个探测器去检测指定的日志目录或文件，对于探测器找出的每一个日志文件，Filebeat会启动收集进程，每一个收集进程读取一个日志文件的内容，然后将这些日志数据发送到后台处理程序，后台处理程序会集合这些事件，最后发送集合的数据到output指定的目的地。

二、FileBeat安装与使用

Filebeat基于go语言开发无其他依赖，它最大的特点是性能稳定、配置简单、占用系统资源很少，安装使用也非常简单，可访问Elastic-Beats官网获取各版本Filebeat。因为filebeat各版本之间的差异较大，这里推荐7以上的新版，首先进行下载解压：

tar -zxvf filebeat-7.tar.gz
mv filebeat-7 filebeat
cd filebeat

1.FileBeat启停指令：

• 调试模式下采用：终端启动（退出终端或ctrl+c会退出运行）

./filebeat -e -c filebeat.yml

• 线上环境配合error级别使用：以后台守护进程启动启动filebeats

nohup ./filebeat -e -c filebeat.yml &

• 零输出启动（不推荐）：将所有标准输出及标准错误输出到/dev/null空设备，即没有任何输出信息。

nohup ./filebeat -e -c filebeat.yml >/dev/null 2>&1 &  

• 停止运行FileBeat进程

ps -ef | grep filebeat
Kill -9 线程号

2.FileBeat配置文件

FileBeat的配置文件定义了在读取文件的位置，输出流的位置以及相应的性能参数，本实例是以Kafka消息中间件作为缓冲，所有的日志收集器都向Kafka输送日志流，相应的配置项如下，并附配置说明：

$ vim fileat.yml

filebeat.inputs: 
- type: log
  enabled: true
  paths:
    - /wls/applogs/rtlog/app.log
  fields: 
    log_topic: appName
  multiline:
        # pattern for error log, if start with space or cause by 
        pattern: '^[[:space:]]+(at|\.{3})\b|^Caused by:'
        negate:  false
        match:   after

output.kafka:
   enabled: true
   hosts: ["kafka-1:9092","kafka-2:9092"]
   topic: applog
   version: "0.10.2.0"
   compression: gzip

processors:
- drop_fields: 
   fields: ["beat", "input", "source", "offset"]

logging.level: error
name: app-server-ip

• paths:定义了日志文件路径，可以采用模糊匹配模式，如*.log
• fields：topic对应的消息字段或自定义增加的字段。
• output.kafka：filebeat支持多种输出，支持向kafka，logstash，elasticsearch输出数据，此处设置数据输出到kafka。
• enabled：这个启动这个模块。
• topic：指定要发送数据给kafka集群的哪个topic，若指定的topic不存在，则会自动创建此topic。
• version：指定kafka的版本。
• drop_fields：舍弃字段，filebeat会json日志信息，适当舍弃无用字段节省空间资源。
• name：收集日志中对应主机的名字，建议name这里设置为IP，便于区分多台主机的日志信息。

以上参数信息，需要用户个性化修改的主要是：paths，hosts，topic，version和name。

4.异常堆栈的多行合并问题

在收集日志过程中还常常涉及到对于应用中异常堆栈日志的处理，此时有两种方案，一种是在采集是归并，一种是Logstash过滤时归并，更建议在客户端agent上直接实现堆栈的合并，把合并操作的压力在输入源头上进行控制，filebeat合并行的思路有两种，正向和逆向处理。由于filebeat在合并行的时候需要设置negate和match来决定合并动作，意义混淆，简直是一种糟糕的设计，直接附上配置源码和说明便于理解

第一种：符合条件才合并，容易有漏网之鱼
说明：将以空格开头的所有行合并到上一行；并把以Caused by开头的也追加到上一行

   multiline: 
        pattern: '^[[:space:]]+(at|\.{3})\b|^Caused by:'
        negate:  false
        match:   after

negate参数为false，表示“否定参数=false”。multiline多行参数负负得正，表示符合pattern、match条件的行会融入多行之中、成为一条完整日志的中间部分。如果match=after，则以b开头的和前面一行将合并成一条完整日志；如果match=before，则以b开头的和后面一行将合并成一条完整日志。

第二种：不符合条件通通合并，需事先约定
说明：约定一行完整的日志开头必须是以“[”开始，不符合则归并！

   multiline:
        pattern: '^\['
        negate:  true
        match:   after

negate参数为true，表示“否定参数=true”。multiline多行参数为负，表示符合match条件的行是多行的开头，是一条完整日志的开始或结尾。如果match=after，则以b开头的行是一条完整日志的开始，它和后面多个不以b开头的行组成一条完整日志；如果match=before，则以b开头的行是一条完整日志的结束，和前面多个不以b开头的合并成一条完整日志。

最后，如果对FileBeat占用资源的要求比较苛刻，有如下几个参数可以配置：

• 采用文件缓冲限制内存使用：

queue.spool:
  file: 
    path: "tmp/spool.dat"     #缓冲区路径
    size: 512MiB              #缓冲区大小
    page_size: 16KiB          #文件页面大小，采用16kb默认值
  write:
    buffer_size: 10MiB        #写缓冲大小
    flush.timeout: 5s         #写缓冲最旧事件的最长等待时间
    flush.events: 1024        #缓冲事件数量，满足则刷新。

• 文件资源优化，filebeat是贪婪式的采集，只要有日志就会坚持采集完日志，否则就会永久持有文件句柄不“放手”，可设置文件资源配置参数优化：

close_inactive: 1m
#没有新日志多长时间关闭文件句柄，默认5分钟可改短一些
clean_inactive: 72h
#多久清理一次registry文件，默认值为0，运行时间长可能会导致该文件变大带来性能问题。

• CPU最大数量使用限制：

max_procs: 4

三、FileBeat调试

当FileBeat在服务主机采集应用日志并向Kafka输出日志时可以通过两个步骤验证Filebeat的采集输送是否正常：

• 采集验证：终端执行./filebeat -e -c filebeat.yml命令，查看控制台输出，如果服务有异常会直接打印出来并自动停止服务。

• 接收验证：Kafka集群控制台直接消费消息，验证接收到的日志信息。
  Kafka消费命令如下：./kafka-console-consumer.sh --zookeeper zk-1:2181,zk-2:2181,zk-3:2181 --topic app.log

经过FileBeat采集并输出的日志会被Json化，原本的应用日志内容都在message属性中，其余还添加了很多客户端信息，这些重要的字段大都是在配置文件中所配置的，至此可完成FileBeat的服务搭建。

{
        "@timestamp": "2019-05-11T07:55:02.127Z",
        "@metadata": {
                "beat": "filebeat",
                "type": "_doc",
                "version": "7.0.1",
                "topic": "app.log"
        },
        "ecs": {
                "version": "1.0.0"
        },
        "log": {
                "offset": 2661796,
                "file": {
                        "path": "/wls/applogs/rtlog/app.log"
                }
        },
        "message": "05-11 00:10:19.851[DEBUG][http-nio-39545-exec-9] ",
        "fields": {
                "log_topic": "app.log"
        },
        "host": {
                "name": "172.33.12.109"
        },
        "agent": {
                "id": "6a86e9d9-e1e8-4b32-b027-f1c936f66e4f",
                "version": "7.0.1",
                "name": "172.33.12.109",
                "type": "filebeat",
                "ephemeral_id": "8326a240-e9de-44f4-b24d-a1c8d2654e19",
                "hostname": "client-ali"
        }
}

• ElasticSearch或者Kibana验证
  如果已经搭建了ELK平台，可根据上传的日志关键属性，于KB或者ES平台查看是否有日志流输入或者在search框中根据host.name/log_topic关键属性来查看是否有落库。