Sie richten synthetische Prüfungen von acht Standorten ein. Soll jeder Standort bei jedem Zyklus getestet werden oder nacheinander in Rotation? Diese eine Einstellung entscheidet, wie schnell Sie einen regionalen Ausfall erkennen und wie viele Prüfungen Sie dabei verbrauchen.
Die meisten Überwachungsplattformen wählen eine Standardeinstellung und verbergen die Auswahl. Dotcom-Monitor macht sie sichtbar, und die beiden Optionen verhalten sich so unterschiedlich, dass die falsche Wahl entweder mit redundanten Prüfungen überflutet oder einen regionalen Ausfall eine komplette Rotation lang unbemerkt lassen kann. Hier erfahren Sie, wie Round-Robin- und Concurrent-Monitoring tatsächlich funktionieren, wo sie sich unterscheiden und wie man wählt.
Zuerst eine Klarstellung: Dies ist kein Round-Robin-Load-Balancing. Load-Balancer verwenden Round-Robin, um eingehenden Benutzer-Traffic auf Backend-Server zu verteilen. Hier beschreibt Round-Robin, wie eine Überwachungsplattform ihre ausgehenden Prüfungen über geografische Standorte plant. Gleicher Name, entgegengesetzter Verkehrsfluss.
Was Round-Robin- und Concurrent-Monitoring bedeuten
Zwei Begriffe erleichtern das Verständnis. Eine Überwachungssitzung ist eine einzelne Prüfung von einem Standort. Ein Überwachungszyklus ist ein kompletter Durchlauf über alle ausgewählten Standorte.
Round-Robin und Concurrent beschreiben, wie Sitzungen über einen Zyklus verteilt werden. Round-Robin führt pro Zyklus eine Prüfung an einem Standort aus und rotiert beim nächsten Zyklus zum nächsten Standort. Concurrent führt bei jedem Zyklus Prüfungen an allen Standorten durch. Die Unterschiede zwischen diesen beiden Mustern entscheiden über Erkennungsgeschwindigkeit, Kosten und Datenqualität.
Wie Round-Robin-Monitoring funktioniert
Round-Robin ist der Standard und wurde ökonomisch gestaltet. In der eingestellten Frequenz startet die Plattform eine Sitzung an einem Standort, im nächsten Intervall am nächsten Standort und durchläuft Ihre Liste. Solange alle Prüfungen bestätigen, dass die Site erreichbar ist, erhalten Sie eine breite geografische Abdeckung, ohne alle acht Standorte gleichzeitig testen zu müssen.
Der clevere Teil ist, was bei Uneinigkeit passiert. Sobald ein Standort einen anderen Status meldet als der Rest, z.B. einen Fehler während die anderen erfolgreich sind, stoppt Round-Robin die Rotation und führt Prüfungen von allen Standorten durch. Dasselbe geschieht nach dem Erstellen, Bearbeiten oder Neustarten eines Geräts, wenn noch keine vertrauenswürdige Basislinie vorhanden ist.
Round-Robin ignoriert also keine regionalen Probleme. Es ist adaptiv. Es bleibt kostengünstig, solange alles gesund erscheint und eskaliert zu voller Abdeckung, sobald etwas auffällig wird. Die Kosten dieses Sparens ist die Zeit, die in den nächsten Abschnitten näher erläutert wird.
Wie Concurrent-Monitoring funktioniert
Concurrent-Monitoring verzichtet auf die Rotation. Jeder ausgewählte Standort führt seine Prüfung bei jedem Zyklus aus, unabhängig vom vorherigen Zyklus. Acht Standorte bei einminütiger Frequenz bedeuten acht Prüfungen pro Minute, jede Minute.
Das gibt Ihnen bei jedem Intervall eine vollständige geografische Momentaufnahme. Wenn Ihr CDN-Edge in Frankfurt langsamer wird, während überall sonst alles schnell bleibt, sehen Sie das im nächsten Zyklus, anstatt zu warten, bis die Rotation Frankfurt erreicht. Bei Dotcom-Monitor ist Concurrent-Monitoring ein kostenpflichtiges Add-on, da es Ihr Prüfaufkommen vervielfacht und den Paketpreis erhöhen kann.
Erkennungsgeschwindigkeit versus Überwachungskosten
Die Entscheidung basiert auf einem Kompromiss zwischen der Geschwindigkeit der Fehlererkennung an einem Standort und der Anzahl der eingesetzten Prüfungen.
| Faktor | Round-Robin | Concurrent |
|---|---|---|
| Standorte pro Zyklus | Einer, bei Anomalie eskaliert auf alle | Alle, bei jedem Zyklus |
| Erkennung regionaler Ausfälle | Bis zu eine Rotation Verzögerung | Sofort |
| Prüfungsvolumen | Niedrig bei gesundem System | Hoch und konstant |
| SLAs pro Standort | Sparse und ungleichmäßig | Kontinuierlich und vergleichbar |
| Kosten | Inklusive Standard | Kostenpflichtiges Add-on |
| Beste Verwendung | Breite Uptime-Abdeckung | Geo-sensitive Apps und strenge SLAs |
Erkennungsverzögerung wird oft unterschätzt. Bei Round-Robin wartet ein Ausfall, der nur eine Region betrifft, bis die Rotation diesen Standort erreicht, bevor der Fehler gemeldet und vollständige Eskalation ausgelöst wird. Bei acht Standorten und fünf Minuten Frequenz sind das bis zu 40 Minuten regionaler Ausfall, bevor die Plattform reagiert. Concurrent schließt diesen Zeitraum auf einen Zyklus.
Die Kehrseite ist die Datenqualität. Da Concurrent jeden Standort kontinuierlich testet, liefert es ein gleichmäßiges, vergleichbares Protokoll pro Standort — genau das, was man braucht, um eine regionale SLA zu beweisen oder einen langsamen CDN-Edge zu analysieren. Round-Robin liefert ein selteneres und schwer vergleichbares Protokoll. Wenn Sie die Kosten von Ausfallzeiten nach Region verfolgen, ist dieser Unterschied entscheidend.
Warum browserbasierte Checks nacheinander laufen
Es gibt einen Punkt, der bei der Konfiguration von Real-Browser-Prüfungen oft übersehen wird. Dotcom-Monitor hat die Einstellung Allow Simultaneous Checks, die steuert, ob alle Standorte gleichzeitig oder nacheinander geprüft werden. Für HTTP-basierte Checks (ServerView und WebView) ist diese Funktion standardmäßig aktiviert, da jede Anfrage zustandslos und unabhängig ist, sodass paralleles Starten sicher ist. Für browserbasierte Checks (BrowserView und UserView) ist sie deaktiviert und kann nicht geändert werden.
Der Grund ist der Zustand. Viele Webanwendungen binden eine eingeloggte Sitzung an einen Satz von Zugangsdaten. Ein Login von einem zweiten Standort beendet die erste Sitzung. Führen Sie eine mehrstufige EveryStep-Transaktion gleichzeitig von fünf Standorten aus, treten Konflikte auf, die zu falschen Fehlern führen, die nichts mit der tatsächlichen Gesundheit Ihrer App zu tun haben.
Gemeinsam genutzte Zustände brechen bei parallelem Zugriff zusammen. Ein Warenkorb, eine Buchungsdatenbank oder ein Lagerbestand, die von fünf gleichzeitigen Sitzungen aktualisiert werden, liefern Ergebnisse, die nicht die Sicht eines einzelnen Benutzers abbilden.
Deshalb laufen browserbasierte Sitzungen selbst bei Concurrent-Monitoring sequenziell ab. Sie erhalten jeden Standort bei jedem Zyklus, aber nicht gleichzeitig, um Konflikte bei Zugangsdaten und gemeinsamen Testdaten zu vermeiden.
Wann Round-Robin die richtige Standardwahl ist
Round-Robin ist oft die richtige Wahl, als es sein bescheidener Ruf vermuten lässt. Verwenden Sie es, wenn:
- Sie eine breite Uptime-Abdeckung benötigen. Eine Marketingseite oder ein Blog, der von einer einzigen Quelle ausgeliefert wird, funktioniert überall gleich. Rotierende Standorte bestätigen die globale Erreichbarkeit, ohne für jeden Standort jede Minute zu testen.
- Ihr Inhalt geografisch homogen ist. Wenn es kein CDN-Routing oder regionale Infrastruktur gibt, teste jeder Standort dasselbe, und die zusätzlichen Prüfungen bei Concurrent bringen wenig neuen Erkenntnisgewinn.
- Das Budget knapp und Ihr SLA global, nicht regional ist. Round-Robin-Eskalation erfasst dennoch Ausfälle, tauscht jedoch eine etwas längere Erkennungszeit gegen viel weniger Prüfungen ein.
Stellen Sie sich eine SaaS-Firma vor, die ihre öffentliche Uptime-Seite über zehn Regionen beobachtet. Keine geographisch bedingten Seitenänderungen. Round-Robin hält einen globalen Aufmerksamkeitsrhythmus, und der erste regionale Fehler eskaliert automatisch auf volle Abdeckung. Das ist das Design, wie es beabsichtigt ist.
Wann Concurrent-Monitoring seinen Preis wert ist
Concurrent-Monitoring zahlt sich aus, wenn Geografie Teil des Testbereichs ist oder Verzögerungen kostspielig sind. Aktivieren Sie es, wenn:
- Sie Inhalte über ein CDN oder Georouting ausliefern. Die Edge-Performance variiert nach Region, und ein Problem in einem POP zeigt sich erst, wenn diese Region getestet wird. Concurrent testet jede Edge bei jedem Zyklus.
- Sie regionale SLAs einhalten müssen. Um 99,9 % in drei Regionen nachzuweisen, brauchen Sie kontinuierliche, vergleichbare Daten pro Standort, nicht die ungleichmäßigen Stichproben von Round-Robin.
- Ein Checkout- oder Login-Prozess Umsätze generiert. Bei einem E-Commerce-Checkout bedeutet ein regionaler Ausfall, der eine halbe Rotation unbemerkt bleibt, verlorene Bestellungen. Sofortige Erkennung lohnt das Add-on.
Denken Sie an einen Händler, der während eines Verkaufs einen Transaktionscheck zu sechs Regionen durchführt. Ein Zahlungs-Gateway, das nur für europäischen Traffic versagt, muss innerhalb von Sekunden sichtbar werden, nicht erst, wenn die Rotation Europa erreicht. Concurrent-Monitoring zusammen mit schnellen Überwachungsbenachrichtigungen macht das möglich.
Das Fazit
Round-Robin ist der wirtschaftliche Standard: ein Standort pro Zyklus, automatische Eskalation zu allen Standorten, sobald eine Prüfung abweicht. Es passt zu breiter, geografisch einheitlicher Uptime-Abdeckung. Concurrent-Monitoring testet jeden Standort bei jedem Zyklus für sofortige regionale Erkennung und saubere Standortdaten – allerdings mit mehr Prüfungen und Zusatzkosten. Es passt zu CDN-basierten Apps, regionalen SLAs und umsatzkritischen Pfaden, wo Verzögerungen teuer sind.
Wählen Sie das Muster, das zu Ihrem Testobjekt passt. Wenn Geografie den Unterschied macht, verwenden Sie Concurrent. Wenn nicht, deckt Round-Robin Sie bereits ab. So oder so beginnt effektive Überwachung aus mehreren Standorten damit, zu verstehen, wie Ihre Prüfungen geplant sind.
Sehen Sie es aus Ihren Regionen laufen
Richten Sie real-browser synthetische Überwachung über ein globales Netzwerk ein und beobachten Sie, wie Round-Robin und Concurrent auf Ihren eigenen Seiten funktionieren. Starten Sie eine kostenlose Testversion.
