3. SLO 定义与度量:镜像拉取加速 SLO 的关键指标及采集方法

在云原生灾备场景中,镜像拉取加速的 SLO(Service Level Objective)是衡量灾备恢复效率的核心契约。本章节定义三个关键指标:P99 延迟、吞吐量 和 成功率,并给出标准化的采集与计算方法。

3.1 关键指标定义与目标值

以下表格列出了镜像拉取加速 SLO 的核心指标、业务含义及建议的初始目标值(可根据实际灾备等级调整):

指标名称 业务含义 建议 SLO 目标值 测量单位
P99 延迟 最慢的 1% 拉取请求完成时间,反映长尾性能 ≤ 5 秒(单层镜像) 毫秒 (ms) / 秒 (s)
吞吐量 单位时间内成功完成的镜像拉取请求数 ≥ 100 次/分钟(单节点) 请求/秒 (req/s) 或 请求/分钟
成功率 成功拉取请求占总请求数的百分比 ≥ 99.9% 百分比 (%)
提示: 灾备场景下的 SLO 目标值应比生产环境更严格。例如,生产环境 P99 延迟可接受 10 秒,但灾备恢复时建议收紧至 5 秒以内,以缩短 RTO(恢复时间目标)。

3.2 指标采集方法

所有指标均通过 Prometheus 客户端 在镜像拉取加速代理(如 Nydus、Dragonfly 的 dfget)中埋点采集,并通过 Prometheus Server 或 VictoriaMetrics 进行聚合。以下是三种指标的详细采集方案:

3.2.1 P99 延迟采集

  • 埋点位置: 加速代理的请求处理结束处,记录从请求开始到结束的耗时。
  • 数据类型: Histogram(直方图),用于计算百分位数。
  • Prometheus 指标名: image_pull_duration_seconds
  • 标签: image_name、layer_type(base/app)、cache_hit(true/false)
# 示例:Prometheus 直方图定义(Go 客户端)
imagePullDuration = prometheus.NewHistogramVec(
    prometheus.HistogramOpts{
        Name:    "image_pull_duration_seconds",
        Help:    "Histogram of image pull durations in seconds.",
        Buckets: prometheus.DefBuckets, // 默认桶:0.005, 0.01, 0.025, ..., 10
    },
    []string{"image_name", "layer_type", "cache_hit"},
)

3.2.2 吞吐量采集

  • 埋点位置: 加速代理的请求入口处,每次请求到达时计数。
  • 数据类型: Counter(计数器),用于计算速率。
  • Prometheus 指标名: image_pull_requests_total
  • 标签: status(success/failure)
# 示例:Prometheus 计数器定义
imagePullRequestsTotal = prometheus.NewCounterVec(
    prometheus.CounterOpts{
        Name: "image_pull_requests_total",
        Help: "Total number of image pull requests.",
    },
    []string{"status"},
)

3.2.3 成功率采集

  • 埋点位置: 请求结束处,根据返回码判断成功或失败。
  • 数据类型: Counter(计数器),通过两个标签值计算比率。
  • Prometheus 指标名: image_pull_requests_total(与吞吐量共用)
  • 计算公式: rate(image_pull_requests_total{status="success"}[5m]) / rate(image_pull_requests_total[5m]) * 100

3.3 指标采集架构图

下图展示了从加速代理到 Prometheus 再到告警系统的完整采集链路:

镜像拉取加速 SLO 指标采集架构 SLO 指标采集架构 加速代理 (Nydus / dfget) Prometheus 客户端 (Histogram / Counter) Prometheus Server (聚合 & 存储) Grafana (可视化 & 仪表盘) Alertmanager (告警 & 通知) 说明: 加速代理内嵌 Prometheus 客户端,通过 /metrics 端点暴露指标;Prometheus Server 定期拉取并聚合; Grafana 用于实时仪表盘,Alertmanager 用于 SLO 违约告警。

3.4 SLO 违约判定与度量公式

在 Prometheus 中,使用 Recording Rules 预计算 SLO 状态,便于快速判定是否违约:

# Prometheus recording rules 示例
groups:
  - name: image_pull_slo
    rules:
      # P99 延迟违约判定(过去 5 分钟)
      - record: slo:p99_duration:violation
        expr: |
          histogram_quantile(0.99, 
            rate(image_pull_duration_seconds_bucket[5m])
          ) > 5

      # 成功率违约判定(过去 5 分钟)
      - record: slo:success_rate:violation
        expr: |
          (rate(image_pull_requests_total{status="success"}[5m]) 
           / rate(image_pull_requests_total[5m])) < 0.999

      # 吞吐量违约判定(过去 1 分钟)
      - record: slo:throughput:violation
        expr: |
          rate(image_pull_requests_total{status="success"}[1m]) < 1.67  # 100 req/min ≈ 1.67 req/s
注意: 吞吐量 SLO 的违约判定需结合节点数。上述规则适用于单节点场景;多节点集群应使用 sum by (node) 或 avg by (cluster) 聚合,避免因单节点抖动导致误告警。

3.5 指标采集与 SLO 违约关系图

下图展示了从原始指标到 SLO 违约告警的完整数据流:

SLO 违约判定数据流 从原始指标到 SLO 违约告警 原始指标 (Histogram/Counter) Recording Rules (预计算 SLO 状态) SLO 状态指标 (0/1 布尔值) 告警规则 (Alertmanager) 数据流说明: 1. 加速代理暴露原始指标(延迟直方图、请求计数器)。 2. Prometheus Recording Rules 将原始指标转换为 SLO 状态指标(0=正常,1=违约)。 3. Alertmanager 根据 SLO 状态指标触发告警,通知 SRE 团队。 4. 告警触发后,进入配置漂移处置流程(后续章节详述)。

3.6 采集方案对比与选型建议

针对不同规模的集群,推荐以下采集方案:

集群规模 推荐方案 优势 注意事项
单节点 / 小规模(< 50 节点) Prometheus Server + 本地存储 部署简单,运维成本低 存储容量有限,历史数据保留时间短
中规模(50-500 节点) Prometheus + Thanos 支持长期存储,全局查询 需要额外部署 Sidecar 和 Store Gateway
大规模(> 500 节点) VictoriaMetrics 集群版 高性能,低资源消耗,支持高基数 需要独立维护 VictoriaMetrics 集群
最佳实践: 无论选择哪种方案,务必为 SLO 指标设置独立的 保留策略(建议至少保留 30 天),以便进行趋势分析和 SLO 回溯审计。同时,在加速代理侧启用 指标采样(如每 15 秒采集一次),避免高频采集对代理性能造成影响。