集群资源瓶颈的定位之所以困难，是因为大多数监控工具只回答“某个指标是多少”，而不是“这个指标是否已经造成了排队或失败”。USE 方法用三个问题把资源状态统一起来：使用率是多少？饱和度有多高？错误是否在增加？将这三个问题应用到集群中的每一个资源，就可以系统化地排除猜测，快速找到真正拖慢系统的组件。
USE 方法最早由 Brendan Gregg 在系统性能分析领域提出，其核心思想是：对任何一个硬件或软件资源，都从 Utilization、Saturation、Errors 三个维度进行检查。在单机上，这通常意味着查看 CPU、内存、磁盘和网络。在集群环境下，资源边界被扩展到了节点间网络、共享存储、负载均衡器、服务网格数据面以及内核连接跟踪表等。只有把这些共享资源也纳入 USE 检查，才能避免出现“单节点指标正常，但整个集群仍被某个隐藏资源卡住”的情况。
一、USE 方法如何对集群资源做标准化拆解
USE 方法的关键在于把资源当成一个可以被观察、被度量的对象，而不是只看某个业务指标。对于集群中的任意一种资源，都需要回答三个问题：第一，使用率是否已经接近容量上限？第二，是否存在排队或等待，也就是饱和度是否大于零？第三，是否已经出现了直接错误？三个维度之间不一定同步变化，例如一台机器的 CPU 使用率达到 90%，但如果运行队列很短，说明请求仍然能及时得到处理；相反，如果 CPU 使用率只有 40%，但运行队列长度持续大于核心数，说明已经出现调度延迟，饱和度高。
以内存资源为例，使用率是已用内存占总内存的比例，但这个指标高并不一定表示瓶颈。真正需要关注的是饱和度指标，比如系统是否开始频繁进行 swap in 或 swap out，以及内核是否触发了内存回收机制。错误维度则包括 OOM 杀死进程、内存分配失败、页错误异常增长等。在实际集群环境中，一个节点出现 OOM，往往不只是内存容量不足，还可能是因为某个服务的内存泄漏、容器 limit 设置不合理，或者内核参数导致的内存碎片。因此 USE 方法并不是单独看一个数字，而是把三个维度的变化趋势放在一起分析。
下表列出了集群中常见资源对应的 USE 指标，可以作为检查清单使用。
| 资源类型 | 使用率指标 | 饱和度指标 | 错误指标 |
|---|---|---|---|
| CPU | 整体使用率、单核使用率 | 运行队列长度、调度延迟 | 机器重启、软锁死 |
| 内存 | 已用容量、页缓存占比 | swap in/out、内存回收延迟 | OOM、分配失败 |
| 磁盘 | 空间使用率、IOPS 使用率 | await、I/O 队列深度 | I/O 错误、坏块 |
| 网络 | 带宽使用率、包转发速率 | 丢包、重传、队列溢出 | 接口错误、CRC 错误 |
| 连接跟踪 | 表项使用率 | 插入失败、满表计数 | conntrack 满丢包 |
| 负载均衡 | 连接数、吞吐 | 后端排队、连接等待 | 5xx 错误、连接拒绝 |
二、集群环境下需要覆盖的资源清单与常见盲区
在集群环境中，节点数量多，资源类型也更杂。除了每台节点的 CPU、内存、磁盘、网卡之外，还需要监控节点之间的网络设备、共享存储阵列、负载均衡器、服务网格 sidecar 的资源消耗，以及内核中一些容易被忽略的共享资源。例如连接跟踪表 conntrack 是一个典型盲区，当集群中运行大量短连接服务时，conntrack 表项会被迅速填满，导致新连接无法建立，表现为随机超时或 502/503 错误，但传统监控面板往往不会显示这个指标。
另一个常见盲区是单核热点。如果只看节点的整体 CPU 使用率，可能只有 30%，但某个 CPU 核心已经跑满 100%，并且该核心上运行着关键的内核线程或网络中断处理程序，同样会造成延迟。因此 USE 方法要求把单核使用率也纳入监控，而不是只取所有核心的平均值。同样的，磁盘不能只看空间是否写满，还要看 IOPS 和延迟，因为日志密集型的服务可能把磁盘打到 100% 繁忙，即使磁盘空间还剩很多，也会导致应用写入阻塞。
下面是一组在 Linux 节点上快速采集 USE 指标的命令，可以在故障排查时直接运行。
# 查看 CPU 运行队列、上下文切换和中断 vmstat 1 5 # 查看每个 CPU 核心的使用率 mpstat -P ALL 1 5 # 查看磁盘 I/O 饱和度，重点关注 await 和 %util iostat -x 1 5 # 查看 conntrack 当前使用情况 cat /proc/sys/net/netfilter/nf_conntrack_count cat /proc/sys/net/netfilter/nf_conntrack_max # 查看 TCP 重传统计，重传率高说明网络或对端出现问题 ss -s cat /proc/net/snmp | grep Tcp
这些命令覆盖了 CPU、磁盘、网络连接跟踪等资源。对于容器化集群，还需要查看宿主机的内核日志、cgroup 限制以及 kubelet 上报的节点状态。很多集群故障的根源不在业务容器内部，而在宿主机的内核参数或者底层网络插件上。因此 USE 方法要求监控系统必须具备节点级别的指标采集能力，而不仅仅依赖容器内部的 metrics。
三、使用率、饱和度与错误的告警和定位案例
在使用 Prometheus 监控集群时，可以针对每个资源的三个维度定义告警规则。使用率维度通常设置一个阈值，例如 CPU 使用率超过 80% 持续 5 分钟就发出警告；饱和度维度则更敏感，一旦运行队列长度超过核心数，或者磁盘 await 大于 20ms，就应该立即通知；错误维度则要求任何非零值都要关注，比如网络接口的 CRC 错误、磁盘的 read error、内存的 OOM 事件，错误一旦出现往往意味着业务已经受到影响。
下面是一个 PromQL 示例，用于计算节点 CPU 的饱和度和磁盘 I/O 饱和度，以及连接跟踪表的使用率。
# 单核 CPU 平均使用率，需要排除 idle 模式
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
# 节点负载除以 CPU 核心数，大于 2 说明存在明显排队
node_load1 / count by (instance) (node_cpu_seconds_total{mode="idle"})
# 磁盘 I/O 饱和度，即设备繁忙时间占比
rate(node_disk_io_time_seconds_total{device=~"sd.*"}[5m]) * 100
# conntrack 表使用率
node_nf_conntrack_entries / node_nf_conntrack_entries_limit * 100
这些查询可以放在 Grafana 面板中，也可以直接作为告警表达式。需要注意的是，使用率和饱和度之间没有固定的线性关系。以磁盘 I/O 为例，如果使用率已经达到 95%，但 await 仍然只有 3ms，说明磁盘虽然繁忙，但响应还是很快，不一定会造成业务问题；如果使用率只有 60%，await 却上升到 50ms，说明磁盘已经出现饱和，应用很可能正在经历写入缓慢。因此告警策略必须把三个维度联合起来看。
一个典型的案例是：集群中某数据库节点磁盘使用率达到 100%，同时 await 超过 100ms，导致大量查询超时。此时如果只看 CPU 和内存，会发现节点状态完全正常。只有通过 USE 方法检查磁盘的饱和度和错误，才能迅速把注意力集中到存储层。另一个案例是负载均衡器后端的连接数打满，表现为客户端随机连接失败，但负载均衡器自身的 CPU 和内存都不高，此时需要查看负载均衡器的连接表使用率和后端排队情况。
四、构建集群 USE 监控看板的落地建议
在实际落地时，建议为每类资源建立三行指标面板：第一行展示使用率，第二行展示饱和度，第三行展示错误。面板按节点分组，并支持通过变量选择某个节点或某类资源进行下钻。集群整体页面则可以先展示所有节点的热点图，用颜色深浅表示使用率或饱和度，这样一眼就能发现异常节点。之后再进入该节点的详细面板，查看具体是哪类资源出了问题。
在告警设计上，可以按资源类型划分告警级别。使用率超过 80% 属于警告，超过 95% 属于严重；饱和度任何非零持续超过 5 分钟都应作为警告；错误维度一旦出现任何增长，都应立即作为严重告警处理，因为错误通常意味着不可恢复的失败。下面是一段 Prometheus 告警规则示例，用于检测节点 CPU 饱和和 conntrack 表使用率。
groups:
- name: cluster_use_alerts
rules:
- alert: NodeCpuSaturated
expr: node_load1 / count by (instance) (node_cpu_seconds_total{mode="idle"}) > 2
for: 5m
labels:
severity: warning
annotations:
summary: "节点 CPU 出现队列饱和"
- alert: ConntrackTableSaturated
expr: node_nf_conntrack_entries / node_nf_conntrack_entries_limit > 0.9
for: 1m
labels:
severity: critical
annotations:
summary: "连接跟踪表使用率超过 90%"
除了静态阈值告警，还可以结合历史数据做异常检测。例如当某个节点的磁盘 await 突然从 5ms 飙升到 80ms，即使还没有超过固定阈值，也可能意味着底层存储设备出现抖动。此时通过对比同一时刻其他节点的表现，可以判断是单节点问题还是共享存储问题。这种跨节点的横向对比是集群 USE 方法相对单机排查的一个重要优势。
最后需要强调的是，USE 方法适合在故障初期快速缩小范围，而不是替代深入的剖析工具。定位到某个资源的饱和度或错误异常之后，仍然需要用 eBPF、tcpdump、perf 或内核日志进行深入分析，才能找到最终的根本原因。把 USE 方法固化为集群监控的基础看板和告警规则，可以减少平均定位时间，避免每次故障都从零开始排查。