filebeat 相关问题清单¶

1.日志文件是如何被发现又是如何被采集的？¶

根据配置获取匹配的日志文件,采用linux glob的规则进行匹配。然后会经过复杂的过滤，可以配置exclude_files忽略文件，还可以配置ignore_older 文件修改时间超过设定值的也不会被匹配。对于文件进行处理，获取文件的状态，同时在已经存在的状态进行对比，如果相同就不会开启新的协程,如果是新的状态就开启一个新的协程。每个input 对象创建时会从register中读取文件状态(offset),对于每一个匹配到的文件都会开启一个新的harvester进行读取。每个harvester都有一个相对应的goroutine

2.如何确保日志采集发送到远程的存储中，不丢失一条数据？¶

Ack 机制，当 Output Publish 成功之后会调用 ACK，最终 Registrar 会收到 ACK，并修改偏移量。 At least once 的上报，但并不保证 Exactly once, 因此一条数据可能会被上报多次，

3.如果挂掉，下次采集如何确保从上次的状态开始而不会重新采集所有日志？¶

记录偏移量

4.不同的文件要能输入到不同的index¶

通过配置参数可以实现

5.出现错误的多行日志要能够作为一个整体进行输入¶

通过配置参数可以实现

6.配置文件要能够动态加载¶

支持reload input配置，module配置，但reload的机制只有定时更新。

7.读取日志文件与写文件会不会冲突？¶

(当前情况是多进程写，如果需要收集日志则再加上多进程读) 当前python环境使用concurrent-log-handler包，这个包使用portalocker 来进行加锁操作， clh 包会自动创建.lock 文件,在写入文件后会释放锁。在获取锁时会尝试获取锁10次，如果没有获得报错。获得锁后会一个excluesive_lock。

8.filebeat 持续运行，配置es index名称为日期格式，会自动改变吗？¶

(即昨天收集的日志 index是昨天，今天收集的日志index是今天) 如果有新数据，会自动生成新的index,index 会包含当天的日志(如果在index 中配置了使用日期格式)

9.根据日志的等级进行过滤¶

10.解析出时间戳，并替换默认的@timestamp字段，并且保证时区为中国时间¶

11.解析出日志级别，作为一个单独的字段，便于检索¶

7.6.2 版本可实现，通过配置 processors.dissect 6.4.0 版本可实现，通过配置 processors.dissect(同时兼容6.1.4版elasticsearch)

12.每一行日志中去除已经解析的时间戳和日志字段¶

13.filebeat 性能调优¶

1.每个日志生产环境生产的日志大小,爆发量都不一样, 要根据自己的日志特点设定合适的event值;什么叫合适,至少能避免内存>200MB的灾难; 2.在不知道日志实际情况(单条大小,爆发量), 务必把event设置上,建议128或者256; 合理的配置日志文件的匹配规则，是否因为通配符的原因，造成同时监控数量巨大的文件，这种情况3.应该避免用通配符监控无用的文件。 4.规范日志，限制单行日志大小，是否文件的单行内容巨大，确定是否需要改造文件内容，或者将其过滤 5.限制cpu