OpenTelemetry 与链路追踪¶

分布式 Trace 描述一次请求穿过多个服务的路径。Trace 由多个 Span 组成，每个 Span 表示一个操作，包含开始/结束时间、状态、属性和父子关系。

Trace: 用户提交订单
  ├─ Gateway Span              180 ms
  └─ Order Service Span        160 ms
       ├─ PostgreSQL Span       20 ms
       └─ Inventory HTTP Span  120 ms  ← 慢点

核心概念¶

概念	作用
Trace ID	标识整条请求链
Span ID	标识一次操作
Parent Span	表示调用层级
Attributes	HTTP 方法、状态、服务、数据库等结构化信息
Events	Span 生命周期中的重要事件或异常
Context Propagation	跨 HTTP、gRPC、消息传递 Trace 上下文

OpenTelemetry 的位置¶

OpenTelemetry 提供 API、SDK、自动插桩、语义约定、OTLP 协议和 Collector，不是最终查询存储。Collector 接收数据后可批处理、过滤、采样、补充 Kubernetes 属性并导出到一个或多个后端。

应用 SDK / Java Agent
  → OTLP
  → OTel Collector：receiver → processor → exporter
  → Tempo / Jaeger / 其他后端

Collector 模式¶

Agent：每节点/每 Pod 附近采集，降低应用到采集端距离。
Gateway：集中处理、采样和导出，便于统一策略。
组合模式：Agent 做轻处理，Gateway 做尾部采样与多后端输出。

生产需要启用内存限制、批处理、发送队列、重试和自身指标，防止后端故障反向拖垮业务节点。

采样¶

方式	特点
Head Sampling	请求开始时决定，开销低但可能丢掉罕见错误
Tail Sampling	收集完整 Trace 后按错误/延迟决定，价值高但资源开销大

关键错误、超时和高延迟请求应提高保留概率。采样策略必须考虑入口流量、Span 数量、Collector 内存和后端成本；不能只设置一个百分比后不监控实际保留量。

排障检查¶

入口是否生成 Trace ID。
HTTP/gRPC/消息 Header 是否传播上下文。
服务名、环境和版本属性是否正确。
Collector receiver 是否收到数据，队列是否丢弃。
Exporter 到后端是否超时、限流或认证失败。
查询时间范围和采样策略是否导致“看不到”。

日志写入 trace_id/span_id 才能与 Trace 互跳，但不要记录 Token、Cookie 和完整敏感请求体。

官方参考：OpenTelemetry Traces、Collector。