Linux服务器在长时间运行过程中，日志文件承担着故障排查、安全审计和行为追溯的核心职责。然而不少运维人员会在某次事故复盘时发现，关键时间段的系统日志或应用日志完全空白。这种日志丢失并非总是被删除，更多是采集链路在特定条件下中断。本文从故障定位、服务配置修复以及架构级冗余三个维度，系统说明如何找回丢失的日志并构建防丢机制。
一、日志丢失的常见根因与现场排查手段
要解决问题，先得弄清日志去哪了。最常见的情况是/var/log所在文件系统被写满。rsyslog或syslog-ng在无法写入目标文件时，默认行为不是崩溃而是丢弃消息，且仅在极其详细的调试日志里留下线索。使用df -h查看各挂载点使用率，若发现/var或/分区占用百分百，基本可判定为空间耗尽型丢失。
另一类隐蔽原因是日志文件被logrotate切割后，原进程仍持有旧文件描述符。比如管理员手动删除了messages-20240101之类的历史文件，但守护进程没收到重开信号，就会继续往已被unlink却仍被占用的inode写数据。此时用lsof | grep deleted能看到大量标记为deleted却大小持续增长的文件。通过kill -HUP $(cat /var/run/rsyslogd.pid)让进程重新打开日志文件，新数据便会正常落盘。
还有一部分丢失源于时间漂移与模板错误。当rsyslog的模板里动态路径含有不存在的目录，且未配置dynaFileCacheSize与自动创建，消息会进入错误队列后被丢弃。排查时应临时将$DebugLevel设为2并观察/var/log/rsyslog.debug，确认每条info级消息的落点。
二、利用rsyslog机制恢复并加固本地采集
确认根因后，第一步是恢复服务可用性。若因磁盘满，先清理或扩容，然后重启rsyslog：systemctl restart rsyslog。对于已被删除但占用的文件，除了HUP信号，也可利用copytruncate方式的logrotate策略，避免重命名造成的描述符错位。以下配置示范了安全的切割写法：
/var/log/myapp/*.log {
daily
missingok
rotate 14
compress
delaycompress
copytruncate
notifempty
size 100M
}
上面这段配置中，copytruncate先拷贝再清空原文件，进程始终写同一inode，不会因重命名而丢失。同时建议为日志单独划分分区，例如将/var/log挂到独立磁盘，避免业务数据把系统日志挤掉。在rsyslog主配置中，可显式限制队列大小并开启持久化：
$WorkDirectory /var/spool/rsyslog $ActionQueueType LinkedList $ActionQueueFileName appqa $ActionResumeRetryCount -1 $ActionQueueSaveOnShutdown on
上述指令让rsyslog在目标不可写时把消息存入磁盘队列，待恢复后重发，从机制上杜绝静默丢日志。配合imfile模块还能把业务自己写的文本日志统一收编，防止应用绕过syslog造成审计盲区。
三、构建异地冗余与监控闭环防止再次丢失
单机防护仍可能因磁盘损坏或误删而失效，因此异地冗余是必选项。rsyslog原生支持将日志同时发往远程syslog服务器，配置极为简单：
*.* @@logserver.ipipp.com:514 *.* /var/log/local-bak.log
上面第一行把全部日志通过TCP发到中央日志节点，第二行保留本地副本。即便本地/var/log故障，远端依旧完整。生产环境应再叠加监控：用Prometheus的node_exporter采集node_filesystem_avail_bytes，对/var/log挂载点设告警；并定时用logcheck或自写脚本比对昨日同时段日志行数，突变超过阈值即通知值班人。
从架构视角看，日志防丢本质是「采集不丢、传输不丢、存储不丢」三段保障。采集端靠队列与HUP信号修复，传输端靠TCP加本地缓存，存储端靠独立盘加远程副本。只有把这三层都做成默认开启，才能说真正解决了Linux服务器日志丢失问题，而不是每次出事再手工救火。