上周跟一个做基础架构的朋友喝酒，他吐槽说最近差点被线上告警搞到猝死。核心问题就是他们之前全量采链路，三个月堆了快20T的存储，成本涨了40%不说，查个问题还要等5分钟导数据。
很多团队踩过的坑，本质上都是没搞懂链路追踪数据采样策略的核心是取舍，不是选一个最先进的就行。
全量采样的代价从来不是存储那么简单
很多人刚上链路追踪的时候，默认开全量。觉得反正要查问题，全的数据总不会错。
真跑起来才知道有多坑。
你以为采的是日志，实际上每个服务实例要把几百个span序列化，走HTTP上报，高峰期QPS到几万的时候，这部分上报流量能占到实例出口的15%以上。更别说存储端要扛得住每秒几十万条span的写入，ES集群的CPU能直接打满到90%以上，连带着其他监控查询都跟着卡。
有个团队去年为了省链路追踪的成本，直接把采样率砍到1%，结果上次出了个订单超时的问题，查了三天，翻遍了所有采样的trace都没找到对应的请求。最后才发现那个超时的请求刚好被过滤掉了。那次排查整个团队熬了两个通宵，最后拍桌子说再也不敢瞎调采样率了。
全量采样的成本从来不是你看得见的存储账单。看不见的带宽、集群CPU、运维排查的时间成本，加起来比存储贵多了。
固定比例采样根本解决不了长尾问题
很多人退而求其次，用固定比例采样。比如10%或者1%，看起来简单，成本可控。
但问题在于，线上的请求不是均匀分布的。
99%的请求都是正常的首页访问，只有1%的是支付、退款这种核心链路的请求。你按固定比例采，很可能把核心链路的请求都给漏掉了。
固定比例采样的本质是对所有请求一视同仁，但线上流量从来不是平均的。
更麻烦的是，出问题的时候，你根本不知道哪些请求被采了。比如某个用户的请求超时了，你去查trace，发现没有，你也不知道是采样率太低没采到，还是服务本身就没打trace。
很多人这里会犯个错，觉得我把核心接口的采样率调高不就行了？比如支付接口采100%，其他接口采1%，听起来合理。
但麻烦在于，一个请求不是只走一个接口。它要经过网关、订单服务、支付服务、库存服务、消息队列，你在网关端采了这个请求，后面的服务如果没拿到采样的标记，还是会把这个请求的span给丢了。
这事没那么玄。很多人刚搞的时候，只在入口服务调了采样率，下游服务根本不认这个标记，最后采到的trace都是缺胳膊少腿的，连不起来，等于白采。
我之前见过一个团队，调了半个月的采样率，采到的trace还是连不起来，最后才发现是网关端的采样标记没透传到下游的服务网格里。白折腾了半个月。
尾采样才是真的解决了大部分人的痛点
现在很多人用的尾采样，也就是请求走完整个链路之后，再判断要不要存这个trace。比如这个请求是报错的、超时的、或者是核心接口的，就100%存，其他正常的请求就按比例丢。
听起来确实比固定采样合理多了。
但实际有代价。
尾采样需要把同一个trace的所有span先存在内存或者临时缓存里，等整个请求走完了再判断要不要上报。如果你的请求链路很长，比如有些异步请求要走十几分钟，那你就得把这些span在缓存里存十几分钟，内存成本一下就上去了。
尾采样的核心是用临时缓存的成本，换核心问题trace的完整性。
也不是所有场景都适合尾采样。比如那种超高QPS的网关层，每秒几十万请求，你要把这些span都存在缓存里，内存直接爆了。
所以很多团队会折中。网关层先做个初步的采样判断，比如看到是支付接口的请求，就先标记成要采，后面的服务直接上报，不用等尾采样的判断。这样既省了缓存的成本，又不会漏核心链路的请求。
说实话，没有完美的方案。
我见过有人为了搞动态采样，写了一套自动调整采样率的逻辑，高峰期自动降非核心接口的采样率，低峰期再调高。听起来很智能，结果上次高峰期刚好出了个核心接口的报错，因为自动把采样率调到了0.1%，那个报错的请求刚好没被采到，又熬了个通宵。
上次跟那个吐槽的朋友聊完，他现在的方案是，核心链路全采，普通接口固定采5%，然后开尾采样把所有报错的trace都捞出来。存储成本比之前全量的时候降了60%，上次出了个库存超卖的问题，10分钟就查到了对应的trace。
他说终于不用熬大夜了。
哦对，还有个小细节，很多人会忽略采样的一致性。比如同一个trace的span，不能一部分被采，一部分被丢，不然你拿到的trace就是断的，根本没法用。这个小坑，踩过的人都懂。