Filebeat如何保证在日志文件被切割时依然正确读取文件

我们的日志收集系统使用Filebeat来收集日志文件,部署时并没有多想,只配置了一下监控的日志文件名。上线几个月,日志监控从没出过问题。后来想想其实这里面有很多点需要考虑的,没出问题真是感谢Filebeat默认配置下想的就很周全。

业务系统使用logback作为日志框架。通过查看源码,发现logback日志切割用的是JDK里File#renameTo()方法。如果该方法失败,就再尝试使用复制数据的方式切割日志。查找该方法相关资料得知,只有当源文件和目标目录处于同一个文件系统、同volumn(即windows下的C, D盘)下该方法才会成功,切不会为重命名的后的文件分配新的inode值。也就是说,如果程序里一直保存着该文件的描述符,那么当程序再写日志时,就会向重命名后的文件中写。那么问题来了,filebeat是会一直打开并保存文件描述符的,那么它是怎么得知日志被切割这件事的呢?

如果只用当前文件描述符一路监控到天黑的话,那么当logback把日志重命名后,filebeat仍然会监控重命名后的日志,新创建的日志文件就看不到了。实际上,filebeat是通过close_inactivescan_frequency两个参数(机制)来应对这种情况的:

  • close_inactive
    该参数指定当被监控的文件多长时间没有变化后就关闭文件句柄(file handle)。官方建议将这个参数设置为一个比文件最大更新间隔大的值。比如文件最长5s更新一次,那就设置成1min。默认值为5min.

  • scan_frequency
    该参数指定Filebeat搜索新文件的频率(时间间隔)。当发现新的文件被创建时, Filebeat会为它再启动一个 harvester 进行监控。默认为10s。

综合以上两个机制,当logback完成日志切割后(即重命名),此时老的harvester仍然在监控重命名后的日志文件,但是由于该文件不会再更新,因此会在close_inactive时间后关闭这个文件的 harvester。当scan_frequency时间过后,Filebeat会发现目录中出现了新文件,于是为该文件启动 harvester 进行监控。这样就保证了切割日志时也能不丢不重的传输数据。(不重是通过为每个日志文件保存offset实现的)

你可能感兴趣的:(Filebeat如何保证在日志文件被切割时依然正确读取文件)