Paketverlust und Latenz über Regionen hinweg überwachen Sie, indem Sie dieselben Prüfungen gegen dieselben Ziele von mehreren Standorten aus ausführen, die der Verteilung Ihrer Nutzer entsprechen, und jede Region mit ihrer eigenen Baseline vergleichen statt mit einem einzigen globalen Wert. Beobachten Sie Perzentile und Jitter statt Durchschnittswerte, senden Sie pro Check genügend Pakete, um Verlust aussagekräftig zu messen, und alarmieren Sie erst, wenn ein Muster über mehrere Messpunkte hinweg auftritt oder über die Zeit anhält.
Messregionen passend zu Ihren Nutzern wählen
Beginnen Sie mit Traffic-Daten, nicht mit einer Landkarte. Stammen die meisten Sitzungen aus Westeuropa, von der US-Ostküste und aus Südostasien, sind das Ihre primären Messregionen; ergänzen Sie sekundäre Regionen dort, wo vertragliche SLAs gelten. Setzen Sie mindestens zwei Messpunkte pro wichtigem Markt ein, damit ein lokales Problem eines einzelnen Messpunkts nie wie ein regionaler Ausfall aussieht.
Bedenken Sie, dass Messpunkte in Rechenzentren sauberere Pfade sehen als private oder mobile Anschlüsse. Betrachten Sie deren Werte daher als Best-Case-Sicht.
Regionale Baselines auf physikalischer Grundlage
Licht legt in Glasfaser etwa 200 km pro Millisekunde zurück, sodass jede 100 km Kabelweg rund 1 ms Round-Trip-Time hinzufügen, noch bevor Warteschlangen ins Spiel kommen. Reale Routen sind länger als die Luftlinie, daher sehen typische Bereiche so aus:
| Pfad | Typische RTT |
|---|---|
| Gleiche Metropolregion oder Cloud-Region | 1–5 ms |
| Innerhalb Westeuropas | 10–30 ms |
| US-Ost nach US-West | 60–75 ms |
| US-Ost nach Westeuropa | 75–95 ms |
| Westeuropa nach Singapur | 150–190 ms |
| Westeuropa nach Sydney | 250–300 ms |
Ein Messwert von 180 ms von Singapur zu einem Server in Frankfurt ist normal; derselbe Wert aus Amsterdam ist ein Incident. Bauen Sie Baselines aus mindestens einer Woche Daten pro Region auf und alarmieren Sie bei Abweichungen, etwa wenn p95 um 30–50 Prozent über den Sieben-Tage-Normalwert steigt.
Verlust und Latenz statistisch sauber messen
Ein Check mit drei Pings kann nur 0, 33, 67 oder 100 Prozent Verlust melden. Das ist zu grob, um die 1–2 Prozent Verlust zu erkennen, die den TCP-Durchsatz bereits spürbar beeinträchtigen. Bewährte Praxis:
- Senden Sie 10–20 Pakete pro Check oder fassen Sie mehrere Checks in einem gleitenden Fünf-Minuten-Fenster zusammen, bevor Sie den Verlust berechnen.
- Berichten Sie p50 für die typische Erfahrung und p95 für die Ausreißer, über die sich Nutzer beschweren. Durchschnittswerte verschleiern Spitzen.
- Erfassen Sie Jitter, also die Schwankung zwischen aufeinanderfolgenden RTT-Messungen. Jitter über etwa 20–30 ms beeinträchtigt Echtzeit-Traffic, selbst wenn die Latenz unauffällig wirkt.
- Kombinieren Sie ICMP mit TCP-Checks auf dem Dienst-Port, da manche Router ICMP drosseln und Verlust anzeigen, den der Anwendungstraffic nie erlebt.
Das Ping-Monitoring von UpScanX unterstützt ICMP-, TCP- und UDP-Checks von über 15 globalen Standorten, sodass Sie identische Prüfungen pro Region ausführen und direkt vergleichen können.
Regionen vergleichen, um die Ursache einzugrenzen
Der regionsübergreifende Vergleich ist der schnellste Weg, ein Problem zu lokalisieren:
- Alle Regionen verschlechtern sich gleichzeitig: Das Problem liegt wahrscheinlich am Origin oder bei dessen Upstream-Provider.
- Eine Region verschlechtert sich, die anderen sind stabil: Verdächtig sind ein Transit-Provider, ein Peering-Punkt oder ein regionaler ISP auf diesem Pfad.
- Nur CDN-Endpunkte verschlechtern sich in einer Region: Prüfen Sie den Edge-Standort, der diese Region bedient, statt Ihres Origins.
- Verlust tritt nur bei ICMP auf: Wahrscheinlich Rate-Limiting auf einem Zwischenrouter, keine echte Beeinträchtigung der Nutzer.
Verschlechtert sich eine Region, führen Sie von diesem Messpunkt aus ein Traceroute oder MTR aus und vergleichen Sie es mit der Route einer gesunden Region. Suchen Sie die Stelle, an der die Latenz springt und über alle folgenden Hops hoch bleibt; eine Spitze an einem einzelnen mittleren Hop, die danach verschwindet, bedeutet meist nur, dass ein Router Antworten niedriger priorisiert. Hängen Sie die Traces an den Incident an, damit Sie einem Provider zeigen können, wo der Pfad gebrochen ist.
Per Quorum alarmieren, pro Region berichten
Alarme auf Basis eines einzelnen Messpunkts erzeugen Rauschen. Alarmieren Sie, wenn mindestens zwei Messpunkte in einer Region oder eine Mehrheit der Regionen den Schwellenwert bei zwei oder drei aufeinanderfolgenden Checks überschreiten. Nutzen Sie eine Warnung für einen betroffenen Markt und einen kritischen Alarm, wenn mehrere Regionen übereinstimmen, zugestellt über Slack, Microsoft Teams, E-Mail, Telegram oder einen Webhook.
Veröffentlichen Sie im Reporting p95-Latenz, Verlust und Jitter pro Region neben der Verfügbarkeit. Die KI-Berichte von UpScanX erkennen Anomalien, korrelieren zusammenhängende Alarme und liefern geplante Zusammenfassungen per E-Mail. Mehr zu RTT und dem Design von Schwellenwerten finden Sie in unserem Leitfaden zum Netzwerk-Latenz-Monitoring.
Wichtigste Erkenntnisse
- Platzieren Sie Messpunkte dort, wo Ihre Nutzer sind, mit mindestens zwei pro wichtigem Markt.
- Erstellen Sie für jede Region eine eigene Baseline; die Entfernung setzt der Latenz eine physikalische Untergrenze.
- Senden Sie genügend Pakete pro Check und beobachten Sie p95 und Jitter statt Durchschnittswerte.
- Vergleichen Sie Regionen und verfolgen Sie Routen, um Probleme bei Origin, ISP und CDN voneinander zu trennen.
- Alarmieren Sie nach Quorum und Dauer, und berichten Sie Kennzahlen pro Region.