bigywater.tech
微服务 · 73

RED 与 USE 方法:每个服务该看哪几个指标

每个服务该看哪几个指标?RED 和 USE 各看什么、各能发现什么问题?错误率该怎么定义?这篇用一个带工作线程池的服务注入四种故障,用 Prometheus 逐项量出来。

17.7% / 67 ms / 100%
错误率升高、下游变慢、过载三种情形下分别最明显的指标:错误率、平均耗时、线程利用率
293 / 秒
过载阶段(到达 600/s)被队列拒绝的请求速率,完成速率只有 307/s
5.0% vs 30.1%
同样的流量,按 5xx 和按非 2xx 计算的错误率

四种情形

实测 · 本机执行输出
  阶段               | 到达速率(/s) | 完成速率(/s) | 错误率   | 平均耗时(ms) | p99(ms) | 线程利用率 | 队列长度(最大) | 被拒绝(/s)
  -----------------+----------+----------+-------+----------+---------+-------+----------+--------
  基准               | 200      | 200      | 0.0%  | 26       | 50      | 60%   | 0        | 0      
  错误率升高            | 200      | 200      | 17.7% | 26       | 50      | 62%   | 1        | 0      
  下游变慢(每个请求 60 ms) | 100      | 100      | 0.0%  | 67       | 100     | 81%   | 0        | 0      
  过载(来得比处理得快)      | 600      | 307      | 48.8% | 186      | 249     | 100%  | 50       | 293    
  同一个服务四种不同的问题:错误率升高时 RED 的错误率马上变,利用率和队列都正常;下游变慢时耗时升高、利用率升高,但还没有排队;过载时到达速率超过完成速率,利用率 100%、队列满、请求被拒绝、耗时被队列拉长——只看某一个指标会漏掉另一种问题

RED(速率、错误、耗时)描述请求的体验,USE(利用率、饱和度、错误)描述资源的状态;不同问题先在不同的指标上露头。

错误的定义

实测 · 本机执行输出
  错误率的定义     | 结果   
  -----------+------
  5xx ÷ 全部   | 5.0% 
  非 2xx ÷ 全部 | 30.1%
  404 是客户端的问题,不是服务的错误;把所有非 2xx 都算错误,错误率会被客户端的请求虚高,告警会误报。哪些状态码算“错误”需要按 SLI 的目的定义
ERRORS {}

客户端错误(4xx)不是服务的错误,要按 SLI 的目的定义哪些状态码算错误。

分步演示

RED 与 USE
本步的对象

    本文用到的工具与边界

    • 本机 macOS 27 arm64 / Python 3.14.8 / Go / nginx / Envoy / etcd / Consul / Nacos / OpenTelemetry / Prometheus(按各篇注明用到哪些及版本);所有服务都是本机自己起的进程,端口 9150 以上,只监听 127.0.0.1,不连任何外部服务,不碰本机已有的实例;故障用 kill -9 进程、让连接断开或在代码里注入延迟与错误来制造;计时用 time.perf_counter,数字每次运行会有小幅抖动。Prometheus 3.15.0 抓取我写的 Python 服务(8 个工作线程、队列 50);理论容量 8 ÷ 20 ms = 400/s,实测过载时完成 307/s(Python 的线程调度开销);注入 20% 错误时测得 17.7%(随机数与 rate 的外推造成的偏差,没有逐项拆解);p99 来自 histogram_quantile,基准的 50 ms 受桶边界影响(见上一篇);每个阶段只跑了一次(25 s)
    • 没有验证:真实应用的 CPU / 内存 / 磁盘 / 网络的 USE;Brendan Gregg 的 USE 方法清单;Google 的四个黄金信号(延迟、流量、错误、饱和度)与 RED 的对应;按路由、按租户拆分的 RED;客户端视角与服务端视角的 RED 差异
    京ICP备2026067502号-1京公网安备11010502063487号