Ein Runbook „Spiky Latency“ ist dann besonders wertvoll, wenn Latenz nicht dauerhaft hoch ist, sondern in kurzen Ausschlägen („Spikes“) auftritt: P99 springt für 1–3 Minuten stark nach oben, danach wirkt alles wieder normal. Genau diese Muster sind im On-Call schwer zu greifen, weil sie selten mit einem einzelnen, konstanten Fehlerbild einhergehen. Spiky Latency kann durch Queueing, kurzzeitige CPU-Saturation, Garbage Collection, Packet Drops, DNS- oder TLS-Ausreißer, Datenbank-Contention, Rate Limiting, Autoscaling, Cold Starts oder externe Abhängigkeiten entstehen. Ein gutes Runbook reduziert das Problem auf eine wiederholbare Methode: erst Daten sichern, dann das Spike-Muster klassifizieren, anschließend entlang der Request-Kette systematisch testen, welche Phase die Latenzspitzen trägt. Dieses Dokument liefert eine Daten-Checkliste und Diagnose-Schritte, die in modernen Observability-Stacks (Metriken, Logs, Traces) funktionieren und die typischen Fallen vermeiden: falsche Aggregation, fehlende Zeitfenster-Konsistenz und voreilige Kausalannahmen. Als methodischer Hintergrund eignen sich die „Golden Signals“ aus der SRE-Praxis, insbesondere die Verbindung aus Latenz, Fehlern, Traffic und Saturation, siehe Google SRE: Monitoring Distributed Systems.
Definition und Zielbild: Was zählt als „Spiky Latency“?
Spiky Latency beschreibt kurzfristige, wiederkehrende Latenzspitzen, die meist nur in hohen Perzentilen sichtbar sind (P95/P99/P99.9). Der Mittelwert kann stabil bleiben, obwohl Nutzer spürbar betroffen sind. Damit die Diagnose sauber ist, definieren Sie vorab ein Zielbild und eine Messdefinition.
- Messpunkt: Welche Latenz betrachten Sie? End-to-End (Client), Gateway/Ingress, Service-Handler, Datenbank-Query, externe API?
- Perzentile: Mindestens P95 und P99, optional „% über Schwelle“ (z. B. > 500 ms) für klarere Spike-Erkennung.
- Zeitauflösung: Spikes verschwinden, wenn Sie zu stark glätten (5–10 Minuten). Starten Sie mit 10–30 Sekunden oder 1 Minute.
- Scope: Gesamtservice vs. einzelner Endpoint vs. Region/Zone vs. einzelner Host/Pod.
Daten-Checkliste: Was Sie sofort sichern sollten
Bei Spiky Latency ist das Zeitfenster entscheidend. Sobald Sie den Spike erkannt haben, sichern Sie Daten für ein konsistentes Intervall: typischerweise 30–60 Minuten vor dem ersten Spike bis mindestens 10 Minuten nach dem letzten Spike. Wenn möglich, exportieren oder verlinken Sie Abfragen mit fixiertem Zeitfenster, damit spätere Analysen reproduzierbar sind.
Checkliste A: Nutzer- und Service-Sicht
- Latenz pro Perzentil: P50/P90/P95/P99 (und ggf. P99.9) für betroffene Endpoints.
- Fehlerquote: 5xx/Timeouts/Abbrüche. Spikes ohne Fehler sind häufig Queueing- oder Ressourcenprobleme.
- Traffic: Requests pro Sekunde, Concurrency, Queue-Länge (falls vorhanden).
- Degradation-Indikatoren: Retries, Circuit Breaker Opens, Rate-Limits (429), Fallback-Nutzung.
Checkliste B: Infrastruktur- und Ressourcen-Sicht
- CPU: Nutzung nach user/system/softirq/irq/steal, plus Run-Queue oder Load pro Core.
- Memory: RSS/Working Set, Page Faults, OOM-Kills, GC-Metriken (bei managed runtimes).
- Disk/I/O: iowait, Latenz pro Device, Queue Depth, Throttling (z. B. in Cloud-Volumes).
- Netzwerk: Packet Drops (RX/TX), Errors/CRC, Retransmissions, qdisc-Drops, Bandbreite.
Checkliste C: Abhängigkeiten
- DNS: Resolution Time und Timeout Rate (synthetisch oder Resolver-Metriken).
- TLS: Handshake Time und Failure Rate (wenn TLS-Termination relevant ist).
- Datenbank: Query-Latenz, Locks/Contention, Connection Pool Saturation.
- Externe APIs: P95/P99, 5xx/Timeouts, Rate Limits, regionale Unterschiede.
Checkliste D: Changes und Ereignisse
- Deployments: neue Versionen, Rollouts, Canary-Prozente.
- Feature Flags: Aktivierungen, Konfigänderungen, Experimente.
- Autoscaling: Scale-Out/Scale-In Events, Pod/Node-Replacements.
- Infrastrukturänderungen: LB/Ingress-Policies, WAF/Rate-Limits, DNS-Änderungen.
Diagnose-Start: Spike-Muster klassifizieren
Bevor Sie tief einsteigen, klassifizieren Sie das Muster. Das spart Zeit, weil viele Ursachen typische Signaturen haben.
- Periodisch: Spikes alle 1, 5 oder 15 Minuten → Batch-Jobs, Cron, GC, Cache-Refresh, Health-Check-Stürme.
- Traffic-gekoppelt: Spikes treten bei Lastspitzen auf → Queueing, LB, DB-Pool, Rate Limits.
- Region/AZ-spezifisch: nur in einer Zone/Region → Netzwerkpfad, Node-Gruppe, Storage, kapazitive Engpässe.
- Endpoint-spezifisch: nur ein Route-Template → Hotspot-Query, externer Call, Locking, Payload-Größe.
- Nur hohe Perzentile: P99 hoch, P50 stabil → Tail-Latency, Queueing, Retries, Contention.
Diagnose-Schritte: Vom Symptom zur Ursache
Die folgenden Schritte sind bewusst in einer Reihenfolge, die in On-Call-Situationen funktioniert. Sie testen zuerst die wahrscheinlichsten Ursachen mit hoher Hebelwirkung und arbeiten dann tiefer in die Kette.
Schritt 1: Scope sauber eingrenzen
- Aufteilen nach Region/AZ, Cluster, Node/Pod, Endpoint, HTTP-Method und Statusklasse.
- Prüfen, ob nur ein Subset betroffen ist (z. B. 10% Pods). Spikes sind oft Hotspot- oder Imbalance-Probleme.
- Wenn vorhanden: Top Contributors identifizieren (Top Pods nach Latenz oder Fehlern).
Schritt 2: Prüfen, ob Queueing die Tail-Latency treibt
Queueing ist eine der häufigsten Ursachen für spiky Latenz: Ein kurzer Stau genügt, um P99 stark zu erhöhen. Indikatoren sind Concurrency-Spitzen, Warteschlangenlängen, steigende Request-Queueing-Zeit oder steigende „in-flight“-Requests.
- Serverseitige Queue-Metriken: Warteschlange im Webserver/Proxy, Threadpool-Queue, Worker-Queue.
- Backpressure: steigende Timeouts, mehr Retries, Circuit Breaker Activity.
- LB-Sicht: Upstream connect/response time Spikes, 504-Anstieg, Backend-Health-Flapping.
Schritt 3: CPU-Saturation und Scheduling-Pressure prüfen
Hohe CPU-Auslastung allein ist nicht automatisch ein Problem. Spiky Latency entsteht eher, wenn CPU knapp wird und Tasks warten müssen (Saturation). Besonders aussagekräftig ist Pressure Stall Information (PSI), weil es Wartezeiten auf Ressourcen sichtbar macht; Referenz: Linux Kernel PSI.
- PSI CPU: Steigen „some“/„full“-Werte genau während der Spikes?
- Run-Queue/Load pro Core: Sind einzelne CPUs „hot“, obwohl der Durchschnitt ok ist?
- SoftIRQ/IRQ: Hohe softirq-Anteile während Spikes deuten auf Netzwerkverarbeitung als Engpass hin.
- Steal Time: In virtuellen Umgebungen kann CPU-Steal spiky Latenz verursachen.
Schritt 4: Garbage Collection und Runtime-Pausen ausschließen
In JVM-, .NET- oder Go-Workloads sind kurze Stop-the-World-Pausen eine klassische Ursache für Latenzspitzen. Das Muster ist oft periodisch oder lastabhängig.
- GC Pause Time: Spikes in GC-Pausen korrelieren mit Latenz-P99.
- Allocation Rate: steigt während eines Deployments oder Feature-Flags?
- Heap Pressure: hoher Heap, häufige Major GCs, Fragmentierung.
- Threadpool Saturation: viele blocked threads während Spikes.
Schritt 5: Netzwerk-Symptome prüfen (Drops, Retransmits, Queueing)
Spiky Latency kann durch kurze Netzwerkverluste oder Queue-Drops entstehen, die dann Retransmissions auslösen. Selbst kleine Drop-Spitzen können Tail-Latency massiv erhöhen. Prüfen Sie Drop-Orte getrennt (NIC vs. qdisc vs. Netzwerkgerät), um Scheinkorrelationen zu vermeiden.
- NIC Drops/Errors: RX/TX drops, overruns, CRC/errors.
- qdisc Drops: Drops durch Traffic Control/Queue-Limits (tc/qdisc), siehe tc(8).
- TCP Retransmissions: steigen parallel zu Latenzspikes?
- LB/Ingress Connect-Latenz: Spikes bei connect/handshake als Transportindikator.
Schritt 6: DNS- und TLS-Ausreißer als „Pre-Request“-Latenz prüfen
Wenn Latenzspikes vor allem beim Verbindungsaufbau entstehen, sehen Sie häufig erhöhte DNS-Resolution-Time oder TLS-Handshake-Time. Das betrifft vor allem Clients ohne stabile Keep-Alive-Verbindungen oder bei vielen neuen Connections.
- DNS Resolution Time: P95/P99 der Lookup-Zeit; Timeouts sind besonders relevant.
- TLS Handshake Time: Spikes im Handshake können auf CPU, Zertifikats-/Chain-Probleme oder Netzpfad hindeuten.
- Cache-Effekte: DNS wirkt oft „spiky“, wenn TTLs ablaufen und viele Clients gleichzeitig neu auflösen.
Für DNS-Fehlerklassifikation kann RFC-Material hilfreich sein, z. B. RFC 8914 (Extended DNS Errors).
Schritt 7: Datenbank-Engpässe (Pools, Locks, langsame Queries)
Die Datenbank ist eine häufige Quelle für Tail-Latency, insbesondere wenn Locking oder Connection Pools kurzzeitig saturieren. Spikes entstehen etwa bei Autovacuum, Checkpointing, Plan-Änderungen, Hot Rows oder Burst-Load.
- Connection Pool: Acquisition-Latenz, Pool Exhaustion, Warteschlange im Pool.
- Locks/Contention: erhöhte Lock-Wartezeiten, Deadlocks, lange Transaktionen.
- Slow Query Outliers: einzelne Query-Klassen dominieren P99.
- I/O-Latenz: Storage-Spikes korrelieren mit Query-Spikes (Queue Depth, IOPS-Limits).
Schritt 8: Externe APIs und Rate Limits prüfen
Wenn ein Endpoint einen externen Call enthält, kann dessen Spikiness direkt in Ihre P99 wandern. Zusätzlich erzeugen Retries und Backoff Muster, die periodisch wirken.
- Per-Dependency Latenz: P95/P99 des externen Calls getrennt nach Region.
- Timeouts vs. 5xx vs. 429: getrennt zählen, weil die Mitigation unterschiedlich ist.
- Fallback-/Cache-Rate: wie oft konnte degradiert werden?
- Retry-Policy: kurze Retries können Spikes verstärken, wenn viele Requests gleichzeitig retryen.
Schritt 9: Traces einsetzen, um die „Latenzphase“ zu lokalisieren
Distributed Tracing ist ideal, um herauszufinden, welche Span-Phase den Spike trägt: Queueing, DB, externer Call, Serialize/Deserialize, TLS, DNS. Voraussetzung ist, dass Attribute stabil sind und Sampling im Incident nicht die relevanten Traces entfernt. Als Einstieg eignen sich OpenTelemetry-Grundlagen, siehe OpenTelemetry Dokumentation.
- Trace Exemplars: Suchen Sie gezielt langsame Traces während eines Spike-Zeitfensters.
- Span Breakdown: Wo liegt die meiste Zeit? Welche Abhängigkeit korreliert?
- Fehlende Spans: Lücken können auf Sampling, Propagation-Probleme oder Async-Flows hindeuten.
Entscheidungspunkte: Schnelle Mitigation vs. Root Cause
Ein Runbook muss auch im Incident helfen, priorisiert zu handeln. Für Spiky Latency sind häufig Maßnahmen sinnvoll, die das System stabilisieren, bevor die exakte Ursache klar ist.
- Traffic dämpfen: Rate Limits, Queue-Limits, Feature-Flag Deaktivierung, um Tail-Latency zu stabilisieren.
- Skalieren: Scale-Out bei CPU- oder Worker-Saturation, aber gleichzeitig prüfen, ob ein zentraler Dependency-Engpass bleibt (DB, externer Provider).
- Retry-Policy entschärfen: aggressive Retries erzeugen Burst-Spikes; Backoff/Max-Retries anpassen.
- Timeouts korrekt setzen: zu hohe Timeouts verlängern Tail; zu niedrige Timeouts erzeugen Fehler und Retries.
- Hotspot isolieren: betroffene Route/Query/Region identifizieren und gezielt mitigieren (Cache, Degradation, Rollback).
Typische Muster und „If-Then“-Diagnosepfade
Die folgenden Heuristiken sind hilfreich, um schnell zu einem plausiblen Pfad zu gelangen. Sie ersetzen keine Verifikation, reduzieren aber Suchraum.
- Wenn P99 spiky, P50 stabil, und Concurrency spiky: Queueing/Backpressure wahrscheinlich → Threadpools, Ingress, Worker-Limits prüfen.
- Wenn Spikes periodisch (z. B. alle 5 Min): Cron/Batch/GC/Cache-Refresh wahrscheinlich → Job-Timing, GC-Metriken, Cache-TTLs prüfen.
- Wenn Spikes nur in einer AZ: Infrastrukturpfad wahrscheinlich → Nodes, Storage, Netzwerkgeräte, LB-Targets segmentieren.
- Wenn Spikes nur bei einem Endpoint: Abhängigkeit oder Query-Klasse wahrscheinlich → Traces, DB-Queries, externe Calls analysieren.
- Wenn Drops/Retransmits spiky parallel zu P99: Netzwerkverlust/Queue-Drops wahrscheinlich → NIC/qdisc/Device-Counter prüfen.
- Wenn CPU softirq spiky parallel zu P99: Netzwerkverarbeitung/Interrupt-Engpass wahrscheinlich → IRQ-Affinität, RSS, NIC-Queues prüfen.
Mess- und Query-Hygiene: Häufige Fehler im Spiky-Latency-Runbook
- Zu grobe Aggregation: Durchschnitt über alle Pods maskiert Hotspots. Immer Top-N und Segmentierung nutzen.
- Zu starke Glättung: Moving Average über 5 Minuten „tötet“ Spikes. Erst fein, dann grob.
- Uneinheitliche Zeitfenster: CPU in 1-Minuten-Schritten, Latenz in 5-Minuten-Schritten → falsche Korrelationen.
- Fehlerklassen vermischen: Timeouts, 5xx, 429 getrennt betrachten, sonst wird Mitigation falsch.
- Retry-Blindheit: Spikes können durch Retries entstehen, die im Standard-Dashboard nicht sichtbar sind.
Als Referenz, warum Latenz und Saturation zusammen gedacht werden sollten, sind SRE-Konzepte zu Monitoring besonders nützlich, siehe Google SRE Monitoring. Für Zeitreihenprinzipien und Querying in einem verbreiteten Metriksystem eignet sich die Prometheus Dokumentation.
Runbook-Output: Was Sie am Ende dokumentieren sollten
Auch ohne formales „Fazit“ ist es wichtig, dass das Runbook einen klaren Output erzeugt, der die nächsten Schritte trägt: bestätigte Ursache, Hypothesen, Mitigation, Validierung und offene Punkte. Das verbessert nicht nur die Incident-Arbeit, sondern auch spätere Reviews.
- Spike-Zeitfenster: Start/Ende, Häufigkeit, betroffene Perzentile/Endpoints/Regionen.
- Bestätigte Korrelation: welches Signal steigt zuerst (Queueing, CPU, Drops, DB-Latenz)?
- Mitigation-Schritte: was wurde getan, von wem, wann, mit welcher Validierung.
- Beweismittel: Links zu Dashboards/Queries/Traces mit fixiertem Zeitfenster.
- Nächste technische Arbeit: konkrete Follow-ups (z. B. Pool-Größe, Query-Optimierung, IRQ-Tuning, Retry-Policy).
Weiterführende Ressourcen
- Google SRE: Monitoring Distributed Systems
- Prometheus: Overview
- OpenTelemetry Dokumentation
- Linux Kernel: Pressure Stall Information (PSI)
- Linux Traffic Control: tc(8)
- RFC 8914: Extended DNS Errors
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.
