上周跟一个做基础架构的朋友蹲在机房走廊吃外卖，他盯着手机上的告警皱眉头。他们家全量开链路追踪撑了三个月，这个月光ES的存储账单就涨了四十万，但是真出问题的时候，关键的那条故障trace还是被漏了。
冤不冤？
先算清楚全量采样的账
很多团队在摸索链路追踪数据采样策略的时候，第一反应就是把采样率拉满。觉得数据越全，排查问题越方便。
大错特错。
现在的微服务架构，一次普通的用户请求，要跨过网关、认证服务、业务逻辑层、数据库、缓存、消息队列，七八跳是常态。每一跳都会产生对应的span数据，算下来一次请求就能生成十几条trace记录。遇到大促峰值，一秒几十万并发请求，一天的trace数据量能冲到几十TB。
你要存这些数据，要建索引，要扛上报流量，要给查询留够资源。钱是一方面，更麻烦的是性能损耗。全量采样从来不是链路追踪的最优解，只是新手最容易踩的第一个坑。客户端要占线程打包trace数据，要走网络上报，本来几十毫秒能完成的请求，光trace上报就能多耗十几毫秒。我见过最夸张的团队，开了全量采样之后，核心接口的平均延迟直接涨了12%。
真要算细账，全量采集的模式下，99%的trace数据是永远不会被人翻出来看的。它们安安静静躺在存储集群里，占着磁盘空间，每月准时生成账单，直到过了保留期被自动删除。
固定采样率的隐形漏洞
踩完全量的坑，大部分团队会退一步，选个固定采样率。比如10%，或者5%。配置写在配置中心，发布完就再也没人管。
省成本是真省。但漏洞也是真的藏得深。
你想，平时流量平稳的时候，10%的采样率好像足够覆盖日常的排查需求。但真出问题的时候——比如某个接口的500错误率突然飙到30%，这时候的采样逻辑是不管请求成功失败，都按10%的比例随机抽。那很可能你翻遍了所有留存的trace，全是正常返回200的请求，那些真正报错的请求，刚好全在被丢弃的90%里。
上次帮朋友查这类问题，翻了三个小时的trace日志，发现所有错误请求的采样标记都是false。当时差点把键盘砸了。
固定采样率最大的问题，是对所有请求一视同仁，完全不区分请求的状态和重要性。你要是想靠调高采样率解决问题，调到100%就是走回全量的老路，调到50%成本直接翻五倍，大部分采到的还是没人看的正常请求，纯浪费。
之前有团队做过统计，他们系统里99.9%的请求都是正常返回的，这些请求的trace，除了定期梳理链路拓扑的时候会拉出来看两眼，平时根本没人动。但就是这些没用的数据，占了采样存储成本的九成以上。
动态采样才是真的在解决问题
折腾过全量、踩过固定采样的坑之后，大部分团队最后都会绕到动态采样的逻辑上。
这事没那么玄。
说白了就是给不同的请求定不同的采样规则，不搞一刀切。什么请求必须100%采？报错的、延迟超过阈值的、带内部测试标记的、VIP用户发起的请求。什么请求可以少采？那些返回200、延迟在正常范围内、来自普通用户的批量请求，可能采0.1%就够了。
但这里有个很容易被忽略的细节：动态采样也不能无限制的全采错误请求。万一真碰到大规模故障，一秒钟上千个500错误，你要是100%把这些trace全上报，瞬间涌来的流量直接能把链路追踪的后端打挂。本来只是业务接口出问题，现在连追踪系统都瘫了，雪上加霜。
所以得给采样设个流量上限。动态采样的核心不是”多采”，是”该采的一个不漏，不该采的一个不多拿”。
我见过落地比较舒服的一套配置：先搭一个全局的基础采样率，比如1%，兜住所有正常流量的基本盘。所有返回4xx、5xx状态码的请求，直接拉到最高优先级，不管全局比例是多少，这些请求的trace必须留。延迟超过P99阈值的请求，同样按全量采集处理。最关键的是得留个硬上限，比如每秒最多采集1000条trace，超过的部分就算是错误请求，也按照比例降采样，绝对不能把后端打垮。
之前那个被四十万账单压得头疼的朋友，后来把全量采样换成这套动态规则，ES的存储成本直接降了82%，故障trace的覆盖率反而从之前的30%涨到了100%。他当时跟我说，早知道调整配置就能解决问题，之前干嘛要硬扛三个月。
很多人觉得采样策略就是个不起眼的技术配置，没什么好深究的。真等你凌晨三点被告警叫起来，翻了半小时找不到关键故障trace的时候，就知道当初在这上面花的十分钟，能帮你省掉多少麻烦。