journalctl 按容量和时间清理归档日志怎么组合

journalctl 可以把容量与时间限制放在同一次调用中：例如同时保留最近 14 天，并把归档日志控制在 1 GiB 以内，可使用 --vacuum-time=14d --vacuum-size=1G。两个条件会共同约束归档 journal 文件；只要某一限制还没有满足，工具就可能继续从最旧的归档文件开始删除。

官方文档：https://www.freedesktop.org/software/systemd/man/latest/journalctl.html

清理前先保护两类资产

我第一次组合这两个参数，是因为一台小磁盘服务器既出现了空间告警，又承担故障追溯。只看容量，很容易把历史压缩得太短；只看时间，日志量突然上升时又可能顶满磁盘。真正要同时保护的是两类资产：一类是可用磁盘，另一类是排障和审计需要的历史窗口。

因此，先不要照抄别人机器上的 500M 或 7d。应先确定业务至少需要保留多久，再从磁盘预算中分配 journal 可用容量。若有合规或审计要求，保留期限必须以组织制度为准，不能把一条运维命令当成法律结论。

先记录当前 journal 占用

我习惯在清理前先保存当前占用值，这能避免清理后只凭感觉判断是否生效。查看系统 journal 通常需要相应权限：

# 记录活动文件与归档文件合计占用，作为清理前基线
sudo journalctl --disk-usage

这里有一个容易忽略的细节：--disk-usage 显示的是活动 journal 文件与归档 journal 文件的合计，而 vacuum 操作只删除归档文件。后面即使指定 --vacuum-size=1G，清理后的总显示值也不保证小于 1 GiB，因为仍在写入的活动文件不会被它直接删除。

把时间和容量放进同一次清理

如果保留目标是“最近 14 天，并且归档文件不超过 1 GiB”，可以直接组合：

# 同时约束归档日志的年龄与容量，旧文件会按两个限制继续收缩
sudo journalctl --vacuum-time=14d --vacuum-size=1G

--vacuum-time=14d 删除早于 14 天的归档文件；--vacuum-size=1G 删除最旧的归档文件，直到归档文件占用低于指定容量。放在一次调用里不是“二选一”，而是同时执行这两类限制。

这意味着最终历史可能短于 14 天：如果最近 14 天产生的归档日志已经超过 1 GiB，容量限制还会继续删除更老的文件。反过来，即使容量很充足，超过 14 天的归档文件也会被时间限制清理。我的理解是，时间值表达想保留的最长历史，容量值表达不能突破的磁盘预算，实际保留量由更紧的那个约束决定。

为什么清理后容量看起来没降到目标值

最常见的原因不是命令失效，而是当前活动 journal 文件仍然占据空间。官方手册明确说明，vacuum 只作用于归档文件；活动文件既不会被 --vacuum-time 删除，也不会直接被 --vacuum-size 收缩。

如果当前活动文件本身较大，而且你确认可以让它立即轮转为归档文件，可以把 --rotate 与两个 vacuum 参数放在同一条命令里：

# 先轮转活动文件，再对全部归档候选应用时间与容量限制
sudo journalctl --rotate --vacuum-time=14d --vacuum-size=1G

组合时，systemd 会先执行轮转，再紧接着进行 vacuum。这样刚才的活动文件也进入归档集合，才可能被时间或容量条件处理。轮转不会停止 journald；它会打开新的活动 journal 文件继续接收日志。

清理后的检查不能只看一个数字

执行完成后，我会再次记录总占用，并抽查最早与最近的日志范围：

# 再次查看活动与归档文件的合计占用
sudo journalctl --disk-usage

# 查看当前可查询日志的时间边界，避免误删超出预期
sudo journalctl --list-boots

# 抽查最近 14 天的日志仍可正常读取
sudo journalctl --since "14 days ago" --no-pager | tail -n 20

这三个检查分别回答不同问题：磁盘占用是否下降、历史启动记录还剩多少、预期时间窗口内是否仍有可查询内容。需要注意，--list-boots 展示的是 journal 中存在的启动记录，不等同于所有服务都在每个时段持续产生日志。

几个会放大风险的误区

一次性清理和长期限制要分开

journalctl --vacuum-* 解决的是当前清理任务，不会把这组参数永久写入 journald 配置。若服务器长期需要相同限制，应在 journald.conf 或 drop-in 中评估 SystemMaxUse=、RuntimeMaxUse= 与 MaxRetentionSec= 等设置。

持久化存储通常位于 /var/log/journal，对应 System* 限制；易失性存储通常位于 /run/log/journal，对应 Runtime* 限制。修改长期策略前要先确认机器实际使用哪种存储模式，并把配置变更、重启或重载步骤纳入运维流程。

# 只查看当前合并后的 journald 配置，不在这里直接修改生产参数
systemd-analyze cat-config systemd/journald.conf

我会怎么选择参数

对普通开发或测试机，我会先按可接受的磁盘预算设置容量，再给一个足够覆盖近期排障的时间窗口；对生产环境，则先确定审计、事故回溯和备份链路，再决定 journal 本机保留多少。若日志已经集中发送到可靠的远端系统，本机窗口可以更短；若 journal 是唯一证据源，就不应为了快速释放空间设得过于激进。

一个实用起点是先运行不带 --rotate 的组合清理，观察归档日志释放量；只有活动文件明显占据大头时，再评估是否加 --rotate。这不是功能限制，而是我更偏好的风险控制方式：先减少可删除集合，再扩大范围。

常见问题

--vacuum-time 和 --vacuum-size 谁先执行？

对运维目标而言，不必依赖参数书写顺序。一次调用会把两类限制都应用到归档 journal 文件，最终结果同时满足可执行的时间与容量约束。

参数写成 0 会清空日志吗？

不会。官方手册说明，这三类 vacuum 参数指定为零等同于不启用对应限制，因此 --vacuum-size=0 不是“全部删除”。

可以再加 --vacuum-files 吗？

可以。--vacuum-size、--vacuum-time 与 --vacuum-files 可以在同一次调用中组合，分别约束归档文件的容量、年龄和数量。