2. OpenTelemetry 基础：项目背景、三大信号与架构组件
2.1 项目背景：从碎片化到统一标准
在 OpenTelemetry（简称 OTel）出现之前，可观测性领域面临严重的厂商锁定与协议碎片化问题。每个 APM 厂商（Datadog、New Relic、SkyWalking、Zipkin 等）都定义了自己的数据模型、采集 Agent 和导出协议。团队每接入一个后端，就需要修改代码、替换 SDK、重新配置采集器，运维成本极高。
OpenTelemetry 由 OpenTracing 与 OpenCensus 两个项目于 2019 年合并而成，现为 CNCF 孵化项目。其核心目标只有一个：一套 SDK、一套协议、一个 Collector，对接任意后端。
- 2019 年：OpenTracing + OpenCensus 合并，启动 OTel 项目
- 2021 年：发布 GA 版本（Traces/Metrics 信号稳定）
- 2023 年：Logs 信号进入稳定阶段，OTLP 成为 CNCF 推荐协议
- 2024 年：Profiling 信号实验性发布，持续演进
2.2 三大信号：Traces / Metrics / Logs
OTel 将可观测性数据归纳为三种核心信号（Signals），它们从不同维度描述系统状态，缺一不可。
| 信号 | 描述 | 典型问题 | OTel 数据模型 |
|---|---|---|---|
| Traces（链路） | 记录一次请求在分布式系统中的完整路径，包含 Span 与 SpanContext | 哪个服务慢？调用链哪里断了？ | Span（名称、开始/结束时间、属性、事件、状态） |
| Metrics（指标） | 聚合后的数值型数据，如请求量、延迟、错误率、CPU 使用率 | 系统整体健康度？趋势是否异常？ | Counter、Histogram、Gauge、UpDownCounter |
| Logs（日志） | 带时间戳的结构化或非结构化文本记录 | 具体错误是什么？上下文细节？ | LogRecord（时间戳、严重级别、body、属性） |
三大信号通过 OTel Context Propagation（上下文传播） 关联。Trace ID 可以嵌入到 Metric 的 Attributes 和 Log 的 Record 中，实现跨信号关联查询。
2.3 架构组件：Collector / Exporter / Processor
OTel 的架构分为三层：Instrumentation（插桩层）、Collector（采集层）、Backend（后端层）。其中 Collector 是核心枢纽，内部由 Pipeline 驱动，包含 Receiver、Processor、Exporter 三大组件。
2.4 核心组件详解
2.4.1 Receiver（接收器）
Receiver 是 Collector 的数据入口，负责接收来自 OTel SDK、Agent 或其他系统的遥测数据。支持多种协议：
- OTLP Receiver：原生 gRPC/HTTP 协议，接收 Trace/Metric/Log
- Prometheus Receiver：抓取 Prometheus 格式指标
- Jaeger Receiver：接收 Jaeger Thrift 格式链路
- Kafka Receiver：从 Kafka Topic 消费数据
2.4.2 Processor（处理器）
Processor 是 Pipeline 的中间件，负责数据变换与路由。常见 Processor 包括：
| Processor 名称 | 功能 | Runbook 自愈场景 |
|---|---|---|
| batch | 将多个 Span/Metric/Log 合并为一批，减少网络开销 | 高吞吐场景下降低后端压力 |
| filter | 根据属性或正则表达式丢弃或保留数据 | 只保留关键服务的 Trace，减少存储成本 |
| attributes | 增删改 Span/Metric/Log 的属性 | 注入环境标签（env=prod, region=cn-east） |
| tailsampling | 基于尾部采样策略，保留高价值链路 | 只保留错误或慢请求的完整 Trace |
| k8sattributes | 从 Kubernetes API 获取 Pod/Node/Namespace 元数据 | 自动关联容器资源与遥测数据 |
2.4.3 Exporter（导出器）
Exporter 将处理后的数据发送到后端。OTel 支持数十种 Exporter，常用如下：
- OTLP Exporter：标准协议，发送到 OTel Collector 或任何支持 OTLP 的后端
- Prometheus Exporter：暴露 /metrics 端点供 Prometheus 抓取
- Jaeger Exporter：发送链路到 Jaeger 后端
- Loki Exporter：发送日志到 Grafana Loki
- File Exporter：写入本地文件，用于调试或离线分析
2.5 Collector 部署模式
Collector 支持两种部署模式，SRE 团队应根据规模选择：
| 模式 | 部署位置 | 优势 | 劣势 |
|---|---|---|---|
| Agent 模式 | 每个节点/ Pod 部署一个 Collector | 低延迟、本地缓存、故障隔离 | 管理成本高、资源占用多 |
| Gateway 模式 | 独立部署 Collector 集群 | 集中配置、统一采样、后端解耦 | 单点瓶颈（可水平扩展） |
大型生产环境通常采用 Agent + Gateway 混合模式：Agent 负责本地采集与预处理，Gateway 负责全局采样、路由与后端分发。
2.6 与 Runbook 联动的基础
理解 OTel 三大信号与 Collector 架构后，Runbook 自愈系统可以这样利用 OTel：
- Metrics 触发告警：Collector 将业务指标（如 p99 延迟、错误率）导出到 Prometheus，Prometheus 触发 Alertmanager 告警。
- Traces 定位故障：告警携带 Trace ID，自愈系统通过 Jaeger 或 Tempo 查询完整调用链，定位故障服务。
- Logs 提取根因：从故障服务的 Logs 中提取错误堆栈或异常上下文，匹配 Runbook 中的已知故障模式。
- Processor 动态干预：自愈系统通过 Collector 的 Processor 动态调整采样率、注入诊断属性，或路由数据到诊断管道。