说白了，大部分团队第一次碰链路追踪数据采样策略的时候，都在走两个极端：要么全量开，要么随便选个固定比例就完事。很少有人真的蹲下来算过，自己到底需要什么样的采样规则。
全量采样的代价从来不是存储
很多人刚接触链路追踪的时候，默认觉得全量存最稳妥。所有请求的链路都拉出来，排查问题的时候想怎么查就怎么查，多爽。
但麻烦在于，现在的微服务架构，一次用户请求可能跨十几个服务，几十次调用，每一次调用生成的span数据，量有多恐怖？
比如一个日活百万的应用，一秒钟可能有几千上万的请求，每个请求拆成几十个span，一天下来的原始数据量可能到几十TB。这还不算你要做的索引、聚合。
真的。别迷信全量。
你以为存下来就完了？查询的时候呢？你要查一个用户半小时前的下单失败链路，全量数据的索引膨胀到你根本跑不动查询，DBA半夜爬起来给你删索引的事我见多了。更别说云厂商的可观测服务，都是按写入量收费的，你开全量跑一周，收到账单的时候心都在滴血。
固定比例采样的坑在哪
被全量采样的账单打疼了之后，大部分团队会退而求其次，搞固定比例采样。比如采10%，1%。听起来成本直接砍到原来的十分之一甚至百分之一，好像捡了大便宜。
但问题来了，那些真正出问题的链路，比如超时的、报错的、慢调用的，本来占比就低。可能1000个请求里才有一个出错的，你按1%采，大概率把那个出错的链路给扔了。
之前碰到过一个团队，按2%采样，线上有个偶发的支付回调失败，排查了两周，翻遍了存储的采样数据都没找到对应的链路。最后把采样比例临时调到100%跑了俩小时，才抓到那一条问题链路。
这事说起来真的好笑。你花几十万搭的可观测系统，最后抓个错链还要靠碰运气？
自适应采样才是能用的路子
说白了，链路追踪数据采样策略的核心，从来不是“省多少钱”，是“把你真正需要的链路留下来”。
什么是真正需要的？报错的链路、超时的链路、慢调用的链路、触发了异常规则的链路，必须全量保留。剩下的正常请求，你爱采多少采多少，哪怕0.1%都没关系。
现在很多开源的链路追踪组件，比如Jaeger、OpenTelemetry，都自带自适应采样的能力。你不用自己写复杂的规则，只要把异常阈值配好，系统会自动把命中异常的链路全部保留，正常的请求按比例丢。
别上来就说我要做智能采样，什么AI预测异常链路，扯远了。先把最基础的异常全采、正常按比例采这套跑顺，能解决80%的问题。
这里有个很容易被忽略的细节：采样的决策要在链路的第一个入口节点做。
对吧？你想啊，网关收到请求，先判断这个请求是不是异常链路，是的话就打个全局标记，后面所有服务看到这个标记，不管什么采样规则，都把这个链路的span存下来。不然东一榔头西一棒子，前面服务采了，后面服务没采，最后拼出来的链路是断的，白存了一堆数据。
当然，没有完美的采样规则。你可以把链路按业务重要性分个类，核心交易链路的异常全采，边缘的非核心接口的异常，你采个50%都行，不用死抠100%。大促的时候请求量翻十倍，你就把正常请求的采样比例调低，把存储额度留给异常链路，别让正常流量把存储占满，到时候连报错的链路都存不下。
别想一劳永逸。你上个月定的采样规则，这个月业务改版加了新的接口，可能就要调。我见过最离谱的团队，把采样规则配完就再也没动过，过了半年，新上的支付接口的错误链路全没存，排查问题的时候哭都来不及。