centos filebeat为何丢数据

在 CentOS 上部署 Filebeat 出现“丢数据”的原因，通常不是 Filebeat 本身 bug，而是配置、系统资源、下游（Elasticsearch/Logstash/Kafka）或文件采集机制导致的。下面按常见原因 → 表现 → 解决办法系统说明。

一、最常见原因（80% 的“丢数据”来自这里）

1. 文件被轮转（log rotate）导致未采集完

现象

日志刚生成就被 logrotate 重命名 / 删除
Filebeat 还没读完

原因

close_inactive / close_timeout 设置不合理
logrotate 使用 copytruncate 或立即 rm

解决

filebeat.inputs:
- type: log
  paths:
    - /var/log/app/*.log
  close_inactive: 1m
  clean_removed: false

logrotate 建议：

copytruncate
notifempty

2. Filebeat 未正常关闭（kill -9 / 宕机）

现象

重启后部分日志没发
registry 文件状态丢失

原因

registry 没刷盘
强制杀进程

解决

不要 kill -9
使用：

systemctl stop filebeat

registry 路径：

/var/lib/filebeat/registry

3. 输出下游拒绝 / 阻塞

常见下游

Elasticsearch（磁盘满、queue满）
Logstash（背压）
Kafka（topic 不存在）

表现

Filebeat 一直重试
看起来“没数据”

查看

journalctl -u filebeat -f

解决

确认下游可用
增加队列：

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

二、Filebeat 自身配置问题

4. 忽略旧文件（ignore_older）

ignore_older: 24h

超过时间的文件直接跳过。

解决

调大或删除该配置

5. 多行日志没合并导致“看起来丢”

如 Java stacktrace：

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

否则异常日志被当新事件，容易误判。

6. exclude 配置误杀

exclude_files: ['.gz$']

可能把正在写的文件排除。

三、CentOS 系统层面原因

7. inode 变化（容器 / 软链）

现象

Docker / K8s 日志
文件替换后 Filebeat 不识别

解决

采集宿主机：

/var/lib/docker/containers/*/*.log

或使用 container input

8. 文件描述符耗尽

ulimit -n

默认可能只有 1024

解决

/etc/security/limits.conf

filebeat soft nofile 65535
filebeat hard nofile 65535

9. 磁盘写满（registry / spool）

/var/lib/filebeat 满
Filebeat 停止工作

解决

df -h

四、如何确认“到底丢没丢”

看 Filebeat 状态

filebeat test output

看 registry

cat /var/lib/filebeat/registry/filebeat/log.json | jq

开启 debug

logging.level: debug

五、推荐生产稳定配置（CentOS）

filebeat.inputs:
- type: log
  paths:
    - /var/log/app/*.log
  ignore_older: 12h
  close_inactive: 5m
  clean_removed: false

queue.mem:
  events: 8192

output.elasticsearch:
  hosts: ["http://es:9200"]

六、总结一句话

CentOS 上 Filebeat “丢数据”90% 不是bug，而是：文件轮转 + 配置不当 + 下游阻塞。

如果你愿意，可以贴：

filebeat.yml
日志类型（Nginx / Java / Docker）
输出方式（ES / Logstash / Kafka）

我可以帮你精确指出是哪一条在丢数据。