centos filebeat为何丢日志

在 CentOS 上 Filebeat 丢日志 是常见问题，通常不是 Filebeat 本身“坏掉”，而是配置、系统资源或采集方式不匹配导致的。下面按最常见原因 → 排查方式 → 解决办法给你系统总结。

一、最常见原因汇总

1️⃣ 日志轮转（logrotate）导致丢日志（最高频）

现象

日志被 logrotate 重命名 / 删除
Filebeat 正在读旧 inode
新文件未被采集或采集重复/丢失

典型场景

app.log → app.log.1

解决

使用 logrotate 的 copytruncate 或
Filebeat 配置支持轮转：

filebeat.inputs:
- type: log
  paths:
    - /var/log/app/*.log
  close_inactive: 5m
  clean_inactive: 72h
  ignore_older: 24h

✅ 推荐：不要依赖 inode，使用通配路径 + close_renamed

2️⃣ Filebeat 还没读完，文件就被删除

现象

临时日志、短期日志
文件存在时间 < scan_frequency

解决

scan_frequency: 1s

或避免采集极短生命周期文件。

3️⃣ registry 文件异常（断点丢失）

位置

/var/lib/filebeat/registry/

问题

registry 被清理
容器/虚拟机重启后 registry 丢失
权限错误

排查

ls -l /var/lib/filebeat/registry

解决

不要删除 registry
确保目录权限：

chown -R filebeat:filebeat /var/lib/filebeat

4️⃣ 输出阻塞（ES / Kafka / Logstash 写不进去）

现象

Filebeat 停止采集
队列满
日志堆积或丢弃

排查

filebeat test output
journalctl -u filebeat

解决

增加队列：

queue.mem:
  events: 4096
  flush.min_events: 512

或启用磁盘队列：

queue.disk:
  path: /var/lib/filebeat/diskqueue
  max_size: 10GB

5️⃣ 文件权限问题（CentOS SELinux）

CentOS 特有坑

现象

Filebeat 启动正常
部分日志读不到

排查

getenforce
ls -Z /var/log/app/

解决

setsebool -P filebeat_read_logs on

或临时测试：

setenforce 0

6️⃣ 多行日志被错误切割

现象

看起来“丢了一部分日志”
实际是被当新事件截断

解决

multiline.pattern: '^\['
multiline.negate: true
multiline.match: after

7️⃣ 文件太多 / 通配太广

问题

文件数 > 系统限制
Filebeat 放弃部分文件

排查

cat /proc/sys/fs/file-max
ulimit -n

解决

max_procs: 4

二、快速自查清单（建议按顺序）

# 1. 看日志
journalctl -u filebeat -f

# 2. 测试配置
filebeat test config
filebeat test output

# 3. 看 registry
ls -l /var/lib/filebeat/registry

# 4. 看文件权限
ls -l /var/log/xxx

# 5. 看是否 SELinux
getenforce

三、如果你愿意，我可以更精准帮你

你可以贴出：

filebeat.yml 相关配置
日志路径 & 是否 logrotate
输出目标（ES / Kafka / Logstash）
CentOS 版本 & Filebeat 版本

我可以直接帮你定位是哪一类丢日志，并给最小改动方案。