USE Methodology: Utilisation, Saturation, Errors

USE — Utilisation, Saturation, Errors — is a methodology invented by Brendan Gregg for systems where the bottleneck is a resource: CPU, memory, disk, network. Every resource is described by three questions: how busy is it, how much extra work is queued, and how often has it failed.

USE is the methodology for hosts. RED is the methodology for services. Both are useful; the two are not interchangeable.

What use is for

USE is a checklist. For every resource in the system:

1. Utilisation. Fraction of time the resource is busy.
2. Saturation. Amount of work queued because the resource is at capacity.
3. Errors. Number of error events.

A complete USE pass on a Linux host produces, for each of CPU, memory, disk, network:

USE produces a complete picture of the host’s resource state. The methodology is repeatable: any engineer can run the same checklist on any host and arrive at the same answer.

What use is not

USE is a resource-side methodology. It does not describe the user-visible state of a service. A host with all resources at 50% utilisation can still serve 5xx responses; USE does not surface that.

USE is also not the right fit for every system:

• Stateful in-memory services (Redis, Memcached). The resource is memory; the service is “what fraction of keys return successfully?” RED is more useful.
• Network-facing services (HTTP APIs, RPC handlers). The resource is the worker pool; the service is the request handling. RED is more useful.
• Distributed queues (Kafka, RabbitMQ). The resource is the broker; the service is end-to-end delivery. USE on the broker is useful but does not capture consumer behaviour.

For those classes of system, RED is the better fit.

How USE works on a Linux host

The canonical Linux metric set under node_exporter:

CPU utilisation:
  1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))

CPU saturation (load average over runnable processes):
  node_load5 / count without (cpu, mode) (node_cpu_seconds_total{mode="idle"})

Memory utilisation (used / total):
  1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)

Memory saturation (major page faults indicate RAM pressure):
  rate(node_vmstat_pgmajfault[5m])

Disk utilisation (fraction of time doing I/O):
  rate(node_disk_io_seconds_total[5m])  # per device

Disk saturation (queue depth approximation):
  rate(node_disk_io_now[5m])

Disk errors:
  rate(node_disk_io_errors_total[5m])

Network utilisation (depends on link capacity; often omitted in
favour of throughput):
  rate(node_network_receive_bytes_total[5m])

Network saturation (drops):
  rate(node_network_receive_drop_total[5m]) + rate(node_network_transmit_drop_total[5m])

Network errors:
  rate(node_network_receive_errs_total[5m]) + rate(node_network_transmit_errs_total[5m])

The metrics are scraped by Prometheus. The PromQL composition is mechanical.

Burn-rate for USE

USE alerts are reactive, not SLO-based. The pattern is:

• 70% resource utilisation for >15 min → warn.
• 90% utilisation for >5 min → page.
• Saturation metric doubling in 5 min → warn.
• Errors metric nonzero → page (always — errors are non-recoverable events).

The threshold is determined by the resource type. CPU at 90% for 5 min is recoverable; disk at 90% utilisation is normal on a busy system but may indicate queue growth if sustained. Memory at 90% is dangerous if OOM is permitted.

When to use USE

USE is the right methodology when:

• The component is a host, a database, a storage backend, a network switch.
• The component has clearly bounded resources (CPU, RAM, disk, network).
• The failure mode is resource exhaustion (OOM, disk full, link saturation).

USE is the wrong methodology when:

• The component is an HTTP API or RPC service that scales horizontally.
• The component is a distributed queue whose capacity is dynamic.
• The failure mode is application logic, not resource exhaustion.

The two are complementary. A production platform uses both.

Production guidance

• Run USE on every host and every infrastructure component (databases, caches, message brokers).
• Tie USE alerts to thresholds derived from operational history, not arbitrary numbers.
• Pair every USE alert with a corresponding RED SLO alert for the user-facing service that depends on the resource.
• Review USE thresholds every quarter; the right threshold shifts as the system evolves.

Verification

You should be able to answer:

• What are the three USE dimensions?
• Which class of system is USE most useful for?
• Construct node_exporter-based PromQL for CPU utilisation.
• Why is USE insufficient as a sole methodology?

Quiz