3、核心指标定义(上):QPS、并发连接数(CCU)、请求延迟(P99/P95)、错误率(5xx)

网关容量规划的核心在于建立可量化的基线。在 K8s 集群升级场景中,网关(Ingress/Gateway API/Service Mesh 入口)是流量入口,其容量直接决定升级期间业务是否受损。本节定义四个最关键的容量指标:QPS、并发连接数(CCU)、请求延迟(P99/P95)、错误率(5xx)。这四个指标构成网关容量评估的“四象限”,缺一不可。

核心原则:容量基线不是单一数字,而是“在满足延迟和错误率约束下的最大 QPS 与 CCU 组合”。升级前必须同时采集这四类指标,才能判断网关是否处于健康水位。

3.1 QPS(每秒查询数)

QPS 是最直观的吞吐量指标,定义网关每秒能处理的请求数量。在 K8s 网关场景下,需区分总 QPS 与 有效 QPS:

  • 总 QPS:网关 Pod 所有 Ingress/Route 规则接收的 HTTP 请求总数(含重试、健康检查)。
  • 有效 QPS:剔除 4xx/5xx 错误后的成功请求数,反映真实业务承载能力。
维度 采集方式 Prometheus 指标示例 升级前基线参考
总 QPS 网关 Pod 级别 rate() 聚合 rate(nginx_ingress_controller_requests[1m]) 峰值不超过单 Pod 上限的 70%
有效 QPS 过滤 status < 500 rate(nginx_ingress_controller_requests{status!~"5.."}[1m]) 不低于总 QPS 的 95%
单 Pod QPS 除以副本数 avg by (pod) (rate(...)) 各 Pod 间偏差 < 20%
升级前检查点:如果总 QPS 已接近网关 Pod 的 CPU 瓶颈(通常 CPU > 80% 时 QPS 增长曲线变平),必须先扩容再升级,否则升级过程中 Pod 滚动重启会导致容量骤降。

3.2 并发连接数(CCU)

CCU(Concurrent Connections)衡量网关同时维持的 TCP/HTTP 连接数。K8s 网关通常使用反向代理模式(如 Nginx、Envoy),每个连接会占用内存和文件描述符。CCU 过高会导致连接超时、内存 OOM 或端口耗尽。

需要区分两类连接:

  • 活跃连接(Active Connections):正在处理请求的连接,直接消耗 CPU 和内存。
  • 空闲连接(Idle Connections):Keep-Alive 保持的空闲连接,主要消耗内存和文件句柄。
# Nginx Ingress 连接数 PromQL 示例
# 当前活跃连接数
nginx_ingress_controller_nginx_process_connections{state="active"}

# 当前空闲连接数
nginx_ingress_controller_nginx_process_connections{state="idle"}

# 总连接数(活跃 + 空闲)
sum(nginx_ingress_controller_nginx_process_connections) by (pod)
连接类型 影响资源 升级前警戒线 扩容建议
活跃连接 CPU、内存、请求队列 单 Pod 活跃连接 > 5000 增加副本数或调大 worker_connections
空闲连接 内存、文件描述符 空闲连接占比 > 60% 缩短 keepalive_timeout
总连接数 系统 ulimit 限制 接近 Pod 文件描述符上限的 80% 调整 fs.file-max 或增加 Pod 资源
常见陷阱:升级过程中,旧 Pod 被逐步销毁,新 Pod 尚未完全就绪,会导致剩余 Pod 的 CCU 瞬间飙升。如果升级前 CCU 已处于高水位(>70% 上限),升级期间极易触发连接拒绝(Connection Refused)错误。建议升级前将 CCU 控制在 50% 以下。

3.3 请求延迟(P99/P95)

延迟是容量规划的“软约束”。即使 QPS 和 CCU 都在范围内,如果延迟大幅增加,说明网关已进入过载状态。P99(99% 请求的延迟上限)和 P95(95% 请求的延迟上限)是最常用的尾延迟指标。

  • P99:代表最差情况下的用户体验,通常用于 SLA 承诺。
  • P95:代表大多数用户的体验,比 P99 更稳定,受极端值影响小。
# Nginx Ingress 延迟 PromQL(分位数)
# P99 延迟(毫秒)
histogram_quantile(0.99, 
  sum(rate(nginx_ingress_controller_request_duration_seconds_bucket[1m])) by (le))

# P95 延迟(毫秒)
histogram_quantile(0.95, 
  sum(rate(nginx_ingress_controller_request_duration_seconds_bucket[1m])) by (le))
延迟分位 典型基线(内部服务) 典型基线(外部 API) 升级前异常信号
P50 < 10ms < 50ms P50 翻倍
P95 < 50ms < 200ms P95 超过 500ms
P99 < 200ms < 500ms P99 超过 1s 或持续抖动
延迟与容量的关系:当 QPS 接近网关瓶颈时,P99 会率先出现“拐点”——延迟急剧上升,而 QPS 增长趋缓。这个拐点就是容量上限。升级前应找到当前集群的“延迟拐点 QPS”,作为升级期间的保护阈值。
延迟拐点与网关容量上限关系 QPS(吞吐量) 延迟(P99) 拐点 QPS 安全区(延迟稳定) 过载区 P99 在拐点前平缓增长; 超过拐点后急剧上升, 此时 QPS 增长极微。 P99 延迟

3.4 错误率(5xx)

错误率是容量规划的“硬红线”。5xx 错误(服务端错误)直接表明网关或后端服务已无法正常处理请求。升级前必须建立 5xx 错误率的基线,并区分网关层错误与后端服务错误。

  • 网关层 5xx:502 Bad Gateway(后端不可达)、503 Service Unavailable(限流/熔断)、504 Gateway Timeout(上游超时)。
  • 后端服务 5xx:500 Internal Server Error(后端代码异常),通常由网关透传。
# 5xx 错误率 PromQL
# 网关层 5xx 占比
sum(rate(nginx_ingress_controller_requests{status=~"5.."}[1m])) 
/ 
sum(rate(nginx_ingress_controller_requests[1m])) * 100

# 按状态码细分
rate(nginx_ingress_controller_requests{status="502"}[1m])
rate(nginx_ingress_controller_requests{status="503"}[1m])
rate(nginx_ingress_controller_requests{status="504"}[1m])
错误类型 常见原因 升级前基线 升级期间容忍上限
502 后端 Pod 未就绪、Service 端点为空 < 0.1% < 0.5%(滚动升级期间)
503 网关限流、后端熔断、Pod 资源不足 < 0.05% < 0.2%
504 后端响应超时、网关与后端网络延迟增加 < 0.1% < 0.3%
500 后端代码异常(非网关问题) < 0.5% < 1.0%
升级前必须执行:在测试环境模拟升级过程(Pod 滚动重启),观察 5xx 错误率的变化。如果模拟升级期间 5xx 超过 0.5%,说明当前网关容量或优雅终止配置不足,必须优化后再进行生产升级。
网关容量四指标联动关系 网关容量基线 QPS CCU P99/P95 延迟 5xx 错误率 四指标联动:QPS 和 CCU 上升 → 延迟增加 → 错误率升高 → 容量触顶。 升级前必须确保四指标均在安全基线内,任一指标超标都应停止升级。

3.5 指标采集与基线记录

升级前至少采集 7 天 的上述四类指标,记录每日峰值和 P99 值,形成基线表。以下是一个基线记录模板:

# 基线记录示例(JSON 格式)
{
  "cluster": "prod-eks-1",
  "gateway": "nginx-ingress",
  "采集周期": "2025-03-01 ~ 2025-03-07",
  "baseline": {
    "qps": {
      "peak": 12500,
      "avg": 7800,
      "单Pod上限": 3000
    },
    "ccu": {
      "active_peak": 4200,
      "idle_peak": 1800,
      "total_peak": 6000,
      "单Pod上限": 8000
    },
    "latency_ms": {
      "p50": 8,
      "p95": 35,
      "p99": 120
    },
    "error_rate_5xx": {
      "502": 0.03,
      "503": 0.01,
      "504": 0.02,
      "500": 0.15
    }
  },
  "升级前水位": "安全(均低于70%阈值)"
}
自动化建议:将上述基线记录写入 ConfigMap 或 Prometheus 的 recording rules,升级前自动比对当前指标与基线。如果当前指标超过基线的 1.2 倍,触发告警并阻止升级流程。