OpenTelemetry全链路追踪实战：从采集到Grafana Tempo可视化的完整部署

全链路追踪为什么选OpenTelemetry

微服务架构下，一次用户请求跨越网关、认证、业务、缓存、数据库等多个服务节点，任何一环出现延迟或错误都需要快速定位。全链路追踪（Distributed Tracing）通过为每个请求生成唯一TraceID并逐层传递Span，还原请求在服务间的完整调用路径。OpenTelemetry作为CNCF孵化的可观测性标准，统一了Trace、Metric、Log三种信号的采集SDK和协议，配合Grafana Tempo作为后端存储和查询引擎，是目前开源社区最主流的链路追踪方案。

OpenTelemetry架构与核心概念

OpenTelemetry由三部分组成：SDK（各语言的采集库）、Collector（数据管道与转发）、Protocol（OTLP传输协议）。核心概念：Trace代表一次完整请求链路，由多个Span组成；Span是单个操作的记录，包含名称、耗时、状态、属性等；Context Propagation负责TraceID在服务间的传递，默认使用W3C Trace Context标准HTTP头traceparent。

Collector部署与Pipeline配置

OpenTelemetry Collector是数据的中间层，接收各服务上报的Trace数据，处理后转发到后端存储。推荐使用DaemonSet方式部署在Kubernetes集群中。核心配置文件otel-collector-config.yaml：

receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318

service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch, filter]
exporters: [otlphttp]

这个Pipeline配置了OTLP接收器、批量处理与内存限制、健康检查接口过滤、以及向Tempo的HTTP导出。filter处理器排除了/healthz等探针请求，避免大量无意义Span污染追踪数据。

应用服务SDK接入

以Python Flask应用为例，使用opentelemetry-sdk自动采集Trace：

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

app = Flask(__name__)
FlaskInstrumentor().instrument_app(app)

Java Spring Boot应用使用opentelemetry-spring-boot-starter，在启动参数中指定OTLP endpoint即可零代码接入：

java -javaagent:opentelemetry-javaagent.jar \
-Dotel.exporter.otlp.endpoint=http://otel-collector:4317 \
-Dotel.resource.attributes=service.name=order-service \
-jar app.jar

Go应用使用opentelemetry-go SDK，在HTTP中间件中注入Span传播逻辑，需要手动为每个外部调用创建Child Span。

Grafana Tempo存储与查询配置

Tempo是Grafana Labs出品的Trace后端，原生支持OTLP协议接收，存储后端可选本地磁盘、GCS、S3或Azure Blob。生产环境推荐对象存储方案。Tempo配置文件tempo.yaml核心部分：

server:
http_listen_port: 3200

storage:
trace:
backend: s3
s3:
bucket: tempo-traces
endpoint: minio:9000
access_key: minioadmin
secret_key: minioadmin
insecure: true
block:
bloom_filter_false_positive: .05
index_downsample_bytes: 1000
pool:
max_workers: 100
queue_depth: 10000

Tempo使用Write-Ahead-Log和分块存储策略，查询时先通过TraceID定位block再读取，对对象存储友好，成本远低于Elasticsearch方案。

Grafana面板配置与Trace查询

Grafana配置Tempo数据源后，在Explore页面选择Tempo数据源，输入TraceID即可查看完整链路。更实用的方式是配置Search查询，按Service Name、Operation Name、Duration范围、Status Code筛选Span。在Dashboard中添加Trace面板，与Metric和Log面板联动：

# TraceQL查询示例：查找慢请求
{ service.name="order-service" && duration > 500ms && status = error }

TraceQL是Tempo提供的查询语言，支持属性过滤、逻辑运算和子查询，比纯TraceID查找灵活得多。结合Grafana Alerting，可以对P99延迟突增自动告警。

性能优化与运维要点

Collector资源消耗主要在batch处理器，发送间隔和批量大小需根据Trace流量调优。流量高峰期batch size过大会导致内存溢出，过小则网络请求频繁。生产建议：每个Collector实例处理不超过5000 spans/s，超出则水平扩展Collector副本数。Tempo的compactor组件负责合并小block为block，降低查询扫描量，需监控compaction延迟。Trace数据保留周期根据合规要求设定，通常7-30天，对象存储成本远低于Elasticsearch索引开销。