4. 容量规划核心指标：QPS、连接数（并发连接）、内存占用、CPU使用率、延迟P99、错误率
在 Service Mesh 数据面升级过程中，容量规划的核心在于建立一组可量化、可观测、可回溯的指标体系。Envoy 作为数据面代理，其资源消耗与流量特征高度相关。以下六个指标构成了容量规划的基准坐标系，任何偏离基线的变化都应触发回滚或限流策略。
4.1 指标全景与优先级
不同指标在升级场景中的敏感度不同。下表按“升级风险关联度”从高到低排序，帮助 SRE 在监控大盘中确定关注优先级。
| 优先级 | 指标 | 升级风险关联 | 典型阈值（参考） |
|---|---|---|---|
| P0 | 错误率 | 直接反映代理转发异常、配置失效 | > 0.1% 触发告警 |
| P0 | 延迟 P99 | 升级导致线程模型或连接池变化 | 基线 + 50ms |
| P1 | 内存占用 | 内存泄漏或配置膨胀的直接表现 | 基线 + 20% |
| P1 | CPU 使用率 | 影响 Pod 密度和调度稳定性 | 基线 + 30% |
| P2 | QPS | 容量水位标尺，用于归一化其他指标 | 不低于目标水位 |
| P2 | 并发连接数 | 决定文件描述符与线程池压力 | 不超过上限 80% |
实践建议： 在灰度升级的第一个批次中，优先观察 P0 指标。如果 P99 延迟和错误率在 5 分钟内保持稳定，再逐步放大批次规模。
4.2 指标详解与计算模型
4.2.1 QPS（每秒查询数）
QPS 是容量规划的“标尺”。Envoy 的 worker 线程模型决定了单核 QPS 上限。升级后应对比同等工作负载下的 QPS 吞吐，确保新版本代理没有引入额外的编解码开销。
- 观测方式： Envoy 的
cluster.upstream_rq_total指标按时间窗口计算。 - 归一化公式：
单核 QPS = 总 QPS / 已分配 CPU 核数。 - 升级关注点： 如果单核 QPS 下降超过 15%，说明新版本存在性能退化。
4.2.2 并发连接数
并发连接数直接影响 Envoy 的连接池大小和文件描述符消耗。升级过程中，连接数突增通常意味着客户端重连风暴或 keepalive 配置不兼容。
- 观测方式：
listener.downstream_cx_total与cluster.upstream_cx_active。 - 关键阈值： 每个 worker 线程建议不超过 5000 个活跃连接。
- 升级关注点： 对比升级前后同一时刻的连接数曲线，偏差超过 30% 需排查。
4.2.3 内存占用
Envoy 的内存占用主要由连接数、请求头大小、TLS 会话缓存和配置规模决定。升级后内存泄漏是最高频的故障模式之一。
- 观测方式： 容器级
container_memory_working_set_bytes或 Envoy 的server.memory_allocated。 - 基线建立： 在低负载时段记录稳定运行 30 分钟后的内存值。
- 升级关注点： 如果内存持续增长且不回落，立即回滚。
4.2.4 CPU 使用率
CPU 使用率决定了 Pod 的调度密度和成本。Envoy 的 CPU 消耗与 QPS 和 TLS 握手频率强相关。
- 观测方式：
process.cpu_percent或 cgroup 级别指标。 - 升级关注点： 在相同 QPS 下，CPU 使用率上升超过 30% 说明新版本存在计算瓶颈。
4.2.5 延迟 P99
P99 延迟是用户体验的黄金指标。升级过程中，Envoy 的线程模型、连接池策略或路由算法变化都可能引入尾部延迟抖动。
- 观测方式： Envoy 的
cluster.upstream_rq_time直方图。 - 基线对比： 取升级前 24 小时的 P99 作为基准线。
- 升级关注点： P99 超过基线 50ms 或相对基线增长 20% 时，暂停批次。
4.2.6 错误率
错误率是升级健康度的“一票否决”指标。包括 5xx 响应、连接超时、重置和 Envoy 内部错误。
- 观测方式：
cluster.upstream_rq_5xx与cluster.upstream_cx_destroy_local。 - 升级关注点： 任何非零的错误率上升都应视为严重事件，立即停止升级并回滚。
关键警告： 不要单独看某个指标。例如，QPS 下降可能被误认为“负载降低”，但实际原因是连接池耗尽导致请求被拒绝。必须将 QPS、连接数和错误率联合分析。
4.3 指标联动分析模型
下图展示了六个核心指标在升级过程中的联动关系。SRE 可以通过该模型快速定位故障根因。
4.4 指标采集与基线建立
在升级开始前，必须完成至少 7 天的基线数据采集。以下是推荐的采集配置示例：
# Prometheus 采集 Envoy 指标的关键配置
scrape_configs:
- job_name: 'envoy-stats'
metrics_path: /stats/prometheus
static_configs:
- targets: ['envoy-admin:9901']
# 升级前基线窗口：7 天
scrape_interval: 15s
# 记录以下核心指标
metric_relabel_configs:
- source_labels: [__name__]
regex: '(envoy_cluster_upstream_rq_total|envoy_listener_downstream_cx_total|envoy_server_memory_allocated|envoy_cluster_upstream_rq_time_bucket|envoy_cluster_upstream_rq_5xx|envoy_cluster_upstream_cx_active)'
action: keep
基线计算规则：
- QPS 基线： 取过去 7 天同一时间窗口的 P50 值。
- 延迟 P99 基线： 取过去 7 天同一时间窗口的 P99 值。
- 内存/CPU 基线： 取过去 7 天同一时间窗口的 P90 值（避免毛刺干扰）。
- 错误率基线： 取过去 7 天的最大值（通常为 0）。
4.5 升级过程中的指标判读规则
以下判读规则适用于每个升级批次（通常为 1-5 个 Pod）：
| 指标 | 绿灯（继续） | 黄灯（观察） | 红灯（回滚） |
|---|---|---|---|
| 错误率 | ≤ 基线值 | 基线 + 0.05% | > 基线 + 0.1% |
| 延迟 P99 | ≤ 基线 + 20ms | 基线 + 20~50ms | > 基线 + 50ms |
| 内存占用 | ≤ 基线 + 10% | 基线 + 10%~20% | > 基线 + 20% |
| CPU 使用率 | ≤ 基线 + 15% | 基线 + 15%~30% | > 基线 + 30% |
| QPS | ≥ 基线 90% | 基线 80%~90% | < 基线 80% |
| 并发连接数 | ≤ 基线 + 10% | 基线 + 10%~20% | > 基线 + 20% |
自动化建议： 将上述判读规则编码为升级流水线的 preStop hook。当任意指标进入红灯区间时，自动执行
kubectl rollout undo 并发送告警到 PagerDuty。
4.6 常见误判场景与规避
- 场景一：QPS 下降但错误率未上升。 可能原因是客户端退避策略生效，导致请求自然减少。此时应检查连接数是否同步下降，如果连接数未降，说明存在连接泄漏。
- 场景二：内存缓慢增长但未超阈值。 升级后 30 分钟内内存持续上升，即使未超 20% 阈值，也应延长观察窗口至 2 小时，排除内存泄漏。
- 场景三：P99 抖动但 P50 正常。 说明存在少量长尾请求，可能由 TLS 握手或路由表重载引起。需要进一步分析 Envoy 的 worker 线程调度延迟。
核心原则： 容量规划不是静态的资源估算，而是动态的指标对比。升级过程中，任何指标偏离基线都意味着新版本引入了不可预期的行为变化。宁可回滚重试，不可带病上线。