阅读中文版本

The USE Method for Resource Analysis

The USE method checks utilisation, saturation, and errors for every resource, turning a vague performance complaint into a systematic checklist.

Definition

The USE method is a checklist that, for each resource, asks about utilisation, saturation, and errors, providing a structured way to find bottlenecks rather than guessing.

It is used during performance investigations on hosts, databases, and network interfaces where the culprit is unknown. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.

When to use it

A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.

How it works

Utilisation is the average busy time of a resource, saturation is the degree to which it has work queued it cannot service, and errors are failed operations.

A resource can be saturated before it is fully utilised because of bursty demand or queueing, so measuring only utilisation misses the bottleneck.

Trade-offs and alternatives

Walking every resource in turn prevents the tunnel vision that leads teams to optimise a component that was never the constraint. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.

Common misconceptions

A persistent misconception is that USE is a tool rather than a reasoning checklist. Another is that saturation is only visible when utilisation reaches one hundred percent. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.

Anti-patterns to avoid

Two recurring anti-patterns are to looking only at CPU and ignoring I/O, memory, and connections and to declaring a resource healthy because errors are zero. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Symptom-Based Alerting, Trace Context Propagation, Exemplars Linking Metrics to Traces.