链路追踪数据采样策略的落地账本

上周在1024南京展区蹲路边跟几个SRE朋友喝冰美式，聊了没十分钟，话题全歪到了链路追踪的采样配置上。

有人刚上了追踪系统两周，云厂商账单下来吓一跳。有人连续三次线上故障，翻遍追踪平台找不到对应链路，最后靠业务日志硬拼调用路径，多花了俩小时排障。

先算清楚全量追踪的糊涂账

很多团队刚上链路追踪的时候，第一反应是开100%全量采样。爽是真爽——所有调用路径、延迟、错误码全在眼前，排查问题的时候想翻哪段翻哪段。

全量采样从来不是默认选项，是烧钱换确定性的奢侈品。按单次请求平均生成12个span算，峰值每秒1万次请求的中等规模集群，一天光span的存储量就能吃掉三个SSD节点的配额，查询时还会挤占ES集群的计算资源。上次有个朋友为了查5分钟的慢调用，光等索引分片对齐就等了20分钟。

说穿了，你线上跑的请求里，90%都是完全正常的快速成功请求——这些链路存下来，除了占存储，几乎没有任何排查价值。真要碰到故障，你需要的从来不是所有请求的全量日志，是那几个能定位根因的关键链路。

固定比例采样的天生bug

被全量账单坑过的团队，转头就会切到最常用的固定比例采样：10%、5%、1%，选一个看起来不心疼的数就跑。

固定比例采样的最大问题是对异常场景的无差别过滤。你按10%的比例采，表面上看是把所有类型的请求都按均等概率筛了一遍，实际上因为正常请求的基数比异常请求高两个数量级，筛出来的样本里99%都是毫无排查价值的快速成功请求，真正需要定位根因的慢调用、报错请求、触发熔断的特殊流量，早就在采样的第一步被滤掉了。

我见过最离谱的配置，是某团队把采样比例设成了1%。连续三次线上p99延迟飘高，运维翻遍追踪系统，找到的全是200ms以内的正常请求，根因在哪完全没线索。最后还是靠应用日志里的错误堆栈，硬拼出来跨服务的调用链，折腾到后半夜才定位到是下游缓存集群的连接池配置错了。

麻烦在于，很多人觉得固定比例采样是“公平”的。根本不是。异常请求占比本来就低，按比例采大概率直接漏掉，等你真要查问题的时候，才会发现自己采了一堆没用的正常流量，关键的故障链路一条没存。

现在没人敢拍胸脯说自己的采样策略最优

折腾完全量、固定比例的坑，大家才开始琢磨更灵活的采样规则。最常见的是尾部采样：请求先不着急丢，等整个链路走完，判断这个请求是不是报错、是不是超时、是不是触发了熔断，符合异常规则的就全量存，正常请求就直接扔。

尾部采样的代价是内存开销的线性上涨。你得把没走完的链路span全缓存在本地内存里，正常请求200ms走完还好，要是碰到个卡了10秒的慢请求，你就得把这10秒内的相关span全占着内存等它结束。碰到流量洪峰的时候，采样器OOM是常事。

还有人做分层采样：核心交易链路的异常请求全量存，正常请求存5%；非核心的内部工具链路，不管正常异常都只存0.5%。规则加得越多，采样器本身的计算开销就越大——别小看这点开销，每秒几万请求的量级下，采样器多花1ms处理每个请求，整体链路的延迟就能上去一截。

说实话，现在聊链路追踪数据采样策略，根本没人敢说自己的配置是最优的。没有放之四海而皆准的模板。你做内部办公系统，一天总共几千个请求，全量采又能花几个钱？你做大促峰值每秒几十万请求的电商核心链路，还敢全量采，财务能追着你骂三栋楼。

昨天那个一开始蹲路边吐槽采样的朋友，今天给我发消息，说他们把之前的固定10%采样改成了分层规则，存储成本直接降了60%，上周的慢调用问题，一翻就找到了对应的链路。

就这么个事。没那么玄。