在 Debian 上运行 Filebeat 出现“丢日志”的问题,通常不是真的“凭空丢失”,而是配置、系统或运行环境导致部分日志未被采集或发送。下面按常见原因 → 排查方法 → 解决建议来说明。
Debian 默认用 logrotate,常见行为:
app.log → app.log.1)问题点:
✅ 解决:
filebeat.inputs:
- type: log
paths:
- /var/log/app/*.log
scan_frequency: 1s
close_inactive: 1h
clean_inactive: 72h
并确保 logrotate 使用 copytruncate 或 Filebeat 能感知新文件。
Debian 上 Filebeat 通常由 systemd 管理:
systemctl status filebeat
journalctl -u filebeat -n 100
常见问题:
✅ 解决:
systemctl enable filebeat
systemctl restart filebeat
Filebeat 是异步发送的:
检查:
filebeat test output
常见错误:
✅ 解决:
output.elasticsearch:
hosts: ["https://es:9200"]
username: filebeat
password: xxx
并开启:
queue.spool: true
配置中可能误伤:
exclude_files: ['.gz$']
或:
harvester_limit: 10
✅ 解决:
exclude_filesharvester_limitclose_inactive: 5m
如果日志 10 分钟才写一次,就可能被关掉再打开,offset 可能异常。
✅ 建议:
close_inactive: 1h
路径:
/var/lib/filebeat/registry
异常会导致:
✅ 解决(谨慎):
systemctl stop filebeat
mv /var/lib/filebeat/registry /var/lib/filebeat/registry.bak
systemctl start filebeat
⚠️ 会重新采集所有日志
df -h
Filebeat:
cat /proc/sys/fs/inotify/max_user_watches
✅ 解决:
echo 524288 > /proc/sys/fs/inotify/max_user_watches
# 1. 状态
systemctl status filebeat
# 2. 日志
journalctl -u filebeat -n 200
# 3. 配置校验
filebeat test config
filebeat test output
# 4. 文件是否在被读
ls -l /var/lib/filebeat/registry
# 5. 磁盘
df -h
你可以贴出:
filebeat.yml(敏感信息可打码)我可以直接帮你定位是哪一类丢日志。