2. OpenTelemetry 基础概念：Signal、Context Propagation、Resource 与 Instrumentation

在构建值班机器人的事件接入层之前，必须理解 OpenTelemetry 的核心数据模型。OpenTelemetry 将可观测性数据抽象为三种核心信号（Signal），并通过统一的上下文传播机制将它们关联起来。本节将逐一拆解这些基础概念，为后续的告警聚合设计奠定理论基础。

2.1 三大信号（Signal）：Traces、Metrics、Logs

OpenTelemetry 将遥测数据分为三类信号，它们从不同维度描述系统状态，共同构成完整的可观测性视图。

下图展示了三种信号在分布式系统中的采集与关联关系：

2.2 Context Propagation（上下文传播）

上下文传播是 OpenTelemetry 的“粘合剂”，它确保一个请求在跨越多个服务、线程或进程时，所有信号能够被关联到同一个事务上下文中。核心机制是 W3C Trace Context 标准。

• Trace ID：全局唯一的请求标识，贯穿整个分布式链路。
• Span ID：单个服务或操作内的唯一标识，用于构建父子关系。
• Baggage：用户自定义的键值对，随上下文传播，用于传递业务属性（如用户ID、租户ID）。

上下文传播的典型流程如下：

1. 注入（Inject）：客户端在发起 HTTP/gRPC 请求前，将当前上下文序列化到请求头中。
2. 传播（Propagate）：请求头随网络请求传递到下游服务。
3. 提取（Extract）：服务端从请求头中反序列化上下文，恢复 Trace ID 和 Span 关系。

// 示例：Go 语言中的上下文注入与提取
// 注入（客户端）
ctx, span := tracer.Start(r.Context(), "POST /api/order")
otel.GetTextMapPropagator().Inject(ctx, propagation.HeaderCarrier(req.Header))

// 提取（服务端）
ctx := otel.GetTextMapPropagator().Extract(r.Context(), propagation.HeaderCarrier(r.Header))
ctx, span := tracer.Start(ctx, "handleOrder")

2.3 Resource（资源）与 Instrumentation（插桩）

Resource 描述生成遥测数据的实体，通常是服务实例、主机或容器。它作为信号的元数据附加到每个 Span、Metric 和 Log 上，是告警聚合时进行维度过滤的关键。

Instrumentation（插桩） 是将 OpenTelemetry SDK 集成到应用程序中的过程。它分为两种方式：

• 自动插桩（Auto-instrumentation）：通过 Agent、Sidecar 或库替换，零代码修改即可捕获常见框架（HTTP、gRPC、数据库）的遥测数据。
• 手动插桩（Manual instrumentation）：通过 SDK API 在关键业务逻辑中创建自定义 Span、记录指标或写入结构化日志。

下图展示了 Resource 与 Instrumentation 在数据采集链路中的位置：

2.4 信号关联与告警聚合的桥梁

在值班机器人中，告警事件并非孤立产生，而是由 Metrics 阈值触发、Traces 定位根因、Logs 提供详情。OpenTelemetry 通过以下机制实现三者的无缝关联：

• Trace-Metrics 关联：Metrics 的 Exemplar 机制可以携带 Trace ID，将指标异常点直接关联到具体请求链路。
• Trace-Logs 关联：日志中嵌入 trace_id 和 span_id 字段，实现从日志到链路的双向跳转。
• Resource 统一：所有信号共享相同的 Resource 属性，确保告警事件能够按统一维度进行聚合与去重。