2. OpenTelemetry 核心概念：Trace、Span、Metric、Log、Exporter、Collector、Instrumentation
在构建 Runbook 联动自动回滚体系时，可观测性数据的质量直接决定决策的准确性。OpenTelemetry（简称 OTel）作为 CNCF 的标准化可观测性框架，统一了遥测数据的采集、处理与导出规范。本章深入拆解 OTel 的七大核心概念，为后续的自动回滚触发逻辑打下坚实的数据基础。
2.1 核心数据模型：Trace、Span、Metric、Log
OTel 将可观测性数据归纳为三种信号（Signal）：Traces（追踪）、Metrics（指标）和 Logs（日志）。其中 Trace 由多个 Span 构成，形成请求的完整调用链。
| 概念 | 定义 | 在回滚场景中的典型用途 |
|---|---|---|
| Trace | 一次请求或事务在分布式系统中的完整路径 | 追踪一次部署后的用户请求是否经过所有预期服务 |
| Span | Trace 中的一个工作单元，包含开始/结束时间、状态、属性 | 检测某个微服务在部署后的响应时间是否突增 |
| Metric | 可聚合的数值测量，如请求速率、错误率、延迟分位数 | 触发回滚的核心阈值指标（如错误率 > 5%） |
| Log | 带时间戳的结构化或非结构化文本记录 | 记录回滚决策原因、异常堆栈、审计信息 |
关键认知： 在自动回滚 Runbook 中，Metrics 负责快速触发告警，Traces 负责定位故障服务，Logs 负责提供根因分析的上下文。三者缺一不可。
2.2 数据采集与处理：Instrumentation、Collector、Exporter
数据从产生到被下游系统消费，需要经过三个关键环节：Instrumentation（插桩）、Collector（收集器）和 Exporter（导出器）。
- Instrumentation：通过 SDK 或自动注入的方式，在应用程序代码中嵌入遥测数据生成逻辑。支持手动插桩（Manual）和自动插桩（Auto）。
- Collector：OTel 的独立组件，负责接收、处理、转发遥测数据。支持批处理、过滤、采样、属性修改等操作。
- Exporter：将处理后的数据发送到后端存储或分析平台（如 Prometheus、Jaeger、Elasticsearch、Datadog）。
架构要点： Collector 是回滚数据管道的核心枢纽。通过在 Collector 中配置
batch processor 和 memory_limiter processor，可以防止数据洪峰冲垮下游系统，确保回滚决策数据的完整性。
2.3 核心架构关系图
下图展示了 OTel 核心组件之间的数据流关系，以及它们如何支撑 Runbook 自动回滚决策。
2.4 各组件在自动回滚中的职责
下表将 OTel 组件与 Runbook 自动回滚的各个阶段进行映射，明确每个组件在回滚流程中的具体职责。
| 组件 | 回滚阶段 | 具体职责 | 配置示例 |
|---|---|---|---|
| Instrumentation | 数据产生 | 在代码中注入错误率、延迟、请求量等关键业务指标 | @WithSpan("deploy.rollback.check") |
| Collector | 数据处理 | 过滤无效数据、聚合指标、添加部署版本标签 | attributes/deployment.version |
| Exporter | 数据输出 | 将处理后的指标实时推送到告警系统（如 Prometheus Alertmanager） | otlp/metrics |
| Trace | 故障定位 | 当错误率上升时，快速定位到具体哪个服务或 API 出现异常 | 查看 Span 状态码 STATUS_CODE_ERROR |
| Metric | 阈值触发 | 提供 http.server.request.error_count 等指标，触发回滚条件 |
错误率 > 5% 持续 30 秒 |
| Log | 审计记录 | 记录回滚开始时间、触发原因、执行结果，用于事后复盘 | 结构化日志包含 rollback_reason 字段 |
2.5 三种信号在回滚决策中的协同关系
自动回滚不是单一指标就能决定的，需要三种信号协同工作。下图展示了从指标触发到根因定位再到审计记录的全流程。
2.6 实战配置示例：Instrumentation 与 Collector
以下是一个典型的 Python 应用手动插桩示例，结合 Collector 配置，展示如何为回滚场景准备数据。
Python 应用手动插桩（关键片段）：
from opentelemetry import trace, metrics
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.exporter.otlp.proto.grpc.exporter import OTLPSpanExporter, OTLPMetricExporter
# 配置 Tracer
trace.set_tracer_provider(TracerProvider())
tracer = trace.get_tracer(__name__)
# 配置 Meter
meter = metrics.get_meter(__name__)
deploy_error_counter = meter.create_counter(
"deploy.rollback.error_count",
description="部署后错误计数，用于触发回滚"
)
# 在关键业务逻辑中记录 Span 和 Metric
with tracer.start_as_current_span("process_order") as span:
try:
# 业务逻辑
process_order()
span.set_status(trace.StatusCode.OK)
except Exception as e:
span.set_status(trace.StatusCode.ERROR, str(e))
deploy_error_counter.add(1, {"deploy.version": "v2.3.1"})
# 此处可触发回滚逻辑
Collector 配置（config.yaml 关键片段）：
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
processors:
batch:
timeout: 1s
send_batch_size: 1024
memory_limiter:
check_interval: 1s
limit_mib: 512
attributes:
actions:
- key: deployment.version
value: "${DEPLOY_VERSION}"
action: upsert
exporters:
prometheus:
endpoint: 0.0.0.0:8889
namespace: deploy_rollback
service:
pipelines:
metrics:
receivers: [otlp]
processors: [memory_limiter, batch, attributes]
exporters: [prometheus]
注意： 在回滚场景中，务必在 Collector 的
attributes processor 中注入 deployment.version 标签。这样 Prometheus 中的指标才能按版本区分，Runbook 才能准确判断是新版本还是旧版本的问题。
2.7 本章小结
OpenTelemetry 的七大核心概念构成了可观测性数据管道的完整闭环：
- Trace / Span / Metric / Log 是三种信号的具体实现，分别负责链路追踪、指标聚合和日志记录。
- Instrumentation 是数据源头，决定了你能观测到什么。
- Collector 是数据枢纽，负责清洗、增强和路由。
- Exporter 是数据出口，将数据送达下游分析系统。