凌晨三点那通电话
电话响的时候，我正梦见自己把线上数据库删了。真的，吓醒。值班同事说，支付成功率从99.6掉到87，持续了六分钟。群里已经有人在猜：MySQL 慢查询？MQ 堆积？还是刚发的版本有 bug？
我打开监控大盘，红得刺眼。但指标只能告诉你哪里疼，不能告诉你谁捅的。CPU 高、错误率涨、RT 飙升，全挤在一起。那感觉像急诊室里一堆人喊疼，你分不清谁先流血。
后来靠链路追踪，我们花了大概四分钟定位：一个不太起眼的用户画像服务调用超时，拖垮了上游线程池。不是数据库。也不是 MQ。是那个平时没人看的旁路接口。说实话，那晚要是没有 trace，我可能得背一口锅到天亮。
不过话说回来，链路追踪也不是装个 agent 就完事。很多团队上了它，出故障时还是靠 grep 日志，为什么？因为埋得不对，采得不对，看的人也不对。
它到底追的是什么
先把词拆开。链路追踪，英文 tracing。核心就两个东西：TraceID 和 Span。TraceID 是一次请求的身份证，Span 是请求经过每个环节的小记录。入口生成 TraceID，经过网关、服务 A、服务 B、数据库、缓存、消息队列，都往同一个 TraceID 上挂信息。最后拼成一棵树，或者一张火焰图。
它和日志不一样。日志是点，链路是线。日志告诉你这个服务报错了，链路告诉你这个错误从哪来、到哪去、在谁身上卡了多久。对吧？尤其是微服务，一次下单能穿过七八个服务，没有线，你只能靠猜。
上下文传播是灵魂。HTTP 请求里塞 header，gRPC 走 metadata，异步线程要手动传。Java 里 ThreadLocal 那道坎，踩过的人都懂。线程池一换，TraceID 就断了。断了以后，你看到的是一堆孤零零的 Span，像断线的风筝。很烦。真的。
再说采样。全量采集当然爽，但成本也爽。高流量系统一天几个 T，存储先报警。头部采样在入口决定，简单，但可能漏掉慢请求。尾部采样等链路结束再判断，适合抓异常，但实现复杂。小团队别一上来追求完美，先保证错误链路和慢链路能留下。
埋点埋得好 不如采样策略对
我见过最可惜的场景：链路追踪接入了半年， dashboard 很漂亮，可真出事时查不到。原因也简单——采样率设了 0.1%，异常请求刚好没被采到。或者只埋了服务间调用，没埋数据库和缓存。结果 trace 里只有 RPC，没有 SQL。那跟看一半剧本有什么区别。
还有人把 trace 当日志搜索用，输入 TraceID 找日志。这没错。但更值钱的是把 trace 和 metrics、logs 串起来。指标发现异常，trace 定位瓶颈，日志解释原因。三者缺一，排障就靠运气。
另外，别忘了业务属性。只记录 HTTP 状态码不够。订单 ID、用户 ID、租户 ID、支付渠道，这些标签在排查时能救命。但别乱加。高基数标签会把存储和查询拖死。用户 ID 这种，最好做哈希或者只在异常时保留。
小团队怎么落地不折腾
如果你的团队刚开始，别想着自研。OpenTelemetry 这类标准先跑起来，SDK 接进去，后端用 Jaeger、Tempo、SkyWalking 都行。关键不是选型，是统一。统一传播格式，统一采样规则，统一告警入口。
落地时抓这几件事：1 入口生成 TraceID，网关和前端请求都带上；2 跨线程传递上下文，线程池、反应式编程、消息消费都要测；3 把数据库、缓存、MQ 埋上，不然链路是断的；4 采样策略分环境，生产别全采，也别低到查不到；5 告警里塞 TraceID，值班人点一下就能跳转。
还有团队协作。可观测性不是运维一个人的事。开发写代码时顺手埋点，比事后补快十倍。SRE 定采样和保留策略，产品关注核心链路转化。每周挑一条真实故障复盘，把 trace 截图丢进文档，比培训十次都管用。
别把它当银弹
链路追踪能解决什么？缩短定位时间。把“大概在支付服务”变成“在支付服务的第三个下游调用，耗时 2.3 秒”。这就够了。它解决不了业务逻辑错误，也解决不了烂代码。一个循环查数据库，trace 只会告诉你它慢，不会帮你重写。
边界要清楚。没有它，现代分布式系统就像关灯修电路。有了它，也别指望一夜之间变成 SRE 标杆。工具是工具，流程和人才是另一半。那晚之后，我们没删掉任何服务，只是加了一条超时和一条熔断。链路追踪让我少背一口锅，也让我知道，锅不是靠猜甩掉的。