ubuntu filebeat为何丢日志了

Filebeat 在 Ubuntu 上“丢日志”通常不是真的凭空消失，而是采集、发送或配置环节出了问题。下面按最常见原因 → 排查方法 → 解决建议来说明。

一、最常见原因（90% 的情况）

1️⃣ 日志文件被轮转（log rotate）导致漏采

Ubuntu 默认会用 logrotate：

• 文件重命名（access.log → access.log.1）
• 或清空原文件

问题表现

• 日志在轮转瞬间产生
• Filebeat 还没读到就被改名/截断
• 看起来“丢了一部分”

✅ 解决：

filebeat.inputs:
- type: log
  paths:
    - /var/log/app/*.log
  close_inactive: 5m
  scan_frequency: 10s
  tail_files: false

并确认 logrotate 配置合理（不要频繁 copytruncate）。

2️⃣ Filebeat registry 文件异常（最隐蔽）

Filebeat 用 registry 记录“读到哪了”：

/var/lib/filebeat/registry

问题表现

• 重启后重复或丢失
• 某些文件不再读取

✅ 排查：

ls -l /var/lib/filebeat/

✅ 解决：

• 不要手动删除 registry
• 如必须重置，先停服务：

systemctl stop filebeat
rm -f /var/lib/filebeat/registry
systemctl start filebeat

3️⃣ 输出端失败（ES / Kafka / Logstash）

如果输出失败，Filebeat 会缓存但不一定无限等。

现象

• 日志没进 ES
• Filebeat 日志有 connection refused / timeout

✅ 查看：

journalctl -u filebeat -f

✅ 配置示例（ES）：

output.elasticsearch:
  hosts: ["http://localhost:9200"]
  bulk_max_size: 512

4️⃣ 文件被删除或 inode 变化

Filebeat 依赖 inode + device

问题场景

• 日志被 rm 后重建
• 容器/临时目录
• NFS / 网络盘

✅ 建议：

• 不要采集临时文件
• 容器日志走 stdout + docker input

5️⃣ 权限问题（Ubuntu 常见）

Filebeat 默认用户：filebeat

sudo -u filebeat cat /var/log/app/app.log

如果失败 → 权限不足

✅ 解决：

chmod 644 /var/log/app/*.log

或修改 systemd：

User=root

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

# 1. 服务状态
systemctl status filebeat

# 2. 实时日志
journalctl -u filebeat -f

# 3. 配置文件是否正确
filebeat test config

# 4. 输入是否生效
filebeat test output

# 5. registry 状态
ls -l /var/lib/filebeat/

三、如何确认“是不是真的丢了”

在 Filebeat 配置中开启调试：

logging.level: debug

观察：

• Harvester started
• Publish event

四、如果你愿意，我可以更精准定位

你可以补充：

1. Ubuntu 版本
2. Filebeat 版本
3. 日志类型（Nginx / 自定义 / Docker）
4. 输出目标（ES / Kafka / Logstash）
5. 是否使用了 logrotate

我可以直接帮你改配置。