Windows
macOS
Android
iOS
链路追踪排障方法的难点，往往不在于不会打开 Jaeger 或 Grafana Tempo，而在于看到的链路并不等于真实发生过的全部调用。高并发服务可能只保留部分请求，异步消息也可能因上下文传递中断而形成断链。排查前先确认采样规则和拓扑边界，才能判断一条“正常链路”是否真的代表系统状态。
先识别采样率造成的假象
固定比例采样适合控制存储成本，但它可能漏掉低频、高延迟或偶发错误请求。例如采样率为百分之一时，一次只发生几十次的异常调用可能完全没有样本。若用户反馈“偶尔超时”，仅凭追踪系统中留下的成功请求下结论，风险很高。
区分三种采样方式
- 头部采样：请求刚进入系统时决定是否记录，开销可控，但当时尚不知道请求最终是否失败，容易漏掉慢请求。
- 尾部采样：等待链路结束后，按错误、延迟或状态码保留记录，更适合捕获异常，但需要暂存数据并增加收集端资源压力。
- 按条件采样：对特定接口、错误码、租户或发布版本提高比例，适合短期专项排查，结束后应恢复常规规则。
实际操作时，可先在 OpenTelemetry Collector 中检查采样配置，再核对 Jaeger 或 Tempo 接收到的 trace 数量。不要把存储中的链路数量直接当作请求总量；应与网关访问日志、应用指标中的请求计数进行时间窗口对照。若两者差距突然扩大，优先检查采样配置变更、Collector 丢弃和上游批量发送失败。
用异常优先策略补足低概率问题
链路追踪排障方法进阶时，应把“是否异常”放在“是否完整”之前。针对支付回调、文件处理、库存扣减等不能频繁复现的场景，可以保留所有错误状态、明显超时和重试次数过高的链路；普通成功请求则采用较低比例采样。延迟阈值不宜脱离业务设置，通常应结合接口正常响应范围、超时配置和下游依赖的处理时间调整。
异常链路要留下足够上下文，但不应在生产环境无期限提高全量采样。专项规则应设定适用接口、持续时间和回滚条件。
如果采用尾部采样，要确认一个完整 trace 的所有 span 能在等待窗口内到达。消息队列、批处理或长事务可能持续数十秒甚至更久，等待窗口过短会让后续 span 迟到，导致系统按不完整链路处理。窗口过长则会增加内存占用，因此应结合最长业务步骤和 Collector 的资源限制进行压测或分阶段调整。
排查拓扑盲区，而不是只盯着服务节点
拓扑可视化常把服务显示成几个清晰的节点，但真实路径还可能经过反向代理、服务网格、消息代理、数据库连接池和第三方接口。任何一段没有注入 trace context 的边界，都会把一条链路切成多个孤立片段。
常见断点与检查顺序
- 检查入口代理是否转发 traceparent 等标准请求头，并确认应用框架没有在重试时生成不一致的上下文。
- 检查 Kubernetes 服务之间的调用是否经过 Istio 或其他网格代理；若代理产生独立遥测数据，要核对服务名和 trace ID 是否能够关联。
- 检查消息生产者是否把上下文写入消息属性，消费者是否在创建新 span 前正确提取，而不是把每条消息都作为全新根链路。
- 检查数据库、缓存和第三方 HTTP 客户端的埋点是否覆盖实际使用的连接库。只看到应用 span，不代表数据库操作已经被记录。
- 用日志中的 trace ID、span ID 反查孤立记录，再与请求时间、实例名称和版本号比对，确认断点发生在哪个发布版本。
异步场景尤其容易误判。一个订单请求可能只记录到“发送消息”，真正的库存处理在消费者服务中完成。如果生产者和消费者没有共享上下文，前端看似快速返回，后台失败却无法归入原请求。此时应同时观察消息积压、重试次数和消费者错误日志，而不是只分析入口 span。
把链路、指标和日志放进同一排障流程
单条追踪适合解释一次请求，指标适合发现趋势，日志适合补充具体错误内容。有效的链路追踪排障方法应按“指标发现范围、链路定位路径、日志确认原因”的顺序执行。
- 先按服务、接口、区域、实例和版本查看错误率、请求量与延迟变化，确定问题开始时间。
- 再筛选该时间段内的错误或慢链路，比较不同服务节点的 span 时长，区分入口等待、网络调用、锁等待和下游处理。
- 最后使用 trace ID 查询结构化日志，确认异常堆栈、参数校验结果、重试原因以及具体依赖返回的状态。
如果指标显示错误率升高，但追踪平台没有对应错误链路，通常要检查采样决策、数据上报失败、时钟偏差和查询过滤条件。若链路数量正常却无法形成完整拓扑，则重点查看上下文传播和异步边界。每次调整后都应记录采样规则、Collector 版本、应用版本与生效时间，便于回溯。
常见问题
采样率越高，排障效果一定越好吗？
不一定。高采样率会增加应用、网络和存储压力。对异常请求采用条件采样，通常比长期全量采样更实用。
为什么日志有 trace ID，平台却搜不到链路？
可能是链路被采样丢弃、数据尚未到达、查询时间范围不正确，或日志与追踪系统使用了不同的 ID 字段。
异步消息必须和原请求共用一个 trace ID 吗？
应传递上下文并保持可关联关系，但具体 span 仍应体现生产和消费两个阶段，不能把长时间异步处理伪装成同步调用。
拓扑图显示正常，为什么用户仍然超时？
拓扑图可能隐藏了未埋点的代理、队列或第三方依赖，也可能只展示被采样的成功请求。应结合超时链路、指标和日志交叉验证。
归根结底，链路追踪排障方法的核心不是收集更多图形，而是明确哪些请求被记录、哪些边界没有被覆盖，以及异常证据能否相互印证。