上个月帮杭州一个做生鲜电商的朋友排障，618大促那晚，用户付完款跳回订单页，要么显示“待支付”，要么直接跳空白。整个技术群从凌晨两点吵到四点，前端说后端接口返回的订单状态不对，后端说支付回调根本没推过来，运维甩锅说网关日志全是200，谁都拿不出实锤。
最后折腾到快五点，还是个后端开发手动在日志里搜用户的手机号，逐行比对时间戳，才发现是优惠券服务的一个灰度版本超时，还没打错误日志。所有人熬到天亮，连个追责的依据都找不到。
没有链路追踪的排查全是玄学
这种场景我见过不下十次。没有链路追踪的分布式系统，排查问题全靠碰运气。每个服务的日志都是散的，没有统一的请求ID，你想找一个用户的完整请求路径，得翻前端的console、网关的访问日志、支付服务的回调记录、订单库的操作日志，还要对着时间戳差个一两秒的误差，跟大海捞针没区别。
说真的，那种感觉就像你家马桶堵了，你不知道是楼上哪层扔的头发，只能挨个敲门问，敲到最后人家说不是我，你还没辙。上次那个生鲜电商的问题，要是有链路追踪，点进去就能看到优惠券服务的节点耗时3秒，直接定位，至于熬到天亮？
别把链路追踪当成只给运维用的工具
很多团队对链路追踪的误解真的太大了。觉得这是运维的事儿，运维搭好平台，开发只要把服务注册进去就行，剩下的跟自己没关系。说实话，见过太多这种情况，运维吭哧吭哧搭了Jaeger，跑起来了，结果业务服务的埋点只加了网关和下单服务，中间的优惠券、库存、消息推送全没接，链路走到一半就断了，跟没装一样。
链路追踪的核心从来不是那个可视化的后台界面，是每个服务都要把请求的上下文透传到底。什么是上下文？就是从网关进来的那个唯一的trace ID，要跟着请求走遍所有节点，哪怕是异步的消息队列，也要把trace ID塞到消息头里，不然异步链路直接断，你根本查不到消息有没有被消费，消费的时候有没有报错。
我之前见过一个团队，异步发消息的时候忘了塞trace ID，结果每次用户支付成功了，通知短信没发出去，查了一周，才发现是消息队列的消费者那边根本没拿到trace ID，链路直接断在生产端，谁都不知道消息到底发出去没有。就这，还有人说链路追踪没用？是你自己没埋对。
落地的时候别贪大求全
很多团队一上来就搞大的，说要把所有服务、所有接口、甚至所有定时任务全接上链路追踪，搞了半个月，埋点代码写了一大堆，还没上线，业务方天天催着排障，谁等你？
真的，先抓核心链路就行。比如电商的核心链路就是“用户点下单-校验权限-扣库存-算优惠券-调支付接口-写订单库-发通知”，就这7个节点，先把这几个的埋点接上，用OpenTelemetry的自动埋点插件，Java服务直接加个javaagent，5分钟就能接入，不用改业务代码，跑通了再说别的。
对了，选平台也别贪贵，开源的Jaeger或者Zipkin就够小团队用了，别上来就买几十万的商业方案，你那点流量，根本跑不满人家的功能，纯纯浪费钱。我之前见过一个创业团队，花了二十多万买商业可观测平台，最后连核心链路的错误率都看不全，为啥？因为埋点都是拍脑袋加的，根本没对着业务流程走一遍。
别听那些厂商吹的什么全链路可观测，你先把核心那10%的链路搞明白，能解决80%的线上排查问题就够了。上次我帮一个做社区团购的团队落地，就花了一下午，把核心下单链路接上，之前每次出问题要查2小时，现在打开链路追踪，点进去看哪个节点红了，哪个节点耗时超过1s，10分钟就能定位问题，老板都夸我们效率高。
没人愿意半夜被电话叫起来查日志。对吧？你装行车记录仪，总不能只装车头不装车尾吧？链路追踪也是一个道理，漏了哪个节点，哪个节点出问题你就瞎。下次再遇到分布式系统的破事，别上来就翻几百行日志，先去链路里找那个trace ID，试过一次你就回不去了。