4. 根因定位方法论：黄金指标、RED 与 USE

在网关故障的根因定位中，如果没有统一的度量维度，不同角色的工程师（网络、系统、应用）会陷入“各说各话”的困境。本章将系统讲解业界最成熟的三个方法论体系：黄金指标（Golden Signals）、RED 方法和USE 方法。掌握这三套工具，你就能在任何网关异常场景下快速锁定排查方向。

4.1 黄金指标：从四个维度定义健康

Google SRE 团队在《SRE: Google 运维解密》中提出了四个通用信号，适用于任何分布式服务，包括网关。这四个指标构成了根因定位的“第一性原理”。

指标 定义 网关场景示例 异常时可能的根因
延迟（Latency） 请求从发出到收到响应的时间 P99 延迟从 50ms 飙升到 5s 后端服务慢、连接池耗尽、DNS 解析慢
流量（Traffic） 系统服务的请求量级 QPS 从 10k 突降到 0 上游限流、证书过期、路由配置错误
错误（Errors） 显式错误（5xx）与隐式错误（成功但结果错误） HTTP 502/503 比例超过 5% 后端宕机、超时配置过短、熔断触发
饱和度（Saturation） 系统资源被使用的程度 CPU 使用率 95%、连接数达到上限 突发流量、内存泄漏、线程池耗尽
实战要点： 在网关监控中，不要只看平均值。延迟必须区分“成功请求”和“失败请求”的延迟——失败请求往往因为快速拒绝而延迟很低，这会掩盖真实问题。建议同时监控 P50、P95、P99 三个分位值。

4.2 RED 方法：面向服务的三大黄金信号

RED 方法由 Tom Wilkie 提出，是黄金指标在微服务和网关场景下的精简版。它只关注三个核心指标：Rate（速率）、Errors（错误）、Duration（持续时间）。RED 特别适合用来衡量“用户视角”的服务质量。

  • Rate（速率）：每秒请求数（RPS/QPS）。回答“服务正在被使用吗？”
  • Errors（错误）：失败请求的比例或数。回答“服务返回正确结果吗？”
  • Duration（持续时间）：请求处理耗时。回答“服务响应快吗？”

与黄金指标相比，RED 去掉了“饱和度”，因为饱和度是运维视角而非用户视角。在网关根因定位中，RED 方法常用于第一轮快速筛查：如果 Rate 正常、Errors 正常、Duration 正常，则问题大概率不在网关本身，而在下游或客户端。

推荐工具： Prometheus + Grafana 是实施 RED 监控的标准组合。在网关层（如 Kong、APISIX、Envoy），建议为每个路由、每个上游服务都暴露 RED 指标。

4.3 USE 方法：面向资源的全维度扫描

USE 方法由 Brendan Gregg 提出，全称是 Utilization（利用率）、Saturation（饱和度）、Errors（错误）。它面向的是系统资源（CPU、内存、网络、磁盘、连接池），而非服务。当 RED 方法定位到网关自身有问题时，USE 方法就是下一步的“手术刀”。

资源 利用率（Utilization） 饱和度（Saturation） 错误（Errors）
CPU % 使用率 运行队列长度、CPU 压力 错误计数、宕机
内存 已用 / 总量 OOM 次数、Swap 使用量 OOM Killer 日志
网络 带宽使用率 丢包率、重传率、backlog 溢出 网卡错误、CRC 错误
连接池 已用连接 / 最大连接 等待连接数、超时次数 连接拒绝、重置
常见误区： 很多工程师在网关延迟升高时，第一反应是看 CPU 利用率。但根据 USE 方法，你应该先检查“饱和度”——运行队列长度或连接等待数，因为利用率高不一定导致延迟，而饱和度高几乎必然导致延迟。这是根因定位中“先看排队，再看使用”的核心原则。

4.4 三套方法论的协同关系

在实际的网关根因定位中，这三套方法论不是互斥的，而是层层递进的。下面的 SVG 图展示了从“发现问题”到“定位根因”的完整链路。

三套方法论协同定位链路 第 1 步：黄金指标（全局扫描） 延迟异常？流量突降？错误率飙升？饱和度告警？ 第 2 步：RED 方法（服务视角） Rate 正常？Errors 集中在哪个路由？Duration 的 P99 是多少？ 第 3 步：USE 方法（资源视角） CPU 利用率高还是排队高？连接池饱和？网络重传？ 输出：根因定位结论

4.5 实战案例：一次网关超时问题的定位过程

假设某电商网关在 10:00 出现大量订单查询超时告警。按照本章方法论，定位过程如下：

  1. 黄金指标扫描：延迟 P99 从 80ms 飙升到 4s，错误率 8%（502），流量无变化，CPU 饱和度 70%。初步判断：网关自身或后端有问题。
  2. RED 方法分析：Rate 正常（10k QPS），Errors 集中在 /order/query 路由（占 95%），Duration 在该路由上 P99 达 6s。结论：问题在 /order/query 对应的上游服务。
  3. USE 方法深入：检查网关到上游服务的连接池——利用率 100%，饱和度（等待连接数）达到 200，错误（连接超时）持续增长。根因：上游订单服务连接池耗尽，导致网关请求排队超时。
定位结论： 上游订单服务因数据库慢查询导致连接池被占满，网关连接池等待队列溢出，最终表现为网关超时。修复动作：优化数据库查询 + 增加上游服务连接池上限。

4.6 方法论选择速查表

在实际排障中，根据你当前的“角色”和“阶段”，选择最合适的方法论：

场景 推荐方法论 核心问题
首次接到告警，需要快速判断影响面 黄金指标 延迟、流量、错误、饱和度哪个异常？
确认网关服务异常，需要定位到具体路由 RED 方法 哪个路由的 Rate/Errors/Duration 异常？
定位到具体资源瓶颈，需要给出修复方案 USE 方法 哪个资源的利用率/饱和度/错误导致问题？
日常巡检与容量规划 黄金指标 + USE 资源饱和度是否接近阈值？延迟是否有劣化趋势？
← 上一章 📖 返回目录 下一章 →