Cloudflare-Ausfälle, regionale CDN-Ausfälle und Beeinträchtigungen auf Edge-Ebene werden nicht immer auf den Statusseiten angezeigt. Wenn der Tokio-POP Ihres CDN sinkt, der globale Status jedoch grün angezeigt wird, wird Ihre Überwachung aus Virginia dies nicht erkennen.
Die Erkennung regionaler Ausfälle erfordert eine Überwachung dort, wo sich Ihre Benutzer tatsächlich befinden – und nicht nur dort, wo sich Ihre Infrastruktur befindet.
Es ist 3 Uhr morgens. Ihr Bereitschaftstechniker wird vom Kundenerfolg gepingt: „Drei Unternehmenskunden in Singapur haben gemeldet, dass sie nicht auf die App zugreifen können. Vor etwa zwei Stunden gestartet.“
Sie überprüfen Ihr Überwachungs-Dashboard – alles ist grün. Statusseite von Cloudflare – betriebsbereit. AWS – keine Vorfälle. Ihr APM – fröhliche kleine Diagramme. Sie bitten die Kunden also, es noch einmal zu versuchen, ihren Cache zu leeren und ihr Netzwerk zu überprüfen.
Aber es passiert immer wieder. Weitere Tickets aus der gleichen Region. Schließlich führt jemand eine Traceroute von einem VPS in Singapur aus und stellt fest: Der Datenverkehr trifft auf einen Cloudflare-Edge, der 502-Fehler zurückgibt. Im CDN liegt ein regionaler Ausfall vor, der einen PoP betrifft – und nichts in Ihrem Überwachungsstapel überprüft diese Region.
Zwei Stunden Ausfallzeit. Für eine bestimmte Geographie. Keine Warnungen. Das ist der blinde Fleck, um den es auf dieser Seite geht.
Ob es sich um einen Cloudflare-Ausfall, einen Fastly-Edge-Ausfall oder eine regionale Verschlechterung bei Akamai handelt – um diese Probleme zu erkennen, ist eine Überwachung durch die betroffenen Regionen erforderlich. So erkennen Sie Probleme, bevor sie zu Kundeneskalationen führen.
Das Internet ist kein einzelnes Netzwerk. Eine Anfrage aus Sydney durchläuft eine völlig andere Infrastruktur als eine Anfrage aus Frankfurt. Wenn ein Teil dieses regionalen Pfads ausfällt, sind nur Benutzer in dieser Region betroffen.
CDNs wie Cloudflare, Fastly und Akamai betreiben weltweit Hunderte von Points of Presence (PoPs). Wenn bei einem bestimmten Edge-Server oder PoP Probleme auftreten – Hardwarefehler, Fehlkonfiguration oder Kapazitätsprobleme – sind nur Benutzer betroffen, die an diesen Edge weitergeleitet werden. Der globale Status des CDN bleibt „betriebsbereit“, da 95 % der Kanten in Ordnung sind.
Beispiel: Im Juni 2022 kam es bei Cloudflare aufgrund einer Änderung der Netzwerkkonfiguration zu einem 30-minütigen Ausfall, der 19 Rechenzentren betraf. Benutzer in diesen Regionen sahen Fehler; Benutzer anderswo erlebten nichts Ungewöhnliches.
DNS ist der erste Schritt bei jeder Anfrage. Wenn Cloudflare 1.1.1.1 oder die DNS-Server Ihres CDN in einer bestimmten Region Probleme haben – eine falsch konfigurierte Anycast-Route, ein überlasteter Nameserver – können Benutzer in dieser Region Ihre Domain nicht auflösen. Ihr Browser zeigt nur „DNS_PROBE_FINISHED_NXDOMAIN“ an.
Beispiel: Regionale DNS-Probleme können durch Filterung auf ISP-Ebene, lokale Resolver-Probleme oder Anycast-Routing-Probleme verursacht werden, die nur bestimmte geografische Gebiete betreffen.
BGP-Routenlecks, Hijacks und Fehlkonfigurationen können den Datenverkehr über suboptimale Pfade umleiten oder ihn vollständig blockieren. Wenn ein großer Netzbetreiber in einer Region Routing-Probleme hat, kann der Datenverkehr von dieser Region zu Ihrem CDN oder Ursprung ausfallen – auch wenn beide Endpunkte einwandfrei funktionieren.
Beispiel: BGP-Vorfälle betreffen regelmäßig Tausende von Netzwerken. Ein einzelner falsch konfigurierter AS-Pfad kann dazu führen, dass Ihre Site aus ganzen Ländern stundenlang nicht erreichbar ist, während sie von Ihrem Überwachungsstandort aus einwandfrei erscheint.
Große ISPs in bestimmten Ländern haben möglicherweise aufgrund von Peering-Streitigkeiten, Überlastungen oder Infrastrukturproblemen eine eingeschränkte Konnektivität zu Ihrem CDN. Bei Benutzern von Telstra in Australien kann es zu Ausfällen kommen, während Benutzer von Optus in derselben Stadt keine Probleme haben – da der Datenverkehr über unterschiedliche Wege fließt.
Beispiel: Peering-Streitigkeiten zwischen ISPs und Cloud-Anbietern haben in der Vergangenheit zu mehrwöchigen Beeinträchtigungen geführt, von denen Millionen von Benutzern in bestimmten Märkten betroffen waren.
Der rote Faden: Alle diese Fehler sind geografisch. Dein Ursprung ist oben. Ihre CDN-Konfiguration ist korrekt. Aber irgendwo zwischen Ihrem Edge und Benutzern in einer bestimmten Region ist etwas kaputt gegangen – und Ihre Überwachung, die von einem Standort in Virginia aus prüft, hat keine Möglichkeit, dies zu erkennen.
Die meisten Uptime-Überwachungen wurden für ein einfacheres Problem entwickelt: „Reagiert der Server?“ Für CDN-beschleunigte Websites, die globale Benutzer bedienen, ist das nicht mehr die richtige Frage.
Die meisten Überwachungsdienste überprüfen standardmäßig von einer Handvoll US- oder EU-Standorten aus. Wenn der Singapur-PoP von Cloudflare ausfällt, wird Ihr Scheck aus Oregon immer noch erfolgreich sein – er erreicht eine andere, gesunde Kante. In der Zwischenzeit sehen Ihre APAC-Benutzer 502-Fehler.
Die Ausführung von Prüfungen von AWS zu Cloudflare nutzt Cloud-Backbone-Konnektivität – optimierte Pfade, die keinen echten Benutzerverkehr darstellen. Ihre synthetische Prüfung von AWS ap-southeast-1 umgeht möglicherweise genau den Netzwerkpfad, der für Benutzer lokaler ISPs fehlschlägt.
CDN-Statusseiten spiegeln ihre interne Sicht wider, oft aggregiert über Hunderte von PoPs. Ein regionales Problem, das 5 % ihrer Infrastruktur betrifft, löst möglicherweise keine Aktualisierung der Statusseite aus – diese 5 % könnten jedoch ganz Südostasien umfassen.
Mithilfe von HTTP-Prüfungen erfahren Sie, ob eine Anfrage erfolgreich war oder fehlgeschlagen ist, aber nicht, wo sie fehlgeschlagen ist. Ohne Traceroute- und Latenzaufschlüsselungsdaten aus der betroffenen Region können Sie nicht feststellen, ob das Problem DNS, ein bestimmter Netzwerk-Hop oder Ihr CDN-Edge ist.
Cloudflare verfügt über mehr als 310 PoPs. Wenn Ihre Überwachung von drei Standorten aus prüft, verifizieren Sie weniger als 1 % der Kanten, auf die Ihre Benutzer möglicherweise stoßen. Das ist keine Ausfallerkennung – das ist das Hoffen auf das Beste.
Jede Minute, in der ein Cloudflare-Ausfall oder ein regionaler CDN-Ausfall unentdeckt bleibt, verlieren Sie Benutzer, Umsatz und Vertrauen in Märkte, von denen Sie vielleicht gar nicht wissen, dass Sie sie bedienen.
Ein regionaler Ausfall während der Geschäftszeiten in dieser Zeitzone kann stundenlange Transaktionen, Anmeldungen oder API-Aufrufe kosten. Benutzer senden keine E-Mails mit der Aufschrift „Ihre Website ist für mich nicht verfügbar“ – sie verlassen sie einfach. Später werden Sie einen Rückgang der regionalen Messwerte feststellen, ohne dass eine eindeutige Ursache dafür vorliegt.
Unternehmenskunden haben SLAs. Wenn sie nicht auf Ihre Plattform zugreifen können und Sie nicht einmal wussten, dass ein Problem vorliegt, ist das ein schlechtes Gespräch. „Wir haben den Ausfall nicht festgestellt“ ist keine vertrauensbildende Antwort – insbesondere, wenn sie für Zuverlässigkeit bezahlen.
Der Googlebot crawlt von mehreren globalen Standorten aus. Wenn Ihr CDN-Edge in einer Region Fehler oder langsame Antworten zurückgibt, wirkt sich das auf das Crawling-Budget, die Core Web Vitals-Bewertungen und letztendlich auf die Rankings aus. In bestimmten Märkten kann es ohne ersichtlichen Grund zu einem Traffic-Rückgang kommen.
Die mittlere Wiederherstellungszeit (MTTR) beginnt, wenn Sie das Problem erkennen. Wenn Benutzer zwei Stunden lang von einem regionalen Cloudflare-Ausfall betroffen sind, bevor Sie aus einem Kundenticket davon erfahren, werden Ihrer effektiven MTTR zwei Stunden hinzugefügt. Nur durch eine proaktive Erkennung können die tatsächlichen Auswirkungen von Ausfallzeiten minimiert werden.
Die Erkennung regionaler Ausfälle erfordert eine Überwachung von dort aus, wo sich Ihre Benutzer befinden, mit einer Diagnosetiefe, um festzustellen, wo Ausfälle auftreten.
Jeder Überwachungsstandort trifft auf unterschiedliche CDN-Edges und durchläuft unterschiedliche Netzwerkpfade. Um regionale Ausfälle zu erkennen, benötigen Sie Knoten in jeder Region, in der es nennenswerten Datenverkehr gibt – Asien-Pazifik, Europa, Amerika, Naher Osten, Afrika. Nicht nur „international“, sondern insbesondere dort, wo sich Ihre Benutzer befinden.
Die Überwachung von mehr als 50 Standorten deckt die wichtigsten CDN-PoPs und ISP-Pfade ab.
Wenn eine Prüfung in Singapur fehlschlägt, überall sonst jedoch erfolgreich ist, müssen Sie wissen: Liegt es am DNS? Ein bestimmter Netzwerk-Hop? Der CDN-Rand? Traceroute und MTR vom betroffenen Standort liefern die Beweise, die Sie benötigen, um die Grundursache zu diagnostizieren und an Cloudflare, Ihren ISP oder Ihren Hosting-Anbieter zu eskalieren.
Diagnosedaten machen aus „etwas ist kaputt“ eine umsetzbare Grundursache.
Sind 400 ms von Tokio aus normal oder handelt es sich dabei um eine Cloudflare-Edge-Verschlechterung? Historische Daten pro Standort bilden Basislinien, mit denen Sie langsame Ausfälle erkennen können – Latenzerhöhungen, die keine schwerwiegenden Ausfälle auslösen, aber die Benutzererfahrung beeinträchtigen. Sie können ein regionales CDN-Problem erkennen, bevor es zu einem vollständigen Ausfall kommt.
Baselines erkennen Beeinträchtigungen, bevor sie zu Ausfällen führen.
Eine Schritt-für-Schritt-Anleitung zur Implementierung einer Überwachung, die Cloudflare-Ausfälle und regionale CDN-Ausfälle erkennt, bevor Ihre Benutzer sie melden.
Überprüfen Sie Ihre Analysen, um herauszufinden, wo sich Ihre Benutzer befinden. Wenn 20 % des Datenverkehrs aus dem asiatisch-pazifischen Raum kommen, benötigen Sie dort mehrere Überwachungsknoten – Singapur, Tokio, Sydney, Mumbai. Passen Sie die Überwachungsabdeckung an die tatsächliche Benutzerverteilung an.
Richten Sie HTTP-Monitore für Ihre primären URLs ein, die über Cloudflare oder Ihr CDN laufen. Diese sollten den CDN-Rand erreichen, nicht direkt Ihren Ursprung. Beziehen Sie Ihre App-Domäne, API-Endpunkte und alle wichtigen öffentlichen Seiten ein.
Verschiedene Regionen haben unterschiedliche Grundlatenzen. Konfigurieren Sie sinnvolle Schwellenwerte: Vielleicht sind 500 ms von Europa aus akzeptabel, aber 500 ms von Ost-USA (wenn Ihr Ursprung dort liegt) weisen auf ein CDN-Edge-Problem hin. Nutzen Sie historische Daten, um realistische Ausgangswerte festzulegen.
Richten Sie Warnungen ein, die ausgelöst werden, wenn bestimmte Regionen ausfallen – und nicht nur, wenn alle Standorte ausfallen. Ein Ausfall nur in Singapur ist immer noch ein wissenswerter Ausfall. Leiten Sie Warnungen mit hoher Priorität an Slack, PagerDuty oder Ihr Vorfallmanagementsystem weiter.
Wenn eine Warnung ausgelöst wird, müssen Sie schnell feststellen: Liegt das Problem bei Cloudflare? Ein Netzwerkpfadproblem? DNS? Aktivieren Sie On-Demand-Traceroute und MTR von Überwachungsstandorten aus, damit Sie Diagnosedaten sofort erfassen können.
Dokumentieren Sie den Prozess: So überprüfen Sie einen regionalen Cloudflare-Ausfall. Wo Sie die Status-API von Cloudflare überprüfen können. So öffnen Sie ein Ticket mit Beweisen. Welche Gegenmaßnahmen können Sie anwenden (Failover, Cache-Umgehung usw.). Wenn Sie dies bereit haben, wird die MTTR erheblich reduziert.
Richten Sie eine wöchentliche Kalendererinnerung ein, um Latenz und Betriebszeit pro Region zu überprüfen. Suchen Sie nach Mustern: Ist APAC durchweg langsamer? Gibt es an einem bestimmten Ort regelmäßig Ausreißer? Eine proaktive Überprüfung erkennt langsame Verschlechterungen, bevor sie sich erheblich auf die Benutzer auswirken.
Für Dienste, bei denen regionale Ausfälle nicht akzeptabel sind, sollten Sie eine Multi-CDN-Strategie in Betracht ziehen, bei der ein DNS-Failover zwischen Anbietern möglich ist. Dies erfordert die unabhängige Überwachung jedes CDN und eine Automatisierung, die den Datenverkehr umschalten kann. Es ist Komplexität, aber auch Widerstandsfähigkeit.
Latency Global wurde entwickelt, um genau diese Art von Problemen zu erkennen – Cloudflare-Ausfälle, regionale CDN-Ausfälle und Netzwerkprobleme, die bei der Überwachung einzelner Standorte übersehen werden. Wir überwachen über 70 reale Standorte auf 6 Kontinenten und decken alle wichtigen CDN-PoP-Regionen ab.
Jede Prüfung umfasst eine vollständige Aufschlüsselung des Timings – DNS-Auflösung, TCP-Verbindung, TLS-Handshake, TTFB und Gesamtantwortzeit. Wenn in einer bestimmten Region ein Fehler auftritt, können Sie Traceroute und MTR von diesem Standort aus ausführen, um genau zu ermitteln, wo im Netzwerkpfad das Problem aufgetreten ist. Die Preisgestaltung ist unkompliziert: 5 $/Monat für 5 Monitore, alle Standorte inbegriffen.
Die Erkennung regionaler Ausfälle erfordert an vielen Standorten Infrastruktur – deshalb bieten die meisten Überwachungstools diese entweder nicht an oder verlangen Unternehmenspreise. Wir konzentrieren uns auf das Wesentliche: Abdeckung und diagnostische Tiefe.
Ein regionaler CDN-Ausfall tritt auf, wenn bestimmte Edge-Server oder Points of Presence (PoPs) in einem CDN-Netzwerk ausfallen oder sich verschlechtern, während andere Edges betriebsbereit bleiben. Beispielsweise könnte Cloudflare Probleme mit seinem PoP in Singapur haben, während seine US- und europäischen Edges einwandfrei funktionieren. Bei Benutzern, die über die betroffene Kante weiterleiten, treten Fehler oder eine langsame Leistung auf. Benutzer anderswo bemerken nichts. Diese Ausfälle sind für die Überwachung unsichtbar, die nur in nicht betroffenen Regionen prüft.
CDN-Statusseiten zeigen normalerweise den aggregierten globalen Status an, nicht den Zustand pro PoP. Wenn 5 % der Kanten betroffen sind, bleibt der Gesamtstatus möglicherweise „Betriebsbereit“, da 95 % der Infrastruktur funktioniert. Auch Statusseiten weisen eine Aktualisierungslatenz auf – es dauert einige Zeit, bis Probleme erkannt, überprüft und veröffentlicht werden. Darüber hinaus erfüllen einige Probleme nicht die Schwelle für eine öffentliche Offenlegung, wirken sich aber dennoch auf Ihre Benutzer aus. Die unabhängige Überwachung von mehreren Standorten aus ist die einzige Möglichkeit, fundierte Informationen über die regionale Verfügbarkeit zu erhalten.
Sie benötigen mindestens Überwachungsstandorte in allen wichtigen Regionen, in denen Sie Benutzer haben: mindestens Nordamerika, Europa und den asiatisch-pazifischen Raum. Für eine bessere Abdeckung decken mehr als 50 weltweit verteilte Standorte die meisten regionalen Probleme ab. Der Schlüssel liegt darin, die Überwachungsabdeckung an die Geografie Ihrer Benutzer anzupassen. Wenn sich 30 % Ihrer Benutzer im APAC-Raum befinden, benötigen Sie dort mehrere Knoten (Singapur, Tokio, Sydney, Mumbai). Es geht nicht darum, jeden CDN-PoP abzugleichen, sondern die wichtigsten regionalen Gruppierungen abzudecken.
Sammeln Sie zunächst diagnostische Beweise: Traceroute und MTR vom betroffenen Standort, HTTP-Antwortcodes und Zeitdaten sowie Zeitstempel. Überprüfen Sie die Statusseite von Cloudflare und Twitter auf etwaige Bestätigungen. Wenn es sich eindeutig um ein Cloudflare-Problem handelt, eröffnen Sie ein Support-Ticket mit Ihren Beweisen. Zur sofortigen Abhilfe können Sie Folgendes in Betracht ziehen: vorübergehendes Umgehen von Cloudflare für die betroffene Region (sofern Ihr Ursprung es verarbeiten kann), Aktivieren eines Backup-CDN, wenn Sie über Multi-CDN-Fähigkeit verfügen, oder Aktualisieren Ihrer Statusseite, um das Problem zu bestätigen, während Cloudflare es behebt. Dokumentieren Sie alles zur Überprüfung nach dem Vorfall.
Ja, mit geeigneten Überwachungsinstrumenten. Das vollständige Timing der HTTP-Überprüfung zeigt: DNS-Auflösungszeit (wenn DNS ausfällt oder langsam ist, wissen Sie, dass es sich um ein DNS-Problem handelt), TCP-Verbindungszeit (Netzwerkpfadprobleme), TLS-Handshake-Zeit (Zertifikat- oder Kryptoprobleme) und TTFB/Antwortzeit (Ursprungs- oder Edge-Verarbeitungsprobleme). Traceroute zeigt den Netzwerkpfad und an, wo Pakete verworfen oder verzögert werden. Durch den Vergleich dieser Daten aus der betroffenen Region mit fehlerfreien Regionen können Sie genau identifizieren, wo in der Anforderungskette der Fehler auftritt.
Mit Prüfintervallen von 1 Minute können Sie einen Ausfall bereits 1–2 Minuten nach Beginn erkennen. Die meisten Überwachungsdienste bestätigen einen Ausfall nach zwei bis drei aufeinanderfolgenden Ausfällen, um eine Warnung bei vorübergehenden Ausfällen zu vermeiden. Eine realistische Erkennungszeit liegt also bei 2 bis 5 Minuten. Vergleichen Sie dies mit den von Kunden gemeldeten Ausfällen, bei denen es Stunden dauern kann, bis sie durch Support-Tickets ans Licht kommen. Der Unterschied in der MTTR ist erheblich – 5 Minuten gegenüber 2 Stunden bedeuten sehr unterschiedliche Auswirkungen auf den Benutzer.
Absolut. Bei Fastly, Akamai, AWS CloudFront, Google Cloud CDN, Azure CDN und jedem anderen CDN kann es zu regionalen Ausfällen kommen. Es gelten die gleichen Prinzipien: CDNs verfügen über eine verteilte Infrastruktur und jedes verteilte System kann Teilausfälle haben. Der Erkennungsansatz ist derselbe: Überwachen Sie von mehreren globalen Standorten aus, um Probleme zu erkennen, die bestimmte Kanten oder Regionen betreffen, unabhängig davon, welches CDN Sie verwenden.
Verlassen Sie sich nicht mehr auf CDN-Statusseiten und Kundentickets, um sich über regionale Ausfälle zu informieren. Fügen Sie Ihre Endpunkte hinzu, wählen Sie Ihre Überwachungsstandorte aus und erfahren Sie innerhalb von Minuten, wann Cloudflare, Fastly oder ein Teil Ihres Stacks in einer Region ausfällt.
$5/month • 70+ Standorte (+40 weitere bald) • Keine Verträge • Jederzeit kündbar