📚 课程目录第2章 OpenTelemetry概述

2. OpenTelemetry 概述：项目起源、核心组件与 CNCF 生态

2.1 项目起源：从 OpenTracing 与 OpenCensus 到统一标准

在 OpenTelemetry 出现之前，可观测性领域存在两大主流开源项目：OpenTracing（提供厂商中立的追踪 API）和 OpenCensus（提供指标与追踪的采集与导出能力）。两者各有优势，但也带来了社区分裂、集成成本高的问题。

  关键痛点： 开发者需要为不同可观测性后端（Jaeger、Zipkin、Prometheus 等）编写不同的 SDK 和导出逻辑，缺乏统一的 instrumentation 标准。

2019 年，CNCF 将 OpenTracing 与 OpenCensus 合并，启动 OpenTelemetry 项目。其核心目标：

统一 API：一套标准接口，覆盖 Traces、Metrics、Logs。
厂商中立：数据可导出到任意后端（Jaeger、Prometheus、Datadog 等）。
无侵入式采集：通过自动 instrumentation 减少业务代码改动。

2021 年，OpenTelemetry 成为 CNCF 孵化项目，2023 年晋升为毕业项目，成为云原生可观测性的事实标准。

2.2 核心组件：API、SDK、Collector

OpenTelemetry 架构分为三层：API（接口定义）、SDK（实现与处理）、Collector（数据接收与转发）。三者协同工作，形成从数据产生到导出的完整链路。

组件	职责	关键能力	典型使用场景
API	定义 Traces、Metrics、Logs 的数据模型与操作接口	TracerProvider、MeterProvider、Span、Counter	库/框架开发者集成 instrumentation
SDK	实现 API 接口，提供采样、处理、导出等能力	SpanProcessor、Sampler、Exporter、Resource	应用运行时采集与处理可观测性数据
Collector	接收、处理、转发遥测数据（独立进程）	Receiver、Processor、Exporter、Pipeline	边缘聚合、数据过滤、多后端分发

最佳实践： 在异步任务编排场景中，Collector 通常部署为 Sidecar 或 DaemonSet，负责聚合多个任务节点的 Trace 数据，减少应用层直接导出带来的网络开销。

2.2.1 API 层：接口契约

API 层定义了 Tracer、Span、Meter、Counter 等核心抽象。开发者只需依赖 API 包，无需绑定具体实现。例如创建一个 Span：

// 使用 OpenTelemetry API 创建 Span
Tracer tracer = openTelemetry.getTracer("task-orchestrator");
Span span = tracer.spanBuilder("process-task")
    .setAttribute("task.id", taskId)
    .startSpan();
try (Scope scope = span.makeCurrent()) {
    // 执行异步任务
    doWork();
} finally {
    span.end();
}

2.2.2 SDK 层：数据处理引擎

SDK 实现了 API 接口，并提供可插拔的组件：

SpanProcessor：在 Span 开始/结束时执行回调（如批量导出）。
Sampler：控制采样率，减少数据量（如基于头部采样、概率采样）。
Exporter：将数据发送到后端（OTLP、Jaeger、Prometheus 等）。
Resource：标识数据来源（服务名、版本、环境）。

2.2.3 Collector 层：数据管道

Collector 是一个独立的二进制进程，通过 Pipeline 处理数据：

# Collector 配置示例：接收 OTLP，过滤后导出到 Jaeger 和 Prometheus
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
processors:
  batch:
    timeout: 1s
  filter:
    spans:
      include:
        match_type: regexp
        services: ["task-.*"]
exporters:
  jaeger:
    endpoint: jaeger:14250
  prometheus:
    endpoint: 0.0.0.0:8889
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, filter]
      exporters: [jaeger]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]

2.3 与 CNCF 生态的关系

OpenTelemetry 是 CNCF 生态中可观测性层的核心组件，与以下项目深度集成：

CNCF 项目	与 OpenTelemetry 的关系	典型集成方式
Kubernetes	运行 Collector 的基础平台，通过 Operator 管理部署	Collector 作为 DaemonSet 采集 Pod 级指标
Prometheus	OpenTelemetry 可导出 Metrics 到 Prometheus	Collector 的 PrometheusExporter 或 Receiver
Jaeger	原生支持 OTLP 协议，接收 Trace 数据	Collector 直接导出到 Jaeger gRPC 端点
Fluentd / Fluent Bit	日志采集与 OpenTelemetry Logs 互补	Fluent Bit 通过 OTLP 输出插件发送日志
Envoy / Istio	服务网格通过 OpenTelemetry 生成 Trace	Envoy 的 OpenTelemetry Access Logs

注意： 在异步任务编排系统中，Collector 的部署位置直接影响数据传输效率。建议将 Collector 部署在任务执行节点附近（如 Kubernetes Sidecar），避免所有 Trace 数据都经过中心 Collector 造成瓶颈。

2.4 本章小结

OpenTelemetry 由 OpenTracing 和 OpenCensus 合并而来，解决了可观测性标准分裂问题。
核心组件 API 定义接口，SDK 实现数据处理，Collector 负责数据管道与路由。
Collector 的 Pipeline 架构（Receiver → Processor → Exporter）为异步任务编排的数据传输优化提供了灵活的基础。
作为 CNCF 毕业项目，OpenTelemetry 与 Kubernetes、Prometheus、Jaeger 等生态深度集成，是云原生可观测性的基石。