3. 入口网关容量水位指标:CPU、内存、连接数、QPS、P99延迟等关键指标定义
在 Istio 入口网关的容量规划与巡检中,水位指标是判断网关是否健康、是否存在过载风险的核心依据。本节将定义五大关键指标:CPU 使用率、内存使用率、活跃连接数、每秒请求数(QPS)以及P99 延迟,并给出每个指标的采集方式、阈值建议与巡检意义。
巡检原则:单一指标超标可能只是瞬时抖动,但两个以上指标同时逼近警戒线,通常意味着网关容量即将耗尽,需要立即扩容或优化。
3.1 指标定义与采集方式
下表汇总了五个核心水位指标的采集来源、Prometheus 查询语句(Metric Query)以及典型阈值范围:
| 指标名称 | 采集来源 | Prometheus 查询示例 | 安全水位 | 警戒水位 | 危险水位 |
|---|---|---|---|---|---|
| CPU 使用率 | istio-proxy 容器 / container_cpu_usage_seconds_total | rate(container_cpu_usage_seconds_total{container="istio-proxy"}[1m]) / 1 |
< 60% | 60% – 80% | > 80% |
| 内存使用率 | istio-proxy 容器 / container_memory_working_set_bytes | container_memory_working_set_bytes{container="istio-proxy"} |
< 70% | 70% – 85% | > 85% |
| 活跃连接数 | Envoy 统计 / envoy_cluster_upstream_rq_active | sum(envoy_cluster_upstream_rq_active{envoy_cluster_name="xds-grpc"}) |
< 500 | 500 – 1000 | > 1000 |
| QPS(每秒请求数) | Envoy 统计 / envoy_cluster_upstream_rq_total | sum(rate(envoy_cluster_upstream_rq_total[1m])) |
< 80% 上限 | 80% – 95% 上限 | > 95% 上限 |
| P99 延迟 | Envoy 统计 / envoy_cluster_upstream_rq_time | histogram_quantile(0.99, sum(rate(envoy_cluster_upstream_rq_time_bucket[1m])) by (le)) |
< 100ms | 100ms – 300ms | > 300ms |
关键说明:QPS 的“上限”指网关所在 Pod 的 CPU 与内存共同决定的瓶颈值,通常通过压测标定。例如,若压测得到单 Pod 最大 QPS 为 5000,则 80% 上限为 4000 QPS。
3.2 指标间联动关系与巡检优先级
五个指标并非孤立存在,它们之间存在典型的因果链。理解这些关系有助于快速定位根因:
- CPU 与 QPS 正相关:QPS 上升通常导致 CPU 使用率同步上升。若 CPU 高但 QPS 低,说明存在计算密集型请求(如复杂 JWT 校验、OPA 策略评估)。
- 内存与连接数正相关:每个活跃连接会占用一定内存(通常 1KB – 10KB)。连接数激增时,内存使用率会快速攀升。
- P99 延迟与 CPU/连接数负相关:当 CPU 使用率超过 80% 或连接数超过 1000 时,请求排队时间增加,P99 延迟会显著恶化。
- 巡检优先级:P99 延迟 > CPU 使用率 > 内存使用率 > QPS > 活跃连接数。延迟是用户体验的直接体现,应作为最高优先级。
避坑提示:不要单独看 QPS 值。例如,QPS 从 2000 降到 1500 不一定是好事——如果同时 P99 延迟从 50ms 飙升到 500ms,说明网关正在丢弃请求或发生熔断,实际吞吐能力已下降。
3.3 容量水位模型:从指标到决策
为了将多个指标综合为一个可决策的“水位等级”,我们定义如下容量水位模型:
- 健康(绿色):所有指标均处于安全水位,无需干预。
- 关注(黄色):任意 1 个指标进入警戒水位,或 2 个指标接近警戒线。建议观察趋势,准备扩容。
- 告警(橙色):任意 2 个指标进入警戒水位,或 1 个指标进入危险水位。需要立即扩容或限流。
- 严重(红色):任意 2 个指标进入危险水位,或 P99 延迟超过 500ms。触发自动弹性伸缩或降级策略。
下图展示了从指标采集到水位决策的完整链路:
3.4 巡检脚本中的指标采集示例
在实际巡检脚本中,我们使用 Prometheus API 批量拉取上述指标,并计算综合水位。以下是一个简化版的 Python 采集片段:
import requests
import json
prometheus_url = "http://prometheus:9090/api/v1/query"
def get_metric_value(query):
resp = requests.get(prometheus_url, params={"query": query})
result = resp.json()["data"]["result"]
if result:
return float(result[0]["value"][1])
return 0.0
# 采集 CPU 使用率(假设 Pod 有 2 核)
cpu_query = 'rate(container_cpu_usage_seconds_total{container="istio-proxy"}[1m]) / 2 * 100'
cpu_usage = get_metric_value(cpu_query)
# 采集内存使用率(假设内存限制为 512Mi)
mem_query = 'container_memory_working_set_bytes{container="istio-proxy"} / 512 / 1024 / 1024 * 100'
mem_usage = get_metric_value(mem_query)
# 采集活跃连接数
conn_query = 'sum(envoy_cluster_upstream_rq_active{envoy_cluster_name="xds-grpc"})'
active_conn = get_metric_value(conn_query)
# 采集 QPS
qps_query = 'sum(rate(envoy_cluster_upstream_rq_total[1m]))'
qps = get_metric_value(qps_query)
# 采集 P99 延迟(单位:毫秒)
p99_query = 'histogram_quantile(0.99, sum(rate(envoy_cluster_upstream_rq_time_bucket[1m])) by (le))'
p99_latency = get_metric_value(p99_query) * 1000
print(f"CPU: {cpu_usage:.1f}%, Mem: {mem_usage:.1f}%, Conn: {active_conn}, QPS: {qps:.0f}, P99: {p99_latency:.0f}ms")
生产建议:上述代码仅用于演示。在生产巡检中,建议使用 Prometheus 的
query_range 接口获取过去 5 分钟的趋势数据,避免单点采样抖动导致误判。同时,将阈值配置化,支持按业务场景动态调整。
3.5 指标可视化与趋势分析
为了直观展示五个指标在时间轴上的变化,我们使用 Grafana 面板进行聚合展示。下图展示了典型入口网关在流量高峰期的指标联动趋势:
巡检最佳实践:建议将上述五个指标聚合为一个“容量水位仪表盘”,并设置复合告警规则。例如:当 CPU > 75% 且 P99 延迟 > 200ms 持续 3 分钟,触发“容量告警”事件,自动拉起 OPA 策略评估流程,判断是否需要降级安全策略以释放资源。