Was ist Synthetic Monitoring? Definition, Arten, RUM-Vergleich

Was ist Synthetic Monitoring?

Synthetic Monitoring (synthetisches Monitoring) führt geskriptete Checks gegen eine Website, API oder Anwendung nach Zeitplan von frei gewählten Standorten aus und alarmiert, wenn ein Check fehlschlägt oder langsamer wird. Der Traffic ist künstlich, deshalb funktioniert es nachts um drei und vor dem Launch, ganz ohne Besucher. Es beantwortet laufend eine Frage: Funktioniert das noch so, wie wir es gebaut haben?

Diese Seite erklärt das Konzept. Zum Einrichten von Checks siehe das Synthetic Monitoring von LoadFocus mit API-Checks und Playwright-Browser-Checks.

So funktioniert Synthetic Monitoring

1. Check definieren. Eine URL, eine API-Anfrage oder eine geskriptete Browser-Strecke, dazu Prüfregeln: Statuscode, Text im Body, Antwortzeit unter einem Limit.
2. Zeitplan festlegen. Jede Minute für kritische Dienste, alle paar Minuten für die meisten, stündlich oder täglich für unwichtige Seiten.
3. Von mehreren Standorten ausführen. Ein Fehler in einer Region, aber nicht in einer anderen, deutet auf Routing-, CDN- oder DNS-Probleme. Wenn zwei Standorte übereinstimmen müssen, sinken auch die Fehlalarme.
4. Ergebnis speichern. Zeiten, Status und bei Browser-Checks Screenshots und Netzwerk-Wasserfälle.
5. Alarmieren. Per E-Mail, Slack, Webhook oder Pager, wahlweise erst nach mehreren Fehlschlägen in Folge.

Arten synthetischer Checks

• Uptime-Checks. Eine URL anfragen und prüfen, ob sie mit dem erwarteten Status antwortet.
• API-Checks. Einen Endpunkt mit Headern und Body aufrufen und Status, Header, Payload und Zeit prüfen. Mehrstufige Checks verketten Aufrufe, zum Beispiel Login, Token übernehmen, geschützten Endpunkt aufrufen. Siehe API-Monitoring.
• Browser-Checks. Einen echten Browser durch eine Seite oder Nutzerstrecke wie Anmeldung, Suche und Checkout steuern und melden, welcher Schritt fehlschlug oder langsam war.
• Seitengeschwindigkeits-Checks. Eine Seite regelmäßig unter Laborbedingungen laden und Werte wie Largest Contentful Paint und Total Blocking Time verfolgen. Siehe Core Web Vitals.
• SSL- und DNS-Checks. Ablauf von Zertifikaten überwachen und prüfen, ob ein Hostname auf die richtige Adresse zeigt.

Synthetic Monitoring vs. Real User Monitoring

Beide messen Unterschiedliches, und reife Teams setzen beide ein.

Den ausführlichen Vergleich finden Sie in Synthetic Monitoring vs. Real User Monitoring.

Kennzahlen, die sich lohnen

• Verfügbarkeit. Anteil der erfolgreichen Checks im Zeitraum. Verfügbarkeitsziele wie 99,9 % werden meist aus dieser Zahl berichtet.
• Antwortzeit. Gesamt, am besten aufgeteilt in DNS, Verbindungsaufbau, TLS, Wartezeit und Download.
• Fehlerrate. Fehlgeschlagene Prüfregeln und unerwartete Statuscodes.
• Time to First Byte. Ein schnelles Signal für die Serverlage.
• Browser-Metriken. LCP, CLS und TBT in Browser- oder Seitengeschwindigkeits-Checks. Interaction to Next Paint braucht echte Nutzer, daher steht TBT in Labormessungen für die Reaktionsfähigkeit.

Ein einfaches Beispiel

Ein Onlineshop legt einen API-Check für GET /products?limit=1 an, der in unter 500 ms mit 200 und einem JSON-Body mit items antworten muss, sowie einen Browser-Check für Anmeldung, Suche und Warenkorb. Beide laufen alle paar Minuten aus zwei Regionen. Fällt nach einem Deployment der Warenkorb-Schritt aus, nennt der Alarm den Schritt und hängt den Screenshot an, bevor die meisten Kunden das Problem bemerken.

Häufige Fehler

• Nur die Startseite prüfen. Die Startseite kann laufen, während Login oder Checkout kaputt sind.
• Nur den Status prüfen. Ein 200 mit Fehlermeldung oder leerer Liste besteht trotzdem. Prüfen Sie auch den Body.
• Ein einziger Standort. Ein lokaler Netzaussetzer weckt Sie nachts.
• Bei jedem Fehlschlag alarmieren. Verlangen Sie zwei Fehlschläge in Folge oder die Übereinstimmung zweier Standorte.
• Geteilte Testkonten, die ablaufen. Der Check scheitert aus Gründen, die mit dem Produkt nichts zu tun haben.
• Es für vollständige Abdeckung halten. Es ersetzt weder Observability noch Application Performance Monitoring, die erklären, warum etwas ausfiel.

Synthetic Monitoring und Lasttests

Synthetische Checks senden ein Rinnsal an Traffic, um zu bestätigen, dass ein Nutzer seine Aufgabe erledigen kann. Ein Lasttest schickt viele Nutzer gleichzeitig, um die Bruchstelle zu finden. Beides ergänzt sich: Der Lasttest findet die Grenze vor dem Launch, das Synthetic Monitoring zeigt, wenn die Produktion sich ihr nähert. Kostenlose API-Checks bei LoadFocus laufen alle 5 Minuten; die bezahlten Intervalle stehen unter API-Monitoring, geplante Lighthouse-Audits beim Page-Speed-Monitoring. Starten Sie mit kostenlosen API-Checks. Praktische Tipps finden Sie in So verbessern Sie die Nutzererfahrung mit Synthetic Monitoring.

Häufige Fragen: Synthetic Monitoring

Worin unterscheidet sich Synthetic Monitoring von Uptime-Monitoring?

Uptime-Monitoring ist der einfachste synthetische Check: Er fragt, ob eine URL antwortet. Synthetic Monitoring umfasst außerdem API-Prüfregeln, mehrstufige Strecken, Browser-Checks und Performance-Messungen.

Wie oft sollten synthetische Checks laufen?

Jede oder jede zweite Minute für umsatzkritische Endpunkte, alle fünf Minuten für die meisten Dienste, stündlich oder täglich für sich selten ändernde Seiten. Kürzere Intervalle finden Probleme schneller, verbrauchen aber mehr Läufe.

Ersetzt Synthetic Monitoring das Real User Monitoring?

Nein. Synthetic Monitoring zeigt, dass etwas kaputt ist, auch ohne Besucher. RUM zeigt, wie echte Menschen auf echten Geräten die Seite erleben. Nutzen Sie beides.

Kann ich Synthetic Monitoring vor dem Launch einsetzen?

Ja. Da es keine Besucher braucht, können Sie Checks auf eine Staging-Umgebung richten und nach jedem Deployment ausführen.

Warum Checks von mehreren Standorten ausführen?

Um einen echten Ausfall von einem lokalen Netzproblem zu unterscheiden und regionale Störungen bei DNS, CDN oder Routing zu entdecken, die ein einzelner Standort übersieht.