链路追踪数据采样策略 别被全量采样的执念绑架

上周跟个在电商做SRE的朋友撸串，他吐槽说上个月大促演练，为了提前把所有跨服务的调用问题都揪出来，直接把全链路的采样率拉到了100%。

跑了三天。

等云服务商的账单发过来，财务直接追着他要解释。多花的钱够部门喝半年奶茶。

更糟的是，因为写入量突然爆涨，观测平台的查询接口直接被打挂，本来想提前发现问题，反而耽误了演练进度。

真的亏。

全量采样从来不是默认选项

很多人刚接触链路追踪的时候，第一反应是数据越多越好。毕竟排障的时候，谁会嫌手里的线索多呢？

但麻烦在于，现在的微服务架构，一个普通的用户请求从网关打进来，要过鉴权、路由、业务逻辑、库存、支付，最后到数据库，生成的span可能几十上百条。如果是大促的峰值流量，一天产生的链路数据量是按TB算的。

全量采样的成本从来不是数字上的加法。存储只是小头，后续的写入带宽、查询算力、索引维护，每一项都是长期的成本投入。更别说如果数据量太大，查询接口扫一次全表要等几十秒，排障的黄金时间都过去了，你拿到再全的数据又有什么用？

很多团队一开始没算过这笔账。总觉得现在存储便宜，多存点没什么。真到流量涨上来的时候，才发现每个月的观测平台账单，已经快赶上服务器的成本了。

全量采样不是不能用。比如你的系统一天就几万请求，总流量还不如别人一个接口的峰值，那你100%采也没多大压力。但要是你的系统一天几十亿请求，硬扛全量的成本，真的没必要。

固定比例采样的隐形bug

成本扛不住，大家自然就会把采样率往下调。最常用的就是固定比例采样，比如不管什么请求，统一采1%。

听起来简单。成本也好算。

但问题很快就来了。

那些出错的请求，那些延迟超过阈值的请求，那些带了核心用户标识的请求，偏偏可能就在那99%被丢掉的里面。

谁都碰到过。用户反馈说支付失败了，运维翻了半小时链路，一条相关的记录都找不到。最后一查，那个失败的请求刚好没被采上。

闹心不闹心。

固定比例采样的核心矛盾，是把所有流量的价值拉平了算。但我们排障的时候，根本不关心那些200响应、毫秒级返回的正常请求。那些占了99%的正常流量，采了也是占存储。真正有价值的，是那些异常的、慢的、可能影响核心流程的请求。

更烦的是跨服务的一致性问题。现在很多团队的采样率是每个服务单独配的。网关层采了这个请求，到后面的支付服务，刚好因为采样率的配置，这个请求没被采上。你拿到的链路就是断的。看到一半线索没了，顺着往下找啥都没有。

那种抓狂的感觉，做过排障的都懂。

太磨人了。

动态采样的取舍账

现在主流的采样方案，基本都往动态采样靠了。

说白了就是，系统自己判断这个请求值不值得采。比如健康检查的请求，采千分之一都嫌多；一旦发现请求返回了500，或者延迟超过了1秒，或者带了某个核心大客户的uid，直接100%采下来。

成本比全量低一大截，关键的异常请求一条都不会漏。

很多团队在搭链路追踪数据采样策略的时候，容易陷入两个极端：要么怕花钱把采样率压得极低，出问题找不到数据；要么怕漏数据把采样率拉满，成本压得扛不住。动态采样刚好卡在中间。

动态采样的本质，是把排障的优先级前置到数据采集的环节。这事没那么玄，不是什么复杂的AI算法，就是提前把什么数据重要、什么数据没用的判断规则写好，让系统自动执行。

当然也不是银弹。

之前碰到个团队，一开始用动态采样的时候，把规则配得太狠，把登录接口的正常请求采样率压到了千分之一。结果后来发现登录接口有个偶发的性能抖动，翻了三天链路都没找到足够的样本，最后不得不临时拉高采样率，折腾了快一周才定位到问题。

没有完美的策略。

你永远要在成本和排障效率之间找平衡。刚搭链路追踪的团队，别上来就抄大厂的复杂架构。先把异常请求全采上，正常请求按5%的比例采，跑半个月，看看成本，看看有没有漏过关键问题，再慢慢调规则。

如果你的系统流量不大，就别硬抠那点存储钱。真出核心故障的时候，损失的钱够你交十年的观测平台费用。如果你的系统流量已经大到存储扛不住，就好好把规则理清楚，哪些流量值得采，哪些扔了也不可惜。

别听那些卖方案的吹得天花乱坠，真落地的时候，适合自己业务的才是最好的。

毕竟采样策略从来不是为了采更多的数据。是为了你真需要查问题的时候，手里刚好有能用的线索。