2. OpenTelemetry 基础回顾：三大信号与 Collector 架构
在事件驱动 Runbook 联动修复体系中，可观测性数据是触发自动化动作的“燃料”。OpenTelemetry（OTel）作为 CNCF 的标准化可观测性框架，统一了 Trace、Metric、Log 三大信号的采集、处理与导出规范。本节将快速回顾其核心概念，为后续构建联动 Runbook 打下基础。
2.1 三大信号：Trace / Metric / Log
三大信号分别从不同维度描述系统状态，共同构成可观测性的“三支柱”。下表对比了它们的核心特征与在 Runbook 联动中的典型用途：
| 信号类型 | 核心描述 | 数据形态 | Runbook 联动触发场景 |
|---|---|---|---|
| Trace（链路） | 记录一次请求在分布式系统中的完整路径，包含 Span 与 SpanContext | 树状结构，含开始/结束时间、属性、状态 | 检测慢调用、错误传播、依赖故障 |
| Metric（指标） | 聚合后的数值型数据，如请求速率、错误率、延迟分位数 | 时间序列，含标签/维度 | 阈值告警触发自动扩缩容、熔断 |
| Log（日志） | 离散的事件记录，通常包含时间戳、严重级别、结构化消息 | 非结构化或半结构化文本 | 错误详情分析、审计、事后复盘 |
联动要点： 在事件驱动 Runbook 中，Trace 提供请求级上下文，Metric 提供聚合趋势，Log 提供根因细节。三者通过
trace_id、span_id 等关联字段实现信号关联，避免信息孤岛。
2.2 OTel Collector 架构
OTel Collector 是一个与供应商无关的代理，负责接收、处理、导出可观测性数据。其核心架构遵循 Pipeline（管道） 模式，由 Receiver、Processor、Exporter 三大组件构成。下图展示了 Collector 的内部数据流：
2.3 Exporter 与 Processor 概念详解
Processor 和 Exporter 是 Pipeline 中实现数据治理与分发的关键组件。理解它们的职责，是配置 Collector 以适配 Runbook 联动逻辑的前提。
Processor（处理器）
Processor 位于 Receiver 与 Exporter 之间，负责对数据进行中间处理。常见用途包括：
- 批处理（Batch）： 将多个数据点合并为一批，减少网络请求次数，提升吞吐量。
- 采样（Sampling）： 按比例或规则丢弃部分 Trace，控制存储成本。
- 属性修改（Attributes）： 添加、删除或修改 Span/Metric 的标签，例如注入环境名称、服务版本。
- 过滤（Filter）： 根据条件丢弃不需要的数据，例如只保留错误 Trace。
- 内存排队（Memory Limiter）： 防止 Collector 因数据堆积而 OOM。
Runbook 联动场景： 在事件驱动修复中，Processor 可用于在数据进入 Exporter 前，自动为所有 Span 注入
runbook_id 标签，便于后续告警系统直接关联到对应的自动化修复流程。
Exporter（导出器）
Exporter 负责将处理后的数据发送到指定的后端系统。每个 Exporter 对应一种数据格式或存储目标：
| Exporter 类型 | 目标后端 | 典型用途 |
|---|---|---|
| OTLP Exporter | OTel Collector 或兼容后端 | 跨 Collector 级联转发 |
| Prometheus Exporter | Prometheus / VictoriaMetrics | 指标存储与告警 |
| Jaeger Exporter | Jaeger 后端 | Trace 存储与检索 |
| File Exporter | 本地文件系统 | 调试、审计日志 |
| Loki Exporter | Grafana Loki | 日志聚合 |
2.4 三大信号与 Collector 的联动关系
下图展示了 Trace、Metric、Log 如何通过 Collector 的 Pipeline 实现统一采集与分发，并最终服务于事件驱动 Runbook：
常见误区： 不要将 Collector 视为简单的“数据转发器”。Processor 的过滤与采样策略直接影响 Runbook 的触发准确性。例如，若采样率过低，可能导致关键错误 Trace 被丢弃，Runbook 无法及时响应。建议在 Processor 中为高优先级服务配置“头部采样”或“错误采样”策略。