线上日志到底留几天：全量 90 天还是只留 7 天就够？

背景

最近帮一个新接手的服务做容量规划，被问到一个让我犹豫很久的问题：「日志到底留多久？」

先给一组具体数字，避免各说各话。我们一个 12 节点的服务，业务日志 + access log 加起来一天约 50GB（含 JSON 未压缩），一个月就是 1.5TB，90 天约 4.5TB。如果按对象存储标准层 0.12 元/GB/月 算，90 天全量留一年大约要 6 万块；如果换成冷存储 0.033 元/GB/月，能压到 1.6 万左右。这个钱不多不少，刚好卡在「财务要问一句」的区间。

但真正的问题不是钱，是两件事：

1. 查得到 vs 查得动：留 90 天没问题，但排障时 grep 一个 4.5TB 的日志目录，本地 SSD 能撑住，S3 上捞 8 天前的某条 traceId，等 3 分钟是常事。我见过一次事故，关键日志只存在于 12 天前，等捞出来复盘时，现场已经凉了。
2. 留了 ≠ 有用：大量 debug 级别日志、健康检查日志、重试日志，留 90 天也只是占地方，真出事时反而把关键行淹没。

常见分歧 / 几种做法

社区里我见过至少四种路线，各有拥趸：

1. 一刀切全量 90 天：合规驱动，审计好交代，成本最高，排障体验最差（数据太散）。
2. 只留 7 天，出事靠重放：成本低，但「重放」在支付、第三方回调这类场景根本做不到，等于赌运气。
3. 按服务分档：核心交易链路 90 天 + access log 180 天，边缘服务 14 天。我的倾向，但落地时要维护一张「分档表」，服务一多就乱。
4. 采样 + 全量归档：在线只留最近 3 天全量，更早的按 10% 采样或只留 ERROR 级别，归档到冷存储。省成本，但「采样漏掉关键行」的锅没人愿意背。

我的倾向与理由

我倾向 3 + 4 混合：核心链路全量 30 天在线（S3 Standard + 按 prefix 分月），30 天到 180 天降采样到 ERROR + traceId 全量，180 天后只留聚合指标。理由有三：

• 90% 的线上事故发生在上线后 7 天内，30 天在线窗口已经覆盖绝大多数复盘场景；
• 真正需要「很久以前那条日志」的，往往是审计和合规，他们要的是可追溯，不是可 grep，降采样 + 保留 traceId 索引就够；
• 成本上比全量 90 天省 60% 以上，且在线部分查询体验更好（数据量小一半）。

但我自己心里没底的一点是：「分档标准」谁来定？ 我见过按「P0/P1 服务」分的、按「QPS 是否 > 1000」分的、按「是否有资金流」分的，三套标准混着用，最后变成每个团队自己拍脑袋。

想听大家的选择

1. 你们团队现在日志留多久？在线 / 冷存储怎么分？
2. 分档标准你们按什么定？（服务等级 / QPS / 资金流 / 业务线）
3. 有没有人试过「采样 + traceId 全量」这条路？漏过什么坑？
4. 合规 / 审计要求你们留多久？这个数字是拍的还是算出来的？

欢迎带着具体数字来聊，纯观点的我也接，但最好能说出「为什么是 7 天 / 30 天 / 90 天」。