链路追踪数据采样策略 不是选百分比那么简单

上次跟某电商平台的SRE挤在机房的走廊里啃凉掉的黄焖鸡，他翻着手机上的告警记录直叹气。上个月为了抓一个偶发的订单创建超时，他脑子一热把全链路的采样率直接拉到100%。

结果呢？

不到俩小时，可观测性平台的对象存储直接被打满，写入堵了整整四十分钟，连带所有服务的日志查询都卡成PPT。最后查出来那笔超时的请求，是第三方物流的回调接口抖了三秒。亏到姥姥家。

先算清楚你到底要存多少数据

很多团队刚搭链路追踪的时候，根本不算存储账。上来就拍脑袋说要全量，要所有请求都留痕，仿佛漏了一条就会出天大的事故。

算笔简单的账。一条完整的跨服务trace，平均下来带全量字段是12KB。如果业务峰值是每秒1万笔请求，全量采集的话，一天光原始trace的存储量就有10TB往上，还不算压缩前的临时块存储、倒排索引的额外开销。真按这个量存，一年的存储成本够养两个中级开发。

反过来，采样率设得太低也不行。我见过太多团队一开始图便宜，把采样率设成0.1%，觉得反正请求多，抓哪条算哪条。结果真出了跨服务的慢请求、权限错误，翻遍平台找不到对应的trace——刚好那条出问题的请求，被采样规则随机丢了。

丢了。

抓瞎。

这时候别着急骂采样工具不好用。先把自己的请求规模、能承受的存储成本算明白，再谈要选多大的采样比例，不然都是空中楼阁。

固定百分比采样早就不够用了

最原始的采样逻辑，就是不管什么请求，统一按固定比例抽。说白了就是纯赌概率。赌赢了，成本低、数据全；赌输了，那些占总请求量不到0.1%的异常请求，刚好落在被丢弃的样本里，你连问题的影子都摸不到。

我接触过最离谱的案例，一个团队连续三周排查不到那个偶发的500错误，最后没办法把所有链路的采样率临时调到100%，蹲了整整三天，才抓到那一条带问题堆栈的trace。算下来这三天多花的存储成本，比他们之前半年的可观测性平台预算还高。

现在的采样逻辑早就不是固定比例那一套了。核心的原则很简单：错误请求零丢弃、慢请求零丢弃、正常请求按需采样。不管是网关层、服务层还是消息队列的链路，只要请求返回了5xx错误，只要响应时间超过你提前设好的慢请求阈值，这条trace就必须完整存下来，不管占比多少。剩下的完全正常的请求，再按业务能承受的存储成本定比例采样就行。

这么算下来，实际需要存的trace量，比全量采集低一个数量级都不止。那些占总请求90%以上的正常快速请求，哪怕只采1%，对统计影响也很小；真正需要排查问题的异常请求，一条都不会丢。

别忽略采样带来的统计偏差

很多人用链路追踪的数据算服务的P99延迟、算接口的错误率，最后发现算出来的数和真实用户反馈对不上。问题大多出在采样的逻辑上。

纯随机采样的逻辑下，如果你只采1%的请求，刚好采到的样本都是响应快的正常请求，那些慢的、错的请求因为占比低，根本没被采到，算出来的P99就会比真实值低一大截。之前有个团队用采样数据算出来的支付接口P99是200ms，结果用户侧的反馈是近一成的请求要等两秒以上，最后排查了半天才发现，那些慢请求的占比只有0.8%，1%的随机采样率根本抓不到足够的样本，算出来的统计值完全是失真的。

还有个很容易踩的坑，就是头尾采样的断点。很多团队在网关层做头部采样，在后端服务做尾部采样，两边的采样规则不打通，就会出现网关层已经记了trace的开头，到后面的服务层因为采样规则把这条trace丢了，最后在平台上拼出来的trace是断的，查的时候连完整的调用链都看不到。

说实话，这事没那么玄。小团队每秒才几百的请求量，全量采也没多少存储成本，根本没必要搞复杂的分层采样逻辑，省得后面为了调规则费半天劲。大团队每秒几十万请求，全量采根本扛不住，就把采样规则拆细，核心交易链路的采样率高一点，内部运维工具的链路采样率低一点，甚至可以按用户的会员等级设不同的采样权重——付费用户的请求100%采，免费用户的请求按比例采，都没问题。

我之前见过有人把采样规则写死在网关的配置文件里，每次调整都要走一遍发布流程，改一次采样率要等半小时才能生效。等到规则改完，那个线上的临时问题早就过去了。

下次再有人上来就问“链路追踪数据采样策略到底设多少合适”，别直接甩给他一个百分比数字。先问清楚他现在的存储预算能扛多少，最担心的是哪类线上问题，再配对应的规则就完了。