📚 课程目录第3章 OpenTelemetry标准

3. OpenTelemetry 标准：OTel 架构、Signal 类型、Collector 组件、Exporter 配置基础

OpenTelemetry（简称 OTel）是 CNCF 孵化的可观测性标准，旨在统一指标（Metrics）、日志（Logs）和链路（Traces）的数据采集、处理与导出规范。在 Grafana 生态中，OTel 是分布式追踪数据的主要来源，理解其架构与配置是构建链路钻取能力的前提。

3.1 OTel 整体架构

OTel 采用“生产-处理-导出”三层架构，核心组件包括 Instrumentation SDK、Collector 和 Exporter。下图展示了数据从应用埋点到后端存储的完整路径：

架构选择建议：在 Kubernetes 环境中，推荐使用 Collector Gateway 模式，集中管理 Exporter 配置和采样策略；在轻量场景下，Agent 模式（DaemonSet）更简单。

3.2 Signal 类型：三大可观测性支柱

OTel 定义了三种核心 Signal（信号），分别对应可观测性的三大支柱：

Signal 类型	数据模型	典型用途	Grafana 后端
Traces（链路）	Span（跨度）组成 Trace（追踪树）	请求端到端延迟分析、错误定位	Grafana Tempo
Metrics（指标）	Counter / Gauge / Histogram	系统吞吐量、错误率、饱和度	Prometheus / Mimir
Logs（日志）	LogRecord（时间戳 + 结构化字段）	详细事件记录、异常堆栈	Loki

在分布式追踪场景中，Traces 是最核心的 Signal。每个 Trace 由多个 Span 组成，Span 包含以下关键属性：

Span ID / Trace ID：全局唯一标识，用于关联上下游
Parent Span ID：构建父子关系，形成调用树
Start Time / End Time：精确到纳秒的时间戳
Span Kind：Client / Server / Internal / Producer / Consumer
Attributes：键值对，携带业务上下文（如 HTTP 方法、状态码）
Events：时间点上的标注事件（如异常、缓存命中）

  链路钻取关键：Span 的 Attributes 和 Events 是 Grafana Explore 中实现“点击跳转”和“条件过滤”的数据基础。埋点时务必携带 service.name、http.url、http.status_code 等标准属性。

3.3 Collector 组件详解

OTel Collector 是一个可插拔的管道系统，核心组件包括 Receiver、Processor 和 Exporter。下图展示了 Collector 内部的数据流：

Receiver：接收来自 SDK 或其他系统的数据，支持 OTLP、Jaeger、Zipkin、Prometheus 等协议 • Processor：对数据进行预处理，如批处理（batch）、过滤（filter）、属性修改（attributes）、采样（tail sampling） • Exporter：将处理后的数据发送到后端存储，支持多目标并行导出

3.4 Exporter 配置基础

Exporter 是 Collector 管道的出口，负责将数据发送到目标后端。以下是一个典型的 OTel Collector 配置文件，展示如何将 Traces 导出到 Grafana Tempo：

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

processors:
  batch:
    timeout: 1s
    send_batch_size: 1024
  memory_limiter:
    check_interval: 1s
    limit_mib: 512

exporters:
  otlp/tempo:
    endpoint: tempo.example.com:4317
    tls:
      insecure: false
      ca_file: /etc/ssl/certs/ca-certificates.crt
    headers:
      "X-Scope-OrgID": "my-tenant"
  logging:
    loglevel: debug

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/tempo, logging]

配置注意事项：

生产环境务必启用 batch Processor，避免高并发下后端压力过大
使用 memory_limiter 防止 Collector OOM
多租户场景（如 Grafana Cloud）需在 Exporter 的 headers 中携带 X-Scope-OrgID
调试时可添加 logging Exporter 输出到控制台，生产环境应移除

3.5 常用 Exporter 对比

Exporter 类型	协议	目标后端	适用场景
otlp	gRPC / HTTP	Tempo、Jaeger、其他 OTel 兼容后端	标准链路导出，推荐首选
prometheus	HTTP Pull	Prometheus、Mimir、VictoriaMetrics	指标导出，需配合 Prometheus Receiver
loki	HTTP Push	Grafana Loki	日志导出，支持结构化日志
jaeger	gRPC / Thrift	Jaeger 后端	兼容旧版 Jaeger 生态
logging	标准输出	控制台	调试和开发环境

最佳实践：在 Grafana 集成中，Traces 优先使用 otlp Exporter 发送到 Tempo，Metrics 使用 prometheus Exporter 发送到 Prometheus/Mimir，Logs 使用 loki Exporter 发送到 Loki。三者通过 Trace ID 关联，实现“指标→日志→链路”的完整钻取。

3.6 本章小结

OTel 架构分为 SDK（数据生产）、Collector（数据处理）、Exporter（数据导出）三层
三大 Signal 类型：Traces、Metrics、Logs，分别对应 Grafana Tempo、Prometheus/Mimir、Loki
Collector 管道由 Receiver → Processor → Exporter 组成，支持灵活的数据处理链
Exporter 配置是链路钻取的基础，需根据后端类型选择合适的协议和认证方式
生产环境必须启用 batch 和 memory_limiter Processor，确保 Collector 稳定性