3、网关Pod关键监控指标：请求延迟、错误率、吞吐量、CPU/内存使用率、连接数
网关Pod作为南北向流量的统一入口，其健康状态直接决定整个微服务系统的可用性。SRE需要从服务质量与资源效率两个维度建立监控指标体系。本章定义5类核心指标，并给出PromQL采集与告警阈值参考。
3.1 指标全景与采集路径
下图展示了网关Pod的指标采集架构：Prometheus通过/metrics端点拉取网关暴露的指标，经Relabeling后存入TSDB，再由Alertmanager与Grafana消费。
3.2 请求延迟（Latency）
延迟是用户体验的核心指标。网关层通常关注全局延迟与上游延迟两个维度。推荐使用Histogram指标类型，配合le标签计算百分位。
| 指标名称 | 类型 | PromQL 示例 | 告警阈值（p99） |
|---|---|---|---|
gateway_request_duration_seconds |
Histogram | histogram_quantile(0.99, sum(rate(gateway_request_duration_seconds_bucket[5m])) by (le)) |
> 2s 触发 Warning > 5s 触发 Critical |
gateway_upstream_duration_seconds |
Histogram | histogram_quantile(0.99, sum(rate(gateway_upstream_duration_seconds_bucket[5m])) by (le)) |
> 3s 触发 Warning > 8s 触发 Critical |
实践建议：延迟告警应区分全局与上游。全局延迟高但上游延迟正常，说明网关自身处理瓶颈（如线程池耗尽）；上游延迟高则指向后端服务异常。
3.3 错误率（Error Rate）
错误率反映网关处理请求的失败比例。按HTTP状态码分类：5xx（服务端错误）、4xx（客户端错误）、超时/断连。推荐使用Counter指标计算速率。
- 5xx 错误率：
sum(rate(gateway_requests_total{status=~"5.."}[5m])) / sum(rate(gateway_requests_total[5m])) * 100 - 4xx 错误率：
sum(rate(gateway_requests_total{status=~"4.."}[5m])) / sum(rate(gateway_requests_total[5m])) * 100 - 超时率：
sum(rate(gateway_upstream_timeout_total[5m])) / sum(rate(gateway_requests_total[5m])) * 100
| 错误类型 | 告警阈值（5m滑动窗口） | 严重级别 |
|---|---|---|
| 5xx 错误率 | > 1% | Critical |
| 4xx 错误率 | > 5% | Warning |
| 超时率 | > 0.5% | Critical |
3.4 吞吐量（Throughput）
吞吐量衡量网关的处理能力，通常以RPS（Requests Per Second）或TPS（Transactions Per Second）表示。吞吐量突降可能预示上游故障或网络分区；突增则可能触发限流。
# 总吞吐量（RPS）
sum(rate(gateway_requests_total[1m]))
# 按路由分组吞吐量
sum(rate(gateway_requests_total[1m])) by (route)
# 吞吐量突降告警（与过去10分钟均值对比）
(
sum(rate(gateway_requests_total[1m]))
/
avg_over_time(sum(rate(gateway_requests_total[1m]))[10m:1m])
) < 0.5
注意：吞吐量告警应结合基线。使用
avg_over_time或predict_linear计算动态阈值，避免在业务低峰期误报。
3.5 CPU/内存使用率
资源指标反映网关Pod的饱和度。CPU使用率过高会导致请求排队；内存使用率过高可能触发OOM Kill。推荐使用container_cpu_usage_seconds_total与container_memory_working_set_bytes（cAdvisor暴露）。
| 指标 | PromQL 示例 | 告警阈值 |
|---|---|---|
| CPU 使用率 | rate(container_cpu_usage_seconds_total{container="gateway"}[1m]) / container_spec_cpu_quota{container="gateway"} * 100 |
> 80% 持续5m → Warning > 95% 持续2m → Critical |
| 内存使用率 | container_memory_working_set_bytes{container="gateway"} / container_spec_memory_limit_bytes{container="gateway"} * 100 |
> 85% 持续5m → Warning > 95% 持续1m → Critical |
3.6 连接数（Connections）
连接数指标包括活跃连接、空闲连接、等待队列长度。连接数过高可能耗尽网关线程池或文件描述符。
- 活跃连接数：
gateway_connections_active— 当前正在处理的请求数。 - 空闲连接数：
gateway_connections_idle— 保持连接但无请求的TCP连接。 - 连接池等待数：
gateway_connections_pending— 等待获取连接池资源的请求数。
| 指标 | 告警阈值 | 说明 |
|---|---|---|
| 活跃连接数 | > 最大线程数 × 0.9 | 接近线程池上限，请求将排队 |
| 连接池等待数 | > 0 持续30s | 连接池耗尽，需扩容或优化 |
| 文件描述符使用率 | > 80% | 可能触发系统级限制 |
3.7 指标关联分析矩阵
单一指标异常往往伴随其他指标联动。下表总结了常见故障场景下的指标变化模式：
| 故障场景 | 延迟 | 错误率 | 吞吐量 | CPU/内存 | 连接数 |
|---|---|---|---|---|---|
| 上游服务雪崩 | ↑↑ p99 > 5s | ↑↑ 5xx > 10% | ↓↓ 下降 > 50% | ↓ 下降 | ↑ 等待队列堆积 |
| 网关线程池耗尽 | ↑↑ 全局延迟 | ↑ 超时/503 | → 或 ↓ | ↑ CPU 高 | ↑↑ 活跃连接达上限 |
| 内存泄漏 | → 缓慢上升 | → 偶发OOM | → 或 ↓ | ↑↑ 持续增长 | → 正常 |
| 突发流量 | ↑ 短暂升高 | → 正常 | ↑↑ 突增 | ↑ 升高 | ↑ 活跃连接增加 |
3.8 告警规则设计原则
- 多窗口避免毛刺：使用
for: 5m或avg_over_time过滤瞬时抖动。 - 百分位优先：延迟告警使用 p99 而非平均值，避免被少量慢请求掩盖。
- 关联抑制：当上游错误率告警触发时，自动抑制网关自身告警，减少告警风暴。
- 动态基线：对吞吐量等指标使用
predict_linear预测未来趋势，提前扩容。