HTTPS
Website- und API-Überwachung
Eine Seite oder ein Endpoint, abgerufen von vier Kontinenten.
Jetzt ausprobieren
Ein Test, von einem Ort, jetzt sofort, und nichts wird gespeichert. Ein Monitor prüft von jedem Standort, den wir betreiben, und bestätigt einen Ausfall von zwei anderen Kontinenten, bevor jemand geweckt wird, was ein einzelner Blick dir nicht zeigen kann.
Wofür es ist
Der Check, mit dem jeder anfängt, und der, bei dem die meisten Produkte aufhören. Wir rufen die URL ab, folgen oder verweigern Weiterleitungen, wie du es angibst, und lesen den Statuscode.
Ein Statuscode allein ist ein schwaches Versprechen. Eine Seite kann 200 zurückgeben, während sie eine Fehlerseite, einen Login-Bildschirm, eine zwischengespeicherte Kopie vom letzten Dienstag oder eine leere Hülle liefert, die nicht gerendert wurde. Der Check kann daher auch verlangen, dass eine Phrase vorhanden ist, eine Weiterleitung an einem bestimmten Ort landet, ein JSON-Feld einen bestimmten Wert enthält und eine Antwort innerhalb einer von dir festgelegten Zeit eintrifft. Das sind die Fehler, die ein Statuscode nicht sehen kann.
Wie jeder Check hier läuft er von Amsterdam, New York, Sydney and Singapore, und ein Fehler wird von zwei anderen Kontinenten bestätigt, bevor jemand geweckt wird. Wie das funktioniert.
Was du einstellen kannst
Alles unten steht im Formular, wenn du einen hinzufügst, in jedem Tarif.
- Methode
- GET, HEAD, POST, PUT, PATCH oder DELETE. HEAD ist die höfliche Standardeinstellung für eine Seite, von der du nur wissen musst, dass sie existiert.
- Erwarteter Status
- Welche Codes als gesund gelten. Ein 401 ist korrekt für einen Endpoint, der dich ablehnen sollte, und dies anzugeben verhindert, dass wir deine funktionierende Authentifizierung als Ausfall melden.
- Schlüsselwort
- Eine Phrase, die vorhanden sein muss oder fehlen muss. Der günstigste Weg, ein 200 zu erkennen, das eigentlich eine Fehlerseite ist.
- JSON-Assertions
- Ein Pfad und der Wert, den er enthalten sollte, für eine API, die 200 mit einem Body beantwortet, der etwas anderes sagt.
- Weiterleitungen
- Der Kette folgen oder eine Weiterleitung als Antwort behandeln. Mit einem erwarteten Ort erkennt dies eine Seite, die still und leise irgendwohin umgeleitet wurde, wo sie nicht sein sollte.
- Langsam ist ein Fehler
- Eine Antwortzeit, ab der der Check als verschlechtert statt als verfügbar gilt, und wie viele in Folge, bevor wir das sagen.
- Authentifizierung
- Basic oder Bearer. Verschlüsselt gespeichert, von der Steuerungsebene entschlüsselt und der Probe mit der Aufgabe übergeben, statt einer gemieteten Maschine den Schlüssel zu allem zu geben.
- Header und Body
- Alles, was die Anfrage benötigt. Ein Header pro Zeile und ein Body für die Methoden, die einen benötigen.
- Timeout
- Wie lange gewartet wird, bevor es als Fehler gilt.
- Bestätigungen
- Wie viele andere Kontinente zustimmen müssen, bevor jemand geweckt wird. Null ist möglich und selten das, was du willst.
Fragen
Was bedeutet ein 502 oder 503, und wirst du darauf alarmieren?
Ein 502 bedeutet, dass der vordere Server dir mitteilt, dass der dahinterliegende Server eine Antwort gegeben hat, die er nicht verwenden konnte. Ein 503 bedeutet, dass ein Server sagt, er nimmt keine Anfragen an, was die meisten Frameworks während eines Neustarts zurückgeben. Beide führen standardmäßig zu einem fehlgeschlagenen Check, da die Standardeinstellung 2xx und 3xx erwartet. Wenn ein Code für diesen Endpoint korrekt ist, füge ihn der Liste der erwarteten Status hinzu, und es ist keine Störung mehr.
Überprüfst du die SSL/TLS-Zertifikatskette?
Ja. Der Check verbindet sich wie ein Browser, gegen den öffentlichen Trust Store, sodass ein fehlendes Zwischenzertifikat, ein selbstsigniertes Zertifikat, ein Hostname-Mismatch oder ein abgelaufenes Zertifikat den Check mit einem TLS-Fehler statt einem Statuscode fehlschlagen lässt. Was er nicht macht, ist die verbleibenden Tage zu zählen, das ist die Aufgabe des SSL/TLS-Zertifikat-Monitors. Die Verifizierung kann pro Monitor für einen internen Host, den du kennst, deaktiviert werden.
Kann ich einen API-Endpoint statt einer Seite überwachen?
Dafür sind die Request-Optionen da, und deshalb gibt es keinen separaten API-Monitor-Typ, der sich von diesem unterscheidet. Wähle POST, PUT, PATCH oder DELETE, füge Header und einen Body hinzu, authentifiziere mit Basic- oder Bearer-Credentials, akzeptiere die Statuscodes, die korrekt sind, und überprüfe einen Pfad im zurückkommenden JSON.
Was ist der Unterschied zwischen einem Timeout und einer langsamen Antwort?
Ein Timeout ist ein Check, der innerhalb der erlaubten Sekunden keine Antwort erhalten hat, und wird als Fehler ohne Statuscode gemeldet, abgesehen von einer Verbindung, die direkt abgelehnt wurde. Langsam bedeutet, dass eine Antwort angekommen ist, aber zu lange gedauert hat: Setze eine Antwortzeit, ab der der Check als verschlechtert gilt, und wie viele in Folge, bevor jemand davon erfährt.
Folgst du Weiterleitungen?
Nicht, es sei denn, du sagst es, was Leute oft genug überrascht, um es zu erklären. Eine Seite, die anfängt, mit 302 auf eine Parking-Seite zu antworten, ist kaputt, und ein Checker, der dem still folgt und eine 200 findet, würde das als gesund melden. Schalte das Folgen ein, wenn der Redirect der Punkt ist, und nenne den Ort, an dem du enden willst.
Führt der Check JavaScript aus oder rendert die Seite?
Nein, und wir sagen das, anstatt etwas anderes zu implizieren. Es ruft das Dokument ab, das der Server sendet, und liest dieses, sodass ein Keyword-Check etwas im HTML finden muss, statt etwas, das ein Framework später rendert. Für eine Seite, die im Browser gerendert wird, überprüfe den Statuscode, die Antwortzeit und einen Ausdruck, der wirklich in der Antwort steht.
Ist die Antwortzeit das, was meine Besucher erleben?
Es ist die Zeit, die unsere Probe gewartet hat, von der Anfrage bis zur Antwort, auf einer Verbindung ohne kalten Cache und ohne Browser davor. Das macht es zu einem ausgezeichneten Stolperdraht für einen Server, der langsamer wird, und zu einem schlechten Modell für eine Person am Telefon. Real User Monitoring und Core Web Vitals beantworten die andere Frage, und dieser Check tut nicht so, als würde er das.
Warum nicht einfach mit curl aus einem Cron-Job abrufen?
Für eine URL von einer Maschine ist ein Cron-Job tatsächlich das meiste davon, und jeder, der dir etwas anderes erzählt, verkauft dir etwas. Was er dir nicht gibt, ist ein Ort zum Ausführen, der nicht selbst still sterben kann: Ein Check auf einer Box, die ihr Netzwerk verloren hat, meldet nichts, was genau so aussieht, als wäre alles in Ordnung. Er sagt dir auch nicht, ob ein kaputter Link zwischen dir und der Seite oder die Seite selbst kaputt ist, wofür das erneute Prüfen von zwei anderen Kontinenten gedacht ist, und es überlässt dir immer noch den Teil, der jemanden aufweckt.
Wie unterscheidet sich das von einem browserbasierten synthetischen Check?
Ein synthetischer Check steuert einen echten Browser, sodass er Dinge sieht, die wir nicht sehen können: eine Seite, die leer gerendert wird, weil ein Skript einen Fehler geworfen hat, ein Button, der nicht mehr funktioniert, eine Schriftart, die nie geladen wurde. Dieser Check macht die Anfrage und liest die Antwort, was bedeutet, dass er nichts davon sehen kann. Was er dir stattdessen gibt, ist ein Check, der günstig genug ist, um alle dreißig Sekunden von drei Kontinenten aus auf jeder URL, die du hast, ausgeführt zu werden, statt einer Handvoll Reisen ein paar Mal pro Stunde. Sie beantworten unterschiedliche Fragen, und viele Leute wollen beides.