全链路可观测性：OpenTelemetry结合Jaeger追踪慢请求配置指南

1. 背景与企业痛点

当企业逐步将传统的单体应用拆分为分布式微服务（Microservices）后，运维和开发团队面临的最大噩梦就是：“服务雪崩与慢请求排查”。
1. 黑盒排障：一个页面请求返回 504 超时，它可能经过了网关 -> 鉴权服务 -> 订单服务 -> 库存服务 -> MySQL。到底是哪一个环节卡住了？
2. 日志割裂：各个服务都在自己的虚机/容器里打印日志，没有统一的 TraceID 将整个请求链路串联起来。

业界最先进的解决方案是引入分布式追踪（Distributed Tracing）。本文将演示如何利用当前云原生标准 OpenTelemetry（OTel），无侵入式地收集 Java/Python/Go 应用数据，并利用 Jaeger 作为后端构建炫酷的请求瀑布流甘特图分析慢查询。

2. 架构设计

App (业务应用)：内置 OTel SDK，或者利用 Java Agent 挂载（零代码侵入），拦截 HTTP/RPC 调用。
OTel Collector (数据采集器)：集中接收各个 App 产生的 Trace 跨度（Spans），进行批处理、脱敏加工。
Jaeger (存储与展示 UI)：从 Collector 接收数据并写入 Elasticsearch/内存，提供前端 UI 进行耗时检索。

3. Docker Compose 基础设施部署

首先，我们需要在监控服务器上拉起 OTel Collector 和 Jaeger。
创建一个 docker-compose.yml 文件：

version: '3.8'
services:
  jaeger-all-in-one:
    image: jaegertracing/all-in-one:latest
    ports:
      - "16686:16686" # Jaeger Web UI
      - "14250:14250" # OTLP 接收端口
      - "4317:4317"
      - "4318:4318"

  otel-collector:
    image: otel/opentelemetry-collector:latest
    command: ["--config=/etc/otel-collector-config.yaml"]
    volumes:
      - ./otel-collector-config.yaml:/etc/otel-collector-config.yaml
    ports:
      - "4317:4317"   # OTLP gRPC 接收端口 (微服务应用发数据到这里)
    depends_on:
      - jaeger-all-in-one

接着，准备 Collector 的核心配置文件 otel-collector-config.yaml：

receivers:
  otlp:
    protocols:
      grpc: {}
      http: {}

processors:
  batch:
    timeout: 1s
    send_batch_size: 1024

exporters:
  otlp: # 将加工后的数据导出给下游的 Jaeger
    endpoint: jaeger-all-in-one:4317
    tls:
      insecure: true
  logging:
    loglevel: debug

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp, logging]

执行 docker-compose up -d，此时底座搭建完毕。你可以访问 http://<服务器IP>:16686 进入 Jaeger UI（暂时空空如也）。

4. 微服务无侵入式接入（以 Java 为例）

传统的监控工具需要在代码里埋点写 log.info()。OpenTelemetry 提供了黑科技：Java Agent 插桩技术，一行代码都不用改！

下载探针包：

wget https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/latest/download/opentelemetry-javaagent.jar

启动你的企业内部微服务（比如 Spring Boot 写的订单中心），只需要在启动时加上 -javaagent 参数，并配置 OTLP Collector 的地址：

java -javaagent:./opentelemetry-javaagent.jar 
     -Dotel.resource.attributes=service.name=order-service 
     -Dotel.exporter.otlp.endpoint=http://<你的OTel-Collector-IP>:4317 
     -Dotel.traces.exporter=otlp 
     -Dotel.metrics.exporter=none 
     -jar target/order-service-1.0.jar

5. 慢查询追踪效果分析

在应用启动并产生真实访问流量后，打开 Jaeger UI 主页：
1. 左侧 Service 菜单会自动出现刚刚注入的 order-service。
2. 筛选持续时间 Min Duration = 500ms，点击 Find Traces。
3. 你会清晰地看到一个类似甘特图的“瀑布流”。

图表会极度直观地展示：
– 整个用户请求耗时 2000ms。
– 前置负载网关耗时 10ms。
– order-service 调用 user-service 的 Feign HTTP 请求消耗了 300ms。
– 罪魁祸首：最深层的一条 Span 显示，SELECT * FROM order_logs WHERE status=1 这个未加索引的 SQL 语句执行硬生生卡了 1680ms！

6. 总结

可观测性（Observability）并非虚无缥缈的高大上概念，它是从“靠猜排障”走向“可视化诊断”的必经之路。借助开放无绑定的 OpenTelemetry 标准结合 Jaeger，我们可以用极低的接入成本透视微服务调用的所有暗流，让深埋底层的慢 SQL 与 HTTP 延迟无所遁形，为技术团队带来极大的排障底气。