Checktypen

Der Tarif bestimmt Intervalle und Regionen

Je nach Tarif gehen Intervalle bis auf 10 Sekunden herunter. Das Webformular bietet 30 Sekunden und länger. Kürzere Intervalle setzen Sie über MCP. Die Preisseite nennt das kürzeste Intervall je Tarif.

Die 11 regionalen Checktypen nutzen die Regionen, die der Tarif enthält: 2 in Free, 3 in Pulse und alle 6 ab Sentinel. Ihre regionale Regel ist konfigurierbar und nutzt standardmäßig ein Quorum von 2 Regionen. Die Seite Uptime-Monitoring erklärt die regionale Regel.

agent und heartbeat tragen keine Region und brauchen kein Quorum, weil die Meldung von Ihrem Host oder aus Ihrem Job kommt.

URLs und Security-Header prüfen

http ruft eine URL ab und prüft das Ergebnis: einen erwarteten Statuscode, ein Stichwort, das im Body stehen muss, oder einen regulären Ausdruck auf den Body. Der Check folgt Weiterleitungen über bis zu 5 Sprünge und prüft jeden Sprung vor dem Abruf gegen SSRF-Ziele. Ein http-Monitor kann außerdem optionale Subchecks für TLS-Zertifikat, Security-Header und DNS-Hygiene tragen, sodass ein Monitor abdeckt, wofür es früher vier brauchte. Nur der Zertifikats-Subcheck braucht https.

http_headers prüft Security-Header als eigenen Monitor mit eigener Aufzeichnung.

DNS, Domains und Zertifikate prüfen

dns löst einen Namen auf und vergleicht die Antworten mit dem, was Sie erwarten. Ein DNS-Monitor kann seine Antworten außerdem mit den Antworten eines anderen Monitors abgleichen. Eine Abweichung läuft durch die normale Incident-Verarbeitung.

dns_hygiene prüft SPF, DMARC und CAA als Konfiguration. Diese Records entscheiden, ob Ihre Mail zugestellt wird und wer Zertifikate für Sie ausstellen darf.

domain beobachtet die Registrierungsebene: NS- und SOA-Konsistenz, DNSSEC und den WHOIS-Ablauf. Eine Domain im Warnfenster, standardmäßig 14 Tage, wird als eingeschränkt gemeldet.

ssl_cert beobachtet ein Zertifikat direkt, unabhängig von jedem http-Monitor. Der Check prüft Gültigkeit, Kette, Ablauf und Aussteller und erkennt selbstsignierte Zertifikate.

Mailserver prüfen

smtp und imap prüfen den Mailweg, von dem Passwort-Resets und Rechnungen abhängen. Aus den Prüfregionen Ihres Tarifs prüfen sie, ob der Server Verbindungen annimmt und sein Protokoll spricht.

Erreichbarkeit und Netzpfad prüfen

ping prüft, ob der Host überhaupt erreichbar ist. tcp prüft, ob ein Port eine Verbindung annimmt, auf Wunsch mit dem TLS-Zertifikat, das dieser Port ausliefert. traceroute zeichnet den Pfad auf und liefert den Nachweis, wenn ein Netz dazwischen den Fehler verursacht und nicht Ihr Dienst.

Einen Host mit dem Agenten überwachen

agent bindet einen Monitor an den Host-Agenten. Er prüft die Verfügbarkeit mit Toleranzzeit, CPU, Arbeitsspeicher und Festplatte gegen Schwellwerte sowie benannte Dienste mit Toleranz gegen Flapping. Eine Metrik ohne frische Daten erzeugt kein Ergebnis und damit keinen Fehlalarm, und ein Verfügbarkeitsmonitor meldet einen schweigenden Agenten als ausgefallen.

Eine Zeile installiert den Agenten vom Verteilpunkt, unter Linux (x86_64, aarch64) und unter macOS als Universal Binary. Unter Linux läuft er als gehärtete systemd-Unit. Er erfasst nie Kommandozeilen, Umgebungsvariablen oder Benutzernamen.

Der Agent aktualisiert sich selbst mit ed25519-signierten Releases. Er prüft jedes Release vor dem Austausch, arbeitet fail-closed und braucht keinen Root-Helper. Er deinstalliert sich sauber und meldet sich dabei vom Cockpit ab.

Jobs mit einem Heartbeat überwachen

heartbeat dreht die Richtung um: Ihr Job ruft Perstat, statt dass Perstat Ihren Dienst ruft. Das deckt einen Cronlauf ab, ein nächtliches Backup, einen Importer oder alles andere ohne Adresse, die sich prüfen ließe.

Sie bekommen eine geheime URL, und der Job ruft sie auf, wenn er fertig ist. Bleibt dieser Aufruf länger aus als die Periode plus die Toleranz, die Sie setzen, geht der Monitor auf ausgefallen. Ein Job, der nie lief, ist der Ausfall, den gewöhnliches Monitoring nicht sehen kann, weil nichts kaputtging, das jemand erreichen könnte.

Jeder Heartbeat hat einen Healthy- und einen Failure-Endpunkt. Ein Job, der lief und scheiterte, kann den Failure-Endpunkt aufrufen, der den Monitor bei der nächsten Auswertung auf ausgefallen setzt, statt den Zeitplan abzuwarten. Ihr Skript bestimmt, welchen Endpunkt es aufruft, und kann so jede Bedingung melden, die es prüfen kann, nicht nur, ob der Job lief.

Die Monitor-Dokumentation nennt die genauen URLs.

Regionale Ergebnisse enthalten Diagnosedaten

• IPv4, IPv6 oder beides, je IP. Jeder Erreichbarkeits-Check läuft auf den Adressfamilien, die Sie auswählen, und ohne Auswahl auf IPv4. Die Ergebnisse bleiben nach Familie und IP getrennt. Sie entscheiden, ob ein Ausfall in einer Familie als eingeschränkt oder als ausgefallen zählt.
• DNS-Zeit getrennt. Wo anwendbar, steht dns_ms getrennt von der Gesamtlatenz, damit ein langsamer Resolver nicht wie eine langsame Anwendung aussieht.
• Ursachenzuordnung. Wo ein unterstützter Check aus dem Prüfnetz eine Zuordnung liefert, nennt er die Schicht: Ihre Anwendung oder Ihr DNS, das Netz oder unseren Resolver oder unseren eigenen Knoten. Unknown bleibt gültig, solange die Ursache nicht feststeht, und nicht jedes Ergebnis trägt eine Ursachenschicht.

Kostenlos mit dem Monitoring starten oder die Produkt-Tour ansehen. Die Tour braucht keine Anmeldung.