微服务架构下，一次用户请求可能经过多个服务节点，任何一个环节的延迟或错误都难以通过单服务日志定位。Jaeger是CNCF毕业的分布式链路追踪系统，通过Span树形结构完整记录请求在各服务间的流转路径、耗时分布和错误信息。OpenTelemetry作为CNCF主推的可观测性标准，统一了Traces、Metrics、Logs三种信号的采集协议。本文从架构原理到部署实操，完整演示Jaeger + OpenTelemetry的链路追踪配置流程。
分布式链路追踪核心概念与Span数据模型
链路追踪的基本单元是Span，一个Span代表一次操作（如HTTP请求、数据库查询、消息发送）。Span包含以下核心字段：
TraceID：标识一次完整的请求链路，所有相关Span共享同一TraceID。
SpanID：标识单个操作，全局唯一。
ParentSpanID：指向父Span，构建调用层级关系。
OperationName：操作名称，如”GET /api/users”。
StartTime/Duration：起始时间和持续时间。
Tags：键值对标签，如http.status_code=200、db.system=mysql。
Span之间通过ParentSpanID组成有向无树，根Span的ParentSpanID为空。多个Span通过TraceID关联成一条完整Trace。Jaeger UI以时间轴瀑布图展示Trace中各Span的执行时序和嵌套关系。
Jaeger后端部署与存储配置
生产环境推荐Docker Compose部署Jaeger，使用Elasticsearch或Cassandra作为后端存储：
# docker-compose.yml
version: "3.8"
services:
jaeger:
image: jaegertracing/all-in-one:1.57
environment:
- COLLECTOR_OTLP_ENABLED=true
- SPAN_STORAGE_TYPE=elasticsearch
- ES_SERVER_URLS=http://elasticsearch:9200
- ES_TAGS_AS_FIELDS_ALL=true
ports:
- "16686:16686" # Jaeger UI
- "4317:4317" # OTLP gRPC
- "4318:4318" # OTLP HTTP
depends_on:
- elasticsearch
elasticsearch:
image: docker.elastic.co/elasticsearch/elasticsearch:8.13.0
environment:
- discovery.type=single-node
- xpack.security.enabled=false
- "ES_JAVA_OPTS=-Xms2g -Xmx2g"all-in-one镜像包含collector、query、UI全部组件，适合中小规模部署。大规模生产环境建议拆分部署collector和query服务，collector无状态可水平扩展。SPAN_STORAGE_TYPE=elasticsearch将Span数据持久化到ES，支持复杂的Tag过滤和全文检索。ES_TAGS_AS_FIELDS_ALL=true将Span Tags映射为ES字段，加速按Tag过滤查询。
OpenTelemetry SDK自动埋点配置
OpenTelemetry提供各语言的自动埋点库，无需修改业务代码即可采集HTTP、数据库、消息队列等调用的Span数据。以Python Flask应用为例：
pip install opentelemetry-distro opentelemetry-exporter-otlp
# 一键安装自动埋点组件
opentelemetry-bootstrap -a install# 启动应用时注入追踪配置
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.instrumentation.flask import FlaskInstrumentor
from opentelemetry.instrumentation.requests import RequestsInstrumentor
from flask import Flask
trace.set_tracer_provider(TracerProvider())
trace.get_tracer_provider().add_span_processor(
BatchSpanProcessor(
OTLPSpanExporter(endpoint="http://jaeger:4317")
)
)
app = Flask(__name__)
FlaskInstrumentor().instrument_app(app)
RequestsInstrumentor().instrument()
@app.route("/api/users")
def get_users():
# 自动生成HTTP Span，下游requests调用也会自动生成Span并关联
return {"users": []}FlaskInstrumentor自动为每个HTTP请求创建Server Span，RequestsInstrumentor为每个出站HTTP请求创建Client Span。两个Span通过W3C Trace Context propagator传递的traceparent头自动关联ParentSpanID。BatchSpanProcessor批量异步上报Span，对应用性能影响小于1%。
Trace Context跨服务传播与Baggage传递
链路追踪的核心机制是Context Propagation——请求从A服务调用B服务时，TraceID和SpanID通过HTTP头传递给B服务，B服务据此创建子Span。W3C Trace Context标准使用traceparent头：
# traceparent格式：version-traceid-parentid-traceflags
# 示例：
traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01OpenTelemetry自动处理上下文注入和提取，开发者通常无需手动操作。但跨非HTTP协议（如Kafka消息）时需要手动注入和提取：
from opentelemetry.propagate import inject, extract
# 生产者：发送Kafka消息时注入上下文
headers = {}
inject(headers)
producer.send("orders", value=order_data, headers=headers.items())
# 消费者：接收Kafka消息时提取上下文
context = extract(dict(msg.headers))
with tracer.start_as_current_span("process_order", context=context):
# 此Span自动关联到原始Trace
process(order_data)Baggage是另一种跨服务传递的键值对数据，与TraceID一起传播，可用于传递租户ID、灰度标识等业务上下文：
from opentelemetry import baggage
# 设置Baggage
ctx = baggage.set_baggage("tenant_id", "acme_corp")
token = context.attach(ctx)
# 后续所有Span自动携带tenant_id=acme_corp
# 跨服务调用时Baggage也自动传播采样策略配置与性能权衡
全量采集Trace在高流量场景下会对应用和后端存储造成巨大压力。采样策略控制上报比例，常见方案：
Head Sampling（头部采样）：在Trace入口处决定是否采样，决策后整条Trace的所有Span都上报或都不上报。优点是实现简单、保证Trace完整性；缺点是可能漏掉偶发错误。概率采样如ParentBased(TraceIdRatio(0.1))表示10%采样率。
Tail Sampling（尾部采样）：在Trace完整结束后根据规则决定是否上报，可以实现”只保留错误请求”的精准采样。需要部署OpenTelemetry Collector作为中间层缓存完整Trace。
# OTel Collector tail sampling配置
processors:
tail_sampling:
decision_wait: 30s
num_traces: 50000
policies:
- name: errors
type: status_code
status_code:
status_codes: [ERROR]
- name: slow
type: latency
latency:
threshold_ms: 1000
- name: sample_10pct
type: probabilistic
probabilistic:
sampling_percentage: 10以上配置保留所有错误请求（status=ERROR）、所有超过1秒的慢请求、以及10%的正常请求。Tail Sampling大幅降低存储压力的同时不丢失关键诊断信息。
Jaeger UI查询分析与性能瓶颈定位
Jaeger UI支持按Service、Operation、Tag、Duration、Time Range多维度查询Trace。定位性能瓶颈的典型流程：在UI中按Duration降序排列Trace，找到最慢的请求展开Span树，瀑布图中跨度最长的Span即为瓶颈节点。常见瓶颈模式：
数据库查询瓶颈：Span的db.statement标签显示SQL语句，Duration超过500ms需检查索引和查询计划。
网络调用瓶颈：Client Span和Server Span的Duration差值即为网络往返时间，差值过大说明网络延迟或跨可用区调用。
串行调用链过长：Span树深度超过10层且每层都有网络调用，考虑用并行调用或缓存优化。通过Trace中的Tags可以快速定位错误Span的异常堆栈和错误码，相比翻阅分散日志效率提升数倍。
原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/jaeger-fen-bu-shi-lian-lu-zhui-zong-xi-tong-bu-shu-yu/
