指标监控体系：RED与USE方法论实战指南

在复杂的分布式系统与微服务架构中，“观测性”（Observability）是确保服务稳定性的基石。然而，很多团队在起步时往往会淹没在海量的CPU、内存、网络等基础指标里，无法快速回答两个核心问题：用户是否满意？系统是否健康？

为了让监控更聚焦且可落地，业界演化出了两套黄金方法论：RED 方法与 USE 方法。前者从外部服务视角衡量用户体验，后者从内部资源视角审视系统瓶颈。本文将通过通俗易懂的方式帮你掌握这两种方法，并搭建起基本的指标监控思维框架。

什么是RED方法

RED是三个单词的首字母缩写，由Tom Wilkie提出，旨在专注于服务端点（Endpoint）的监控。它不关心系统内部的状态，只关心外部请求流量变现的三个关键信号：

• Rate（速率/吞吐量）：每秒接收到的请求数量。
• Errors（错误率）：每秒失败的请求数量。
• Duration（耗时/延迟）：每个请求所花费的处理时间。

为什么RED有效

RED将复杂系统的监控问题简化到面向“请求-响应”模式的原子指标上。它能直接回答业务最关心的问题：

• 用户访问量是否突然激增或暴跌？（Rate）
• 用户是否收到了错误页面或错误码？（Errors）
• 用户打开页面或获得响应的速度是否在可接受范围内？（Duration）

对于每一个对外提供的HTTP API、gRPC服务、数据库查询接口，只要定义好请求的成功/失败语义，RED方法就能无差别地覆盖，非常适合微服务环境。

RED实践要点

1. 分别监控每个端点：不要只监控服务的整体QPS，/api/login 和 /api/search 的RED指标应该分开看。
2. 错误的定义要统一：什么是错误？是HTTP 5xx状态码，还是业务逻辑返回的code != 0？必须明确约定并体现在指标标签中。
3. 耗时要关注分布：不要只看平均值，要用百分位数（P50、P95、P99）来观察Duration。平均值常常掩盖了尾部延迟的恶化。
4. 利用RED构建SLI（服务等级指标）：RED天然适合计算可用性和延迟SLI。例如，可用性 = 总请求数 / (总请求数 - 错误数)；延迟SLI = Duration P95 < 500ms 的请求比例。

什么是USE方法

USE由Brendan Gregg提出，聚焦于物理资源及软件资源的健康状态。它的出发点不是“用户请求长什么样”，而是“我的服务器、虚拟机、容器、磁盘等组件，有没有被榨干或出现异常”。同样由三个维度组成：

• Utilization（使用率）：资源忙于工作的平均时间或容量占比。
• Saturation（饱和度）：资源无法再承载更多工作的程度，通常是等待队列的长度。
• Errors（错误）：资源中发生的错误事件计数。

为什么USE有效

RED擅长发现“服务变慢了”，但无法回答“为什么变慢”。USE方法恰恰填补了这一点。当服务器的CPU使用率飙升至100%（Utilization），或CPU运行队列长度持续大于核数（Saturation），又或者网卡出现大量CRC错误包（Errors），答案就浮现了。它帮助我们从基础设施和操作系统层面定位瓶颈。

USE方法需要监控的典型资源

USE方法可以应用于多种资源，你需要为每类资源分别梳理U、S、E指标：

USE实践思想：内部资源视图

不同于RED对服务端点的监控，USE告诉你资源瓶颈在哪里。当服务延迟（RED的Duration）上升时：

• 检查 CPU Saturation（负载高、队列长）还是 Disk I/O Utilization 高？
• 检查 Memory Saturation（在大量使用Swap）吗？
• 检查是否有网络 Errors（导致大量重传）？

把USE指标作为排查问题的第一层现场证据，你就能从症状直接跳转到原因。

RED vs USE：如何协同使用

这两套方法论并不互斥，而是互为补充：

• RED是面向应用和服务的外部监控
  让你知道服务是否“生病了”：慢了、失败了、流量突降了。
• USE是面向资源和节点的内部监控
  让你给“生病”的诊断提供病理依据：资源耗尽、硬件故障、过度饱和。

在实际落地时，可以总结为一句口诀：RED发现症状，USE定位病灶。

一个成熟的指标监控体系会同时铺开两层视图：

1. 服务面板：基于RED，展示核心业务的黄金指标，用于告警和SLI看板。
2. 资源面板：基于USE，展示节点、容器、中间件的资源健康度，用于排障和容量规划。

实战：构建一个最小化的监控面板

下面我们模拟一个简单的微服务系统，设计一个初学者都能上手的指标监控计划。

第一步：为服务埋点，提取RED指标

假设你有一个用户服务 user-service，对外暴露了两个REST API：GET /users/{id} 和 POST /users。

你需要从服务网格或应用内部采集以下指标（以Prometheus指标形式为例）：

# 请求速率
http_requests_total{service="user-service", endpoint="/users/:id"}

# 错误速率（假设 5xx 状态码视为错误）
http_requests_total{status=~"5.."}

# 请求耗时分布直方图
http_request_duration_seconds_bucket{service="user-service", endpoint="/users/:id"}

查询RED看板的PromQL示例：

• 速率：rate(http_requests_total[1m])
• 错误率：rate(http_requests_total{status=~"5.."}[1m]) / rate(http_requests_total[1m])
• 延迟P95：histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[1m]))

第二步：为节点采集USE指标

对运行服务的每个节点（或Pod）采集USE，常用Node Exporter或Cadvisor。你需要关注的核心指标：

CPU

• node_cpu_seconds_total 可用于计算使用率
• node_load1 / node_load5 判断饱和度

内存

• node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes 反映利用率
• node_memory_SwapFree_bytes 急剧下降意味内存饱和

磁盘

• node_filesystem_avail_bytes 关注空间使用率
• node_disk_io_time_seconds_total 查看I/O使用率
• rate(node_disk_io_time_seconds_total[1m]) 接近1说明饱和

网络

• rate(node_network_receive_drop_total[1m]) 如果持续增长，表示网络饱和或配置问题
• rate(node_network_transmit_errors_total[1m]) 检测错误

第三步：建立预警路径

当收到 “API P95延迟 > 500ms” 的RED告警时，你的排查流程：

1. 打开USE资源面板，查看对应时间段内所有节点的CPU Saturation和IO Saturation。
2. 若发现某个节点 node_load5 远超CPU核数，且 node_disk_io_time 很高，基本判定是资源饱和。
3. 接着查看该节点上进程的详细指标或日志，最终锁定原因。

当收到 “磁盘空间使用率 > 90%” 的USE告警时：

1. 判断该磁盘是否挂载给数据库或服务，评估风险。
2. 若持续上升，要立即触发自动化清理或扩容。
3. 同时关注关联的服务RED面板，确认是否因此导致了API Errors增加（磁盘写满导致服务不可用）。

常见误区与最佳实践

1. 误区：RED只看平均值
   务必使用直方图量化延迟分布。平均值可能非常乐观，而P99延迟已经让用户感知到卡顿。

2. 误区：USE只适用于物理机
   容器或虚拟机同样有虚拟化的CPU、内存、磁盘等资源，USE方法完全适用。对于Kubernetes环境，可以对Pods设置资源限制，并以限制百分比来观察Utilization。

3. 最佳实践：标签（Label）规范
   无论RED还是USE指标，标签体系要统一。如service、endpoint、status、host等，这能让你在排查时任意关联从应用到资源的链路。

4. 最佳实践：覆盖全链路
   RED不仅限于前端API，对数据库查询、消息队列消费等同样重要。将RED推广到每一次关键的技术请求，才能建立全链路的观测能力。

总结

指标监控体系的建立不是堆砌采集项，而是要带着清晰的问题导向。RED方法让你始终从用户视角守护服务质量，USE方法让你从资源视角提前发现风险和快速定位瓶颈。

把这两套方法作为你监控体系的“骨架”，再逐步补充业务指标和日志、链路追踪，你就能够构建起一套抗干扰、可行动的现代可观测性系统。

下一步行动： 立即选出一个你最核心的服务和一个最关键的节点，分别按照RED和USE思路设计并展示指标看板，亲身感受从“看起来很多指标”到“一眼看穿问题”的转变。