使用Filebeat从Airflow海量复杂目录结构采集日志到Logstash问题咨询

1. Filebeat输入路径遍历逻辑 #

Filebeat的路径扫描分为两个阶段，底层基于Go语言原生filepath.Glob实现，和通用glob工具逻辑有差异：

• 初始全量扫描：进程启动时，会对inputs.paths配置的glob规则覆盖的所有目录做一次全量遍历，匹配符合规则的文件并注册到采集队列
• 增量扫描：完成初始扫描后，按照scan_frequency配置的周期（默认10s）只扫描新增的目录、文件，已经被registry记录过的文件不会重复触发目录遍历
  如果你的路径规则配置为深层递归模式（例如<LOG_PATH>/*/*/*/*/*.log），初始扫描阶段需要拉取所有层级目录的元数据，这一步的性能瓶颈主要取决于底层存储的元数据响应速度，共享存储场景下延迟会显著高于本地磁盘。

2. 遍历性能与Python glob的差异 #

两者性能差距非常大，不会出现Python脚本无报错终止的问题：

• Go的filepath.Glob为编译型原生实现，没有Python的GIL开销，且采用流式迭代返回匹配路径，不会像Python glob一样将全量匹配结果一次性加载到内存，内存占用低1~2个数量级
• 你之前遇到的Python脚本被终止，基本是内存溢出导致的OOM kill，Filebeat只要配置合理，不会出现同类问题。仅当全量匹配的文件数量超过千万级且未做任何扫描优化时，才有可能触发OOM，该场景可以通过配置调整规避。

3. 共享卷场景下的采集支撑能力 #

Filebeat完全可以支撑日均30万新增文件的采集需求，但是需要针对Airflow日志的目录特征做针对性配置优化：

• 缩小扫描范围：不要配置全量深层glob规则，利用Airflow日志按EXECUTION_DATE分目录的特征，仅匹配最近N天的目录，例如规则可以写为<LOG_PATH>/*/*/*/2024-05-*/*.log，动态裁剪不需要扫描的历史目录，从根源降低遍历压力
• 调整扫描参数：将scan_frequency调整为30s~1min，降低扫描频率；关闭不必要的symlinks扫描、recursive_glob递归规则，减少无效IO
• 共享存储优化：共享卷挂载时开启元数据缓存，例如NFS挂载时添加lookupcache=positive参数，将目录元数据缓存到本地，大幅降低元数据请求延迟
• 实例拆分：如果单实例压力过大，可以按STREAM或WORKFLOW维度拆分多个Filebeat实例，每个实例仅负责一部分目录的采集，分散扫描压力

内容的提问来源于stack exchange，提问作者Luka Klarić