上周跟几个做可观测的工程师吃饭，一半人在吐槽采样的事。真的。
有人全链路开100%采样，月底账单出来直接拍桌子，存储成本飙到原来的三倍，告警还没少几个。有人采样率压到1%，出了线上问题翻遍日志找不到那条慢请求的trace，急得满头汗。说白了，链路追踪数据采样策略从来不是拍脑袋定个数字的事。
你以为的采样，根本不是省成本那么简单
很多团队刚接链路追踪的时候，第一反应就是”采样不就是为了少存点数据，降成本吗”。错。
静态固定比例采样是最懒的方案，也是最容易踩坑的方案。比如你定个10%的采样率，正常请求的时候没问题，真到了故障时刻，所有报错、慢请求的trace可能刚好都被采样规则筛掉了——正常请求占90%，故障请求本来就只有10%，按固定比例采，最后剩下的故障样本可能连1%都不到。这时候你对着满屏的正常trace，根本定位不到根因。
麻烦在于，很多团队一开始算成本的时候，只算了存储的钱，没算故障排查时浪费的人力成本——一个资深工程师一小时的成本，够你存半个月的trace数据了。
我之前碰到过一个团队，为了压成本把采样率调到0.5%，结果大促的时候出现了部分支付请求超时，翻了三个小时的trace，只找到两条成功的支付链路，超时的请求一条都没存下来。最后靠业务侧的日志拼了半天才定位到是下游网关的超时配置错了。事后复盘的时候CTO说，早知道多花两万块存数据，也不至于整个团队熬到后半夜。
动态采样的坑，比你想的要多
现在大家都知道固定采样不行，开始搞动态采样。就是碰到报错、慢请求、特定接口的请求，优先级拉高，全量采。听起来很美好对吧？但真落地的时候，问题全来了。
动态采样的核心矛盾，是规则的优先级和资源的阈值平衡。比如你设了规则，只要是5xx的请求全采，只要是响应时间超过1s的请求全采。真到了服务雪崩的时候，所有请求都是5xx，所有请求响应时间都超1s，这时候动态采样的规则等于失效——所有请求都要全量存，存储瞬间就爆了。
我第一次看到这种场景的时候，真的觉得很讽刺。本来是为了防故障设计的策略，结果故障来了直接把系统干挂。
那怎么调整？有人说，加阈值啊，当存储写入的速率超过某个值的时候，自动把非核心的规则降优先级。比如核心的支付链路的请求，不管什么情况都采，其他非核心的页面访问、日志查询类的请求，哪怕报错了，也按比例采。听着合理对吧？但代价是什么？你得先把自己的业务核心链路理得明明白白。很多团队连自己的核心接口有哪些都数不全，谈什么优先级划分？到最后规则写了一堆，核心请求没采到，无关的请求存了一大堆。
还有人喜欢用尾部采样。就是请求先过一层，最后根据整个链路的状态决定要不要存。这种方式确实能把故障相关的请求都捞到，但代价是，你得把所有请求的临时数据先存在内存或者临时存储里，等整个链路跑完了再做判断。内存的成本，比永久存储的成本高多了。小团队根本扛不住。
没有最优的采样率，只有适配你阶段的取舍
别信网上那些教程说的”最佳采样率是20%””生产环境必须10%采样”的鬼话。真的。你一个刚上线的小服务，一天总共几千个请求，你采10%有什么意义？直接100%采，成本也没多少，排查问题还方便。等你到了日活百万的规模，全链路一天几个亿的请求，你100%采，存储和计算的成本能把你利润吃干。
说白了，链路追踪数据采样策略的本质，是在”排查问题的效率”和”系统运行的成本”之间找平衡，没有放之四海而皆准的标准答案。
比如刚起步的团队，别整那些花里胡哨的动态规则，先100%采个一两个月，把所有的请求路径、常见的故障类型摸清楚，再慢慢调采样率。等业务到了中等规模，再上简单的动态规则：核心链路全采，非核心链路按比例采，碰到报错的请求临时拉高采样率。真到了超大规模的场景，你甚至可以给不同的租户、不同的用户群体设不同的采样规则——付费用户的请求全采，免费用户的请求按低比例采，反正免费用户出问题的优先级本来就低。
采样规则上线之前，一定要做灰度验证。我之前见过团队刚把新的采样规则推到生产，因为规则写反了，把核心链路的请求全筛掉了，非核心的请求全存了，出问题的时候连个trace都找不到，折腾了半天才发现是规则写反了字段。这种低级错误，本来是可以避免的。
上周跟那个之前踩坑的团队吃饭，他们现在的采样规则很简单：核心的三个交易接口，全量采；其他内部系统的接口，采5%；静态资源请求，直接不采。存储成本比之前10%固定采样的时候还低30%，上次出问题的时候，三秒钟就找到了对应的trace。
这事没那么玄。别上来就追求最复杂的策略，先把自己的业务场景摸透，比看十篇教程都有用。