当线上接口响应时间从 200ms 飙升到 2s，你首先想到什么？数据库慢查询？网络抖动？还是某个下游服务超时？如果没有链路追踪，你只能凭直觉逐个服务排查，而有了链路追踪，你可以像看地图一样，沿着一次请求的调用链，精确找到耗时最高的那个瓶颈节点。
本文将从实际问题出发，介绍如何利用链路追踪定位慢请求的瓶颈节点，并结合 Prometheus 和 OpenTelemetry 等工具，给出可操作的排查步骤和取舍建议。
为什么普通监控找不到瓶颈？
传统的监控工具（如 Prometheus）擅长采集指标，比如每个服务的平均响应时间、错误率、CPU 使用率等。但指标是聚合的，无法告诉你某一次慢请求具体经过了哪些服务、每个服务耗时多少。例如，Prometheus 可以显示“订单服务平均响应时间 500ms”，但无法解释为什么这笔订单的响应时间长达 3s。
链路追踪（Distributed Tracing）则不同，它记录一次请求从入口到出口的完整调用链，包含每个服务（或方法）的耗时、状态和依赖关系。通过查看调用链的火焰图或时间线，你可以迅速发现耗时最长的那个节点，这就是瓶颈节点。
链路追踪的核心概念：Trace 与 Span
要使用链路追踪，你需要理解两个基本概念：Trace 和 Span。
- Trace：一次请求的完整生命周期，从客户端发起请求到最终响应，由多个 Span 组成。
- Span：Trace 中的一个单元，代表一次操作，比如一个 HTTP 调用、一个数据库查询或一段业务逻辑。每个 Span 有开始时间、结束时间、名称和可选的标签（如 HTTP 状态码）。
例如，一个典型的电商下单请求可能包含：网关 Span、订单服务 Span、库存服务 Span、数据库 Span 等。通过 Trace，你可以看到每个 Span 的耗时，从而定位哪一步最慢。
排查慢请求的实操步骤
步骤 1：选择链路追踪工具
市面上有多种链路追踪实现，如 Zipkin、Jaeger、SkyWalking，以及标准化的 OpenTelemetry。OpenTelemetry 是目前业界主流的开源可观测性框架，它提供了统一的 API、SDK 和导出协议，支持多种语言，且被众多厂商支持。如果你要开始新的项目，建议直接采用 OpenTelemetry 进行埋点，因为它不锁定厂商，未来可以灵活切换后端。
部署时，你需要一个后端来存储和展示 Trace 数据，可以是 Jaeger、Zipkin 或云厂商的 APM 服务。OpenTelemetry 可以导出数据到这些后端。
步骤 2：为关键服务添加埋点
埋点（Instrumentation）是链路追踪的基础。你可以手动埋点，也可以使用自动埋点（如 OpenTelemetry 的 Java Agent、Python Agent 等）。自动埋点通常能捕获 HTTP 请求、数据库调用等常见操作，但业务逻辑中的复杂路径可能需要手动添加 Span。
// 以 OpenTelemetry Java 为例，手动创建一个 Span
tracer.spanBuilder("processOrder").startSpan();
// 执行业务逻辑
span.end();在关键流程（如支付、下单）中，确保每个外部调用（HTTP、RPC、DB）都有对应的 Span，这样才能完整还原调用链。
步骤 3：搜索慢请求的 Trace
当线上出现慢请求时，你可以通过链路追踪系统的查询界面，按服务名、耗时阈值（如 >2s）、时间范围等条件搜索 Trace。例如，在 Jaeger 中，你可以设置“Min Duration”为 2s，快速找到所有慢请求的 Trace。
点击一个慢请求，你会看到它的完整调用链。此时，重点观察每个 Span 的耗时，找出耗时占比最大的节点。通常，瓶颈节点会以红色或较长的条形突出显示。
步骤 4：结合指标进一步分析
链路追踪告诉你“哪里慢”，但有时还需要知道“为什么慢”。此时可以结合 Prometheus 等指标系统。例如，如果瓶颈节点是数据库 Span，你可以查看 Prometheus 中数据库连接池的指标，确认是否连接数耗尽；如果是某个下游服务 Span，可以查看该服务的 CPU、内存、GC 等指标。
Prometheus 是一个开源系统监控和告警工具，它采集并存储时间序列数据，每个指标都带有时间戳和标签。你可以将 Prometheus 的指标与 Trace 的标签（如 service.name）关联，从而在定位到瓶颈节点后，进一步分析其资源使用情况。
步骤 5：验证修复效果
定位到瓶颈节点后，进行针对性优化（如增加缓存、优化 SQL、扩容等）。然后，重新观察该节点的 Span 耗时，确认是否下降。同时，持续监控慢请求的数量，确保问题彻底解决。
取舍与常见误区
误区 1：采样率越高越好
全量采集 Trace 会带来较大的性能开销和存储成本。通常建议采用采样策略，比如只采集错误请求和一定比例的普通请求（如 10%）。OpenTelemetry 支持多种采样策略，你可以根据业务重要性调整。
误区 2：只关注单次 Trace
单次 Trace 可能具有偶然性，比如网络抖动导致某一跳变慢。应该结合多次 Trace 的统计，如 P99 耗时，来确认瓶颈是否稳定存在。
取舍：自动埋点 vs 手动埋点
自动埋点成本低，但可能无法覆盖业务逻辑的细节；手动埋点灵活，但需要开发成本。建议先使用自动埋点覆盖大部分场景，再对关键业务路径添加手动埋点。
注意：Trace 与日志、指标的关系
链路追踪不是万能的，它只能告诉你“调用链”，但无法替代日志和指标。最佳实践是三者结合：Trace 负责定位瓶颈节点，指标提供资源视角，日志提供错误详情。OpenTelemetry 正是统一了这三类信号的框架。
实战案例：一个慢请求的排查过程
假设一个电商系统的“提交订单”接口变慢，平均耗时从 500ms 涨到 3s。你在链路追踪系统中搜索到该接口的 Trace，发现调用链包含：网关（50ms）→ 订单服务（300ms）→ 库存服务（2.5s）→ 数据库（200ms）。显然，库存服务是瓶颈节点。
进一步查看库存服务的指标，发现其连接池活跃连接数达到上限，且 GC 时间较长。结合代码，你发现库存服务在调用外部库存系统时使用了同步 HTTP 调用，且没有超时设置。于是，你改为异步调用并设置超时，优化后库存服务耗时降到 300ms，接口整体恢复到 600ms。
这个过程展示了链路追踪如何帮助你快速缩小范围，而不是盲目地排查所有服务。
总结
链路追踪是定位慢请求瓶颈节点的利器。通过 Trace 和 Span，你可以还原一次请求的完整路径，快速找到耗时最长的节点。结合 Prometheus 等指标系统，还可以深入分析瓶颈原因。在实际应用中，注意采样策略、结合多种信号、避免只关注单次 Trace，这样才能高效解决慢请求问题。
参考资料
- OpenTelemetry 官方文档 – 了解 OpenTelemetry 框架的安装、配置和 API。
- Prometheus 官方文档 – 了解 Prometheus 的指标采集和查询。
延伸阅读