磁盘写满时日志收集系统常静默丢弃日志，需从磁盘状态（检查实际写入路径及reserved space）、服务行为（查看rsyslog/journald/filebeat等错误日志）、缓冲机制（验证是否真丢弃而非延迟）三方面排查，并通过可控测试确认，再紧急清理与配置限流加固。
日志收集系统（如 rsyslog、fluentd、filebeat、journalctl）在磁盘写满时通常会静默丢弃日志，不报错也不告警，排查需从磁盘状态、服务行为、缓冲机制三方面入手。
确认磁盘空间是否真的耗尽
不要只看 df -h 的根分区，重点检查日志实际写入路径：
- 运行
df -h /var/log /var/lib/rsyslog /var/lib/fluentd /var/lib/filebeat（按实际部署路径补充） - 用
du -sh /var/log/* | sort -hr | head -10找出占用最大的日志目录或归档文件 - 注意：
df显示 100% 但仍有少量 reserved space（默认 5%，root 用户可用），普通用户进程可能已无法写入
检查日志服务是否进入“丢弃模式”
不同服务表现不同，需针对性验证：
-
rsyslog：查看
systemctl status rsyslog，若看到imjournal: journal is not accessible或queue full, dropping message日志，说明缓冲区溢出且磁盘不可写 -
journald：执行
journalctl --disk-usage，若返回Journal file not found或实际用量远低于SystemMaxUse=配置值，可能是自动清理失败或写入被拒；再查journalctl -u systemd-journald | grep -i "dropped\|full\|fail" -
filebeat/fluentd：检查其日志（如
/var/log/filebeat/filebeat），搜索failed to publish events、output is full、write: no space left on device
验证日志是否真被丢弃（而非延迟写入）
避免误判，做一次可控触发测试：
- 清空测试用日志文件（如
> /var/log/test.log），确保其所在分区已满（可临时dd if=/dev/zero of=/var/log/fill bs=1M count=2000占满） - 执行
logger "test-log-$(date +%s)"，然后立即检查：
•tail -n1 /var/log/messages（rsyslog）
•journalctl -n1 | grep "test-log"（journald）
• 对应 filebeat 输出目标（如 ES、kafka）中是否存在该条目 - 若本地日志文件无记录，但上游接收端也缺失，基本确认丢弃发生
快速恢复与长期防护建议
先止损，再加固：
-
紧急清理：删除过期压缩日志（
find /var/log -name "*.gz" -mtime +7 -delete）、清空 journald 归档（journalctl --vacuum-size=200M）、清理 Docker 日志（docker system prune -f若适用） -
限制日志大小：修改
/etc/systemd/journald.conf中SystemMaxUse=500M、RuntimeMaxUse=200M；rsyslog 配置中启用$ActionFileDefaultTemplate+$ActionFileRotateCount -
增加监控项：在 Prometheus + node_exporter 中添加
node_filesystem_avail_bytes{mountpoint="/var/log"} / node_filesystem_size_bytes{mountpoint="/var/log"} 告警
