API-Monitoring in HostTracker einrichten

Haupteinstellungen

Für diesen Abschnitt gibt es beim Typ API keinen eigenen Screenshot, er verwendet aber dieselben gemeinsamen Steuerelemente wie jeder andere Prüfungstyp. Überwachung aktiviert ist der Hauptschalter. Intervall-Zeitplan (1 Minute bis 24 Stunden, Regler oder Dropdown) oder ein Cron-Zeitplan-Baukasten (alle N Minuten/Stunden, täglich, wöchentlich, monatlich, oder ein eigener Ausdruck, nur kostenpflichtiger Plan) steuert, wie oft die Prüfung läuft. Timeout liegt bei 1 bis 100 Sekunden; die DNS-Auflösungszeit zählt nicht mit. Tags sind durch Komma getrennte Bezeichnungen zum Gruppieren und Filtern. Full Log speichert jedes Ergebnis, statt aufeinanderfolgende identische zu gruppieren, und Open Stats veröffentlicht die Statistik und das Protokoll der Aufgabe über einen öffentlichen Link. Anders als bei HTTP hat das API-Formular keinen DNSBL-Schalter (DNSBL bleibt nur bei Http/Ping/Port erhalten); es trägt aber dieselben Kacheln Domain-Ablauf, Zertifikatsablauf und Web Risk, jede alle 12 Stunden laufend - Ablauf-Erinnerungen folgen Ihren Erreichbar-Abonnements unten, ein schlechtes Ergebnis folgt Nicht erreichbar/Repeat.

Anfragekonfiguration

• HTTP-Methode - GET, HEAD, POST, PUT, DELETE oder PATCH. GET (Vorgabe) ist nötig, um einen Antwortkörper zu lesen und zu analysieren; HEAD holt nur Header.
• Request-Body (nur POST/PUT/PATCH) - Raw Body sendet genau das, was Sie eintippen (fügen Sie Ihren eigenen Content-Type-Header hinzu, um json/xml/plaintext zu beschreiben); POST-Parameter akzeptiert ein KEY=VALUE pro Zeile und wird als form-urlencoded Body gesendet.
• Weiterleitungsverhalten - Sofortige Antwort beurteilt die erste Antwort so wie sie ist; Weiterleitungen folgen (Vorgabe) folgt der Kette, mit einem Regler Max. zu folgende Weiterleitungen (1-20); Weiterleitung ist Fehler lässt die Prüfung bei jeder Weiterleitung fehlschlagen (im Assertion-Modus nicht verfügbar).
• HTTP-Header - eigene Name/Wert-Paare, mit Vorschlägen für gängige API-Header-Namen und -Werte (Content-Type, Authorization, X-API-Key, Bearer/Basic-Präfixe und mehr). Leer gelassen, sendet die Prüfung Standard-Header (User-Agent, Accept, Accept-Language, ein Referer).
• Anfrage-Authentifizierung - zeigt Benutzername/Passwort für die eigene HTTP-Challenge-Authentifizierung des Servers (Basic, Digest, NTLM, Kerberos, Negotiate). Für ein Bearer-Token oder einen API-Schlüssel fügen Sie stattdessen oben einen Authorization-Header hinzu.
• DNS-Serverauswahl - Standard-DNS-Server an den Standorten; Öffentliche DNS-Server des Landes des Standorts; oder Manuell festgelegte DNS-Server (Ihre eigenen Resolver-IPs). Die letzten beiden brauchen einen kostenpflichtigen Plan.
• DNS-Cache deaktivieren - erzwingt bei jeder Prüfung eine frische DNS-Abfrage, statt den Cache des Agenten wiederzuverwenden.

Antwortvalidierung

Standardmäßig ist eine Prüfung erfolgreich, wenn DNS aufgelöst wird, die Verbindung und der TLS-Handshake (bei https) gelingen, der Server einen HTTP-Ok-Status zurückgibt und die Antwort sich im unten gewählten Format parsen lässt.

• Assertion-Modus - der Screenshot zeigt ihn aus, mit einem Banner, das Sie einlädt, ihn für Statuscode-, Antwortzeit-, Header- oder Inhaltsregeln einzuschalten. API und HTTP sind die einzigen zwei Prüfungstypen mit funktionierendem Assertion-Editor; die vollständige Regelsprache finden Sie in der Assertion-Modus-Tiefenanleitung. Solange er aus ist, bestimmen die klassischen Felder unten das Urteil.
• HTTP-Fehler ignorieren - Statuscodes, die die Prüfung NICHT fehlschlagen lassen sollen, z. B. 401, 403, 500; leer bedeutet, jeder Code ab 400 ist ein Fehler.
• Fehler bei diesen HTTP-Status - umgekehrt: Codes, die die Prüfung fehlschlagen lassen sollen, auch wenn sie es normalerweise nicht täten.
• Antwortformat - wie der Body geparst wird, bevor der Selektor läuft: JSON-Analyse (JSONPath oder Eigenschaftsselektor, im Screenshot ausgewählt), XML-Analyse (XPath-Abfrage), oder String-Analyse (Regex mit Erfassung). GET ist nötig, um einen Body zu lesen.
• Selektor - wählt einen Wert aus der geparsten Antwort; leer lassen, um die gesamte Antwort als Wert zu verwenden.
• Was zu prüfen ist - standardmäßig beurteilt die Bedingung unten den ausgewählten Wert selbst (Den erhaltenen Wert selbst prüfen); wechseln Sie zu Die Wertänderung zwischen Prüfungen prüfen, oder eine Änderungsrate pro Sekunde/Minute, um stattdessen zu beurteilen, wie stark sich der Wert bewegt hat.
• Bedingung - vergleicht den Wert: beliebig (keine Prüfung) (Vorgabe, im Screenshot gezeigt), gleich, ungleich, in Menge von, außerhalb der Menge, kleiner als, kleiner oder gleich, größer als, größer oder gleich, im Bereich, außerhalb des Bereichs, nicht im Inhalt vorhanden, oder JSON null. Jede Bedingung außer den letzten beiden braucht darunter einen eingetragenen Vergleichswert.
• HTTP-Richtlinien - dieselben Opt-in-Header-/Cookie-/Inhaltsprüfungen wie beim Prüfungstyp HTTP: HTTPS erzwingen, HSTS-Header, kein Downgrade von https zu http, CSP, Clickjacking-Schutz, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, keine Versionsoffenlegung, Cache-Control-Assertions, CORS-Antwort-Header, Cookie-Sicherheit und Mixed Content. Die Vorgaben Baseline, Strict und API ersetzen die ganze Auswahl; ein Verstoß beendet die Prüfung wie jeder andere Fehlschlag mit Nicht erreichbar.
• TLS-Handshake - vier Strenge-Schalter (kostenpflichtiger Plan): eine gültige SSL-Zertifikatskette verlangen, TLS 1.2 oder höher verlangen, schwache Cipher (128-Bit oder darunter) blockieren, und Zertifikatswiderruf prüfen.
• Validierung erwarteter IPs - bestätigt bei jeder Prüfung, dass DNS Ihren Host zu einer der von Ihnen aufgeführten IPs auflöst, und fängt Hijacking oder einen veralteten Eintrag ab, selbst während ein Server noch antwortet.
• Maximale Antwortgröße - liest den Body nicht über diese Größe hinaus, der Parser und Selektor sehen also nur den heruntergeladenen Teil. Vorgabe 1 MB, Maximum 10 MB; 0 liest keinen Body.

Eine Anmerkung zu den obigen Screenshots: Sie wurden auf einem Konto aufgenommen, dessen Paket den Prüfungstyp API nicht enthält, das Typauswahlfeld zeigte dort also "nicht in Ihrem Paket enthalten". Das ist ein Artefakt des Testkontos, nichts, was Sie sehen werden - jedes hier beschriebene Feld und jede Vorgabe entsprechen sonst genau dem, was das Formular zeigt.

Benachrichtigungsabonnements

Wird von jedem Prüfungstyp geteilt. Down = der Endpunkt hat die Prüfung nicht bestanden, Up = er hat sich erholt, Repeat = Erinnerungen, solange er down bleibt. Alle Kontakte für Up/Down-Ereignisse abonnieren ist eine Abkürzung; die Tabelle gibt Ihnen Kontrolle pro Kontakt, einzeln oder über wiederverwendbare Kontaktgruppen-Vorgaben. Eine Aufgabe ohne Benachrichtigungsabonnements läuft trotzdem und protokolliert Ergebnisse - sie benachrichtigt nur niemanden.

Berichtsabonnements

Periodische Uptime-Berichte, nur per E-Mail. Wählen Sie Daily, Weekly oder Monthly pro Kontakt; Monthly bündelt zusätzlich Quartals- und Jahreszusammenfassungen. Der Alle-abonnieren-Schalter funktioniert wie bei den Benachrichtigungsabonnements.

Überwachungsstandorte

• Standortauswahl - durchsuchen oder durchblättern Sie den Region-/Länderbaum und haken Sie Standorte an, von denen aus geprüft werden soll; jede Zeile zeigt verfügbare gegenüber ausgewählten Agenten. "Standorte von einer anderen Aufgabe übernehmen" nutzt eine bestehende Auswahl.
• Nachprüfungsstrategie - bei einem Statuswechsel (z. B. Erreichbar zu Nicht erreichbar) bestätigen ihn mehrere Standorte erneut, bevor der neue Status akzeptiert wird, als Schutz vor einem Fehlalarm aus einer Region. Optionen: Vorgabe Mehrheitsentscheidung; eine festgelegte Anzahl von Standorten, die Nicht erreichbar bestätigen (fügt einen Regler von 1-7 hinzu); keine Nachprüfung; vollständige Übereinstimmung aller Nachprüfungsstandorte; oder vollständige Übereinstimmung für Nicht erreichbar, Mehrheitsentscheidung für Erreichbar.
• Wenn ausgewählte Standorte nicht verfügbar sind - Nur ausgewählte Standorte (Vorgabe) wartet, statt einen Fehlalarm zu riskieren; Nächstgelegene Standorte nutzt den nächsten verfügbaren Standort; Beliebiger Standort weicht weltweit aus.

Durchgerechnetes Beispiel

Überwachung eines JSON-Statusendpunkts: API-Prüfung, 5-Minuten-Intervall, 40s Timeout, GET, Weiterleitungen folgen (max. 20). Antwortformat JSON-Analyse, Selektor $.status, Was zu prüfen ist "der erhaltene Wert selbst", Bedingung "gleich" mit Vergleichswert ok. HTTP-Fehler ignorieren leer gelassen. Überwachungsstandorte auf Ganze Welt mit der Standard-Nachprüfungsstrategie belassen. Die E-Mail des Bereitschaftsteams für Down, Up und Repeat abonniert, sowie für Weekly-Berichte.

Problembehandlung

• Die Prüfung besteht immer, obwohl der Endpunkt eindeutig kaputt ist - Bedingung ist standardmäßig beliebig (keine Prüfung), was nur Parsing und Transport beurteilt, nicht den Wert selbst. Wählen Sie eine echte Bedingung und einen Vergleichswert, sobald Sie wissen, wie eine gesunde Antwort aussieht.
• Selektor liefert nichts - bestätigen Sie, dass das Antwortformat dem entspricht, was der Endpunkt zurückgibt (JSON vs XML vs Klartext); ein JSONPath-Selektor gegen einen XML-Body passt nie. Lassen Sie den Selektor zuerst leer, um zu bestätigen, dass die gesamte Antwort ankommt, und grenzen Sie dann ein.
• Eine numerische Bedingung (größer als, im Bereich usw.) meldet einen Fehler - sie braucht den ausgewählten Wert als Zahl konvertierbar. Ein Selektor, der auf einen String zeigt, oder eine Änderungsmodus-Berechnung ohne bisherige vorherige Prüfung, gibt ihr nichts zum Vergleichen.
• Direkt nach dem Einschalten von HTTP-Richtlinien (besonders Strict) auf Down gegangen - Strict erwartet Header, die viele APIs nicht konfiguriert haben. Beheben Sie die Header, wechseln Sie zu Baseline, oder führen Sie die Richtlinien zuerst als separate Aufgabe aus.
• Der Selektor findet bei einer großen Antwort keinen Wert mehr - Maximale Antwortgröße schneidet den Body ab, sodass nichts hinter dem Schnittpunkt den Parser oder Selektor erreicht. Erhöhen Sie sie.

Verwandte Themen

• API-Monitoring und -Validierung - die Produktseite für diesen Prüfungstyp.
• Kostenlose Sofort-HTTP-/API-Prüfung - führen Sie eine einmalige Prüfung ohne benötigtes Konto aus.
• Assertion-Modus-Regeln zur Antwortvalidierung - die vollständige Regelsprache hinter der Antwortvalidierung.
• HostTracker-API - automatisieren Sie die Monitor-Verwaltung aus Ihrem eigenen Code.
• API-v2-Dokumentation - die vollständige Referenz für die API, mit der Integrationen gebaut werden.
• 429 Too Many Requests - der Status, den eine API zurückgibt, wenn der Aufrufer ratenbegrenzt ist, und was dagegen zu tun ist.
• Alle Monitoring-Anleitungen - die Einrichtungsanleitung für jeden anderen Prüfungstyp.