上周三凌晨两点十七分，我放在床头柜上的工作机震得快把玻璃震碎。钉钉上三十多条未读，全是电商大促的告警：用户端支付成功率掉了42%，所有服务的CPU、内存指标全绿，日志翻了三小时没找到问题在哪。
支付团队说自己接口响应平均耗时80ms，完全在阈值内。订单团队说收到的请求参数全对，没有异常。风控团队翻了自己的错误日志，连一条ERROR级别的记录都没有。就连对接的三方支付渠道，都甩过来一长串成功回执的截图。
大家隔着钉钉群互相甩锅，甩到天快蒙蒙亮的时候，才有人想起——三个月前为了应付架构评审，我们其实在各个服务里埋了链路追踪的探针，只是一直没把采集规则开全。
那些排障排到崩溃的夜晚到底缺了什么
把采集规则切到临时全量模式，花了两分钟拉取对应时间段的调用拓扑，所有人都沉默了。
原来问题根本不在大家翻了几百页日志的核心服务里。是风控服务调用用户画像服务的边缘节点，在大流量下触发了连接池的静默超时——这个超时被服务内部的熔断逻辑兜住了，对外返回的是不带任何错误标识的空响应，既不会抛异常打错误日志，也不会触发服务自身的告警阈值。
我当时盯着面板上那根标红的、耗时1.2s的调用线，差点把手里温掉的冰可乐捏爆。
说真的，这种“所有监控全绿但用户就是用不了”的故障，在微服务架构下真的太常见了。单服务的监控只能看到自己内部的指标，日志只能记录自己处理过程中抛出来的异常，那些跨服务的、藏在连接池、熔断逻辑、异步线程里的隐性问题，没有链路追踪串起来的话，你就算把服务器的根目录翻遍，也未必能找得到问题在哪。
别把链路追踪只当成监控工具的附属品
我见过太多团队，对链路追踪的认知还停留在“可观测性三件套凑齐就行”的阶段。
花大价钱买了商业版的可观测平台，把链路追踪模块当赠品用，接回来就默认开全量采集，跑个三天，存储磁盘被trace数据撑满，服务因为上报数据占了太多带宽，响应速度直接慢了20%，然后就骂骂咧咧把整个链路追踪功能关了，说这东西纯纯是负担。
其实链路追踪的核心价值从来不是“无死角记录所有请求”。它真正能帮你解决的问题，是把一次用户请求从前端到后端、从业务服务到数据库缓存、从同步调用到异步消息的全路径，按照时间顺序拆解成一个个独立的Span节点，让你一眼就能看到到底是哪个环节拖了后腿。
之前接触过一个做本地生活的团队，一开始踩了全量采集的坑，后来把采样规则改成了分层模式：核心交易链路（从用户下单到支付完成的全路径）100%采样，非核心的内容推荐、用户画像查询链路只采1%，遇到请求报错、响应超时的场景自动触发全量补采。调整完之后，每天产生的trace数据量从之前的80G降到了7G，排障的时候从来没漏过关键的故障链路。
别贪多。
真的没必要追求100%的请求覆盖率，你把那些真正影响用户体验的核心链路串通，就已经能解决80%以上的线上排障问题了。
真正好用的链路追踪从来不是靠买出来的
很多厂商在宣传的时候，总爱说自己的链路追踪是“无侵入零代码接入”，好像只要装个探针，就能把所有的链路串得明明白白。
真碰到复杂的异步场景，这些自动探针十有八九会掉链子。
上次我们排查一个消息队列的消费延迟问题，找了快两个小时，才发现自动探针根本没把MQ生产端的traceID透传到消息头里，消费端拿到的traceID是全新生成的，跟生产端的链路完全接不上。后来我们手动在生产端把traceID塞进消息的自定义头，消费端取出来顺着线程上下文透传，才把整个异步链路完整串了起来。
说实话，那些自动探针能覆盖普通的同步HTTP调用就不错了，碰到跨线程的异步任务、批处理作业、自定义的RPC框架，你不手动补几个埋点，根本别想拿到完整的链路数据。而这些补埋点的工作，没有哪个厂商会帮你做。
别一上来就想着把所有服务全接进链路追踪体系。先从你最常出故障的核心交易链路开始，把网关、核心业务服务、数据库、三方接口的路径先串通，能拉出完整的耗时瀑布图，能顺着traceID在十分钟内定位到具体的慢节点，这就已经跑赢大多数团队了。剩下的边缘链路，后面慢慢补就行。
我到现在都记得上次那个凌晨的故障，从打开链路追踪面板到定位问题，只花了不到三分钟。之前三小时的无效翻日志，跟这三分钟的精准定位比起来，真的显得特别讽刺。