日志该留多久

2026-08-30

这个问题没有标准答案，但可以算。算清楚之后，大多数机器上默认的保留策略都是错的 —— 要么留太短查不到问题，要么留太长没人看还占满盘。

先算磁盘成本

取一个中等流量的站点，假设每天 50 万请求，日志格式是 combined（约 120 字节/行，加上压缩前的膨胀）：

50 万 × 120 B ≈ 60 MB/天 ≈ 1.8 GB/月 ≈ 22 GB/年

40G 系统盘的机器上，一年不清理就会满。加上 gzip 压缩通常能到 1/8 到 1/10，也就是每月不到 200 MB —— 压缩与否差了一个数量级，这是第一个值得做的优化。

再算排查效率

日志的实际用途大致三类，各自对时间窗口的要求完全不同：

• 故障排查：通常看最近 1-7 天。超过一周的问题，靠日志本身也查不出什么了。
• 流量分析：看趋势需要 30-90 天，但这类分析不该在原始日志上做，应该先聚合。
• 安全审计：合规要求可能是 6 个月到 1 年，但这部分通常不在业务机器上存。

结论：业务机器的原始访问日志留 7-30 天足够。真要长期趋势，把聚合后的指标（每天请求数、状态码分布、P95 延迟）另存一份，体积小两个数量级。

journald 的几个坑

systemd 机器上的日志默认走 journald，它有几个容易漏掉的配置：

1. 默认不持久

很多发行版的默认值是 Storage=auto，含义是 "/var/log/journal 存在就持久化，不存在就只放内存"。全新安装的机器上这个目录往往不存在，于是重启日志全丢。

mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald

2. 上限是按目录算的

SystemMaxUse 限制的是整个 journal 目录，不是单个文件。设了 4G 意味着总量到 4G 才开始淘汰，单个文件可能很大。排查问题时按大小切分更容易处理：

[Journal]
SystemMaxUse=2G
SystemMaxFileSize=128M
MaxRetentionSec=30day

3. 有的服务不写 journal

nginx 默认写自己的文件（/var/log/nginx/*.log），不走 journald。这不冲突，但意味着你的日志分散在两个地方，做保留策略时要分别配。

一个实际的选择

我现在的做法：

• 业务日志：nginx access log，按天切割，gzip，留 14 天；
• 系统日志：journald，SystemMaxUse=1G，留 30 天；
• 敏感服务：Storage=volatile，只进内存，重启即清 —— 这类日志的价值不在事后追溯。

最后一条值得展开：并不是所有日志都值得落盘。如果一份日志的用途只是"出问题时看一眼当前状态"，那内存足够了，落到磁盘上反而是负担 —— 既是存储负担，也是信息暴露面。