Filebeat 并不依赖 tail -f 等外部命令，而是通过定期调用操作系统原生的 stat() 系统调用（如 Linux 下的 os.Stat）获取文件元信息（大小、修改时间、inode 等），比对历史快照来精准识别文件更新、轮转与新增，再由 Harvester 组件增量读取。
filebeat 并不依赖 `tail -f` 等外部命令，而是通过定期调用操作系统原生的 `stat()` 系统调用（如 linux 下的 `os.stat`）获取文件元信息（大小、修改时间、inode 等），比对历史快照来精准识别文件更新、轮转与新增，再由 harvester 组件增量读取。
Filebeat 的文件内容监控机制高度依赖其内部的 Prospector（探针） + Harvester（收割器） 架构。核心逻辑并非实时流式监听（如 inotify 或 kqueue），而是采用基于时间轮询 + 文件状态比对的轻量稳健策略。
工作流程概览
-
周期性扫描（Scan）：
Prospector 按配置项 scan_frequency（默认 10s）定时触发 scan() 方法，遍历所有配置的 paths（支持 glob，如 /var/log/**/*.log）。 -
路径匹配与元信息采集：
对每个 glob 调用 scanGlob()，使用 filepath.Glob() 解析匹配文件列表；对每个匹配文件执行 os.Stat(file) —— 这是关键一步，它返回包括 Size()、ModTime()、Sys().(*syscall.Stat_t).Ino（inode）等核心字段的 os.FileInfo。 -
状态决策（启动/续采 Harvester）：
根据 stat 结果与内存中维护的文件状态快照（prospectorList）对比：- ✅ 新文件：路径未见过，或 inode/device 变化 → 启动新 Harvester；
- ✅ 已有文件更新：Size 增大 或 ModTime 更新 → Harvester 从上次偏移量（offset）继续读取；
- ⚠️ 文件轮转识别：inode 变化但文件名相同（如 app.log → app.log.1）+ Size 归零 → 触发轮转处理逻辑（保留旧 offset，新建 Harvester 处理新文件）。
示例：关键代码逻辑精要（Go）
func (p *ProspectorLog) scanGlob(glob string) {
matches, _ := filepath.Glob(glob)
for _, file := range matches {
fileinfo, _ := os.Stat(file) // ← 核心：获取当前文件元数据
isKnown := p.isKnownFile(file)
if !isKnown {
p.startHarvester(file, fileinfo) // 新文件
} else {
h := p.getHarvester(file)
if h.Stat.Size <h3>注意事项与最佳实践</h3>
- 非实时性：最小延迟 ≈ scan_frequency（默认 10s），若需亚秒级响应，应结合 close_inactive、close_removed 等参数优化 Harvester 生命周期，而非缩短扫描间隔（会增压）；
- 跨平台一致性：os.Stat 在 Linux/macOS/Windows 均可用，但 inode 在 Windows 无意义，Filebeat 会自动降级使用 file path + modification time + size 组合判别；
- 避免误判：确保日志轮转工具（如 logrotate）使用 copytruncate 或 create 时正确设置权限，否则 stat 可能因权限丢失导致 Harvester 异常终止；
- 性能考量：大量小文件场景下，频繁 stat() 仍可能成为瓶颈，此时可启用 ignore_older 过滤陈旧文件，或使用 harvester_buffer_size 调整单次读取缓冲区。
总之，Filebeat 的设计哲学是可靠性优先于绝对实时性——它放弃复杂内核事件监听，转而用可预测、易调试、跨平台的系统调用组合，实现了在高并发日志采集场景下的稳定与可控。
