结论先行：强监管行业做全链路监测，链路数据要同时承担两个角色：日常排障的素材，和监管审计的证据。可行做法是按"在线可查 + 归档留存"两层设计留存周期——近期明细数据在线供检索，超期数据转归档并保留可回溯能力；同时提前把业务标识纳入检索索引，并对敏感字段在采集侧脱敏。这样既满足异常交易回溯，也不让存储成本失控。
为什么"日志留存"不等于"链路留存"
很多机构在合规清单里已经写了日志留存周期，但监管问的是"这一笔交易当时是怎么走的"，而不是"这台服务器当时报了什么错"。两者的差别在于：
| 对比维度 | 日志留存 | 链路留存 |
|---|---|---|
| 回答的问题 | 某个时点发生了什么 | 一笔业务完整经过了哪些环节 |
| 数据形态 | 离散的文本记录 | 带父子关系的调用树 |
| 关联方式 | 靠时间戳与关键字 | 靠全局标识天然串联 |
| 回溯效率 | 需跨系统人工拼接 | 按标识一次还原 |
换句话说，日志能证明"系统记录了这件事"，链路才能证明"这件事是怎么发生的"。异常交易回溯、纠纷举证、事后问责，要的是后者。
两层留存怎么设计
把所有链路数据都在线保存既不经济也没必要。更常见的做法是分两层：
- 在线层：保存近期全量或高采样明细，供日常排障与按需检索，要求秒级到分钟级响应。
- 归档层：保存超期数据，响应要求放宽到小时级，重点是"还能调出来"而不是"马上调出来"。
留存周期怎么定，建议按数据类型分开考虑，而不是一刀切：
| 数据类型 | 留存考量 | 说明 |
|---|---|---|
| 操作与配置变更日志 | 周期最长 | 合规审计通常对操作留痕有明确年限要求 |
| 交易链路明细 | 在线短、归档长 | 近期高频排查，历史按需回溯 |
| 性能指标聚合值 | 可长期在线 | 聚合后体量小，适合做趋势对比 |
| 含敏感字段的原始数据 | 脱敏后留存 | 留存前先完成脱敏，避免合规风险转移 |
具体年限应结合所在行业的监管要求与法务意见确定，本文不给出统一数值——不同行业、不同数据类型差异很大，照抄别人的周期反而容易出问题。
回溯能力依赖三件事
- 标识贯穿。全局标识必须在入口生成并全程透传，中途任何一个环节丢标识，这段链路在归档后就再也拼不回来。
- 业务字段进索引。只按技术标识检索，业务部门给不出单号就查不到。订单号、客户标识、渠道这类业务字段应当与标识一并写入检索索引。
- 采集侧脱敏。标识透传会顺带把账号、手机号带进链路与日志。脱敏要在采集侧完成，而不是等到存储之后再处理。
归档之后：别忘了验证可读性
归档做得好不好，判断标准不是"存了多少"，而是"能不能调出来"。建议把归档回溯纳入定期演练：
- 每季度随机抽取一批历史业务标识，完成一次从归档到还原的全流程，记录耗时。
- 检查归档格式是否仍可被当前平台版本解析，避免格式随版本升级而失效。
- 核对归档数据的完整性——抽样比对归档前后同一笔链路的环节数与耗时分布。
只存不验的归档，等到真正需要举证时才发现读不出来，代价远高于定期演练的成本。
落地清单
- 梳理哪些业务属于"必须可回溯"的范围，不要全量一刀切
- 确定在线层与归档层的分界时间与采样策略
- 把业务标识与关键业务字段纳入检索索引
- 在采集侧完成敏感字段脱敏规则配置
- 建立季度归档回溯演练机制，并留存演练记录
奇摩在协助金融、政务客户建设可观测体系时，通常会把留存与回溯方案单独作为交付物输出，与平台的采集、告警配置一并验收。
如果您正在规划相关建设，欢迎预约咨询，奇摩技术团队可基于现网数据做一轮评估，再决定是否推进。