3. Metric 基础概念：定义、类型、维度与采集方式
在构建跨团队 CI/CD 流水线 SLI 体系之前，必须统一团队对 Metric（度量指标） 的认知。Metric 是 SLI 的原始数据来源，错误的 Metric 设计将直接导致 SLI 口径偏差。本节从定义、类型、维度标签、采集方式四个维度建立 Metric 基础共识。
3.1 Metric 的定义与核心类型
Metric 是随时间变化的、可聚合的数值序列，用于描述系统或流程的某一可观测特征。在 Prometheus、OpenTelemetry 等主流可观测性体系中，Metric 分为四种核心类型：
| 类型 | 英文 | 核心特征 | 典型 CI/CD 场景 |
|---|---|---|---|
| 计数器 | Counter | 只增不减（除重启外），适合累计量 | 流水线总执行次数、构建失败次数 |
| 仪表 | Gauge | 可增可减，反映当前瞬时值 | 排队中的 Job 数、Agent 空闲数量 |
| 直方图 | Histogram | 对观测值分桶统计，可计算分位数 | 构建耗时分布、部署耗时分布 |
| 摘要 | Summary | 客户端直接计算分位数，无法聚合 | 端到端流水线延迟的 P50/P95/P99 |
⚠️ 类型选择原则： SLI 中的“速率”类指标（如每分钟部署次数）必须基于 Counter 计算 rate()，不可直接使用 Gauge 累加；延迟类 SLI 优先使用 Histogram 以获得可聚合的分位数能力，Summary 仅用于无法修改客户端埋点的遗留系统。
3.2 Metric 的维度与标签
维度（Dimension）和标签（Label）是 Metric 可观测性的核心扩展能力。一个 Metric 名称加上一组标签键值对，唯一确定一条时间序列。
标签设计三原则：
- 高基数控制： 避免将 request_id、commit_sha 等无限增长的字段作为标签，会导致存储爆炸和查询性能下降。
- 可过滤性： 标签应支持按团队、流水线名称、环境、阶段等维度进行下钻分析。
- 一致性： 跨团队使用统一的标签命名规范，例如 team、pipeline_name、stage、status、branch。
| 标签示例 | 基数级别 | 是否推荐 | 说明 |
|---|---|---|---|
| team, pipeline_name, stage | 低（< 1000） | ✅ 强烈推荐 | SLI 下钻与聚合的基础维度 |
| status (success/failure/skip) | 低（< 10） | ✅ 推荐 | 用于计算成功率、失败率 |
| branch, environment | 中（< 10000） | ⚠️ 谨慎使用 | 需要配合 retention 策略，避免基数膨胀 |
| commit_sha, request_id | 极高（无限） | ❌ 禁止 | 应使用日志或事件系统存储，而非 Metric |
💡 跨团队对齐建议： 在组织级 Metric 规范中，强制要求所有 CI/CD 流水线指标必须携带 team、pipeline_name、stage 三个标签，否则拒绝采集。这是实现跨团队 SLI 聚合与对比的前提。
3.3 Metric 的采集方式：Push vs Pull
采集方式决定了 Metric 数据的传输模型，直接影响流水线 SLI 的可靠性、延迟和运维成本。两种模式对比如下：
| 对比维度 | Pull 模式（拉取） | Push 模式（推送） |
|---|---|---|
| 代表系统 | Prometheus, OpenTelemetry Collector (Pull) | Graphite, StatsD, OpenTelemetry (Push) |
| 数据流向 | 监控系统主动访问目标端点获取数据 | 目标主动将数据发送到监控系统 |
| 服务发现 | 依赖服务发现机制（K8s SD, Consul） | 无需服务发现，目标已知接收端地址 |
| 生命周期 | 适合长期运行的服务 | 适合短生命周期任务（如 CI Job） |
| 失败处理 | 采集失败可重试，不影响目标 | 推送失败可能导致数据丢失 |
| CI/CD 适用性 | 适合 Agent 常驻的构建集群 | 适合每个 Job 独立推送的流水线 |
🚨 流水线场景关键决策： CI/CD Job 通常是短生命周期（秒级到分钟级），Pull 模式可能因 Job 结束而错过采集窗口。推荐采用 Push → 网关 → Pull 的混合架构：Job 将 Metric 推送到本地网关或 Sidecar，Prometheus 再从网关 Pull 数据。这样既兼容短生命周期任务，又保留 Pull 模式的数据可靠性。
3.4 跨团队 Metric 设计集成要点
在跨团队协作中，Metric 设计必须满足以下集成要求：
- 命名空间隔离： 每个团队使用前缀区分，例如
team_a_pipeline_build_duration_seconds，避免命名冲突。 - 标签对齐： 所有团队必须使用相同的标签键（如
team、pipeline_name、stage），否则无法在组织级仪表盘上聚合。 - 单位标准化： 时间类指标统一使用
_seconds或_milliseconds后缀，大小类指标使用_bytes，禁止混用。 - 采集方式统一： 推荐全组织采用 Push → 网关 → Pull 架构，避免部分团队用 Push、部分用 Pull 导致的数据孤岛。
📐 集成检查清单：
✅ 所有 Metric 名称符合
✅ 所有 Metric 携带 team、pipeline_name、stage 标签
✅ 时间单位统一为秒（seconds），不使用毫秒或分钟
✅ 采集方式统一为 Push → 网关 → Pull
✅ 高基数标签（如 commit_sha）已排除在 Metric 之外
✅ 所有 Metric 名称符合
<namespace>_<name>_<unit> 格式✅ 所有 Metric 携带 team、pipeline_name、stage 标签
✅ 时间单位统一为秒（seconds），不使用毫秒或分钟
✅ 采集方式统一为 Push → 网关 → Pull
✅ 高基数标签（如 commit_sha）已排除在 Metric 之外