Site icon bintorosoft.com

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

Red Snapper

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?

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.

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.

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.

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.

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.

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).

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.

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.

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.

Ttotale2e = Tdnslookup + Ttcpconnect + Ttlshandshake + Thttpqueue + Tapphandler + Tdbwait

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

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

Outbound-Links zur Vertiefung

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:

Lieferumfang:

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.

 

Exit mobile version