OpenTelemetry 落地实战：我把跨服务超时定位从 90 分钟压到 8 分钟（附 trace 采样策略）

OpenTelemetry 落地实战：我把跨服务超时定位从 90 分钟压到 8 分钟（附 trace 采样策略）

凌晨 1 点，支付链路 P99 从 280ms 突然跳到 2.4s。

最痛苦的不是慢，而是大家都在猜。网关说下游慢，订单说库存慢，库存说数据库慢。三组人对着各自日志互相甩锅，90 分钟过去了还没锁定根因。

这次我把 OpenTelemetry 真正落到生产，把根因定位时间从 90 分钟压到 8 分钟。下面是完整可复现方案。

为什么以前定位慢

我们之前只有三类观测：

• 应用日志
• Prometheus 指标
• Nginx access log

这三类都重要，但都缺了一个关键维度，调用链上下文。

一次请求跨 6 个服务，日志里根本看不到完整路径。指标只能告诉你某服务慢，不能告诉你它在这条请求里为什么慢。

我做的最小可用链路追踪

我没有一上来就全量采样，而是先做最小闭环：

1. 网关注入 traceparent
2. 核心 6 个服务透传 context
3. Collector 聚合后写入 Jaeger
4. 只对慢请求和错误请求提采样

Collector 配置（精简版）：

receivers:otlp:protocols:grpc:http:processors:batch:tail_sampling:decision_wait:10snum_traces:50000policies:-name:errorstype:status_codestatus_code:{status_codes:[ERROR]}-name:slowtype:latencylatency:{threshold_ms:800}exporters:jaeger:endpoint:jaeger-collector:14250tls:{insecure:true}service:pipelines:traces:receivers:[otlp]processors:[tail_sampling,batch]exporters:[jaeger]

8 分钟定位的关键动作

告警触发后，我只做三步：

• 在 Jaeger 过滤service=api-gateway AND duration>800ms
• 打开最慢 20 条 trace，看 span 瀑布图
• 按 span 占比排序找最大耗时段

结果很直观，瓶颈不在数据库，而在库存服务调用风控服务的一个 HTTP 请求，重试策略写成了线性 5 次重试，单次超时 300ms，理论最坏就 1.5s。

修复方案

我做了 3 个改动：

1. 把同步调用改成异步预校验
2. 重试从 5 次降到 2 次，并改指数退避
3. 给风控下游加并发舱壁和超时预算

Java 侧关键配置（示意）：

RetryConfigretry=RetryConfig.custom().maxAttempts(2).waitDuration(Duration.ofMillis(80)).intervalFunction(IntervalFunction.ofExponentialBackoff(50,2.0)).retryOnException(ex->exinstanceofTimeoutException).build();TimeLimiterConfigtl=TimeLimiterConfig.custom().timeoutDuration(Duration.ofMillis(180)).build();

前后对比

改造前后一周同业务峰值对比：

• 支付链路 P99：2.4s -> 620ms
• 超时率：3.8% -> 0.7%
• 根因定位耗时：90 分钟 -> 8 分钟

写在最后

可观测性最怕“全都采、全都存、全都看不懂”。

我的经验是，先围绕真实事故做最小闭环，把“定位时长”当成第一 KPI，再逐步扩面。

你不一定今天就把平台搭完，但你可以今天就把下一次事故的定位时间砍半。