上周跟一个做云原生运维的哥们喝酒，他拍着桌子骂，说自己花了几十万搭的链路追踪平台，现在成了纯摆设——线上出了支付超时的问题，查不到对应的完整trace，翻了半小时采样日志，才发现默认配的全链路1%采样，刚好把那笔出问题的请求给滤掉了。
这事我太熟了。
太多团队在刚上链路追踪的时候，对链路追踪数据采样策略的重视程度，还不如对日志保留天数的重视程度高。
别拿默认采样当万能解法
大部分开源链路追踪组件的默认配置，都是固定比例全链路采样，常见的比例是1%。这个配置的初衷是帮用户降低初期接入的存储成本，根本不是为了生产环境长期用的。
麻烦在于，固定比例采样最反人性的地方是——它根本不知道哪条请求是有问题的。大促的时候流量翻10倍，原来1%的采样率对应10倍量，你要是不调，采到的请求里可能刚好没有跨服务调用超时的那条，等你想起来要把采样率拉满，故障已经过了半小时了。
很多人这时候会走极端，说那我干脆100%采样不就完了？那代价是什么？一条完整的trace从客户端到网关，到应用，到数据库，到缓存，十几二十个span，每个span带几十KB的上下文，按每秒十万请求算，一天下来存的trace数据能把你监控集群的磁盘吃满，光存储成本一年够给运维团队发俩月年终奖。
100%采样从来不是中小团队的最优解，是预算无限的大厂玩的配置。我见过最夸张的一个团队，全链路100%采了三个月，光Elasticsearch的存储节点就扩了12台，最后发现80%的trace都是静态资源加载的请求，跟核心业务排查半毛钱关系没有。
别信通用最优采样比例的鬼话
我之前见过不少技术博客上来就给数，说什么固定20%采样率是性价比最高的。
纯扯。
说白了，你的采样策略根本不是由流量规模决定的，是由你自己的故障排查需求决定的。比如你是做电商交易链路的，那涉及支付、下单的核心请求，哪怕流量占比只有5%，你也得100%采；那些静态资源加载的请求，占了总流量的60%，你哪怕采0.1%都不会影响排查。
这种基于标签的分层采样，听着简单，实际用的时候坑特别多。很多人配规则的时候，只记得把核心业务路径加进去，漏了最关键的一类请求——异常返回的请求。比如你配了下单链路全采，但是某条请求在调用库存服务的时候抛了个空指针，返回状态码是500，要是你的规则里没写“所有返回状态码非2xx的请求强制全采”，那这条错误请求可能因为比例采样被滤掉，你排查的时候连个线索都没有。
我之前碰到过一个团队，他们一开始只给核心业务路径配了全采，上次出了个缓存穿透导致数据库打满的问题，翻遍了trace都找不到是哪个请求触发的——因为他们把缓存层的span采样率设到了0.5%，刚好那批穿透的请求全没采上。这事没那么玄，就是你配规则的时候，根本没把“异常路径”当核心路径算。
自适应采样才是能长期用的路子
现在很多人对自适应采样有误解，觉得就是系统自己根据流量调比例，听着很高科技。其实根本不是。
自适应采样的核心，是在你总存储成本不超预算的前提下，把采样的配额优先留给你最需要的请求。比如平时流量平稳的时候，核心路径采20%，非核心采1%，总数据量刚好卡在磁盘配额的80%；突然流量涨了3倍，系统自动把非核心路径的采样率降到0.1%，核心路径的采样率保持在10%，总数据量还是不超配额，而且那些占了大部分流量的非核心请求，根本不会挤占核心请求的采样额度。
我之前跟个做可观测性产品的工程师聊，他说他们见过最离谱的配置，是团队把所有带trace头的请求全采，不管是核心还是非核心，结果赶上一次爬虫刷静态页面，一天产生了120G的trace数据，把原本用来存交易链路的存储集群给挤爆了，真出故障的时候反而查不到数据。
这里有个容易被忽略的点——链路追踪数据采样策略从来不是一劳永逸的配置，是要跟着你业务的核心链路迭代同步调的。比如你上个月刚上了个新的用户积分兑换功能，要是你没把这个新链路加到核心采样规则里，等这个功能出了超时问题，你翻遍trace都找不到对应的数据，等于你新功能上线的前两周，相当于在裸奔。
很多人觉得调采样策略是运维的事，跟开发没关系。
错了。
你开发写代码的时候，要是给关键的业务节点打了明确的标签，比如“这里是支付回调节点”“这里是库存扣减节点”，后面配采样规则的时候根本不用瞎猜哪个路径是核心的。反过来，你写代码的时候span的标签写得乱七八糟，连个接口名都不带，就算你把采样率调到100%，你排查的时候也得翻半天数据，跟没采差不多。
上周那个喝酒骂人的哥们，后来回去把策略改了：所有返回非2xx的请求强制100%采，支付、下单路径强制100%采，静态资源路径采0.2%，总存储成本比之前1%全链路固定采样的时候还低30%。上周他们出了个优惠券计算超时的问题，10秒就从trace里定位到是规则引擎的调用超时，他说现在终于觉得当初搭这个平台的钱没白花。