Skip to content

The USE method for capacity planning

Monitoring · Capacity
Studied

Problem

"Everything is slow, we need more servers" — the classic without any diagnosis. The team scales on CPU, while the real limit is disk IOPS or database locks. The money went into vCPUs, the problem stayed.

Solution

Brendan Gregg's USE method — "a methodology for analyzing the performance of any system", summarized in one line: "For every resource, check utilization, saturation, and errors." It is "intended to be used early in a performance investigation, to identify systemic bottlenecks."

Definition (Gregg) Example for CPU
Utilization The average time the resource was busy servicing work rate(node_cpu_seconds_total{mode!="idle"}[5m])
Saturation The degree to which the resource has extra work it can't service, often queued node_load1 vs the number of cores
Errors The count of error events CPU throttling, OOM kills, retries

Resources are CPU, memory, disks, network, and software resources such as DB connections. If all three look normal, the resource isn't to blame — keep looking. If one is "on fire", that's the bottleneck.

Example

A checklist for a Kubernetes node. All three signals across 5 resources = 15 queries, covering 95% of "the service is sluggish" cases.

CPU

# Utilization
1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))
# Saturation
node_load1 / count by (instance) (node_cpu_seconds_total{mode="idle"})
# Errors
rate(node_vmstat_oom_kill[5m])

Memory

# Utilization
1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes
# Saturation
rate(node_vmstat_pgmajfault[5m])
# Errors
rate(node_vmstat_oom_kill[5m])

Disk

# Utilization (busy time)
rate(node_disk_io_time_seconds_total[5m])
# Saturation (queue)
node_disk_io_time_weighted_seconds_total
# Errors
rate(node_disk_io_errors_total[5m])

Put it on one Grafana page — the "USE panel": 5 rows × 3 columns. During an incident, look there first, before any business dashboards.

When to use

  • Before scaling: USE first, +2 nodes later.
  • When investigating a "it's slow" incident — as the first screen.
  • As part of a post-incident review: which resource was overloaded.

Source

How to apply it yourself

  1. For one service, list the 5 key resources (CPU, memory, disk, network, an app-specific one like DB connections).
  2. For each — three PromQL queries (U/S/E).
  3. Combine them into one Grafana dashboard page "USE — ".
  4. Once the first overload is localized via the USE panel within a minute — status Studied.