Sättigung (Saturation) beschreibt, wie voll eine Ressource oder ein Service ist, also ob die Nachfrage die Kapazität erreicht oder übersteigt, sodass zusätzliche Arbeit in einer Warteschlange warten muss. Sie ist eines der vier Golden Signals und das S der USE-Methode und wird über Run-Queue-Länge, Wartezeiten in Pools oder Pressure Stalls gemessen.
Was ist Sättigung (Saturation)?
Sättigung, englisch Saturation, beschreibt, wie voll eine Ressource oder ein Service ist. Eine Ressource ist gesättigt, wenn sie mehr Arbeit hat, als sie gerade bedienen kann, sodass sich zusätzliche Arbeit staut: Threads warten auf eine CPU, Requests auf eine Datenbankverbindung, I/O-Requests auf einen Datenträger. Sättigung ist ein Frühindikator. Sie steigt meist, bevor Nutzer Fehler bemerken, und zeigt sich zuerst als wachsende Latenz.
Sättigung ist eines der vier Golden Signals aus dem Google-SRE-Buch, neben Latenz, Traffic und Fehlern. Das SRE-Buch beschreibt sie als Maß dafür, wie „voll“ ein Service ist, mit Fokus auf die knappsten Ressourcen, und weist darauf hin, dass viele Systeme schon deutlich vor 100 Prozent Auslastung schlechter werden.
Auslastung vs. Sättigung: die USE-Methode
Die USE-Methode von Brendan Gregg liefert eine Checkliste für jede Ressource: Prüfen Sie Utilization (Auslastung), Saturation (Sättigung) und Errors (Fehler). Der Unterschied zwischen den ersten beiden ist entscheidend:
- Auslastung ist der Zeit- oder Kapazitätsanteil, in dem eine Ressource beschäftigt ist, etwa 85 Prozent CPU.
- Sättigung ist die Menge zusätzlicher Arbeit, die die Ressource noch nicht bedienen kann, meist als Warteschlangenlänge oder Wartezeit ausgedrückt.
Eine CPU mit 100 Prozent Auslastung und leerer Run Queue ist voll genutzt, aber nicht gesättigt. Eine CPU mit durchschnittlich 70 Prozent kann in kurzen Bursts dennoch gesättigt sein, was Mittelwerte verbergen. Sättigung sagt daher mehr über die Auswirkung auf Nutzer aus als die Auslastung allein. Für die Fehlersuche lohnt es sich, die USE-Methode systematisch für jede Ressource eines betroffenen Hosts durchzugehen, statt bei der ersten auffälligen Kurve stehen zu bleiben.
Typische Sättigungsmetriken
| Ressource | Sättigungssignal |
|---|---|
| CPU | Run-Queue-Länge über der Zahl der CPUs, Load Average im Verhältnis zu den Kernen, CPU Pressure (/proc/pressure/cpu), CFS-Throttling in Containern |
| Arbeitsspeicher | Swapping, Major Page Faults, Memory Pressure Stalls, OOM-Kills, häufige Pausen durch Garbage Collection |
| Datenträger | Mittlere I/O-Queue-Größe (aqu-sz in iostat), I/O Wait, I/O Pressure |
| Netzwerk | Verworfene Pakete, Interface-Overruns, überlaufende Socket-Backlogs, TCP-Retransmits |
| Anwendungspools | Threads, die auf einen Worker warten, Wartezeit im Connection-Pool, ausstehende Requests |
| Queues und Broker | Queue Depth, Consumer Lag, Alter der ältesten Nachricht |
Unter Linux ist Pressure Stall Information (PSI), verfügbar seit Kernel 4.20, besonders nützlich: Sie zeigt direkt, welchen Zeitanteil Tasks blockiert auf CPU, Speicher oder I/O gewartet haben.
Warum Sättigung so wichtig ist
Die Warteschlangentheorie erklärt, warum Sättigung so stark wirkt: Nähert sich die Auslastung der Kapazität, steigt die Wartezeit steil statt linear. Ein Service, der bei moderater Last in 50 ms antwortet, kann Sekunden brauchen, wenn ein Thread-Pool erschöpft ist, obwohl keine Komponente ausgefallen ist. Deshalb ist Sättigung auch die richtige Grundlage für die Kapazitätsplanung: Füllt sich ein Datenträger mit konstanter Rate oder steigt die Wartezeit eines Connection-Pools von Woche zu Woche, können Sie vorhersagen, wann die Grenze erreicht ist, und handeln, bevor es zum Incident kommt.
Beispiel: ein erschöpfter Connection-Pool
Ein illustratives Szenario: Ein Bestellservice nutzt einen Datenbank-Connection-Pool mit 20 Verbindungen. Normaler Traffic braucht etwa 12 gleichzeitig. Eine langsame Abfrage aus einem Release erhöht die Zeit, die jeder Request eine Verbindung hält, von 20 ms auf 80 ms. Nach Little's Law steigt die Zahl belegter Verbindungen etwa auf das Vierfache, der Pool erreicht 20, und neue Requests warten auf eine Verbindung. CPU und Speicher des Services sehen normal aus, aber die Pool-Wartezeit springt, und die p99-Latenz klettert bis zum Pool-Timeout. Das Sättigungssignal (Pool-Wartezeit) führt viel schneller zur Ursache als die Auslastungsmetriken.
Best Practices
- Warten messen, nicht nur Beschäftigung. Erfassen Sie für jede kritische Ressource neben der Auslastung eine Warteschlangenlänge oder Wartezeit.
- Hochaufgelöste Daten nutzen. Sättigung tritt oft in Bursts auf, die Minutenmittelwerte glätten.
- Pools in der Anwendung instrumentieren. Thread-Pools, Connection-Pools und interne Queues sind häufige Engpässe, die Host-Metriken nicht zeigen.
- Auf Symptome alarmieren, mit Sättigung analysieren. Alarmieren Sie auf Latenz und Fehler, die Nutzer betreffen, und finden Sie mit Sättigungssignalen die knappe Ressource.
- Prognosen erstellen. Werten Sie Trends der Sättigungssignale aus, um Kapazität rechtzeitig zu planen.
- Limits bewusst setzen. Begrenzte Pools und Queues mit klaren Timeouts machen Sättigung sichtbar, statt sie in endlos wachsenden Wartezeiten zu verstecken.
Wie Obseria hilft
Der Obseria Agent erfasst Sättigungssignale von Hosts und Containern wie Run Queue, Pressure Stalls und Throttling, während Traces und Laufzeitmetriken Pool-Wartezeiten und Garbage Collection zeigen. Obseria TopoGraph verknüpft diese Signale mit den abhängigen Services, und die Anomalieerkennung meldet steigende Sättigung gegenüber gelernten Baselines. So sehen Sie, welche Ressource knapp ist und wer betroffen ist.
