Filebeat 日志收集组件介绍

2020-10-22 0 By admin

Filebeat 的可靠性很强,可以保证日志 At least once(至少一次) 的上报,同时也考虑了日志搜集中的各类问题,例如日志断点续读、文件名更改、日志 Truncated 等。
Filebeat 并不依赖于 ElasticSearch,可以单独存在。我们可以单独使用Filebeat进行日志的上报和搜集。
Filebeat 内置了常用的 Output 组件, 例如 kafka、ElasticSearch、redis 等,出于调试考虑,也可以输出到 console 和 file 。我们可以利用现有的 Output 组件,将日志进行上报。当然,我们也可以自定义 Output 组件,让 Filebeat 将日志转发到我们想要的地方。
Filebeat 附带预构建的模块,这些模块包含收集、解析、充实和可视化各种日志文件格式数据所需的配置,每个Filebeat模块由一个或多个文件集组成,这些文件集包含摄取节点管道、Elasticsearch模板、Filebeat勘探者配置和Kibana仪表盘。

一、整体工作原理

Filebeat 由两个主要组件组成:harvester 和 prospector。

1.1、采集器 harvester

主要职责是读取单个文件的内容。读取每个文件,并将内容发送到 the output。 每个文件启动一个 harvester,harvester 负责打开和关闭文件,这意味着在运行时文件描述符保持打开状态。如果文件在读取时被删除或重命名,Filebeat 将继续读取文件。

1.2、查找器 prospector

主要职责是管理 harvester 并找到所有要读取的文件来源。如果输入类型为日志,则查找器将查找路径匹配的所有文件,并为每个文件启动一个 harvester。每个 prospector 都在自己的 Go 协程中运行。
注:Filebeat prospector只能读取本地文件, 没有功能可以连接到远程主机来读取存储的文件或日志。
由以上两个组件一起工作来读取文件(tail file)并将事件数据发送到您指定的输出。

Filebeat 官方提供的架构图
Filebeat 官方提供的架构图

1.3、Filebeat 工作流程

  1. 当启动 Filebeat 程序时,它会启动一个或多个查找器去检测指定的日志目录或文件。
  2. 对于查找器 prospector 找到的每个日志文件,FIlebeat 会启动收集进程 harvester。
  3. 每个 harvester 读取一个日志文件,并将新日志数据发送到后台处理程序,后台处理程序会集合这些事件,最后发送集合的数据到 output 指定的目的地。

1.4、其他组件

除了图中提到的各个组件,整个 filebeat 主要包含以下重要组件:

  1. Crawler:负责管理和启动各个 Input。
  2. Input:负责管理和解析输入源的信息,以及为每个文件启动 Harvester。可由配置文件指定输入源信息。
  3. Pipeline: 负责管理缓存、Harvester 的信息写入以及 Output 的消费等,是 Filebeat 最核心的组件。
  4. Output: 输出源,可由配置文件指定输出源信息。
  5. Registrar:管理记录每个文件处理状态,包括偏移量、文件名等信息。当 Filebeat 启动时,会从 Registrar 恢复文件处理状态。

filebeat 的整个生命周期,几个组件共同协作,完成了日志从采集到上报的整个过程。

二、Filebeat 安装与使用

Filebeat 基于 Go 语言开发无其他依赖,它最大的特点是性能稳定、配置简单、占用系统资源很少,安装使用也非常简单,可访问 Elastic-Beats 官网获取各版本 Filebeat。

2.1、版本下载和安装

因为 Filebeat 各版本之间的差异较大,这里推荐7以上的新版,首先进行下载解压:
tar -zxvf filebeat-7.tar.gz
mv filebeat-7 filebeat
cd filebeat

2.2、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 线程号

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

四、资源限制配置

在Filebeat 服务维护过程中,如果对占用资源要求高的话,可以配置一下参数。

4.1、设置内存的使用

采用文件缓冲限制内存使用:

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

4.2、文件资源优化

filebeat 是贪婪式的采集,只要有日志就会坚持采集完日志,否则就会永久持有文件句柄不“放手”,可设置文件资源配置参数优化:
close_inactive: 1m
#没有新日志多长时间关闭文件句柄,默认5分钟可改短一些
clean_inactive: 72h
#多久清理一次registry文件,默认值为0,运行时间长可能会导致该文件变大带来性能问题。

4.3、CPU资源的设置

CPU最大数量使用限制:
max_procs: 4