链路动态采样：存储成本与故障取证兼得

结论先行：链路数据该不该全量存，是个伪命题——真正要做的不是选一个固定比例，而是让采样率随业务状态变化。可行配置是：常态下按接口重要性采用不同比例的低采样；一旦出现报错、超时或关键接口劣化，自动切换为全量采集；异常结束后回到常态。这样既把存储成本压在可承受范围，又保证故障现场一定有完整链路可查。下面给出具体的分级方法、触发规则与成本测算口径。

固定采样的两难

链路追踪的数据量取决于请求量，而请求量在业务高峰期可能是平峰期的数倍。如果按峰值配置全量存储，成本会长期闲置；如果按平峰配置，高峰期要么丢数据要么撑爆存储。于是很多团队选择固定比例采样，比如统一采集 10%。

固定采样有两个绕不开的问题：一是故障往往发生在少量请求上，1% 的异常请求在 10% 采样下大概率采不到；二是不同接口的重要性差异巨大，登录接口和后台报表接口用同一个采样率显然不合理。

动态采样的三条触发规则

动态采样的核心是"平时省着用，出事全留着"。建议配置以下三类触发规则，任一命中即切换为全量采集。

错误触发优先级最高，任何接口报错都应无条件保留完整链路——故障样本本来就是稀缺资源。延迟触发要考虑成本，建议只对核心交易接口开启，避免大量非关键慢请求把存储打满。

按接口分级配置常态采样率

常态采样率应该体现业务重要性，而不是一刀切。参考分级如下：

• 核心交易类（下单、支付、放款）：20%–50%，配合动态基线告警。
• 关键交互类（登录、查询、提交）：10%–20%。
• 后台批量类（报表、同步、定时任务）：1%–5%，只需保证有样本即可。

分级的依据不是技术复杂度，而是"出问题时的业务代价"。一个跑批任务失败了可以重跑，一次支付失败直接产生客诉，两者的取证价值完全不同。

异常时刻的全量补采

动态采样的一个细节容易被忽略：从异常发生到触发规则生效之间存在时间差，最初几条异常请求可能已经按低采样率丢弃了。解决办法是在采集端保留一个短暂的本地缓冲，比如保留最近 30 秒的全部链路数据在内存中，收到全量触发信号后再回写，就能补上这段空窗。

另一个要点是给全量采集设置上限与自动回落。如果异常持续数小时，全量数据可能远超预算，需要在配置里明确"单次全量最长持续多久""存储水位超过多少时强制降级"，避免保护措施本身变成新的故障源。

成本测算：先看量级再定策略

采样策略不能拍脑袋定，建议先做一次量级测算。按下面这张表的口径填一遍，就能大致知道自己的存储压力在哪。

测算之后常见的调整是：降低后台批量类接口的采样率、缩短冷数据留存周期、对超长链路做裁剪。这三项通常能省下三到五成存储，且几乎不影响排查能力。

落地清单

• 梳理接口清单，按业务代价分三级，配置差异化常态采样率
• 开启错误触发全量采集，覆盖所有接口
• 为核心交易接口增加延迟触发规则，设置全量持续时长上限
• 配置采集端本地缓冲，补齐异常发生到触发之间的空窗
• 按峰值日做一次存储量级测算，明确留存周期与冷热分层
• 每季度复核一次采样率与接口分级，跟随业务变化调整

采样策略不是配一次就结束的事。业务上线、接口重构、流量结构变化都会让原有分级失效，建议每季度复核一次：哪些接口已经不再核心、哪些新接口需要提升采样率、上一季度的全量触发频次是否超出预期。奇摩在为金融客户做可观测体系建设时，通常把采样策略与告警策略一起调：先跑一到两周拿到真实分布，再定各级阈值，避免上线初期因阈值不合理产生大量无效告警。

还有一个实用建议：把采样率配置纳入版本管理。采样率的调整同样会影响排查能力，如果某次故障查不到数据，需要能追溯到当时的采样配置是什么。

如果您的分布式系统正在补齐外部依赖与链路数据的可观测能力，欢迎预约咨询，我们会结合您的业务链路与成本约束给出分阶段实施建议。