Case Study: „Ping normal, aber App langsam“ (OSI-Diagnose Schritt für Schritt)

Die Case Study „Ping normal, aber App langsam“ ist ein Klassiker im Betrieb verteilter Systeme – und gleichzeitig eine der häufigsten Fehlinterpretationen im On-Call: Weil ICMP-Ping gute Werte liefert, wird das Problem vorschnell als „nicht Netzwerk“ eingeordnet und die Diagnose springt direkt in Applikationslogs. In der Praxis ist das riskant. Ping misst nur Erreichbarkeit auf IP-Ebene und grob die Round-Trip-Time; er sagt wenig über TCP-Connect-Zeiten, TLS-Handshakes, Paketverluste, Retransmits, Queueing in Proxies, DNS-Lookups, HTTP-Server-Queueing oder langsame Downstreams aus. Genau deshalb eignet sich eine OSI-basierte Diagnose Schritt für Schritt: Sie trennt Schichten, grenzt Ursachenräume ein und verhindert Aktionismus. Diese Fallstudie zeigt, wie ein Team systematisch vorgeht, wenn Nutzer „App ist langsam“ melden, während Ping weiterhin sauber ist. Sie bekommen eine nachvollziehbare Diagnosekette, typische Messwerte pro Layer, plausible Hypothesen, schnelle A/B-Tests und praxisnahe Mitigations, die Sie in War Rooms kopieren können. Gleichzeitig wird klar, warum „Ping normal“ und „App langsam“ sich nicht widersprechen, sondern häufig genau dann auftreten, wenn Probleme in Layer 4–7 oder in Abhängigkeiten liegen.

Ausgangslage: Symptom, Kontext und erste Hypothesen

Ein Produktteam meldet: „Seit etwa 20 Minuten lädt das Dashboard extrem langsam. Teilweise kommen Timeouts, meistens dauert es aber einfach ewig.“ Parallel zeigt ein einfacher Ping vom Jump Host zur öffentlichen IP des Load Balancers stabile 12–15 ms und keine Paketverluste. Das On-Call-Team steht vor der Kernfrage: Wo in der Kette entsteht die Verzögerung – und warum bildet Ping das nicht ab?

• Symptom: erhöhte Seitenladezeit, API-Calls dauern 3–10 Sekunden, sporadische 504
• Scope: betroffen sind vor allem EU-Nutzer, US weniger stark
• Ping: stabil, keine auffälligen Ausreißer
• Erste Hypothesen:
  • DNS langsam oder inkonsistent (Cache-Miss, Resolver-Problem)
  • TCP/Transport: Packet Loss, Retransmits, Congestion – Ping verdeckt das
  • TLS/HTTP2: Handshake oder ALPN-Verhandlung problematisch
  • Edge/Gateway: Queueing oder Upstream-Timeouts (504)
  • App/Downstream: Datenbank langsam, Locks, Connection Pool erschöpft

Warum Ping hier nicht reicht: Was ICMP misst und was nicht

Ping nutzt ICMP und prüft im Wesentlichen: „Kommt ein Paket hin und zurück?“ Viele Produktionspfade für echte Nutzer unterscheiden sich aber erheblich: TCP ist zustandsbehaftet, TLS ist rechenintensiver, HTTP kann über Proxies laufen, und Lastverteilung/Rate Limits greifen. Außerdem behandeln Netzkomponenten ICMP oft anders als TCP/UDP. Ein normaler Ping bedeutet daher vor allem: IP-Connectivity ist vorhanden. Er bedeutet nicht: „Meine App ist performant.“ Für HTTP-Semantik und Fehlerbilder (z. B. 504) ist RFC 9110 eine gute Referenz; für TCP-Details RFC 9293.

Schritt 1: OSI-Check auf Layer 3 – Ist es wirklich „Netzwerk“ oder nur „nicht Ping“?

Da Ping sauber ist, ist ein kompletter Layer-3-Ausfall unwahrscheinlich. Trotzdem wird geprüft, ob die Störung segmentiert ist (nur EU, nur bestimmte ASNs, nur bestimmte Regionen). Das ist wichtig, weil Routing-/Peering-Probleme häufig partiell auftreten, ohne Ping sofort zu verschlechtern.

• Pflichtdaten:
  • Fehler/Latenz nach Region segmentiert (EU vs. US)
  • Quell-ASNs/ISPs (häufen sich bestimmte Netze?)
  • Mehrere synthetische Checks aus unterschiedlichen Standorten
• Beobachtung: EU zeigt höhere P99-Latenz, US stabiler
• Zwischenfazit: Layer 3 nicht ausgeschlossen, aber eher „Pfadqualität/Peering“ als „Connectivity weg“

Schritt 2: DNS als vorgelagerter Spezialfall – Lookup-Latenz und Cache-Miss prüfen

Bevor TCP überhaupt startet, muss der Client den Hostnamen auflösen. DNS-Probleme sind eine häufige Ursache für „App langsam“, während Ping zur IP stabil bleibt (weil Ping häufig auf eine bereits bekannte IP geht oder lokal gecacht ist). Grundlagen zu DNS finden Sie in RFC 1034 und RFC 1035.

• Checks:
  • Lookup-Zeit messen (mehrere Resolver, mehrere Regionen)
  • Antwortcodes prüfen (SERVFAIL, Timeout, NXDOMAIN)
  • TTL und CNAME-Kette prüfen (unerwartet lang?)
• Beobachtung: DNS-Lookups sind normal, keine auffälligen Timeouts
• Zwischenfazit: DNS nicht der Engpass

Schritt 3: Layer 4 – TCP Connect und Packet Loss als „unsichtbarer“ Latenztreiber

Jetzt wird der Unterschied zwischen „Ping ok“ und „App langsam“ meist sichtbar: TCP reagiert empfindlich auf Paketverluste und Congestion. Retransmits können die effektive Latenz massiv erhöhen, ohne dass Ping im Mittel auffällig wird. Zudem sind Connect-Zeiten (SYN/SYN-ACK/ACK) ein eigener Budgetposten, den Ping nicht abbildet.

• Pflichtdaten:
  • TCP Connect Time (P95/P99) aus Client-/Proxy-Telemetrie
  • Retransmits/Resets (falls verfügbar: Host/Node/Load Balancer)
  • Connection Errors und Connection Pool Saturation auf Proxy-Seite
• Beobachtung: Connect Time in EU sporadisch erhöht; Retransmits steigen in Edge-Metriken
• Hypothese: Pfadqualität oder Überlast in einem Segment verursacht Retransmits, die HTTP-Anfragen verzögern

Schneller A/B-Test: Ping vs. TCP-Probe

Das Team führt statt Ping eine TCP-basierte Probe durch (z. B. synthetischer Connect/HTTP HEAD). Ergebnis: Ping stabil, aber TCP-basierte Probe zeigt Ausreißer. Das bestätigt, dass ICMP hier kein ausreichender Indikator ist.

Schritt 4: Layer 5–6 – TLS Handshake und Protokollnegotiation

Als Nächstes wird TLS überprüft. Ein TLS-Handshake kann durch erhöhte RTT, CPU-Engpässe auf Termination (Edge/Load Balancer), Zertifikatsprobleme oder mTLS-Policies verlangsamt werden. Für TLS 1.3 ist RFC 8446 eine belastbare Quelle.

• Checks:
  • Handshake Success Rate und Handshake-Latenz (P95/P99)
  • ALPN/HTTP2-Verteilung (gab es Änderungen?)
  • Zertifikatsstatus (Expiry, Chain) und mTLS-Events (falls relevant)
• Beobachtung: Handshake-Latenz ist leicht erhöht, aber nicht ausreichend, um 10 Sekunden zu erklären
• Zwischenfazit: TLS ist nicht die Hauptursache, aber Teil der Gesamtlatenz

Schritt 5: Layer 7 – Edge/Gateway: 504, Queueing und Upstream-Reason-Codes

Jetzt wird geprüft, ob die Langsamkeit „vor“ der App entsteht (Gateway/Ingress) oder „in“ der App (Handler/Downstream). Ein wichtiger Hinweis sind 504: Häufig ist das ein Timeout am Proxy, nicht zwingend ein App-Error. Entscheidend sind Reason Codes (z. B. upstream connect timeout vs. upstream response timeout) und ob die App die Requests überhaupt sieht.

• Pflichtdaten:
  • Gateway-Statuscodes: 502/503/504 und deren Anteile
  • Upstream-Timeouts vs. Upstream-Connect-Fails
  • Request Rate und Queue Depth am Gateway (wenn verfügbar)
  • Vergleich: Gateway Requests vs. App Access Logs (kommt alles an?)
• Beobachtung: 504 steigt in EU, Reason Codes zeigen „upstream_response_timeout“
• Beobachtung: App sieht Requests, aber Antwortzeiten sind stark erhöht
• Zwischenfazit: Problem liegt sehr wahrscheinlich in der App oder in Downstreams, nicht primär im Gateway

Schritt 6: Anwendungsebene – Tail Latency, Sättigung und „langsamer Downstream“

Die App-Metriken werden nun segmentiert: Welche Route ist langsam? Ist es nur ein Endpoint (z. B. Dashboard-Aggregation) oder alles? Ist die Langsamkeit gleichmäßig (P50 steigt) oder hauptsächlich im Tail (P99 explodiert)? Diese Unterscheidung ist zentral, weil sie unterschiedliche Ursachen nahelegt (Queueing/Locks vs. allgemeine Unterdimensionierung).

• Checks:
  • P50/P95/P99 nach Route und Region
  • CPU, Memory, GC-Pausen (falls JVM/ähnlich), Threadpool-Auslastung
  • Queue Depth / Request Backlog (Webserver/Worker)
  • DB-Pool Auslastung und Wait Times
• Beobachtung: P50 ist moderat erhöht, P99 massiv erhöht
• Beobachtung: Threadpool ok, aber DB-Connection-Pool nahe 100% und Wait Time steigt
• Hypothese: Datenbank wird langsam oder zu stark kontendiert; Requests warten auf Connections/Locks

Warum P99 hier entscheidend ist

Wenn P99 stark ansteigt, ist häufig nicht „alles langsamer“, sondern ein Teil der Requests hängt in Warteschlangen oder blockiert an Locks. Das führt zu Timeouts im Gateway, obwohl Ping und sogar Connect/TLS größtenteils unauffällig sein können.

Schritt 7: Downstream-Diagnose – Datenbank als Root Cause

Das Team prüft Downstream-Metriken: Query-Latenzen, Locks/Waits, Connection Utilization. Dabei zeigt sich: Eine bestimmte Query-Klasse ist seit kurzem deutlich langsamer. Gleichzeitig gab es vor 30 Minuten einen Deploy mit einer Feature-Flag-Aktivierung, die eine neue Sortierung im Dashboard erzwingt. Ergebnis: neue Query-Pläne, schlechter Index-Nutzung, steigende Latenz und Lock-Contention.

• Beweise (Pflichtdaten für RCA):
  • Top N langsamste Queries (P95/P99) und deren Startzeitpunkt
  • DB Wait/Lock-Metriken und Connection Pool Sättigung
  • Trace-Beispiele: lange DB-Spans mit Trace-IDs
  • Change-Korrelation: Deploy/Feature Flag Zeitpunkt

Schritt 8: Mitigation – Rückkopplungen brechen und Stabilität wiederherstellen

Bei „Ping normal, App langsam“ ist die falsche Sofortreaktion oft „mehr Retries“ oder „Timeouts erhöhen“. Beides verstärkt Queueing und kann einen Retry Storm erzeugen. Stattdessen werden Mitigations gewählt, die Last reduzieren und den Engpass entlasten.

• Mitigation 1: Feature Flag zurücksetzen (Rollback des neuen Query-Pfads)
• Mitigation 2: Temporäre Degradation (Dashboard weniger datenintensiv, weniger Sortierung/Join)
• Mitigation 3: Load Shedding/Rate Limiting für teure Endpunkte, um DB zu stabilisieren
• Mitigation 4: DB-seitig: Index ergänzen oder Query Plan fixen (wenn Change kontrolliert möglich)

Nach dem Flag-Rollback sinkt die DB-Wartezeit innerhalb weniger Minuten, P99 normalisiert sich, 504 gehen zurück. Das bestätigt die Root Cause: nicht das Netzwerk im Sinne von „Connectivity“, sondern eine datenbankgetriebene Tail-Latency, die sich als App-Langsamkeit gezeigt hat – bei gleichzeitig normalem Ping.

Die Diagnose in Zahlen: Latenz als Summe von Phasen

Ein hilfreiches Modell ist, die Ende-zu-Ende-Latenz als Summe von Teilphasen zu betrachten. Ping deckt davon praktisch nur einen Teil von „IP-Roundtrip“ ab, aber nicht die entscheidenden Anteile in TCP/TLS/HTTP/App/DB.

$T{\mathrm{total}}_{\mathrm{e2e}}=T{\mathrm{dns}}_{\mathrm{lookup}}+T{\mathrm{tcp}}_{\mathrm{connect}}+T{\mathrm{tls}}_{\mathrm{handshake}}+T{\mathrm{http}}_{\mathrm{queue}}+T{\mathrm{app}}_{\mathrm{handler}}+T{\mathrm{db}}_{\mathrm{wait}}$

In dieser Case Study war Tdbwait der dominante Term. Genau deshalb war Ping normal: Der Engpass lag nicht in der IP-Erreichbarkeit, sondern in der Verarbeitung und im Downstream-Waiting.

Typische Stolperfallen und „False Friends“ in genau diesem Szenario

• „Ping ist gut, also kein Netzwerk“: TCP kann leiden, ohne dass ICMP auffällig ist (Retransmits, Congestion, Priorisierung).
• Timeouts erhöhen: verlängert Queueing und blockiert Ressourcen länger; Symptome werden „zäher“ statt besser.
• Retries aktivieren: kann bei partieller Degradation Lastlawinen auslösen (Retry Storm), insbesondere ohne Jitter.
• Nur Durchschnitt betrachten: P50 kann ok sein, während P99 kollabiert; Nutzer erleben dann „random langsam“.
• Keine Segmentierung: Wenn nur EU betroffen ist, ist „global“ zu debuggen ineffizient; Region/Route/Version müssen früh getrennt werden.

Copy-Paste-Diagnosepfad: „Ping normal, aber App langsam“ als OSI-Runbook

• Symptom präzisieren: Welche Nutzer, welche Regionen, welche Routen, seit wann, welche Statuscodes?
• DNS prüfen: Lookup-Latenz und Fehlercodes aus mehreren Regionen/Resolvern.
• TCP prüfen: Connect Time (P95/P99), Retransmits/Resets, Connection Errors.
• TLS prüfen: Handshake-Latenz, Handshake Success Rate, ALPN/mTLS-Events.
• Gateway prüfen: 504/502/503, Reason Codes, App sieht Requests ja/nein.
• App prüfen: P95/P99 nach Route, Queueing, Threadpools, CPU/Memory.
• Downstreams prüfen: DB/Cache/Provider-Latenz, Connection Pools, Locks/Waits.
• Change-Korrelation: Deploys, Feature Flags, Config-Änderungen in den letzten 60 Minuten.
• Mitigation: Rückkopplung brechen (Load Shedding/Degradation), Engpass entlasten (Rollback/Index/Plan).
• Beweise sichern: Dashboard-Snapshots, Log-Queries, Trace-IDs, Change-IDs.

Outbound-Links zur Vertiefung

• RFC 9110 (HTTP Semantics) für Statuscodes, Proxy-Fehlerbilder und saubere Interpretation von 504
• RFC 9293 (TCP) für Retransmits, Verbindungsaufbau und Transportverhalten
• RFC 8446 (TLS 1.3) für Handshake-Mechanik und typische Failure Modes
• RFC 1034 und RFC 1035 für DNS-Grundlagen, die bei „App langsam“ oft unterschätzt werden
• Google SRE Book: Incident Response für War-Room-Struktur, Rollen und Incident-Dokumentation
• W3C Trace Context für Trace-Propagation und Korrelation von End-to-End-Latenz über Servicegrenzen hinweg

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.