日志缺失排查

摘要：日志查不到时不要一上来就重启采集 agent。日志链路有五个环节，任一处断开都会导致"看不见"。本文从最靠近应用的一端开始逐段验证，快速定位断点。

适用环境

systemctl is-active filebeat fluent-bit rsyslog 2>/dev/null
ls -l /var/log/app/ | head
df -h /var/log

排障步骤

第 1 步：确认应用真的输出了日志

# 直接看标准输出（容器场景）
kubectl logs <pod> -n <ns> --tail=20
# 手工触发一次可观测行为，再确认是否有新日志
curl -sS http://127.0.0.1:8080/health && tail -5 /var/log/app/app.log

第 2 步：确认文件确实在写入

ls -l --time-style=full-iso /var/log/app/
stat /var/log/app/app.log | grep -i modify
wc -l /var/log/app/app.log

文件修改时间停滞说明应用侧就没在写（日志级别、输出目标配置错误）。

第 3 步：检查轮转是否破坏了句柄

cat /etc/logrotate.d/app 2>/dev/null
ls -l /proc/<PID>/fd 2>/dev/null | grep -i 'log\|deleted'

logrotate 后 inode 变化导致采集中断

默认 create 方式轮转会新建文件，应用若仍持有旧 inode 句柄，日志会写进已删除文件。应使用 copytruncate 或让应用支持重新打开日志。

第 4 步：检查采集 agent 状态与位点

systemctl status filebeat --no-pager 2>/dev/null
systemctl status fluent-bit --no-pager 2>/dev/null
journalctl -u filebeat -S -30min --no-pager | tail -30

关注 agent 日志中的 registry/offset 是否正常推进，以及是否有发送失败、队列积压的报错。

第 5 步：检查磁盘与队列

df -h /var/lib/filebeat /var/log 2>/dev/null
du -sh /var/lib/filebeat/queue 2>/dev/null

采集限流会静默丢日志

磁盘满或下游不可用时，agent 常按策略丢弃。这类丢失不会报错到业务日志，只能从 agent 自身日志中发现。

第 6 步：核对时间范围与索引

date
ls -l --time-style=full-iso /var/log/app/ | tail -5
curl -sS 'http://<es>:9200/_cat/indices?v' 2>/dev/null | head -10

时区不一致会造成"查不到"

容器默认 UTC 而查询按本地时间，日志实际落在另一个时间段。核对时间戳时务必统一时区。

验证

logger -t logtest "check $(date -Iseconds)"
journalctl -t logtest --no-pager | tail -3
tail -f /var/log/app/app.log

常见坑

多行堆栈被切成多条

Java 异常堆栈未按多行规则合并，搜索时只能看到第一行，误以为日志缺失。

容器 stdout 与文件双写导致重复或丢失

同时配置两种输出方式时，采集规则可能只覆盖其一，或产生重复计费。

只看最近 N 分钟

采集与索引存在延迟，刚发生的日志可能几十秒后才可查，不要据此判定丢失。

删除采集位点文件强制重采

清除 registry 会导致全量重传，产生数倍流量与重复数据，可能压垮日志平台。应仅在确认必要时操作。

参考资料

• Fluent Bit Documentation
• Filebeat Reference
• journalctl(1) manual page
• Grafana Loki Documentation