2. OpenTelemetry 基础:OTel 架构、Signal 与 Collector 组件

OpenTelemetry(简称 OTel)是 CNCF 的毕业项目,旨在为可观测性提供一套统一、厂商中立的采集框架。本章从架构全景、三大 Signal(信号)以及 Collector 组件三个维度,建立你对 OTel 的核心认知。

2.1 OTel 整体架构

OTel 采用 Instrumentation(插桩)→ OTel SDK → OTel Collector → 后端 的分层架构。应用通过 SDK 产生 Trace、Metric、Log 数据,由 Collector 接收、处理并导出到任意后端(如 Jaeger、Prometheus、Loki、云厂商服务)。

OpenTelemetry 架构全景 应用 / 服务 OTel SDK(自动 + 手动插桩) Trace / Metric / Log OTel Collector Receiver → Processor → Exporter 批处理 / 过滤 / 采样 / 租户路由 OTLP / gRPC / HTTP 后端 Jaeger Prometheus Loki / 云服务 架构要点 • 插桩层:通过 SDK 或 Agent 自动注入 Trace 上下文,无需修改业务代码。 • Collector 层:核心枢纽,负责数据接收、处理、路由;支持多租户隔离。 • 后端层:任意兼容 OTel 的存储/可视化系统,可同时导出到多个目标。

2.2 三大 Signal:Trace、Metric、Log

OTel 将可观测性数据抽象为三种核心信号(Signal),它们各自关注不同维度,又通过 Context 传播 实现关联。

Signal 定义 核心数据模型 典型用途
Trace(链路) 记录请求在分布式系统中的完整路径 Span(名称、开始/结束时间、属性、事件、状态) 请求延迟分析、错误定位、依赖拓扑
Metric(指标) 聚合后的数值型测量数据 Counter、Histogram、Gauge、UpDownCounter 系统负载、请求速率、错误率、饱和度
Log(日志) 带时间戳的结构化或非结构化事件记录 LogRecord(时间戳、Body、Severity、Attributes) 详细错误信息、审计、调试
关联机制: Trace 和 Log 通过 trace_id / span_id 关联;Metric 可通过 Attributes 携带 service.name、trace_id 等标签实现跨 Signal 关联。

2.3 Span——Trace 的基本单元

Span 是 Trace 的最小工作单元,每个 Span 代表一个操作(如一次 RPC 调用、一个数据库查询)。多个 Span 通过 Parent-Child 关系构成 Trace 树。

// Span 核心字段示例(伪代码)
Span {
  trace_id: "0xabc123..."
  span_id: "0xdef456..."
  parent_span_id: "0x789ghi..."  // 空表示根 Span
  name: "HTTP GET /api/orders"
  start_time: 1710000000000000000  // 纳秒
  end_time:   1710000000123000000
  status: Status{code: OK}
  attributes: {
    "http.method": "GET",
    "http.url": "/api/orders",
    "http.status_code": 200
  }
  events: [
    { name: "cache.miss", timestamp: ..., attributes: {...} }
  ]
}

2.4 OTel Collector 组件详解

Collector 是 OTel 生态的 数据平面,负责接收、处理、导出可观测性数据。它由三个核心组件构成:

  • Receiver(接收器):从应用或其他数据源接收数据。支持 OTLP、Jaeger、Prometheus、Zipkin、Kafka 等多种协议。
  • Processor(处理器):对数据进行批处理、过滤、采样、属性修改、租户路由等操作。处理器按 pipeline 顺序执行。
  • Exporter(导出器):将处理后的数据发送到后端存储或可视化系统。支持同时导出到多个目标。
Collector Pipeline 内部流程 Receiver OTLP / Jaeger / Prometheus 数据接入 Processor 链 batch → filter → attributes → sampling → 租户路由 顺序执行,可配置 Exporter OTLP / Prometheus / 文件 数据导出 Pipeline 配置示例(YAML) receivers: [otlp] processors: [batch, filter, attributes] exporters: [jaeger, prometheus]

2.5 Collector 部署模式

Collector 支持两种主流部署模式,根据场景选择:

模式 部署位置 优势 适用场景
Agent 模式 与应用同节点(Sidecar / DaemonSet) 低延迟、本地缓存、减少网络依赖 Kubernetes 集群、边缘节点
Gateway 模式 独立集群(中心化部署) 统一路由、租户隔离、集中策略管理 多租户平台、大规模集群、混合云
实战建议: 在租户隔离场景中,推荐 Agent + Gateway 混合模式:Agent 负责本地采集和初步过滤,Gateway 负责租户路由、数据脱敏和导出到不同后端。

2.6 本章小结

  • OTel 架构分为 插桩层 → SDK → Collector → 后端 四层。
  • 三大 Signal(Trace / Metric / Log)通过 Context 和 Attributes 实现关联。
  • Span 是 Trace 的基本单元,包含时间、状态、属性、事件等关键字段。
  • Collector 的 Receiver → Processor → Exporter 管道是数据处理的核心。
  • Agent 和 Gateway 两种部署模式可组合使用,满足租户隔离需求。