链路追踪不是装个SDK就完事
2026-11-11 07:26:35
作者：
fawen
上个月帮河西做本地生鲜的老伙计排查线上问题。
那天他们做店庆大促，APP点提交订单之后，一半用户要等十多秒才能跳支付页。
运维盯着各个服务的监控面板看，CPU、内存、数据库连接池全在正常阈值里，没一点异常。
日志翻了三小时。
眼都花了。
最后是临时把尘封了半年的链路追踪面板打开，才一眼揪出来问题——库存服务调第三方物流预估接口的时候，超时阈值设成了8秒，那天第三方节点抽风，每个请求都卡7.9秒才返回，单看每个服务的日志，谁都没觉得自己有问题，串到一起才发现，整整三分之一的时间全耗在这个第三方调用上了。
很多团队从一开始就把链路追踪用偏了
说实话，太多人对链路追踪的认知还停留在“运维出问题了才翻的监控工具”。
就像我那个生鲜朋友，当年花了十几万采购的APM平台，SDK装完就扔在运维机房，开发团队没人看，告警规则全是默认的，连traceId怎么往下游传都没人管。
很多人觉得链路追踪就是个画调用图的工具，点进去能看到服务之间的调用关系就够了。哪有那么简单。
分布式链路追踪调用链火焰图示例
真正好用的链路追踪，是把用户从点下按钮开始的每一步——网关鉴权、订单创建、库存扣减、优惠券核销、支付单生成——所有的耗时、错误、参数透传，全串在同一个traceID下面。
我见过太多团队，traceId只在网关层打了日志，后面的服务调用的时候根本没把这个ID往下传，等出了问题要串全链路的时候，拿着半截的日志，根本拼不出来完整的请求路径。
这不等于白装吗。
那些看起来很美的配置，全是坑
刚上链路追踪的团队，最容易犯的错就是怕漏数据。
我之前在徐庄软件园见过个创业公司的CTO，拍脑袋说要100%全量采样，生怕哪个出问题的请求没被记录到。结果跑了不到两周，存储账单翻了三倍，面板点一下要转半分钟的圈，查询的时候慢到让人想摔鼠标。
链路追踪采样策略配置界面示例
更搞笑的是，后来他们觉得成本太高，直接把采样率砍到1%，结果店庆当天出故障的时候，刚好把那个报错的请求给采样滤掉了，整个技术组在会议室对着空的面板，当场僵住。
现在想起来那个账单，他们技术负责人还拍大腿，说当时脑子一热，差点把当月的服务器预算全造完。
正确的采样逻辑根本不是非黑即白的。正常的无报错请求，采1%足够覆盖日常观测需求；只要是报错的、耗时超过接口P99阈值的请求，不管占比多少，全量采集。
还有人喜欢给链路加一堆没用的标签，什么用户头像地址、商品详情快照，存了一大堆，真要查问题的时候半毛钱用不上，还把查询速度拖得慢到离谱。
对了，上次有个开发跟我说，他们之前把链路追踪的告警直接接到了值班手机上，结果半夜三点因为一个测试环境的请求报错，把三个人全叫起来了，折腾半天才发现是测试的人忘关告警规则了。
真要落地，别一开始就搞大而全
很多团队一上来就想把几十个微服务全接上链路追踪，搞全链路的可观测体系，最后折腾俩月，成本超了，效果还没出来，就把这套东西扔在角落吃灰。
真要落地，先抓核心。
第一步，别贪多，先把最近三个月出过最多线上问题的三个核心链路——一般就是下单、支付、登录——的traceId透传搞明白。网关传ID，每个服务接收ID，调下游的时候主动带上，日志里把traceId打全。就这一步，就能解决80%的跨服务排查问题。
第二步，别搞花里胡哨的自定义规则，先把最基础的告警配好。只要某个链路的错误率超过1%，或者P99耗时比日常基线高50%，直接推到技术值班群。别等用户打电话投诉到客服了，才知道系统出问题了。
第三步，别光出问题了才想起链路追踪。每周抽半小时，拉上开发和运维对着链路面板过一遍，看看哪些慢接口是真的有优化空间。我之前跟一个做本地外卖的团队聊，他们就靠这招，每次大促前把核心链路每个节点的耗时列出来，哪个节点超过200ms就必须优化，去年双十一的下单成功率从92%涨到99.2%，全程没出过大的故障。
其实链路追踪从来不是什么高大上的黑科技。
说白了就是给你的分布式系统装了个行车记录仪。
装了不用，等于白花钱。
装了乱设置，真出事的时候照样抓瞎。
上次那个生鲜的老伙计，后来把采样逻辑改了，把三个核心链路的traceId透传顺了，上个月做店庆活动，有个用户反馈支付流程慢，他们从打开链路面板到定位到第三方物流接口的超时问题，只用了47秒。
换之前？
他们得翻至少三个小时的日志。
免责声明：市场有风险，选择需谨慎！此文仅供参考，不作买卖依据。如有侵权请联系删除。
文章名称：
链路追踪不是装个SDK就完事
文章链接：https://m.itcdj.com/news/720.html