Ein Deployment besteht jeden Health Check, und trotzdem steigt die p99-Latenz zwischen zwei Regionen, ohne dass jemand sagen kann, warum. Die Logs zeigen Timeouts, die Cloud-Konsole zeigt Grün. Das Netz zwischen Ihren Diensten, ob VPC-Peering, Transit Gateway oder das öffentliche Internet zwischen einem CDN-Edge und Ihrem Origin, ist der Teil, der Ihnen nicht gehört und den kein Dashboard abbildet. Ein Traceroute legt ihn Hop für Hop offen: welcher Router, welches Netz, und wo die Verzögerung beginnt.
Ein visuelles Traceroute macht aus dieser Liste von Hops etwas, das ein Team während eines Incidents lesen kann: jeder Hop auf einer Karte, mit Latenz, Jitter, Paketverlust und dem ASN, dem er gehört. Von mehreren Quellen gestartet, zeigt es, ob Nutzer in Frankfurt und Nutzer in São Paulo denselben Edge erreichen, ob DNS sie in die richtige Region schickt und ob sich der Pfad nach Ihrem letzten Release geändert hat. Exportieren Sie es, hängen Sie es ans Ticket, und die Debatte, ob das Netz schuld ist, endet dort.
Ein Deployment von dort prüfen, wo Ihre Nutzer sind
Prüfen Sie ein Deployment in einer neuen Region nicht nur vom CI-Runner aus. Tracen Sie den neuen Endpunkt von Falkenstein, Gravelines und einer Globalping-Sonde in der Nähe Ihrer Nutzer. Zuerst DNS: Löst der Name auf die Adresse auf, die Sie in dieser Region erwarten, oder schickt Anycast oder GeoDNS den Verkehr woandershin? Dann der Pfad: Wie viele ASNs liegen zwischen der Sonde und dem Netz Ihres Providers, und was kostet der letzte Hop? Ein Pfad, der in der falschen Region endet, oder ein erster Hop beim Provider, der 40 ms weiter entfernt ist als erwartet, ist ein Routing- oder DNS-Problem, kein Anwendungsfehler. Endet der Trace in Sternchen, wiederholen Sie ihn per TCP auf Port 443: Viele Load Balancer filtern ICMP, antworten aber auf dem Port, den sie bedienen.
Ein echtes Problem von einem Router unterscheiden, der Sie ignoriert
Router drosseln die ICMP-Antworten, von denen Traceroute lebt. Ein Zwischen-Hop mit 50 % Verlust, während das Ziel 0 % zeigt, ist kosmetisch: Der Router leitet Ihre Pakete weiter und drosselt nur seine eigenen Antworten. Echter Verlust beginnt an einem Hop und bleibt bis zum Ziel bestehen. Bei Latenz gilt dasselbe: Ein Hop mit 200 ms, gefolgt von Hops mit 20 ms, ist eine langsame Control Plane, kein langsamer Pfad. Wichtiger als der Mittelwert ist der Jitter: Eine Strecke mit 30 ms im Schnitt und 25 ms Jitter schadet einem gRPC-Aufruf mit knappem Timeout mehr als stabile 60 ms. Behalten Sie die ASN-Spalte im Blick: Springt die Verzögerung genau dort, wo das ASN wechselt, liegt das Problem an der Übergabe zwischen zwei Netzen, und das können Sie mit Belegen eskalieren.
Das Netz überwachen wie alles andere auch
Eine Route, die sich ändert, ist ein Frühindikator: ein Transitanbieter im Failover, ein CDN, das Sie auf einen anderen Point of Presence verschiebt, eine BGP-Änderung weiter oben. Planen Sie einen Trace zu jedem kritischen Endpunkt, etwa Ihrem Origin, einem Datenbank-Endpunkt in einer anderen Region oder einer Drittanbieter-API, und legen Sie Alarme für Latenz, Paketverlust und Routenänderung an. Löst ein Alarm aus, öffnen Sie den vorherigen und den neuen Trace nebeneinander und sehen, ob eine Verschlechterung um 80 ms von Ihrem eigenen Release stammt oder von einem neuen Transitpfad. Über die API starten Sie einen Trace als Schritt nach dem Deployment und vergleichen Ziel und Latenz des letzten Hops mit Ihren eigenen Schwellenwerten. Exportieren Sie CSV oder JSON für Ihre Incident-Werkzeuge, PDF für das Postmortem.
Einen Trace lesen: ein regionsübergreifender Aufruf wird langsam
Ein Lehrbeispiel, keine echte Kundenmessung. Ein Dienst in Frankfurt ruft eine API in Virginia auf. Hop 1 bis 5 bleiben im Netz des Cloud-Providers bei 1 bis 3 ms. Bei Hop 6 wechselt das ASN zu einem Transitanbieter, die Latenz liegt bei 12 ms; Hop 7 zeigt 95 ms, und jeder weitere Hop bleibt nahe 95 ms, ohne Verlust. Weil der Sprung bis zum Ende bestehen bleibt, ist er echt, und 90 ms sind schlicht die Atlantiküberquerung. Ein zweiter Trace von einer Globalping-Sonde in New York erreicht das Ziel in 8 ms: Die API ist gesund; der Dienst in Frankfurt ruft die falsche Region auf. Leiten Sie den Aufruf an die europäische Replik oder planen Sie die Latenz ein. Wären die Hops nach 7 wieder auf 12 ms gefallen, wäre der Ausreißer Router-Rauschen gewesen, kein Pfadproblem.
Werkzeuge, die das Bild vervollständigen
Ping über eine Minute liefert Jitter und Verlust ohne Hop-Details, ein schneller Weg, eine Verschlechterung zu bestätigen, bevor Sie tracen. DNS Lookup zeigt, welche Adresse jeder Resolver zurückgibt, das Erste, was Sie prüfen, wenn eine Region zu verschwinden scheint. HTTP/SSL Check folgt Weiterleitungen und liest das Zertifikat wie ein Client, inklusive abgelaufener oder falsch benannter Zertifikate, die ein Health Check übersehen kann. Port Check bestätigt eine Firewall-Regel von außen. BGP Viewer sagt Ihnen, welches ASN das Präfix ankündigt, in dem Ihr Verkehr endet.
Häufige Fragen
- Kann ich ein Traceroute aus einer CI-Pipeline heraus starten?
- Ja, über die API, die in den Tarifen Pro und Business enthalten ist. Rufen Sie sie nach einem Deployment auf, um den neuen Endpunkt von der Quelle Ihrer Wahl aus zu tracen, und vergleichen Sie die zurückgegebenen Hops, Latenzen und die Zieladresse in Ihrem eigenen Skript mit dem, was Sie erwarten. Das Ergebnis ist dasselbe JSON, das Sie auch in der Oberfläche herunterladen können, und lässt sich sauber an einen Deployment-Bericht oder einen Incident anhängen.
- Mein Trace endet vor dem Load Balancer in Sternchen. Ist der Dienst down?
- Nicht unbedingt. Viele Load Balancer und Cloud-Edges verwerfen ICMP und ignorieren UDP-Sonden, sodass der Trace verstummt, obwohl HTTPS funktioniert. Wiederholen Sie ihn im TCP-Modus auf dem Port, den Sie tatsächlich bedienen, und bestätigen Sie das Ergebnis mit HTTP/SSL Check. Erreicht der TCP-Trace das Ziel und antwortet der HTTP-Check, ist der Dienst in Ordnung, und die Sternchen sind Filterung, kein Ausfall.
- Woher weiß ich, ob ein Latenzproblem bei mir oder bei meinem Provider liegt?
- Schauen Sie, wo die Verzögerung zuerst auftritt und ob sie bestehen bleibt. Beginnt sie im ASN Ihres Providers und hält bis zum Ziel an, liegt das Problem in dessen Netz oder an dessen Peering. Taucht sie genau dort auf, wo das ASN wechselt, handelt es sich um eine Übergabe zwischen zwei Betreibern. Starten Sie denselben Trace von einer zweiten Quelle: Zwei Quellen, die sich auf denselben Hop einigen, sind ein starker Beleg für Ihr Ticket.