📚 课程目录第2章 OTel基础回顾

2. OTel基础回顾：OpenTelemetry核心组件概述

OpenTelemetry（OTel）是可观测性领域的统一标准，其核心管线由四个组件构成：Receiver（接收器）、Processor（处理器）、Exporter（导出器）以及核心的Collector（收集器）。理解这四个组件的职责与协作关系，是设计自助目录模板的前提。

2.1 核心组件总览

下表从功能定位、数据流向、配置复杂度三个维度对比四个核心组件：

组件	功能定位	数据流向	配置复杂度
Receiver	接收来自应用、SDK或其他数据源的遥测数据	外部 → Collector	低（协议与端口配置）
Processor	对数据进行过滤、采样、批处理、属性修改等	Receiver → Exporter	中（规则链编排）
Exporter	将处理后的数据发送到后端存储或分析平台	Collector → 后端	中（认证、端点、重试）
Collector	作为统一网关，编排Receiver/Processor/Exporter	全链路调度	高（管线拓扑）

2.2 组件协作流程

下图展示了OTel Collector内部的数据处理管线：数据从Receiver流入，经过Processor链处理，最终由Exporter发送至后端。每个阶段均可独立配置与扩展。

2.3 各组件深度解析

2.3.1 Receiver — 数据入口

Receiver 负责接收来自不同来源的遥测数据。OTel Collector 内置了多种 Receiver，覆盖主流协议与数据源。

OTLP Receiver：接收 OTel SDK 发送的原生 gRPC/HTTP 数据。
Jaeger Receiver：兼容 Jaeger 协议，接收 Trace 数据。
Prometheus Receiver：抓取 Prometheus 格式的 Metric 数据。
Host Metrics Receiver：采集主机级别的 CPU、内存、磁盘等指标。

设计提示：在自助目录模板中，Receiver 的协议类型决定了数据源的接入方式。建议为每种 Receiver 预设端口、TLS 证书路径等参数占位符。

2.3.2 Processor — 数据处理引擎

Processor 是管线的核心处理单元，支持串联多个 Processor 形成处理链。常用 Processor 包括：

Processor 类型	功能	典型场景
batch	将数据合并为批次，减少网络开销	高吞吐场景下提升导出效率
filter	根据条件过滤数据（如排除健康检查请求）	降低存储成本，聚焦业务数据
attributes	增删改属性键值对	统一数据标签，便于后续分析
span	修改 Span 的 Name、Status 等字段	修复错误命名或标记异常 Span
memory_limiter	限制 Collector 内存使用，防止 OOM	生产环境稳定性保障

2.3.3 Exporter — 数据出口

Exporter 将处理后的数据发送至后端系统。OTel 支持多种后端，常见 Exporter 包括：

OTLP Exporter：发送到另一个 OTel Collector 或后端。
Prometheus Exporter：暴露 Metric 端点供 Prometheus 抓取。
Jaeger Exporter：发送 Trace 到 Jaeger 后端。
Logging Exporter：将数据输出到控制台，用于调试。

注意：Exporter 的配置通常包含认证信息（、）和重试策略。在模板设计中，应将敏感信息标记为环境变量占位符，避免硬编码。

2.3.4 Collector — 统一调度中心

Collector 是 OTel 管线的核心，负责加载配置、启动 Receiver/Processor/Exporter 并编排数据流。Collector 支持两种部署模式：

Agent 模式：与应用同机部署，轻量级采集。
Gateway 模式：独立集群部署，集中处理多 Agent 数据。

下图对比了两种部署模式的架构差异：

2.4 组件配置示例

以下是一个完整的 Collector 配置文件片段，展示了四个组件的协同工作方式：

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:
    endpoint: "backend.example.com:4317"
    tls:
      insecure: false
  logging:
    loglevel: debug

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

  模板设计要点：在自助目录模板中，应将上述配置中的 endpoint、timeout、limit_mib 等参数抽象为变量，允许用户通过表单或环境变量动态注入，避免直接修改 YAML 文件。

2.5 组件选型建议

根据不同的可观测性场景，组件选型可参考以下原则：

轻量采集场景：使用 Agent 模式 + OTLP Receiver + batch Processor + OTLP Exporter。
多数据源汇聚：使用 Gateway 模式 + 多 Receiver（OTLP + Jaeger + Prometheus）+ filter Processor + 多 Exporter。
成本控制场景：启用 memory_limiter Processor + 采样 Processor（如 tail_sampling），降低后端存储压力。
调试与验证：临时启用 logging Exporter，配合 debug Processor 查看原始数据。