日志切割后 Filebeat 又把旧文件读了一遍 重复数据从哪来

日志按小时切割后，Kibana 里同一时间段的记录数比业务计数多出 18%，重复的条目全部来自切割前的旧文件。碰到这种情况，我一般先确认改动有没有真的生效。

原因不复杂，切割方式是 rename 加新建，Filebeat 的文件标识基于 inode，rename 后旧文件被当成新文件从头再读一遍。registry 里记的 offset 和新文件对不上。

「日志重复采集」相关的日志我一般连着看前后五分钟，单看一条报错经常判断不出是哪一步失败。别只看报错的最后一行，往上看几行，真正的起因通常在上面。

filebeat.inputs:
  - type: log
    paths: ["/var/log/app/*.log"]
    close_renamed: true
    clean_removed: true

同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。

具体做法是，切割后保持文件名不变 用 truncate 方式清空；Filebeat 开启 close_renamed 和 clean_removed；确认 registry 里每个文件的 inode 和 offset 都正确；用一次切割验证条数没有翻倍。

最后用这个标准收尾，切割后同一小时的记录数等于业务计数 不再重复入库。