OpenTelemetry 落地实战：我把跨服务超时定位从 90 分钟压到 8 分钟（附 trace 采样策略）
凌晨 1 点，支付链路 P99 从 280ms 突然跳到 2.4s。
最痛苦的不是慢，而是大家都在猜。网关说下游慢，订单说库存慢，库存说数据库慢。三组人对着各自日志互相甩锅，90 分钟过去了还没锁定根因。
这次我把 OpenTelemetry 真正落到生产，把根因定位时间从 90 分钟压到 8 分钟。下面是完整可复现方案。
为什么以前定位慢
我们之前只有三类观测：
- 应用日志
- Prometheus 指标
- Nginx access log
这三类都重要，但都缺了一个关键维度，调用链上下文。
一次请求跨 6 个服务，日志里根本看不到完整路径。指标只能告诉你某服务慢，不能告诉你它在这条请求里为什么慢。
我做的最小可用链路追踪
我没有一上来就全量采样，而是先做最小闭环：
- 网关注入 traceparent
- 核心 6 个服务透传 context
- Collector 聚合后写入 Jaeger
- 只对慢请求和错误请求提采样
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 个改动：
- 把同步调用改成异步预校验
- 重试从 5 次降到 2 次，并改指数退避
- 给风控下游加并发舱壁和超时预算
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，再逐步扩面。
你不一定今天就把平台搭完，但你可以今天就把下一次事故的定位时间砍半。
