什么是 OpenTelemetry？

前面一直在提 OpenTelemetry，可还没对 OpenTelemetry 进行过介绍。OpenTelemetry 简称 OTel，是一个对云供应商中立的可观测性的框架和工具包，用于创建和管理遥测数据。其目标是为应用和系统提供 统一的采集标准和工具。

所谓云供应商中立，意味着一个技术、标准或平台 不依赖、不绑定任何特定的云服务提供商（AWS、阿里云、GCP、Azure 等），用户可以在不同环境下自由选择和迁移，而不会被单一厂商锁定（vendor lock-in）。其像是一个规范和协议，例如 HTTP，你可以在任何云厂商部署的应用中使用。

为什么需要 OpenTelemetry

在 OTel 之前，业界有很多零散的标准或实现：

Tracing 有 OpenTracing、OpenCensus；
Metrics 有 Prometheus client；
Logging 则更是百花齐放。

这就导致了：

这些标准/工具 互不兼容；
开发者需要为每个 APM/监控厂商（Datadog、New Relic、Grafana…）写不同的埋点代码，成本高。

OpenTelemetry 的目标就是：
✅ 提供 统一标准 API/SDK，一次埋点，兼容多个后端。
✅ 用户只要关注数据采集，不用被某个监控厂商绑定。
✅ 可扩展，支持 自动探针（auto-instrumentation） 和手动埋点。

架构概览

OpenTelemetry 的典型工作流程：

OTel SDK / Auto-Instrumentation：采集 trace、metrics、logs。
OTel Collector（可选）：集中式处理和转发，支持批量、过滤、转换。
Exporter：将数据导出到后端（Prometheus, Grafana Tempo, Jaeger, Zipkin, Datadog, etc.）。

Collector-架构概览

OTel Collector

简介

OTel Collector 全称是 OpenTelemetry Collector，在 OpenTelemetry 项目中是一个 独立运行的进程/服务，主要作用是：

接收来自应用或 Agent 的数据（traces、metrics、logs）
对数据进行处理（批量、过滤、聚合、转换格式）
将数据导出到各种后端（Prometheus、Jaeger、Grafana、Datadog、AWS CloudWatch …）

它就像一个 “可观测性数据的路由器 + 处理器”。

虽然应用可以直接通过 OTel SDK 把数据导出到后端，但有几个问题：

应用代码里可能要配置很多 Exporter，很复杂。
后端地址/认证/格式变化时，需要修改应用并重新部署。
在高流量场景下，应用直接导出会影响性能。
多个应用或服务的数据如果要统一处理（比如采样、过滤），直接导出不方便。

Collector 就是为了解决这些痛点：它把采集和导出解耦，让应用只负责上报数据，Collector 负责处理和转发。

架构组成

Collector 的内部主要分为三类组件：

Receivers
- 接收数据输入。
- 支持多种协议，比如 OTLP（OpenTelemetry Protocol）、Jaeger、Zipkin、Prometheus Remote Write、Fluentd 等。
Processors
- 在数据导出前做中间处理。
- 功能包括：批处理 (batching)、采样 (sampling)、限流 (rate limiting)、属性/标签处理、格式转换等。
Exporters
- 把处理好的数据发送到后端系统。
- 支持 Prometheus、Grafana Tempo、Jaeger、Zipkin、Datadog、Elastic、云监控服务（AWS/GCP/Azure）等。

Config 示例

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


processors:
  batch:  # 添加批处理提高性能
  tail_sampling:        # 尾采样
    decision_wait: 20s  # 等待收齐整个 trace 的时间
    num_traces: 50000   # 缓存中可保存的 trace 数量
    policies:
      # 1. 错误 trace 全采样
      - name: error-traces
        type: status_code
        status_code:
          status_codes: [ERROR]

      # 2. 带 otel.debug=true 的 attribute 的 trace 全采样
      - name: debug-traces
        type: string_attribute
        string_attribute: 
          key: "otel.debug"
          values: ["true"]

      # 3. 其余正常 trace 采样 20%
      - name: normal-traces
        type: probabilistic
        probabilistic:
          sampling_percentage: 20


exporters:
  debug:
  
  otlp/jaeger:
    endpoint: "jaeger:4317"
    tls:
      insecure: true

  prometheus:
    endpoint: "0.0.0.0:9464"  # Collector 自带 Prometheus Exporter

  otlphttp/logs:
    endpoint: http://loki:3100/otlp
    tls:
      insecure: true


service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, tail_sampling]
      exporters: [debug, otlp/jaeger]

    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]

    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/logs]

常见后端

Traces 后端

Jaeger
Zipkin
Tempo（Grafana 提供的 tracing 存储）
AWS X-Ray
Datadog APM

Metrics 后端

Prometheus（通过 remote_write 或 exporter）
InfluxDB
Graphite
StatsD
Cloud Monitoring（如 Google Cloud Monitoring、Azure Monitor、AWS CloudWatch）

Logs 后端

Elasticsearch
Loki（Grafana 提供的日志存储）
Splunk
Fluentd / Fluent Bit

架构示例

Opentelemetry-collector 与 Opentelemetry-collector-Contrib

OpenTelemetry Collector 在 GitHub 上有 2 个存储库：opentelemetry-collector 和 opentelemetry-collector-contrib 。

**opentelemetry-collector （otelcol）**是 OTel Collector 的核心版本，极其轻量，只包含最基础、最稳定、最通用的组件：

Receiver：OTLP（OpenTelemetry Protocol）
Processor：batch、memory limiter、attributes 等核心处理器
Exporter：OTLP、logging

opentelemetry-collector-contrib （otelcol-contrib） 是社区增强版，在 opentelemetry-collector 的基础上，又额外增加了大量社区贡献的 Receiver、Processor、Exporter、Extension，例如，Prometheus 和 Jaeger 接收器。

正常情况下，我们应该使用 otelcol-contrib。

参考与资源

主要使用了 GPT 和各项官方的各种文档。