RED方法适用场景
RED方法最适合面向用户的服务，如Web应用、API网关、数据库查询服务，在电商秒杀场景下，Rate骤升伴随Duration变长，可能预示资源不足；Errors抬高则需排查代码或依赖问题，相比USE方法，RED更贴近业务，但无法直接指出资源瓶颈，业内专家指出，RED方法的核心价值在于从用户出发，保障服务等级目标，近年来，随着可观测性理念普及,RED方法已成为服务监控的标准起点。
如何落地RED方法
- 定义指标：根据业务语义确定Rate、Errors、Duration的具体含义，HTTP 5xx算Errors，4xx通常不算,但可根据业务调整。
- 采集工具：使用Prometheus + 客户端库（如Go、Java、Python）暴露指标,或采用OpenTelemetry自动注入。
- 可视化：在Grafana中创建Dashboard，每个服务一个面板,展示三项指标的变化趋势。
- 告警：对Error Rate超过阈值（如1%）和Duration超过P99目标（如500ms）设置告警,避免噪音。
USE方法：面向资源的监控视角
USE方法的核心指标
USE方法由Brendan Gregg提出，针对所有资源类型，Utilization指资源用于服务的时间比例，Saturation衡量排队等待的任务量，Errors记录资源层异常，CPU利用率通过top命令查看，饱和度通过平均负载判断，错误通过dmesg检查硬件问题，存储场景下，iostat输出%util反映利用率，await反映饱和度，svctm和错误计数反映错误情况，USE方法的核心是直击资源瓶颈,适用于系统调优和容量规划。
USE方法适用场景
当系统响应变慢但服务层指标正常时，USE方法能快速定位具体资源CPU、内存、磁盘、网络，在数据库服务器迁移场景中，关注磁盘IOPS利用率和饱和度，可避免性能回退，行业共识认为，USE方法让运维人员从资源角度完整审视系统，避免盲点，在容器化环境中，结合cgroup暴露的资源指标,可以精细控制每个容器的资源使用。
如何落地USE方法
- 列出资源清单：CPU、内存、磁盘、网络、控制器等,每个资源定义利用率和饱和度的度量方式。
- 采集工具：使用
node_exporter、cAdvisor或collectd收集指标,批量导入Prometheus。 - 常用命令：
top、vmstat、iostat、sar、netstat,可快速做一次现场检查。 - 饱和度阈值：CPU平均负载持续超过CPU核心数的2倍，磁盘avgqu-sz持续大于1,都需关注。
RED方法和USE方法有什么区别
视角差异：用户 vs 资源
RED方法从服务状态出发，USE方法从资源状态出发，一个关注业务指标，一个关注系统指标，当用户投诉加载缓慢时，RED方法显示Duration升高，USE方法可能显示CPU饱和度或磁盘利用率过高，两者互补，缺一不可，在故障排查中，通常先用RED判断服务是否异常,再用USE定位具体资源。
指标数量与粒度
RED仅三个指标，精简但依赖服务端定义；USE指标较多，但适用于所有资源类型，在容器化环境中，RED方法需要每个服务暴露指标，USE方法则依赖cgroup和内核暴露的数据，从实施成本看，RED方法需要业务团队配合,USE方法运维团队可独立完成。
故障定位效率
RED方法适合快速判断服务是否健康，USE方法适合深入分析资源为何不足，实际运维中，通常先用RED缩小范围，再用USE确认根因，一个典型场景：RED显示错误率上升，USE发现数据库连接池饱和度达到100%，于是扩容,两者结合能缩短平均修复时间。
监控系统选RED还是USE
场景决定选择
如果团队主要关注用户体验，如电商、SaaS平台，优先实现RED方法，如果团队负责基础设施，如云平台、网络设备，优先实现USE方法，多数情况下，成熟监控系统会同时覆盖两者，但侧重点不同，对于初创团队，建议先实现USE方法，因为资源指标容易采集,再逐步完善RED方法。
结合实践：RED + USE完整监控
以Prometheus为例，通过node_exporter收集USE指标，通过业务应用暴露RED指标，在Grafana中，一个Dashboard可以同时展示服务的RED和主机的USE，让运维人员从两个视角分析问题，业内专家指出，实现双视角监控后,故障定位时间可缩短相当比例。
成本考量
RED方法需要应用改造，增加埋点成本；USE方法依赖系统工具，采集成本较低，选择时需评估团队研发资源，对于中小团队，建议先实现USE方法覆盖资源，再逐步完善RED方法，在云原生环境下，许多托管服务已内置RED指标，如AWS Lambda的监控,可直接使用。
RED和USE方法结合使用案例
电商大促保障
大促期间，监控系统同时启用RED和USE，RED指标展示下单成功率、响应时间；USE指标展示CPU、带宽、数据库连接池利用率，当RED显示错误率上升，结合USE发现数据库连接池饱和度达到100%，立即扩容，通过观察USE中的网络饱和度，预判带宽瓶颈,提前扩容SLB。
微服务故障排查
某服务延迟增加，RED方法的Duration指标突出，USE方法查看该服务所在节点发现CPU利用率不高，但网络入站流量饱和，进一步排查发现对端服务限流，问题解决，此过程体现了两个视角的协同：RED发现问题,USE缩小范围。
日常容量规划
通过历史RED和USE数据，团队可以预测资源需求，RED的Rate持续增长，USE的CPU利用率趋势同步上升，可提前规划扩容，在季度总结中，使用USE的饱和度指标判断资源是否需要升级,避免盲目采购。
RED方法和USE方法常见问题解答
RED方法中的错误如何定义？
错误通常指HTTP 5xx、超时、业务错误码等，需要根据业务语义自定义，确保错误指标能反映真实用户问题，一个支付服务，支付失败算错误，但余额不足不算,除非业务层面定义。
USE方法中的饱和度指标如何获取？
饱和度指标通常通过观察资源等待队列长度或时间获取，CPU的负载平均值反映饱和度，磁盘的平均等待时间（await）反映IO饱和度，网络接口的丢包率反映网络饱和度，利用系统工具如top、iostat、sar即可获取，也可以从Prometheus指标如node_load1、node_disk_io_time_weighted
RED方法和USE方法可以互相替代吗？
不能，两者视角不同，RED关注服务行为，USE关注资源状态，结合使用才能全面掌握系统健康状况，多数生产环境同时部署两种监控体系，并在Dashboard中并排展示，实现一站式监控，据CNCF相关报告,可观测性实践成熟的组织均会同时使用服务级和资源级监控。
通过RED方法和USE方法，团队能从服务与资源两个视角全面掌控系统，既保障用户体验，又确保基础设施稳健，无论选择哪种，都应基于实际场景，灵活组合，构建高效监控体系，在实践中，从RED和USE开始，逐步扩展至更细粒度的指标,是性能监控的可靠路径。