1.问题背景：
实际采集过程中可能会遇到要采集的文件在某一刻文件名发生变化的情况，比如filebeat采集文件名为a.log，五分钟后变为a.log.2022-04-08-15-01，同时产生新的a.log文件，此种情况在log4j配置产生日志文件比较常见。或者日志文件名一直随着时间变动改变，现在文件名为a-2022-04-08-15-01.log，三分钟后变为a-2022-04-08-15-04.log。
2.问题产生：
发生此种问题时，第一直觉是用正则匹配来解决，很巧，filebeat支持此种方式解决这种问题，并为每一个文件分配一个harvester线程来监听，但是问题是假如正则要匹配的文件数量很多，且仅配置了正则表达式来匹配要采集的文件。那么过多的harvester就会 消耗大量的cpu资源来做无谓的监听，因为真正需要监听的文件可能只有两个。如下配置，当要采集的文件过多时会大量消耗cpu资源。
filebeat.inputs:
- type: log
enabled: true
paths:
- /task/a.log.*
encoding: plain
3.解决方法：
参数说明：
scan_frequency: 扫描频率
harvester_limit: 打开监听文件的数量，默认为0，不限制。
close_*:配置选项用于在特定标准或时间之后关闭harvester
close_inactive:
当读取文件最后一行结束后，开始计时，在指定时间范围内文件没变化，关闭harvester，默认5m;
如果关闭的文件发生变化，一个新的harverster将在scan_frequency运行后被启动
close_eof:
close_eof 如果读取到了EOF(即文件末尾)，是否要结束读取。如果为true，则读取到文件末尾就结束读取，否则Harvester将会继续工作。默认只为false。
harvester_limit + close_inactive + close_eof（可以忽略）
close_inactive 决定了最长没有读到新消息的时长，默认为 5m(即五分钟)。如果超过了 close_inactive 规定的时间依然没有新消息，则 Harvester 退出。
harvester_limit 决定了监听日志数量，如果旧的日志在close_inactive设置的时间范围内无变化，则关闭Harvester，同时新启动一个harvester，保持harvester_limit数量。
最终配置如下：
filebeat.inputs:
- type: log
enabled: true
paths:
- /task/a.log.*
encoding: plain
harvester_limit: 2
close_inactive: 2h
经测试有效：
此时a-2022-04-11.log日志还未获取，等5min后待b.log 的 harvester服务失效后开始读取。
以下截图为5min后生效日志 以及kafka消费信息
参考地址：
Log input | Filebeat Reference [6.5] | Elastic
