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