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关键属性来查看是否有落库。

推荐阅读更多精彩内容