这条路径解决什么
日志突然没有新内容，或者历史记录不见了，原因通常在五个环节：写入方（应用还开着旧文件）、轮转（logrotate 换了 inode）、空间（磁盘满导致写失败）、journal 配置（未持久化或做过头）、以及人为操作。排查顺序是从文件现状开始，一路向下确认，避免一上来就怀疑被入侵。
基本信息
| 适用场景 | 日志文件停在某时刻、内容变空或历史缺失 |
|---|---|
| 排查顺序 | 文件现状 → 轮转记录 → 磁盘空间 → journal 配置 → 审计痕迹 |
| 关键工具 | ls、stat、lsof、logrotate 状态文件、journalctl、df |
| 核心判据 | inode 是否变化、进程是否仍持有旧 inode、磁盘是否满 |
| 恢复目标 | 先恢复日志链路，再评估丢失范围与影响 |
典型使用场景
- 应用日志不再增长：确认是应用停止写入还是写到了别处
- 日志文件变小：怀疑被轮转或被人为截断
- 归档缺失：确认 logrotate 是否执行成功
- 整机日志异常：区分是应用侧还是 journald 侧问题
- 事后取证：确认日志链路本身是否可信
第 1 步：文件现状
第 1 步：文件现状
ls -l --time-style=long-iso /var/log/myapp/ # 大小与时间对比
stat /var/log/myapp/app.log # 看 inode 与三个时间戳
lsof /var/log/myapp/app.log # 谁还持有这个 inode
lsof +L1 2>/dev/null | grep myapp # 找出已被删除但仍被持有的日志第 2 步：轮转与空间
第 2 步：轮转与空间
cat /var/lib/logrotate/logrotate.status 2>/dev/null | tail # 上次轮转时间
grep -r myapp /etc/logrotate.d/ | head # 轮转策略
ls -lh /var/log/myapp/ | head # 归档文件是否在
df -h /var # 文件系统是否写满journal 侧检查
journal 侧检查
journalctl --disk-usage # journal 占用
journalctl --verify 2>&1 | tail -n 5 # 归档完整性
journalctl -u systemd-journald -n 30 --no-pager
ls -l /var/log/journal/ 2>/dev/null | head # 是否存在（未持久化时目录不存在）断档形态与原因
| 现象 | 常见原因 | 处置 |
|---|---|---|
| 文件大小不再增长 | 进程仍持有被轮转的旧 inode | 重启或重载应用，或把策略改为 copytruncate |
| 文件突然变空 | 被人为截断，或应用自行截断 | 结合审计记录确认，必要时用备份比对 |
| 归档文件缺失 | logrotate 未执行或执行失败 | 检查定时任务与 logrotate 状态文件 |
| 写入直接报错 | 磁盘写满或配额用尽 | 清理或扩容，并确认服务已恢复正常写入 |
| journal 无记录 | 未持久化或轮转参数过于激进 | 检查 journald 配置与持久化目录 |
先分清日志写向（journal、文本文件还是远端收集）再逐段验证。最常见的原因其实是磁盘满或轮转后未通知应用：应用继续往已改名的 inode 写，新的日志文件自然一直是空的。
如果怀疑日志被有意清除，注意人为截断（例如用重定向清空）只改变文件内容与时间戳，不会留下明显痕迹。这类判断要结合审计记录（如 auditd、登录记录、命令历史）与备份比对，不能只凭单个文件的时间戳下结论。