Korrelation CPU-Saturation ↔ Packet Drops ↔ Latenz: Analyse-Methode

Die Korrelation CPU-Saturation ↔ Packet Drops ↔ Latenz ist eine der zuverlässigsten Analyseachsen, um Performance-Incidents in verteilten Systemen schnell einzugrenzen. In der Praxis treten diese drei Signale häufig gemeinsam auf: CPU-Saturation erhöht die Verarbeitungszeit für Netzwerk- und Applikationsarbeit, Paketverluste entstehen durch überlaufende Queues oder Treiber-/Kernel-Pfade, und Latenz steigt durch Queueing, Retransmissions und Backpressure. Das Schwierige ist jedoch die Reihenfolge: Manchmal sind Packet Drops die Ursache und CPU-Saturation nur eine Folge durch Retries; manchmal ist CPU-Saturation der Auslöser und Drops sind ein Begleitsymptom; und manchmal ist Latenz das sichtbare Symptom, während die eigentliche Ursache in einer Engpasskette aus Scheduling, SoftIRQs, NIC-Ringpuffern und Queue-Disziplinen liegt. Eine robuste Analyse-Methode kombiniert deshalb saubere Definitionen von „Saturation“, verlässliche Drop-Quellen (NIC, Kernel, qdisc, Switch), konsistente Latenz-Perzentile (P95/P99) und eine zeitliche Korrelation mit Lag-Analyse. Der folgende Leitfaden beschreibt ein praxistaugliches Vorgehen, um diese Signale korrekt zu messen, zu normalisieren und als Kausal-Hypothese zu testen, ohne sich in Einzeldiagrammen zu verlieren.

Begriffe sauber definieren: Was genau wird korreliert?

Bevor Sie Korrelationen berechnen, müssen die Größen vergleichbar und fachlich korrekt sein. „CPU“ ist nicht gleich „CPU-Saturation“, „Drops“ sind nicht immer Verlust im WAN, und „Latenz“ muss auf eine klar definierte Transaktion bezogen sein.

• CPU-Saturation: Zustand, in dem zusätzliche Arbeit nicht mehr zeitnah verarbeitet wird. Praktische Indikatoren sind Run-Queue-Länge, CPU-Steal (Virtualisierung), hohe SoftIRQ-Anteile, Kontextwechsel, Load Average im Verhältnis zu CPU-Kernen sowie anhaltend hohe Nutzlast auf den relevanten CPUs.
• Packet Drops: verworfene Pakete auf unterschiedlichen Ebenen: NIC-Ring, Treiber, Kernel-Stack, qdisc (Traffic Control), iptables/nftables, oder auf Netzwerkgeräten. „Drops“ sind nur dann End-to-End-Paketverlust, wenn sie auf dem Pfad tatsächlich Verkehr verwerfen, den Ihre Anwendung benötigt.
• Latenz: möglichst als Perzentile (P95/P99) eines Service-Level-Signals: HTTP-Request-Latenz, gRPC-RPC-Latenz, Datenbank-Query-Latenz oder TCP-Handshake/TTFB, je nach System. Als Referenz für robuste Service-Signale eignen sich die „Golden Signals“ aus SRE-Praxis, siehe Monitoring Distributed Systems (Google SRE).

Messgrundlage schaffen: Datenquellen und Metriken

Eine belastbare Korrelation steht und fällt mit der Datengüte. Ziel ist, für jedes Signal eine primäre Quelle (systemnah, verlässlich) und eine sekundäre Quelle (applikationsnah, interpretierbar) zu haben.

CPU-Saturation: Welche Metriken wirklich helfen

• Run Queue / Load: Load Average ist nur im Kontext sinnvoll. Für Linux ist die Run-Queue-Länge oder die Anzahl „runnable“ Tasks oft aussagekräftiger als ein nackter Load-Wert.
• CPU-Nutzung nach Kategorien: user/system/iowait/softirq/irq/steal. Ein hoher softirq-Anteil kann auf Netzwerkverarbeitung als Engpass hinweisen.
• Scheduler Pressure: Metriken wie PSI (Pressure Stall Information) zeigen, ob Tasks auf CPU warten. PSI ist besonders hilfreich, um „Saturation“ von „hoher Auslastung ohne Stau“ zu unterscheiden; Einstieg über Linux Kernel PSI Dokumentation.
• Interrupt-/SoftIRQ-Last pro CPU: wichtig bei NICs und RSS (Receive Side Scaling), weil einzelne CPUs „hot“ werden können, obwohl der Durchschnitt unauffällig aussieht.

Packet Drops: Drop-Orte trennen, sonst ist die Diagnose zufällig

• NIC- und Treiber-Counter: RX/TX drops, errors, overruns. Diese sind ein harter Hinweis auf lokale Engpässe oder Linkprobleme.
• Kernel-Stack und qdisc: Drops in Traffic Control (qdisc) weisen oft auf Queue-Limits oder Shaping hin. Eine kompakte Einführung bietet die tc(8)-Dokumentation.
• Conntrack/Firewall-Drops: unter Last können stateful Firewalls droppen (Tabellen voll, Rate Limits). Diese Drops wirken wie „Netzwerk“, sind aber in Wahrheit Ressourcenengpässe.
• Network Device Drops: Switch/Router-Interfaces (Queue drops, tail drop, WRED). Diese sind häufig der Auslöser, wenn viele Hosts gleichzeitig betroffen sind.

Latenz: Warum Perzentile Pflicht sind

Durchschnittswerte sind bei Incidents meist unbrauchbar, weil einige Requests normal sind, während ein relevanter Teil massiv leidet. Für die Korrelation nutzen Sie daher P95 und P99, optional zusätzlich den Anteil über einer Schwelle (z. B. > 500 ms). Für Metriksysteme wie Prometheus ist die Grundlogik der Zeitreihen und Labels in der offiziellen Doku beschrieben: Prometheus Overview.

Normalisieren: Aus Countern und Raten werden vergleichbare Signale

Viele Drop- und Fehlerwerte sind monotone Counter. CPU- und Latenzwerte sind dagegen Gauges oder Histogramm-Perzentile. Um Korrelationen zu berechnen, brauchen Sie konsistente Zeitauflösung, Einheiten und Transformationen.

• Counter → Rate: Drops pro Sekunde (oder pro Minute) aus Differenzen bilden.
• Skalierung: Raten pro Interface, pro Pod, pro Node oder pro Service normalisieren (z. B. pro 1.000 Requests), damit Lastanstiege nicht fälschlich als Problem interpretiert werden.
• Glättung: Kurze Peaks können für Ursache-Wirkung relevant sein, aber für Korrelationen ist ein kurzer Moving Average (z. B. 30–60 s) oft stabiler.
• Baseline-Abgleich: „Was ist normal?“ ist entscheidend. Eine Drop-Rate von 5/s kann für ein 100G-Interface normal sein, für ein 1G-Interface alarmierend.

Eine robuste Normalform für Incident-Korrelation

In vielen Teams funktioniert ein einheitliches Signalset, das pro Zeitfenster z-ähnliche standardisierte Werte nutzt. Sie müssen dafür nicht zwingend echte z-Scores berechnen, aber das Prinzip ist nützlich: Werte in „Abweichung von normal“ ausdrücken.

$z=\frac{x-\mu }{\sigma }$

Hier ist x der aktuelle Messwert, μ die Baseline (z. B. Median der letzten 7 Tage zur gleichen Uhrzeit) und σ eine Streuung (z. B. MAD/Standardabweichung). Damit werden CPU-Saturation, Drop-Raten und Latenzperzentile besser vergleichbar.

Lag-Analyse: Korrelation ist nur sinnvoll mit zeitlicher Verschiebung

In realen Systemen tritt Ursache und Wirkung selten gleichzeitig auf. CPU-Saturation kann erst nach Packet Drops steigen (Retry-Sturm), oder Drops können erst nach CPU-Saturation auftreten (Queueing im Kernel, verpasste Interrupts). Deshalb ist eine Lag-Analyse zentral: Sie prüfen Korrelationen für mehrere Zeitverschiebungen und suchen nach einem plausiblen Maximum.

Cross-Correlation als Denkmodell

$r\left(\tau \right)=\frac{\sum \left(x\right(t)-\mu x)\cdot \left(y\right(t+\tau )-\mu y)}{\sigma x\cdot \sigma y}$

Sie müssen diese Formel nicht „hart“ implementieren, um davon zu profitieren. Praktisch reicht oft: Visuelle Overlays plus Test von Verschiebungen (z. B. Drops um 30 s, 60 s, 120 s verschieben) und prüfen, wann das Muster am besten passt. Das Ziel ist, eine plausible Reihenfolge der Ereignisse zu finden.

Die eigentliche Analyse-Methode: Ein reproduzierbarer Workflow

Die folgende Methode ist so aufgebaut, dass sie in Incident-Situationen funktioniert: schnell, strukturiert und mit klaren Entscheidungspunkten. Sie ist bewusst tool-agnostisch, lässt sich aber gut in gängige Observability-Stacks übertragen.

Schrittfolge für die Korrelation CPU-Saturation ↔ Packet Drops ↔ Latenz

• Scope festlegen: Welcher Service, welche Region, welche Node-Gruppe? Korrelationen über „alles“ sind selten hilfreich.
• Ein gemeinsames Zeitfenster wählen: Start 30–60 Minuten vor Symptombeginn, Ende bis zur Stabilisierung. Zeitstempel konsequent in UTC führen.
• Drei Kernsignale als Perzentile/Raten extrahieren: CPU-Saturation-Indikator (z. B. PSI CPU oder Run-Queue), Drop-Rate (pro Interface/qdisc), Latenz P95/P99.
• Normalisieren: pro Node/Service und gegen Baseline, damit Laständerungen nicht als „Problem“ erscheinen.
• Lag testen: Drops vs. Latenz, CPU vs. Drops, CPU vs. Latenz jeweils mit Zeitverschiebungen prüfen.
• Hypothese formulieren: z. B. „CPU-Saturation in SoftIRQ verursacht RX-Drops, was Retransmits erhöht und P99-Latenz treibt“.
• Gegenbeweise suchen: Welche Metrik müsste nicht passen, wenn die Hypothese falsch ist? Beispiel: Wenn Drops schuld sind, müssten Retransmissions steigen und Goodput sinken.
• Segmentieren: nur bestimmte Nodes? nur ein Interface? nur ein AZ? Segmentierung ist häufig der schnellste Weg zur Ursache.

Interpretationsmuster: Häufige Kausal-Ketten und ihre Indikatoren

Die Korrelation allein sagt noch nicht, was Ursache ist. Hilfreich sind typische Muster, die Sie mit Zusatzsignalen absichern. Dadurch wird aus „Korrelation“ eine belastbare Incident-Hypothese.

Muster: CPU-Saturation führt zu Drops und dann zu Latenz

• Signalbild: CPU-Saturation steigt zuerst, kurz danach Drops, danach Latenz-P99.
• Typische Begleitsignale: hoher softirq/irq-Anteil, steigende Kontextwechsel, RX overrun/queue full, höhere TCP-Retransmits.
• Ursachen: Hot CPU durch Interrupt-Affinität, zu wenig RSS-Queues, ineffiziente Crypto/Compression, GC-Pressure.

Muster: Packet Drops führen zu CPU-Saturation (Retry-Sturm) und Latenz

• Signalbild: Drops steigen zuerst, Latenz steigt fast gleichzeitig, CPU-Saturation folgt durch Retries/Backoff.
• Typische Begleitsignale: steigende TCP-Retransmissions, mehr HTTP-Retries, erhöhte Connection-Fehler, Queue drops auf Network Devices.
• Ursachen: Congestion, zu kleine Queues, Shaping/Policing, fehlerhafte Links, DDoS-Mitigation.

Muster: Latenz steigt ohne Drops, aber mit CPU-Saturation

• Signalbild: CPU-Saturation und Latenz steigen, Drops bleiben niedrig.
• Typische Begleitsignale: hoher iowait, Lock-Contention, Queueing in Applikation, Threadpool-Sättigung.
• Ursachen: CPU-bound Workload, DB-Engpass, Synchronisationsprobleme, ineffiziente Queries.

Validierung durch Zusatzmetriken: Damit die Korrelation „gerichtet“ wird

Um aus der Korrelation eine Ursache-Wirkung-Kette zu machen, sollten Sie bewusst zusätzliche Signale hinzunehmen, die das Netzwerk- und Transportverhalten erklären.

• TCP-Retransmissions: steigen Retransmits parallel zu Drops und Latenz, ist „echter“ Verlust wahrscheinlicher.
• Goodput vs. Throughput: Wenn Throughput hoch bleibt, Goodput (nutzbare Daten) aber sinkt, deuten Retries/Overhead auf Transportprobleme.
• Queue-Längen: NIC-Ringfüllstände, qdisc backlog, oder device-Queues zeigen Queueing als Ursache von Latenz.
• Errors/CRC: physische Linkprobleme erzeugen Drops und Retransmits, oft ohne hohe CPU-Saturation zu Beginn.
• DNS/TLS-Teilstrecken: Wenn Latenz primär vor dem Request entsteht, können DNS/TLS Metriken die „Latenz“ erklären, ohne dass Drops relevant sind.

Zur Einordnung von Paketverlust und seinen Auswirkungen ist eine kompakte Übersicht hilfreich, etwa Einführung zu Packet Loss.

Praktische Visualisierung: Drei Diagramme, die fast immer reichen

In Incidents hilft Reduktion. Statt 20 Panels funktionieren oft drei überlagerte Sichten, jeweils mit identischer Zeitachse und klaren Aggregationen.

• Panel 1: CPU-Saturation (PSI CPU oder Run-Queue) plus softirq-Anteil.
• Panel 2: Packet Drops als Rate, getrennt nach RX/TX und nach Drop-Ort (NIC vs. qdisc, wenn möglich).
• Panel 3: Latenz als P95/P99 plus Error Rate oder Timeout Rate.

Diese Panels ergänzen Sie nur dann, wenn eine Hypothese zusätzliche Evidenz braucht (z. B. Retransmissions, qdisc backlog, Deploy-Events). Damit vermeiden Sie Analyse-Paralyse.

Fehlerquellen: Warum Korrelationen oft in die Irre führen

Viele Teams „sehen“ Korrelationen, die statistisch oder fachlich nicht tragen. Die häufigsten Fallen sind vermeidbar, wenn Sie sie bewusst prüfen.

• Aggregation verschleiert Hotspots: Durchschnitt über alle Nodes kann stabil wirken, während 10% der Nodes brennen. Immer segmentieren.
• Unterschiedliche Samplingintervalle: CPU alle 10s, Drops alle 60s, Latenz alle 5s – das erzeugt falsche Lag-Effekte.
• Drops sind nicht gleich Loss: Manche Drops betreffen nur Control-Plane oder irrelevanten Traffic. Kontext ist Pflicht.
• Last als Confounder: Mehr Traffic erhöht CPU und Drops gleichzeitig, ohne dass ein „Problem“ vorliegt. Normalisierung pro Request ist entscheidend.
• Änderungen im Instrumentation-Stack: Exporter-Ausfall oder Label-Explosion kann Metriken verzerren. Metamonitoring ist hilfreich.

Operationalisierung: Alerts und Runbooks aus der Methode ableiten

Wenn Sie die Analyse-Methode einmal etabliert haben, lohnt sich die Ableitung in standardisierte Alarme und Runbooks. Ziel ist, nicht erst im Outage mit Grundsatzfragen zu beginnen, sondern die Korrelation CPU-Saturation ↔ Packet Drops ↔ Latenz als „Incident-Dreieck“ automatisiert sichtbar zu machen.

• Composite Alert: Alarm, wenn CPU-Saturation über Baseline und Drop-Rate steigt und P99-Latenz über Schwelle liegt.
• Early Warning: Warnung bei steigender Drop-Rate plus Retransmissions, bevor Latenz eskaliert.
• Mitigation-Guides: Runbook-Abschnitte für „CPU hot durch SoftIRQ“, „qdisc drops durch Shaping“, „Link errors/CRC“.
• Change-Korrelation: Deploy- und Config-Events automatisch in dieselbe Zeitachse einblenden.

Weiterführende Ressourcen

• Google SRE: Monitoring Distributed Systems (Golden Signals)
• Linux Kernel Dokumentation: Pressure Stall Information (PSI)
• Linux Traffic Control: tc(8)
• Prometheus Dokumentation: Overview
• Cloudflare: Was ist Packet Loss?

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.