journal 持久化为什么要先查
排查前先确认 journal 到底有没有落盘：Storage=volatile 时日志只存在内存里，主机一重启就没了；即使已落盘，也要看是否被清理或替换导致断档。这一步直接决定你能拿到多长的日志，以及要不要转向 rsyslog 落盘文件或上游日志采集平台。
基本信息
| 配置项 | /etc/systemd/journald.conf 的 Storage=persistent/volatile/auto |
|---|---|
| 落盘位置 | /var/log/journal/<machine-id>/ |
| 配额 | SystemMaxUse、MaxRetentionSec 控制保留量 |
| 断档判断 | 时间戳跳变、目录被清空、只剩本次启动 |
| 默认行为 | auto：只要 /var/log/journal 存在就持久化 |
| 补救方向 | 上游日志采集平台与 rsyslog 落盘文件 |
典型使用场景
- 排查开始前确认可用的日志范围
- 事件后主机重启过，判断日志是否还在
- 评估是否需要调整日志持久化配置
- 分析断档到底是清理、轮转还是人为造成
- 生产环境加固：确认日志已持久化
- 与其他日志源交叉验证事件时间线
检查落盘与历史启动
检查落盘与历史启动
grep -E '^Storage|^SystemMaxUse|^MaxRetentionSec' /etc/systemd/journald.conf # 持久化与配额
ls -la --time-style=long-iso /var/log/journal/*/ | head # 落盘目录是否存在及体积
journalctl --list-boots --no-pager | tail -n 10 # 可见的历史启动记录
journalctl --disk-usage # 当前占用情况
journalctl -b -1 --no-pager | head -n 20 2>/dev/null # 上一次启动的日志还在不在配置与现象判读
| 配置或现象 | 含义 | 如何判断 |
|---|---|---|
| Storage=persistent | 固定落盘 | 日志可跨重启保留 |
| Storage=volatile | 只存内存 | 重启后丢失，需转向其他日志源 |
| Storage=auto | 有 /var/log/journal 就落盘 | 先看目录再下结论 |
| SystemMaxUse | 占用上限 | 达到上限后旧日志被自动清理 |
| journal 目录时间戳 | 最后写入时间 | 与启动时间不连续即存在断档 |
默认值 auto 不等于关闭：只要 /var/log/journal 目录存在，就是持久化模式，判断前先看目录本身，不要凭默认值猜测。
事件后若发现 Storage=volatile，关键日志已随内存消失：此时必须转向 rsyslog 落盘文件与上游采集平台，别在这台机器上继续找。
journalctl --list-boots 是最快的断档探针：如果只能看到本次启动，要么此前日志已被清理，要么主机确实是第一次在这台设备上运行。