3. 采集器层故障（二）：日志文件轮转（Log Rotation）导致的数据丢失或重复采集，配置检查与 inode 追踪

日志文件轮转（Log Rotation）是运维中常见的文件管理策略，用于防止单个日志文件无限增长。然而，轮转操作会改变文件路径、文件名甚至文件 inode，如果采集器（如 Filebeat、Fluent Bit、Logstash）没有正确处理这些变化，就会引发数据丢失或重复采集。本节深入分析轮转场景下的故障根因，并给出基于 inode 的排查方法。

3.1 轮转场景下的数据管道故障模型

日志轮转通常通过 logrotate 工具执行，常见策略包括：

• copytruncate：先复制原文件，再截断原文件（inode 不变）。
• create：重命名原文件，创建同名新文件（inode 改变）。
• compress：轮转后压缩旧文件（文件名改变）。

采集器依赖文件路径或 inode 来追踪读取位置。当轮转策略与采集器追踪机制不匹配时，故障模式如下表所示：

3.2 故障排查：inode 追踪与注册表文件分析

大多数现代采集器（如 Filebeat）使用 注册表文件（registry file） 来持久化记录每个被追踪文件的 inode、设备号、偏移量等信息。当怀疑轮转导致数据丢失或重复时，第一步是检查注册表内容。

3.2.1 检查 Filebeat 注册表

Filebeat 的注册表默认位于 data/registry/filebeat/log.json。使用 jq 解析关键字段：

# 查看注册表中所有活跃条目
jq '.[] | {source: .source, inode: .inode, offset: .offset, state: .state}' \
  /var/lib/filebeat/registry/filebeat/log.json | head -20

输出示例：

{
  "source": "/var/log/app/access.log",
  "inode": 1234567,
  "offset": 1048576,
  "state": "active"
}
{
  "source": "/var/log/app/access.log.1",
  "inode": 1234567,
  "offset": 2097152,
  "state": "active"
}

异常模式识别：

• 数据丢失：注册表中 source 指向旧文件名（如 access.log.1），但 inode 与当前 access.log 的 inode 不同，且 offset 未更新 → 采集器未切换到新文件。
• 重复采集：注册表中出现两个条目，source 分别为 access.log 和 access.log.gz，但 inode 不同 → 压缩文件被当作新文件。

3.2.2 实时 inode 对比命令

在轮转发生后，立即对比文件系统的 inode 与采集器注册表中的 inode：

# 获取当前日志文件的 inode
stat /var/log/app/access.log | grep Inode

# 从注册表中提取对应文件的 inode
jq '.[] | select(.source == "/var/log/app/access.log") | .inode' \
  /var/lib/filebeat/registry/filebeat/log.json

如果两者不一致，说明采集器仍绑定在旧 inode 上，新文件未被追踪。

3.3 配置检查：采集器轮转适配参数

不同采集器提供了专门应对轮转的配置项。以下列出关键参数及推荐值：

3.4 轮转故障排查流程图

下图展示了从发现日志缺失到定位根因的完整排查路径：

3.5 预防性配置清单

为避免轮转导致的数据管道故障，建议在部署阶段完成以下检查：

1. 统一轮转策略：所有日志文件使用 copytruncate 或 create 中的一种，避免混用。
2. 采集器追踪方式对齐：若使用 create，确保采集器配置为文件名追踪（Filebeat 默认使用 inode + 文件名双校验，无需额外配置）。
3. 注册表持久化：将采集器的注册表文件存储在持久化磁盘上，避免容器重启后丢失。
4. 设置合理的 close_inactive：根据日志写入频率调整，避免频繁打开/关闭文件句柄。
5. 启用轮转后延迟：在 logrotate 配置中添加 delaycompress 选项，避免压缩操作与采集器读取冲突。