Die USE-Methode ist eine Checkliste zur Performance-Analyse von Brendan Gregg: Für jede Ressource, etwa CPU, Arbeitsspeicher, Datenträger, Netzwerkschnittstelle oder Connection Pool, prüfen Sie Utilization (Auslastung), Saturation (Sättigung, also wartende Arbeit) und Errors (Fehlerereignisse). So lässt sich der Engpass in einem System schnell eingrenzen.
Was ist die USE-Methode?
Die USE-Methode ist eine Methodik zur Analyse der Systemleistung, die Brendan Gregg eingeführt hat. Ihre Regel passt in einen Satz: Prüfen Sie für jede Ressource Auslastung, Sättigung und Fehler. Statt mit den Metriken zu beginnen, die ein Tool zufällig anzeigt, listen Sie zuerst die Ressourcen eines Systems auf und stellen dann für jede dieselben drei Fragen. Aus einem vagen „der Server ist langsam“ wird so eine strukturierte Suche, die den Engpass selten übersieht.
Während die RED-Methode Services von außen betrachtet (Anfragen, Fehler, Dauer), blickt die USE-Methode nach innen auf die Hardware- und Software-Ressourcen, die die Arbeit erledigen. Beide ergänzen sich.
Auslastung, Sättigung und Fehler
- Utilization (Auslastung) ist der Zeitanteil, in dem eine Ressource beschäftigt war, oder der Anteil ihrer Kapazität, der belegt ist. Eine CPU mit 90 % Auslastung war 90 % des Intervalls beschäftigt; 80 % Speicherauslastung bedeutet, dass 80 % der Kapazität belegt sind.
- Saturation (Sättigung) ist die zusätzliche Arbeit, die eine Ressource gerade nicht bedienen kann und in eine Warteschlange stellen muss, etwa die Run Queue der CPU, Swapping beim Arbeitsspeicher oder die Warteschlange eines Datenträgers. Sättigung ist oft das früheste Warnzeichen, denn die Latenz steigt, sobald Arbeit warten muss.
- Errors (Fehler) sind gezählte Fehlerereignisse: I/O-Fehler von Datenträgern, verworfene Netzwerkpakete, fehlgeschlagene Speicheranforderungen, abgewiesene Verbindungen.
Eine Ressource kann auch bei moderater durchschnittlicher Auslastung ein Problem sein. Kurze Spitzen bei 100 % verschwinden in Minutenmittelwerten, und Sättigung tritt immer dann auf, wenn die Nachfrage kurzzeitig die Kapazität übersteigt.
Typische Ressourcen und Metriken
| Ressource | Auslastung | Sättigung | Fehler |
|---|---|---|---|
| CPU | Belegte Zeit je Kern | Länge der Run Queue, CPU-Throttling in Containern | Machine-Check-Fehler (selten) |
| Arbeitsspeicher | Belegt vs. verfügbar | Swapping, Page Scanning, OOM Kills | Fehlgeschlagene Allokationen |
| Datenträger | Belegte Gerätezeit | Länge der I/O-Warteschlange | I/O-Fehler des Geräts |
| Netzwerkschnittstelle | Durchsatz vs. Link-Geschwindigkeit | Verworfene oder gepufferte Pakete | Schnittstellenfehler |
| Connection- oder Thread-Pool | Belegte vs. maximale Verbindungen | Aufrufer, die auf eine Verbindung warten | Timeouts, Abweisungen |
Die letzte Zeile zeigt, dass die USE-Methode nicht auf Hardware beschränkt ist. Software-Ressourcen wie Thread-Pools, Datenbankverbindungen, Locks und Message Queues haben dieselben drei Eigenschaften und sind in Cloud-nativen Systemen häufige Engpässe.
Gregg empfiehlt außerdem, vor dem Start ein einfaches Funktionsdiagramm des Systems zu zeichnen, einschließlich Bussen, Verbindungen und Controllern. Jeder Kasten und jeder Pfeil ist eine Ressource, die geprüft werden kann. Ressourcen, die sich nur schwer messen lassen, sollten Sie ausdrücklich als „unbekannt“ notieren, denn auch das ist ein Ergebnis: Es zeigt, wo zusätzliche Instrumentierung nötig ist. Gehen Sie die Liste anschließend systematisch durch und halten Sie für jede Ressource fest, ob Auslastung, Sättigung und Fehler unauffällig sind. Schon nach wenigen Minuten ist der Kreis der Verdächtigen meist deutlich kleiner.
Beispiel: USE-Prüfung für einen Kubernetes-Node
Mit Metriken aus dem Prometheus Node Exporter und cAdvisor könnte ein erster Durchlauf beispielhaft so aussehen:
# CPU-Auslastung je Node
1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))
# CPU-Sättigung: Load Average je Kern
node_load1 / count by (instance) (node_cpu_seconds_total{mode="idle"})
# CPU-Throttling von Containern (Sättigungssignal)
rate(container_cpu_cfs_throttled_periods_total[5m])
/ rate(container_cpu_cfs_periods_total[5m])
# Netzwerkfehler
rate(node_network_receive_errs_total[5m])Auf Linux-Hosts lassen sich dieselben Prüfungen interaktiv mit Werkzeugen wie vmstat, mpstat, iostat und sar durchführen. Zusätzlich melden die Pressure-Stall-Information-Dateien unter /proc/pressure, wie lange Tasks auf CPU, Speicher oder I/O gewartet haben, ein direktes Maß für Sättigung.
Best Practices
- Mit einer Ressourcenliste beginnen, nicht mit verfügbaren Metriken. Lücken in der Liste zeigen, wo Sie blind sind.
- Bei steigender Latenz zuerst auf Sättigung schauen. Warteschlangen erklären Verlangsamungen besser als die Auslastung allein.
- Kurze Intervalle für die Auslastung wählen. Spitzen verschwinden in langen Mittelwerten.
- Mit RED kombinieren. Alarmieren Sie auf nutzerseitige RED-Signale und nutzen Sie USE, um die Ursache zu finden.
- Ergebnisse in die Kapazitätsplanung einfließen lassen, denn dauerhaft hohe Auslastung und wiederkehrende Sättigung zeigen, wo skaliert werden muss.
Häufige Fehler
- Nur die Auslastung zu prüfen und eine Ressource für gesund zu erklären, weil sie „nur bei 60 %“ liegt.
- Software-Ressourcen wie Connection Pools, File Descriptors oder Locks zu vergessen.
- Container-Limits zu übersehen: Ein Pod kann gedrosselt werden, während der Node noch freie CPU hat.
- Allein auf hohe Auslastung zu alarmieren, was oft Rauschen ohne Auswirkung auf Nutzer erzeugt.
Wie Obseria hilft
Obseria erfasst Host-, Container- und Runtime-Metriken über OpenTelemetry und Prometheus, sodass Auslastung, Sättigung und Fehler von Nodes, Pods, Datenbanken und Pools direkt neben den Service-Signalen liegen, die davon abhängen. Das Kubernetes-Monitoring umfasst Throttling und Ressourcenlimits, und Obseria TopoGraph zeigt, welche Services auf einer gesättigten Ressource laufen. Das verkürzt den Weg vom Symptom zur Ursache.
