2. OpenTelemetry 核心概念：Signal、Instrumentation、Exporter、Collector

在构建 CI/CD 流水线性能指标采集体系之前，必须理解 OpenTelemetry 的四大核心概念：Signal（遥测信号）、Instrumentation（插桩）、Exporter（导出器） 和 Collector（采集器）。这四个概念构成了从数据产生、采集、处理到导出的完整链路。

2.1 Signal：遥测信号的三大支柱

Signal 是 OpenTelemetry 定义的可观测性数据模型，包含三种标准信号：Traces（链路）、Metrics（指标） 和 Logs（日志）。在 CI/CD 场景中，三种信号分别回答不同的问题：

信号类型 核心概念 CI/CD 场景示例
Traces Span（跨度）、Trace（完整链路）、SpanContext（上下文传播） 一次构建请求从代码检出 → 编译 → 测试 → 打包的完整调用链
Metrics Counter（计数器）、Histogram（直方图）、Gauge（仪表盘） 构建耗时分布、构建成功率、并发构建数、资源使用率
Logs LogRecord（日志记录）、Severity（严重级别）、Attributes（属性） 构建失败错误日志、编译警告、测试失败详情
实践要点：在自助流水线场景中，建议优先采集 Metrics 用于实时监控和告警，Traces 用于故障定位和性能瓶颈分析，Logs 用于深度排查。三种信号通过 TraceId 和 SpanId 实现关联。

2.2 Instrumentation：自动插桩与手动插桩

Instrumentation 是让应用产生遥测数据的过程。OpenTelemetry 提供两种方式：

  • 自动插桩（Auto Instrumentation）：通过字节码增强、库拦截或 Agent 方式，无需修改业务代码即可采集常见框架的遥测数据。适用于 Jenkins、GitLab CI、GitHub Actions 等 CI/CD 平台的基础监控。
  • 手动插桩（Manual Instrumentation）：通过 SDK API 在代码中显式创建 Span、记录 Metric、写入 Log。适用于自定义流水线步骤、业务逻辑埋点、性能关键路径的精细化监控。
推荐策略：CI/CD 流水线采用 自动插桩 + 手动插桩 混合模式。自动插桩覆盖平台层（如 Jenkins 插件、GitLab Runner），手动插桩覆盖流水线中的关键业务步骤（如构建脚本、测试用例、部署阶段）。 
// 手动插桩示例：在自定义构建步骤中创建 Span
import io.opentelemetry.api.trace.Span;
import io.opentelemetry.api.trace.Tracer;

Tracer tracer = openTelemetry.getTracer("ci-pipeline-instrumentation");
Span buildSpan = tracer.spanBuilder("build-step")
    .setAttribute("pipeline.name", pipelineName)
    .setAttribute("build.number", buildNumber)
    .startSpan();

try {
    // 执行构建逻辑
    executeBuild();
} catch (Exception e) {
    buildSpan.recordException(e);
    buildSpan.setStatus(StatusCode.ERROR);
} finally {
    buildSpan.end();
}

2.3 Exporter：数据导出与后端适配

Exporter 负责将采集到的遥测数据发送到后端存储或分析系统。OpenTelemetry 支持多种导出协议和格式：

导出方式 协议/格式 适用后端 CI/CD 推荐场景
OTLP Exporter gRPC / HTTP + Protobuf OpenTelemetry Collector、Jaeger、Zipkin 标准链路，推荐首选
Prometheus Exporter HTTP /text 格式 Prometheus、VictoriaMetrics 指标监控，适合告警
Console Exporter 标准输出 调试、本地开发 流水线调试阶段
File Exporter JSON / Line Protocol 日志文件、离线分析 合规审计、历史回溯
注意：在 CI/CD 环境中，Exporter 的配置需要考虑网络隔离和性能开销。建议在流水线内部署 Collector 作为代理，由 Collector 统一处理数据导出，避免每个构建任务直接连接后端。

2.4 Collector：数据采集与处理中枢

OpenTelemetry Collector 是一个独立运行的组件，负责接收、处理、导出遥测数据。在 CI/CD 架构中，Collector 扮演着核心枢纽角色：

  • 接收器（Receiver）：支持 OTLP、Prometheus、Jaeger、Kubernetes 等多种数据源接入。
  • 处理器（Processor）：提供数据过滤、采样、批处理、属性修改、重试等能力。
  • 导出器（Exporter）：将处理后的数据发送到后端系统。
架构建议：在 CI/CD 场景中，推荐部署 两层 Collector 架构：
1. Agent Collector：部署在每个 CI Runner 节点上，负责本地数据采集和轻量处理。
2. Gateway Collector：部署在集群中，负责聚合、过滤、路由数据到后端存储。
OpenTelemetry 核心概念架构图 Instrumentation 自动插桩 （Agent / 字节码增强） 手动插桩 （SDK API） Signal 遥测信号 Traces（链路） Metrics（指标） Logs（日志） Exporter OTLP Prometheus Console / File Collector 采集器 Receiver（接收器）→ Processor（处理器）→ Exporter（导出器） 数据过滤 · 采样 · 批处理 · 属性修改 · 重试 Agent Collector（节点级）→ Gateway Collector（集群级） 数据流向：Instrumentation 产生 Signal → Collector 处理 → Exporter 导出到后端

2.5 核心概念关系总结

四个核心概念在 CI/CD 流水线中的协作关系如下：

  1. Instrumentation 在流水线各阶段（代码检出、编译、测试、打包、部署）植入探针，产生 Traces、Metrics、Logs 数据。
  2. Signal 作为标准化的数据模型，确保不同语言、不同框架产生的遥测数据格式统一。
  3. Collector 接收所有信号，执行数据过滤、采样、聚合、属性增强等处理，降低后端存储压力。
  4. Exporter 将处理后的数据发送到 Prometheus、Jaeger、Elasticsearch 等后端系统，用于可视化、告警和分析。
关键设计原则：在自助流水线场景中，Collector 是架构的核心。通过 Collector 的处理器（Processor）可以实现：
- 采样策略：对成功构建只保留 10% 的 Trace，对失败构建保留 100%。
- 属性增强：自动添加流水线名称、构建编号、触发用户等上下文信息。
- 数据路由：将 Metrics 发送到 Prometheus，Traces 发送到 Jaeger，Logs 发送到 Elasticsearch。
CI/CD 自助流水线数据流 代码检出 编译构建 自动化测试 镜像打包 部署上线 Instrumentation 层：自动插桩 + 手动插桩 Signal 层：Traces + Metrics + Logs Collector 层：接收 → 处理 → 路由 Exporter 层：OTLP / Prometheus / File 数据流向 流水线 ↓ Instrumentation ↓ Signal ↓ Collector ↓ Exporter ↓ 后端存储

2.6 本章小结

理解 OpenTelemetry 的四大核心概念是构建 CI/CD 自助流水线性能指标采集体系的基础：

  • Signal 定义了标准化的数据模型，确保不同来源的遥测数据可以统一处理。
  • Instrumentation 提供了灵活的数据采集方式，自动插桩降低接入成本，手动插桩满足定制需求。
  • Collector 作为数据中枢，承担接收、处理、路由的核心职责，是架构设计的重点。
  • Exporter 负责将数据送达后端，支持多种协议和存储系统。
← 上一章 📖 返回目录 下一章 →