filebeat作为日志采集客户端，相比较于java编写的fluent，有着低功耗的特性。但在一些极端情况下，忽视filebeat的一些特性配置，可能会带来灾难。之前发过一篇，今天再说下filebeat占用文件句柄、耗费主机磁盘甚至导致磁盘满的案例。

案例1: 某某通信日志系统建设

案例描述：通信公司A日志量很大，需要搭建一套自己的日志管理系统，方式是基于ELK做，日志采集agent使用filebeat(5.3.2)。系统数据规模是400+esc，日增2T。主机端部署了filebeat后，12小时内所有主机触发磁盘使用率告警。排查后发现，filebeat持有大量被deleted的文件句柄不释放，把filebeat进程停掉后磁盘告警恢复，被占用的deleted文件句柄被释放。故障现象见下图：

排查过程：

1.检查filebeat日志，发现日志里打了大量的io timeout，表明日志传输受阻，可能日志的生产速度>>采集速度；

2.检查filebeat的registry文件，发现registry里累积了超过1000+没有传输完成的文件；

3.检查所采集文件的滚动策略，约10s钟滚动切换一次，test.log->test.20180816.log;

4.发现宿主机配置crontab每分钟清理所有已被滚动不再更新的日志如test.20180816.log;

结论：

filebeat所采集的日志量大切滚动迅速，filebeat未能及时发送所采集的日志，未传输完成的日志文件的句柄被filebeat长期持有直到传输完成，如此以来原有crontab清理日志的机制失效，加上宿主机的磁盘本来就不富裕，累积一定事件后触发磁盘使用率告警。

根因分析：

默认配置下filebeat对日志的采集是贪心的，只要发现了日志就会坚持把日志采集完，否则会永久持有文件句柄不会“放手”，即使文件被删除。

解决方案：

1. 优化filebeat的配置项, 涉及到的filebeat配置项如下：

### State options # Files for the modification data is older then clean_inactive the state from the registry is removed # By default this is disabled. #clean_inactive: 0 # Removes the state for file which cannot be found on disk anymore immediately #clean_removed: true # Close timeout closes the harvester after the predefined time. # This is independent if the harvester did finish reading the file or not. # By default this option is disabled. # Note: Potential data loss. Make sure to read and understand the docs for this option. #close_timeout: 0 # Defines if prospectors is enabled #enabled: true

（1）close_inactive: 1m

       没有新日志采集后多长时间关闭文件句柄，默认5分钟，设置成1分钟，加快文件句柄关闭；

（2）close_timeout: 3h

       传输了3h后荏没有传输完成的话就强行关闭文件句柄，这个配置项是解决以上案例问题的key point；

       注意了，开了这个配置项旨在避免以上案例的问题，但是有丢数据的风险哦。鱼与熊掌不可兼得也。

（3）clean_inactive: 72h

        这个配置项也应该配置上，默认值是0表示不清理，不清理的意思是采集过的文件描述在registry文件里永不清理，在运行一段时间后，registry会变大，可能会带来问题。

（4）ignore_older: 70h

        设置了clean_inactive后就需要设置ignore_older，且要保证ignore_older < clean_inactive

完美收官！下期再见！