Synthetic Monitoring
Das Synthetic Monitoring von HostTracker steuert Ihre Website nach einem Zeitplan, von 300+ Standorten aus, mit dem Check, der zur Aufgabe passt: eine gescriptete Browser-Journey, ein nach Regeln bewerteter API-Aufruf oder eine einfache HTTP-Anfrage. Wählen Sie unten eine aus und werden Sie alarmiert, sobald sie nicht mehr dem entspricht, was Sie erwarten.
Dieselbe Form bei allen dreien: laufen, bewerten, erneut prüfen, alarmieren
Synthetic Monitoring bedeutet, dass der Traffic absichtlich erzeugt wird. Statt darauf zu warten, dass ein echter Besucher auf ein Problem stößt, steuert ein Monitoring-Dienst Ihre Website selbst, nach einem festen Zeitplan, von außerhalb Ihres Netzwerks, und prüft, was zurückkommt, gegen von Ihnen festgelegte Regeln. Die Synthetic-Monitoring-Werkzeuge von HostTracker decken drei Check-Formen ab - Browser-Monitoring für eine gescriptete Journey, einen nach Regeln bewerteten API-Aufruf und eine einfache HTTP-Anfrage - und reichen damit von einem vollständigen Checkout-Ablauf bis zu einer einzelnen Statuscode-Prüfung, alles von 300+ Standorten weltweit.
Es ist kein Real User Monitoring. HostTracker erzeugt jeden Check selbst; es sammelt keine Zeit- oder Fehlerdaten aus den Browsern Ihrer tatsächlichen Besucher. Wenn Sie wissen müssen, was Ihre echten Besucher erlebt haben, ist das eine andere Disziplin mit einem anderen Namen - die vollständige Gegenüberstellung finden Sie unter Synthetic vs. Real User Monitoring. Der Vorteil von Synthetic Monitoring liegt genau umgekehrt: Es funktioniert, bevor Sie auch nur einen einzigen Besucher haben, und es funktioniert weiter um drei Uhr morgens, wenn niemand zusieht.
Die drei Check-Typen beantworten unterschiedliche Fragen, und den falschen zu wählen ist der häufigste Grund, warum ein echtes Problem unentdeckt bleibt. Diese Tabelle ordnet fünf häufige Bedürfnisse dem Check zu, der sie tatsächlich abdeckt.
Die meisten Konten führen am Ende mehr als eine Zeile dieser Tabelle gleichzeitig aus - einen HTTP-Check unter allem, plus einen Transaction- oder API-Check auf dem einen oder den zwei Abläufen, die am wichtigsten sind.
Ein Transaction-Szenario ist eine Abfolge benannter Aktionen; ein API-Regelbündel ist eine Menge von Assertions über eine Antwort. Beides wird konfiguriert, nie skriptiert.
Transaction: ein Fünf-Schritte-Szenario
0 navigate https://shop.example.com/ 1.4 s 1 type #email "[email protected]" 0.2 s 2 click #add-to-cart 0.9 s 3 waitForNavigation /checkout 1.1 s 4 checkContent "Order summary" present 0.1 s
API: ein Vier-Regeln-Bündel
status isOk header("Content-Type") contains "json" body.json.path("$.count") gt 0 time lt 5s
Jeder beantwortet eine andere Frage. Die meisten Konten, die HostTracker nutzen, betreiben am Ende mehr als einen.
Öffnen Sie einen echten Chromium-Browser und durchlaufen Sie bis zu zehn Schritte - anmelden, suchen, in den Warenkorb legen, bezahlen - und prüfen Sie dann, was auf der Seite steht. Erkennt, was ein Statuscode nicht kann: einen entfernten Button, einen defekten Formular-Post, einen JavaScript-Fehler mittendrin. Transaction-Monitoring
Senden Sie einen HTTP-Aufruf und bewerten Sie die Antwort gegen bis zu 20 Assertion-Regeln über Status, Header, Zeit sowie JSON-, XML- oder reinen Text-Body. Gebaut für den Endpunkt, von dem ein anderes System abhängt. API-Monitoring
Fragen Sie eine URL von 300+ Prüfpunkten in 158 Städten ab und prüfen Sie Status, Body-Keywords, Antwortzeit und TLS. Die ständig aktive Basis, auf der die anderen beiden aufsetzen. HTTP-Monitoring
Die Form des Checks ändert sich; die Prüfpunkte, die Bestätigungslogik und die Alarmkanäle dahinter nicht.
Jeder Check-Typ läuft von derselben öffentlichen Prüfpunkt-Flotte. Wählen Sie die Standorte, die zu dem passen, wo Ihre Besucher oder die Nutzer Ihrer API tatsächlich sind.
Ein einzelner fehlschlagender Prüfpunkt eröffnet nie allein einen Vorfall. Der Check wird von anderen, unabhängigen Prüfpunkten erneut ausgeführt, und erst ein übereinstimmendes Ergebnis wird zur Warnung.
Ein Transaction-Check behält einen Screenshot des letzten Schritts, und einen weiteren im Moment, in dem ein Schritt fehlschlägt, sodass die Fehlersuche mit dem beginnt, wie die Seite tatsächlich aussah.
Prüfen Sie gerenderten Text, einen per JSONPath oder XPath ausgewählten JSON-Wert oder ein einfaches Keyword - bis zu 20 Assertion-Regeln oder 10 Keyword-Treffer pro Monitor, je nach Check-Typ.
E-Mail, SMS, Sprachanruf, Slack, Telegram und Webhooks, einmal pro Kontakt eingerichtet, werden zwischen den Transaction-, API- und HTTP-Checks Ihres Kontos geteilt.
Fügen Sie jeden Monitor - Browser-Journey, API-Aufruf oder HTTP-Check - derselben öffentlichen Statusseite hinzu, sodass Kunden eine Seite sehen statt drei getrennter.
Websites, Server, APIs, Zertifikate. Ein Prüftyp pro Seite, dahinter dieselben Standorte, Alarme und Berichte.
Vertraut von Teams bei
Jedes Kapitel öffnet sich an Ort und Stelle, damit die Seite kurz bleibt.
Die beiden Ansätze beantworten unterschiedliche Fragen. Synthetisches Website-Monitoring erzeugt seinen eigenen Traffic, von seinen eigenen Prüfpunkten, nach einem von Ihnen kontrollierten Zeitplan - eine gescriptete Browser-Journey, ein API-Aufruf oder eine einfache HTTP-Anfrage. Real User Monitoring beobachtet stattdessen die Browser Ihrer tatsächlichen Besucher, was bedeutet, dass es echten Traffic braucht, um überhaupt etwas sagen zu können, und es kann Ihnen nicht sagen, was morgen passieren wird, nur was heute bereits passiert ist.
HostTracker ist ein Synthetic-Monitoring-Dienst - er bietet kein Real User Monitoring an, und diese Seite wird nichts anderes behaupten. Was Synthetic Monitoring stattdessen bringt: Eine Staging-Website mit null Besuchern wird trotzdem geprüft; ein Ausfall um drei Uhr morgens wird genauso erkannt wie einer zur Stoßzeit; und weil das Szenario deterministisch ist, nennt das Ergebnis den genauen Schritt oder die genaue Regel, die fehlgeschlagen ist, statt eines vagen Symptoms. Die vollständige Gegenüberstellung finden Sie unter Synthetic vs. Real User Monitoring; die Transaction-Monitoring-Seite trägt zusätzlich eine ausführliche Tabelle, wenn Sie die Mechanik möchten.
Jeder Check-Typ hat seine eigene Intervall-Untergrenze, denn jeder verursacht einen anderen Arbeitsaufwand. Eine HTTP- Anfrage ist günstig und kann auf einem kostenpflichtigen Plan so schnell wie einmal pro Minute laufen. Ein API-Aufruf ergänzt Parsing und Regelauswertung, läuft aber trotzdem von einer Minute bis zu 24 Stunden. Ein Transaction-Check öffnet einen echten Browser und durchläuft ein Szenario Ende zu Ende, weshalb er eine Untergrenze von 10 Minuten hat - Browser- Checks sind aufwendig auszuführen und zu empfangen, und einen davon mit einem schnellen HTTP-Check auf derselben Website zu kombinieren, deckt sowohl die Frage „ist es gerade erreichbar“ als auch „funktioniert der Ablauf noch“ ab, ohne alle sechzig Sekunden einen Browser zu starten.
Bei allen dreien können Sie wählen, von welchem der 300+ Prüfpunkte in 158 Städten ein bestimmter Monitor läuft - Geografie zählt mehr, als es scheint, denn ein CDN oder ein geo-geroutetes Load Balancing kann in einer Region gesund sein und in einer anderen ausfallen.
Die Versuchung bei jedem neuen Check-Typ ist, ihn direkt an eine Seite anzuschließen, die jemanden weckt. Widerstehen Sie dem in der ersten Woche: Lassen Sie einen neuen Monitor ruhig laufen, lesen Sie eine Handvoll echter Ergebnisse, und entscheiden Sie erst dann, wer sofort alarmiert wird und wer eine tägliche Zusammenfassung erhält. Ein Transaction-Check, der fehlschlägt, weil sich der Selektor eines Marketing-Banners geändert hat, ist nicht dieselbe Schwere wie einer, der fehlschlägt, weil der Checkout nicht mehr durchläuft - schreiben Sie Ihre Content-Assertions auf stabilen, aussagekräftigen Text, damit die Warnung, die Sie tatsächlich bekommen, eine ist, auf die es sich zu reagieren lohnt.
Warnungen gehen über die Kanäle hinaus, die Sie pro Kontakt einrichten - E-Mail, SMS, Sprachanruf, Slack, Telegram, Webhook und mehr -, dieselbe Auswahl über alle drei Check-Typen hinweg, sodass ein Transaction-Fehlschlag und ein HTTP-Fehlschlag dieselbe Person auf demselben Weg erreichen. Ein Zustandswechsel wird erst bestätigt, wenn andere Prüfpunkte übereinstimmen, sodass die Warnung, die Sie bekommen, bereits eine abgewogene ist statt einer einzelnen instabilen Beobachtung; eine Wiederherstellungs-Meldung folgt, sobald der Check wieder besteht, und schließt den Kreis, ohne dass Sie selbst nachsehen müssen.
Synthetic Monitoring ist Monitoring, bei dem der Traffic absichtlich, nach einem Zeitplan, von einem Dienst außerhalb Ihrer eigenen Systeme erzeugt wird - statt darauf zu warten, dass ein echter Besucher auf ein Problem stößt und zu hoffen, dass er es Ihnen meldet. Das Synthetic Monitoring von HostTracker kommt in drei Formen: eine gescriptete Browser-Journey, die einen mehrstufigen Ablauf durchläuft, ein API-Aufruf, der gegen von Ihnen geschriebene Regeln bewertet wird, und eine einfache HTTP-Anfrage, die auf Status, Body und Zeit geprüft wird. Alle drei laufen von 300+ Standorten, nutzen dieselben Alarmkanäle und halten eine Warnung zurück, bis andere Prüfpunkte den Ausfall bestätigen.
Nein. HostTracker erzeugt den Traffic selbst, von seinen eigenen Prüfpunkten, nach einem von Ihnen festgelegten Zeitplan - es sammelt keine Zeit- oder Fehlerdaten aus den Browsern Ihrer echten Besucher. Wenn Sie wissen müssen, was Ihre tatsächlichen Besucher erlebt haben, ist das Real User Monitoring, eine andere Disziplin mit einem anderen Namen; die vollständige Gegenüberstellung finden Sie unter Synthetic vs. Real User Monitoring. Der Vorteil von Synthetic Monitoring liegt genau umgekehrt: Es funktioniert, bevor Sie auch nur einen einzigen Besucher haben, und es prüft weiter um drei Uhr morgens, wenn niemand surft.
Uptime-Monitoring meint im engeren, alltäglichen Sinn meist genau eine dieser drei Formen: den einfachen HTTP-Check, der eine URL anfragt und Statuscode sowie Antwortzeit betrachtet. Synthetic Monitoring ist der breitere Begriff, der auch Browser-Monitoring - die gescriptete Journey - und synthetisches API-Monitoring umfasst, den nach Regeln bewerteten Aufruf. Ein HTTP-Check beantwortet „ist der Server erreichbar“; ein Transaction-Check beantwortet „läuft der mehrstufige Ablauf tatsächlich durch“; synthetisches API-Monitoring beantwortet „entspricht die Antwort tatsächlich ihrem Vertrag“. Eine Website kann jeden HTTP-Check bestehen, während ihr Checkout defekt ist - genau diese Lücke schließen die anderen beiden.
Nein. Alle drei Check-Typen werden im Web-Editor gebaut. Ein Transaction-Szenario ist eine Liste von Aktionen - navigieren, klicken, tippen und so weiter -, ausgewählt aus einem Menü, mit einem CSS-Selektor, der in ein Feld eingegeben wird. Die Assertion-Regeln eines API-Monitors sind jeweils eine Zeile in einfacher, lesbarer Syntax, kein Skript. Die Keywords und Optionen eines HTTP-Monitors sind Formularfelder. Nichts davon ist eine Programmiersprache, auch wenn die vollständige Aktions- und Regeloberfläche zusätzlich über die API erreichbar ist, falls Sie das Einrichten selbst automatisieren möchten.
Bis zu zehn geschriebene Schritte, innerhalb eines 40-Sekunden-Budgets für den gesamten Lauf. Eine anfängliche Navigation zur eigenen URL des Monitors wird automatisch als Schritt null hinzugefügt, sodass die zehn Schritte, die Sie schreiben, zehn Schritte echter Arbeit sind - Klicks, eingegebener Text, Content-Assertions - nicht neun plus ein Seitenaufruf. Ein Ablauf, der wirklich mehr als zehn Schritte braucht, lässt sich meist besser in zwei Monitore aufteilen; das verrät Ihnen zudem, welche Hälfte kaputt war.
Beginnen Sie mit einem HTTP-Check auf der Website selbst - er ist das günstigste Signal und die ständig aktive Basis, die jedes Konto haben sollte. Fügen Sie dann hinzu, was auch immer von den anderen beiden zu Ihrem größten Risiko passt: einen Transaction-Check, wenn ein defekter Checkout- oder Login-Ablauf Sie direkt Geld kostet, einen API-Check, wenn ein anderes System - Ihre eigene App, die Integration eines Partners - davon abhängt, dass ein Endpunkt korrekt antwortet. Die meisten Konten, die alle drei nutzen, führen den HTTP-Check am häufigsten aus, den API-Check danach, und den Transaction-Check im längsten Intervall, da er am aufwendigsten zu betreiben ist.
Das hängt vom Check-Typ ab, denn jeder verursacht einen anderen Arbeitsaufwand. HTTP-Checks können auf einem kostenpflichtigen Plan so schnell wie einmal pro Minute laufen. API-Checks laufen von einer Minute bis zu 24 Stunden. Transaction-Checks haben - weil jeder Lauf einen echten Browser öffnet und ein Szenario Ende zu Ende durchläuft - eine Untergrenze von 10 Minuten. Ein gängiges Muster kombiniert einen Ein-Minuten-HTTP-Check für schnelle Ausfallerkennung mit einem Transaction- oder API-Check alle 10 bis 15 Minuten für die tiefere Frage.
Dem Fehlschlag wird bei der ersten Beobachtung nicht vertraut. HostTracker führt den Check von anderen, unabhängigen Prüfpunkten erneut aus und bestätigt den Zustandswechsel erst, wenn genug davon übereinstimmen, sodass ein einzelner instabiler Netzwerkpfad oder ein einzelner langsamer Knoten allein noch keine Warnung auslöst. Sobald bestätigt, alarmiert HostTracker die von Ihnen eingerichteten Kontakte über die gewählten Kanäle - E-Mail, SMS, Sprachanruf, Slack, Telegram, Webhook und mehr - nach der jeweils festgelegten Verzögerung, und eine Wiederherstellungs-Meldung folgt, sobald der Check wieder besteht.
Starten Sie eine kostenlose Testphase und fügen Sie demselben Konto einen Transaction-, API- oder HTTP-Check hinzu - dieselben 300+ Standorte und dieselben Alarme hinter allen dreien.
Teil der Website-Monitoring-Software von HostTracker.
