Synthetisch vs Real User Monitoring: was jedes erfasst
Synthetisches Monitoring führt skriptgesteuerte Prüfungen nach Zeitplan von selbst gewählten Standorten aus; Real User Monitoring erfasst Zeiten aus den Browsern der Besucher Ihrer Website. Synthetisch sagt Ihnen, ob die Website funktioniert, Real User Monitoring sagt Ihnen, wie es sich für die Menschen anfühlte, die da waren.
Was jedes der beiden tut
Synthetisches Monitoring, manchmal auch aktives oder proaktives Monitoring genannt, sendet eine von Ihnen definierte Anfrage von einem Rechner, den Sie kontrollieren, in einem von Ihnen festgelegten Intervall. Diese Anfrage kann so klein wie ein HTTP GET oder so umfangreich wie eine skriptgesteuerte Browser-Sitzung sein, die sich anmeldet, einen Artikel in den Warenkorb legt und zur Kasse geht. Jeder Lauf liefert ein Ergebnis, unabhängig davon, ob jemand die Website besucht hat.
Real User Monitoring, meist mit RUM abgekürzt, ist passiv. Ein kleines Skript in Ihren Seiten meldet, was der Browser für diesen Besuch gemessen hat: Navigationszeiten, Ressourcen-Ladevorgänge, Fehler und die Core Web Vitals so, wie der Besucher sie erlebt hat. Es liefert Daten nur im Verhältnis zu Ihrem Traffic und liefert nichts, wenn niemand da ist.
Was synthetisch erfasst, was RUM übersieht
- Ausfälle um 4 Uhr morgens, oder auf jeder Seite mit wenig Traffic. Lädt niemand die Seite, hat RUM nichts zu melden, und ein vollständiger Ausfall ist genau der Fall, in dem das Beacon nicht gesendet werden kann
- Erreichbarkeit von Orten, an denen Sie noch keine Nutzer haben, was der Weg ist, herauszufinden, dass ein neuer Markt Sie nicht erreichen kann
- Eine saubere Baseline. Dasselbe Skript, vom selben Standort, im selben Intervall, sodass eine Änderung der Zahl eine Änderung an der Website ist, nicht eine Änderung, wer gerade zufällig vorbeikam
- Mehrstufige Abläufe, die Sie nicht von echten Nutzern durchlaufen lassen wollen, etwa eine Kasse, die eine echte Bestellung erzeugen würde, oder ein Login, das Sie gegen ein Testkonto ausführen können
- Ablauf- und Konfigurationsfehler, die einen Browser nie erreichen: Zertifikate, DNS-Einträge, Blacklist-Listungen, offene Ports
- Den ersten Fehler nach einem Deployment, bevor der Traffic eintrifft, der ihn aufgedeckt hätte
Was RUM erfasst, was synthetisch übersieht
- Die echte Verteilung von Geräten, Netzwerken und Standorten. Eine synthetische Prüfung über eine Rechenzentrumsverbindung wird nie ein Mittelklasse-Telefon auf mobilen Daten nachbilden
- Drittanbieter-Skripte, Consent-Banner und Personalisierung, die nur für echte Sitzungen mit echten Cookies laden
- Probleme, die eine Teilmenge der Nutzer betreffen: eine Browser-Version, eine Region, eine A/B-Variante
- Welche langsamen Seiten wichtig sind, gewichtet danach, wie viele Menschen sie sehen
- Feld-Core-Web-Vitals, die Suchmaschinen verwenden, im Unterschied zu den Laborwerten, die ein synthetischer Lauf liefert
Wann Sie beides brauchen
Die beiden beantworten unterschiedliche Fragen, die Trennung ist also meist klar. Nutzen Sie synthetisch für alles, worüber Sie jemanden alarmieren würden: Erreichbarkeit, Antwortzeit gegen einen Schwellenwert, Zertifikats- und Domain-Ablauf sowie die kritischen Abläufe, mit denen Sie Geld verdienen. Diese müssen um 4 Uhr morgens ohne jeden Traffic stimmen, und sie brauchen eine stabile Baseline, gegen die alarmiert wird.
Nutzen Sie RUM, um zu entscheiden, was zu beheben ist. Ist eine Seite für manche Menschen langsam, sagt Ihnen RUM, für wen und für wie viele, was genau die Information ist, die ein Priorisierungsargument braucht und die eine synthetische Prüfung nicht liefern kann.
Ein praktischer Aufbau ist synthetisches Monitoring, das die Alarme und die Uptime-Aufzeichnung antreibt, und RUM, das den Performance-Rückstand antreibt. Können Sie nur eines betreiben, betreiben Sie synthetisch: Ein unüberwachter Ausfall ist teurer als eine ungemessene langsame Seite, und RUM kann über eine Seite, die nicht geladen hat, nichts berichten.
Wo Transaction-Monitoring hineinpasst
Eine Transaction-Prüfung ist synthetisches Monitoring in seiner detailliertesten Form: ein aufgezeichnetes Browser-Skript, das eine echte Nutzerreise Schritt für Schritt durchläuft und an dem Schritt fehlschlägt, der kaputt war, statt an der Website als Ganzes. Sie erfasst die Fehlerklasse, die eine einfache Erreichbarkeitsprüfung als gesund meldet, bei der die Startseite 200 zurückgibt, während das dahinterliegende Login-Formular kaputt ist.
Weil sie synthetisch ist, läuft sie nach Zeitplan ohne benötigten Traffic, und weil sie einen echten Browser steuert, übt sie das JavaScript, die Drittanbieter-Abhängigkeiten und die Weiterleitungen aus, die eine einfache HTTP-Prüfung überspringt. HostTrackers Transaction-Monitoring funktioniert so, und die Anleitung zur Transaction-Prüfung behandelt, wie ein Skript aufgezeichnet wird und was jeder Schritt meldet.
Aus einer Messung einen Alarm machen
Keiner der beiden Ansätze ist nützlich, bis etwas auf das Ergebnis reagiert. Eine synthetische Prüfung lohnt sich, weil sie läuft, ob Sie zusehen oder nicht, und weil ein Fehler Sie sofort erreichen kann: HostTracker führt seine Prüfungen von über 300 Prüfpunkten in 158 Städten über 13 Monitor-Typen aus und sendet Alarme per E-Mail, SMS, Sprachanruf, Slack, Telegram und mehr, wenn sich ein Ergebnis ändert. Kombinieren Sie das mit dem RUM, das Sie bereits erfassen, und Sie haben beide Hälften: einen Alarm, wenn die Website kaputtgeht, und Belege dafür, für wen sie langsam war. Die dahinterstehenden Begriffe finden Sie im übrigen Bereich Monitoring-Konzepte.