为什么使用FileBeat？
日志采集器有很多，比如Logstash，虽然Logstash的功能强大，但是它依赖java并且在数据量大的时候进程会消耗过多的系统资源，会严重影响业务系统的性能。
而filebeat就是一个完美的替代者，它基于Go语言没有任何依赖，配置文件简单。同时，filebeat比logstash更加轻量级，所以占用系统资源极少，非常适合安装在生产机器上。
Filebeat可以直接将数据发送到Elasticsearch、Kafka或者Redis，在那里可以进一步处理和增强数据，然后在Kibana中将其可视化，目前来说Filebeat是 ELK 日志系统在Agent上的第一选择。
Filebeat主要组件
filebeat主要由两个组件构成prospector（探测器）和harvester（收集器），这两类组件一起协作完成Filebeat的工作。
Filebeat的工作流程
当开启Filebeat程序的时候，它会启动一个或多个探测器去检测指定的日志目录或文件。对于探测器找出的每一个日志文件，Filebeat会启动收集进程，每一个收集进程读取一个日志文件的内容，然后将这些日志数据发送到后台处理程序，后台处理程序会集合这些事件，最后发送集合的数据到output指定的目的地。
FileBeat安装与使用
Filebeat基于go语言开发无其他依赖，它最大的特点是性能稳定、配置简单、占用系统资源很少，安装使用也非常简单。
tar -zxvf filebeat-7.tar.gz
mv filebeat-7 filebeat
cd filebeat
FileBeat启停指令
./filebeat -e -c filebeat.yml
ps -ef | grep filebeat
Kill -9 线程号
FileBeat配置文件
FileBeat的配置文件定义了在读取文件的位置，输出流的位置以及相应的性能参数
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，便于区分多台主机的日志信息。
异常堆栈的多行合并问题
在收集日志过程中还常常涉及到对于应用中异常堆栈日志的处理，此时有两种方案，一种是在采集是归并，一种是Logstash过滤时归并，更建议在客户端agent上直接实现堆栈的合并，把合并操作的压力在输入源头上进行控制，filebeat合并行的思路有两种，正向和逆向处理。由于filebeat在合并行的时候需要设置negate和match来决定合并动作，意义混淆，简直是一种糟糕的设计，直接附上配置源码和说明便于理解
符合条件才合并（容易遗漏日志）
将以空格开头的所有行合并到上一行；并把以Caused by开头的也追加到上一行
multiline:
pattern: '^[[:space:]]+(at|\.{3})\b|^Caused by:'
negate: false
match: after
negate参数为false，表示“否定参数=false”。表示符合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开头的合并成一条完整日志。
采用文件缓冲限制内存使用
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