这篇指南帮助你用 OpenTelemetry（一种开源可观测性标准）为云服务器应用接入分布式链路追踪，定位慢请求根因和跨服务调用瓶颈。传统监控只告诉你”慢了”，链路追踪告诉你”哪一步慢、为什么慢”，是排查复杂微服务性能问题的核心工具。
如果你已经在用 多层缓存架构优化性能，链路追踪能帮你确认缓存是否真的减少了数据库调用。Hostease 中文博客的 MySQL 慢查询分析讲了单库查询层面的优化，本文则聚焦跨服务链路：一个请求经过网关、应用、缓存、数据库多个节点时，怎么找到最慢的那一段。
一、链路追踪解决什么问题
一个用户请求在微服务架构中可能经过多个服务：API 网关接收请求，调用业务服务，业务服务查询数据库和缓存，可能还调用第三方 API。当用户反馈”页面慢”时，如果没有链路追踪，需要在每个服务里单独查日志，耗时耗力且经常找不到根因。
链路追踪把一次请求的完整路径记录为一个 trace（链路），每个服务内的操作记录为 span（跨度），span 之间有父子关系。通过 trace 可以看到请求在每个服务停留多久、调用了哪些下游、哪一步最慢。这种端到端的可视性是单点日志无法提供的，因为日志只记录单个服务的视角，无法自动关联跨服务的因果关系。OpenTelemetry 是 CNCF（云原生计算基金会）维护的开放标准，兼容 Jaeger、Zipkin 等多种后端，不绑定特定厂商。
二、接入 OpenTelemetry SDK
OpenTelemetry 支持多种语言的自动和手动插桩。以 Python 应用为例，先安装 SDK。
pip install opentelemetry-distro opentelemetry-exporter-otlp opentelemetry-bootstrap -a install
然后配置导出器，把 trace 数据发送到后端（如 Jaeger）。
export OTEL_EXPORTER_OTLP_ENDPOINT=http://jaeger:4317 export OTEL_SERVICE_NAME=my-api export OTEL_TRACES_EXPORTER=otlp opentelemetry-instrument python app.py
自动插桩会为 HTTP 请求、数据库调用、缓存操作自动创建 span，不需要改业务代码。手动插桩用于补充业务逻辑相关的 span，如自定义函数或第三方 API 调用。建议先用自动插桩覆盖基础链路，再按需添加手动 span。
三、定位慢请求根因
接入后，在 Jaeger 或 Grafana 中查看 trace 列表，按耗时排序找到最慢的请求。展开 trace 后看 span 瀑布图，找到耗时最长的 span。常见模式：
- 数据库 span 很慢：查询本身耗时，需要用 数据库复制延迟排查或慢查询分析定位。
- 缓存 span 很慢：缓存未命中导致穿透到数据库，或缓存连接池耗尽。
- 外部 API span 很慢：第三方服务响应慢，需要设超时和熔断。
- span 之间有大段空白：不是某个操作慢，而是服务间网络延迟或消息队列等待。
找到根因后，修复方式和问题类型对应：数据库慢补索引或拆查询，缓存穿透增加布隆过滤或预热，外部 API 慢加超时和降级，网络延迟优化路由或就近部署。需要注意的是，一次慢请求可能有多个叠加因素，比如数据库查询本身慢、同时缓存又未命中导致每次都穿透到数据库。链路追踪的优势在于能看到完整的调用链，发现这些叠加效应，而不是只盯着一个节点。建议在排查时先看总耗时分布，再逐层下钻到具体 span，避免过早锁定单一原因而忽略其他瓶颈。
四、跨服务调用追踪
跨服务追踪依赖 trace context 传递。OpenTelemetry 使用 W3C Trace Context 标准，通过 HTTP header 中的 traceparent 字段在服务间传递链路上下文。如果某个服务没有接入 OpenTelemetry，链路会在该服务处断裂，下游的 span 不会关联到原 trace。
| 追踪能力 | 自动插桩覆盖 | 需手动补充 |
|---|---|---|
| HTTP 请求 | 自动 | 自定义路由名 |
| 数据库查询 | 自动 | 慢查询标签 |
| 消息队列 | 部分 | 消费者端 |
| 定时任务 | 不覆盖 | 手动创建 span |
对于消息队列和定时任务，自动插桩覆盖不完整，需要在消费者端或任务入口手动创建 root span。如果你在做 微服务拆分，拆分后的每个服务都必须接入链路追踪，否则跨服务链路会断裂，追踪失去意义。
五、采样策略与性能开销
链路追踪会产生额外开销。每个 span 包含序列化、网络传输和存储成本。在高流量服务中全量采集 trace 会导致可观的开销。OpenTelemetry 支持采样策略控制采集量：head sampling 在请求入口按比例采样（如 10%），tail sampling 在链路完成后按条件采样（如只保留耗时超过 1 秒的 trace）。
建议生产环境用 tail sampling：只保留慢请求和错误请求的 trace，正常请求不采集。这样既保留了排查需要的链路数据，又控制了开销。采样配置在 OpenTelemetry Collector 层面设置，不需要改应用代码。Collector 可以部署为独立服务接收所有服务的 trace 数据，按规则过滤后只导出符合条件的 trace 到后端存储。这种架构让采样策略可以集中管理，业务服务只需要把 trace 发给 Collector，不需要关心采样逻辑。如果你做过 容器安全加固，Collector 作为基础设施组件应该和业务容器隔离部署，避免追踪数据采集影响业务进程。
总结
OpenTelemetry 链路追踪解决的是”慢在哪里”的问题。接入步骤是安装 SDK、配置导出器、自动插桩覆盖基础链路、按需添加手动 span。定位慢请求时看 trace 瀑布图找最长 span，再对应到数据库、缓存、外部 API 或网络延迟的修复策略。生产环境用 tail sampling 控制开销，只保留慢请求和错误请求的链路。对于 Hostease 环境上的多服务架构，链路追踪是从”知道慢”到”知道为什么慢”的关键工具。