用p99延迟和SLO替代平均CPU利用率：构建更准确的容量规划指标体系

平均 CPU 利用率长期以来是容量规划的核心指标，但在容器化环境中，这一指标正变得越来越不可靠。Jeremy Theocharis 在 Hacker News 上的讨论指出，平均 CPU 图表可能是最具误导性的监控视图之一 —— 它看起来健康，却可能掩盖严重的性能问题。

平均 CPU 的陷阱

传统监控依赖平均 CPU 利用率来判断服务是否 "健康"。当平均 CPU 维持在 50%-60% 时，运维团队通常认为资源充足。然而，这种平滑后的指标无法反映 CPU 使用的瞬时波动，特别是在 Kubernetes 等容器编排平台中。

问题的根源在于 Linux 的 CFS（Completely Fair Scheduler）调度器。当容器配置了 CPU 限额（quota）时，CFS 以 100ms 为周期分配 CPU 时间。如果容器在某周期内用完了配额，即使节点整体 CPU 空闲，该容器也会被强制节流（throttle），直到下一个周期开始。这种节流对用户而言表现为请求延迟的突然增加，但平均 CPU 利用率可能仍然显示为 "正常"。

CFS Throttling 机制解析

CFS throttling 的核心机制可以用一个简单的例子说明：假设一个容器配置了 200m CPU limit（即每 100ms 周期可用 20ms CPU 时间）。如果请求突发导致容器在 10ms 内用完了这 20ms 配额，剩下的 90ms 该容器将被强制休眠，即使此时节点 CPU 使用率只有 10%。

这种节流在监控上的表现是：container_cpu_cfs_throttled_periods_total指标持续增加，而平均 CPU 利用率可能仅显示为 20%—— 远低于告警阈值。对于延迟敏感型服务，这意味着 p99 延迟可能已经恶化数倍，但监控仪表盘依然一片绿色。

从平均 CPU 到 p99+SLO 的指标转型

替代方案的核心是将监控重心从 "资源利用率" 转向 "用户体验"。具体而言，需要建立三层指标体系：

第一层：延迟分位数监控

• p50 反映典型用户体验
• p95/p99 捕捉尾部延迟，这是 CFS throttling 最直接的信号
• 建议设置 p99 延迟 SLO（如 < 200ms），并监控 SLO burn rate

第二层：节流指标

• container_cpu_cfs_throttled_periods_total / container_cpu_cfs_periods_total：节流周期占比
• container_cpu_cfs_throttled_seconds_total：实际被节流的时间
• 当节流周期占比 > 5% 或节流时间持续非零时触发告警

第三层：容量关联指标

• Pod CPU usage vs limit ratio：判断是否因限额过低导致节流
• Request rate 与 queue depth：识别请求堆积
• CPU burst 模式分析：了解工作负载的突发特征

可落地的监控参数清单

对于生产环境的容量规划，建议配置以下监控参数：

Prometheus 查询示例：

# 节流周期占比
rate(container_cpu_cfs_throttled_periods_total[5m]) / rate(container_cpu_cfs_periods_total[5m])

# 每秒被节流时间
rate(container_cpu_cfs_throttled_seconds_total[5m])

# CPU使用率与限额比值
container_cpu_usage_seconds_total / container_spec_cpu_quota * container_spec_cpu_period

告警阈值建议：

• 节流周期占比 > 5% 持续 5 分钟：警告级
• 节流时间 > 0 且 p99 延迟超过 SLO：严重级
• CPU usage/limit ratio>0.8 且存在节流：容量不足信号

容量规划实践建议

基于 p99 延迟和 SLO 的容量规划需要调整传统思路：

设置 CPU request 与 limit 的策略差异

• Request 基于稳态负载设置，用于调度决策
• Limit 应足够高以吸收正常突发，对于延迟敏感服务可考虑不设 limit 或设为 request 的 2-3 倍

优先基于延迟而非 CPU 扩容

• 对于用户 - facing 服务，自动伸缩应触发于 p95/p99 延迟或队列深度，而非 CPU 利用率
• CPU 利用率可作为辅助信号，但不应是主要决策依据

定期审查节点超售

• 集群层面的 CPU 争用会加剧 CFS throttling 的影响
• 即使单个 Pod 资源配置合理，节点过度超售仍可能导致节流

测试验证

• 合成负载测试往往产生平滑的 CPU 曲线，难以发现节流问题
• 使用生产流量镜像或混沌测试验证容量规划

结论

平均 CPU 利用率在容器化时代已经不足以支撑准确的容量规划。CFS throttling 机制使得 "低平均 CPU" 与 "良好用户体验" 之间不再存在必然联系。将监控核心从资源指标转向以 p99 延迟为代表的体验指标，配合节流监控和 SLO burn rate，才能构建真正可靠的容量规划体系。

这一转变不仅是技术层面的指标替换，更是运维哲学从 "资源管理" 向 "服务等级目标管理" 的演进。

参考来源

• Jeremy Theocharis, "How CFS throttling works and the case against the average CPU graph", Hacker News, 2026
• Dan Luu, "The container throttling problem", https://danluu.com/cgroup-throttling/

systems