OpenTelemetry辅助定位接口链路耗时

2024年8月记录，分类「服务器运维」。这篇更像工作笔记，记录的是一次问题拆解和复用清单。

为什么接链路追踪

接口慢的时候，如果只有总耗时，很难判断卡在网关、应用、数据库还是外部服务。OpenTelemetry 的价值是把链路拆开。

我更关注它在真实提测流程里怎么落地，而不是单独演示一个命令或脚本。

看哪些span

• 压测或接口回归时保留 traceId。
• 对数据库查询、外部 HTTP、消息处理分别看 span 耗时。
• 把慢请求样本和链路截图放进缺陷。

traceId=7f2a...
api gateway: 32ms
app service: 180ms
mysql query: 1260ms

和测试结合

• 能定位耗时最高的下游依赖。
• 异常链路和正常链路可对比。
• traceId 能从响应或日志里拿到。

执行时最好把截图、请求、响应、日志时间点放在一起，后面复盘会省很多事。

收益

链路追踪让接口性能问题从猜测变成证据。等业务规则再稳定一点，可以把这里的检查点拆成参数化用例。