RED方法和USE方法分别监控用户请求视角和系统资源视角，两类视角互为补充，构成完整的可观测性体系。你在大促前盯监控屏，最怕两种场面：一是用户点按钮没反应，二是服务器CPU被拉满，前一种指向请求链路，后一种指向资源瓶颈，RED和USE这两套方法，恰好对应了这两种盯法。
RED方法：站在用户请求的视角看服务健康
RED方法是Google SRE实践中总结的思路，三个字母拆开是Rate速率、Errors错误、Duration耗时，它不关心你的机器有多累，只关心用户发出去的请求有没有得到体面回应。
RED方法具体看哪些指标
- Rate速率：每秒请求数，代表了系统的流量压力，比如电商秒杀场景，请求量会瞬间飙升。
- Errors错误：请求失败的比例，包括4xx、5xx状态码，也包括业务逻辑里的超时和异常。
- Duration耗时：请求从发出到返回的间隔，通常看平均值、P95和P99分位值，P99代表最差的1%用户体验。
这套指标组合起来,能直接回答“服务现在到底行不行”，业内专家指出，RED方法更适合放在API网关或服务网格层，因为那里能看到全部请求流。
举个例子,一个商品详情页接口，平时每秒处理200个请求，P95耗时120毫秒，突然某次上线后，P95飙到800毫秒，错误率从0.1%涨到5%，RED面板立刻拉响警报，你就能马上定位到是这次发布引起的，而不是等到用户打电话投诉才反应过来。
RED方法适合哪些监控场景
- 面向用户端的Web服务和移动端接口。
- 微服务调用链路的SLA监控。
- 告警规则里的“错误率突增”和“延迟飙升”场景。
用拟人化的说法：RED方法就像一个站在用户身后的暗访员，每次点击、每次滑动，他都在心里打分，响应快就是好评，报错就是差评。
USE方法：站在系统资源的视角看基础设施
USE方法由Brendan Gregg提出，三个字母是Utilization利用率、Saturation饱和度、Errors错误，它盯的是CPU、内存、磁盘、网络这些基础设施部件，看它们是不是被压榨到极限了。
USE方法怎么拆解
- 利用率 Utilization：资源在忙的时间占比，比如CPU使用率80%，就意味着大部分时间在干活。
- 饱和度 Saturation：资源排队等待服务的程度，CPU运行队列长度、内存换页量、磁盘I/O等待时间都属于这类。
- Errors错误：资源自身的设备错误，比如磁盘坏道、网卡丢包计数。
USE方法实际操作路径
- 先列出所有基础设施资源：CPU、内存、磁盘、网络。
- 对每类资源分别问：利用率高不高？有没有排队？有没有报错？
- 把回答映射到具体指标,比如CPU对应利用率、运行队列长度和软错误计数。
- 在服务器上用现成命令快速验证：
uptime看1分钟和15分钟负载差，top看CPU空闲率和进程状态，iostat看磁盘util和await，如果负载数值远高于CPU核数，说明调度已经排队。
USE方法像一台尽职的体检仪,不关心用户满不满意，只关心硬件有没有过劳，如果CPU已经跑到满负荷，哪怕请求全部正常，过一会儿也迟早出问题。
RED方法和USE方法区别：两类监控视角如何选
把两者放在一起,区别就很明显：
| 维度 | RED方法 | USE方法 |
|---|---|---|
| 视角 | 用户请求 | 基础设施资源 |
| 核心对象 | 服务、API、链路 | CPU、内存、磁盘、网络 |
| 典型指标 | 请求量、错误率、延迟 | 利用率、饱和度、错误 |
| 发现问题 | 业务体验受损 | 性能瓶颈风险 |
| 适用层 | 应用层 | 系统层 |
为什么两类视角缺一不可
- 只有RED没有USE：你能看到接口变慢，但不知道是代码问题还是下面CPU已经打满。
- 只有USE没有RED：你能看到资源忙碌，但不知道这对用户实际造成了多大影响。
实际故障排查时,往往从RED发现告警，再顺着USE定位根因，比如中午订单量下跌，RED面板显示成功率下降，切到USE面板发现数据库磁盘饱和，问题一目了然。
系统监控指标太多怎么分类？按这两类视角
如果你正在为监控面板上百个指标发愁,可以直接套用分类逻辑：
- 凡是描述“用户请求”的指标，丢进RED盒子。
- 凡是描述“资源忙闲”的指标，丢进USE盒子。
- 分类后优先关注两类告警：RED里的错误率和延迟，USE里的饱和度和错误。
这样梳理完,监控项的数量能减少一大半，国内主流云厂商控制台的默认监控项，大多也遵循这种二分法，只是没有明说。
云原生监控用什么方法？先分清资源与请求
云原生环境里,容器、Kubernetes、微服务让监控对象越来越多，传统的服务器看板已经不够用，这时更需要RED和USE配合。
在Prometheus里怎么同时落地
- USE层面：用node-exporter采集节点指标，比如CPU利用率、负载、磁盘空间和I/O等待。
- RED层面：用云厂商的托管Prometheus或开源的Grafana+Loki链路方案，采集HTTP请求的请求量、错误率、耗时。
- 告警规则分开写：USE告警关注资源饱和，比如CPU持续90%以上；RED告警关注SLO偏差，比如错误率超过2%。
行业共识认为,云原生监控最容易踩的坑是把容器和节点混为一谈，用USE看宿主机资源，用RED看服务Pod的请求表现，两层数据互相对照，才能判断是容器编排问题还是应用自身问题。
小团队如何快速起步
- 别急着搞全套链路,先在网关层配上RED三件套。
- 再给最核心的数据库主机配上USE四件套。
- 开源方案没有额外费用,商业APM产品的价格差异主要在数据量和采样精度，小团队用开源足够。
把两类视角绑到同一条日常巡检路径里：先看RED是不是正常，再扫一遍USE有没有隐患，一天两次，比等告警更主动。
把两类视角装进自己的监控体系
选方法不是做单选题,RED负责对外感知用户痛苦，USE负责对内预判机器风险，双视角配合，就像一个人同时拥有感觉神经和体检报告，哪里不舒服当下就能知道，隐藏病灶也能提前发现，以后看到监控面板，先问一句：这个指标是在讲用户的故事，还是在讲机器的故事？答案自然会帮你归类。
关于RED与USE监控视角的常见问题
RED和USE方法可以互相替代吗？
不能,RED面向业务体验，USE面向资源健康，一个负责感知用户痛苦，一个负责预判机器崩溃，只靠一种视角会留下盲区，比如磁盘快满时请求可能还没异常，但USE会提前报警。
监控指标太多抓不住重点怎么办？
先按RED和USE做第一层过滤,属于这两类的指标保留，其他全部降级为可查不可告警，然后用错误率、延迟、饱和度作为核心告警项，其余指标只在排查时翻看，以国内主流云监控平台为例，自定义告警里通常都有这两类指标模板，直接套用即可。
哪类方法更适合做容量规划？
USE方法更适合,因为它直接反映资源余量，通过饱和度的历史趋势，可以判断什么时候需要扩容，但容量调整后，最终效果要靠RED来验证，比如扩容后P99延迟是否真正下降，需要回归到用户体验指标上确认。