Monitore und Checktypen

Die 13 Typen

http, http_headers, tcp, dns, dns_hygiene, domain, ssl_cert, smtp, imap, ping, traceroute, agent und heartbeat. Die Checktyp-Referenz erklärt jeden davon im Klartext. Die Abschnitte unten behandeln die Konfiguration.

HTTP-Monitore

• Assertions: erwarteter Statuscode, ein Stichwort, das der Body enthalten muss, oder ein regulärer Ausdruck auf den Body.
• Mitlaufende Subchecks: Ein http-Monitor bringt Subchecks für das TLS-Zertifikat (Ablauf, Aussteller, Erkennung selbstsignierter Zertifikate), für Security-Header und für DNS-Hygiene direkt mit. Ein Monitor deckt damit ab, wofür früher vier nötig waren.
• Redirects: werden bis zu 5 Hops weit verfolgt. Perstat prüft jeden Hop vor dem Abruf gegen SSRF-Ziele: private Adressbereiche, Link-local, Metadaten-Endpunkte.

Dual-Stack-Verhalten

Ein Check läuft über alle A- und AAAA-Einträge und liefert ein Ergebnis je Adressfamilie und je IP. Ob ein Fehler, der nur IPv6 trifft, als beeinträchtigt oder als Ausfall zählt, entscheiden Sie je Monitor. dns_ms wird getrennt von der Gesamtlatenz ausgewiesen.

DNS im Einzelnen

Ein dns-Monitor vergleicht die Antwortmenge mit Ihrer Erwartung und kann sie zusätzlich der Antwortmenge eines zweiten Monitors gegenüberstellen. Weicht etwas ab, läuft das durch dieselbe Incident-Verarbeitung wie alles andere. dns_hygiene prüft SPF, DMARC und CAA als Konfiguration. domain behält NS, SOA, DNSSEC und den WHOIS-Ablauf im Blick.

Einen bestimmten Nameserver fragen. Ohne weitere Angabe fragt ein dns-Monitor den Resolver von Perstat und misst damit die Zone als Ganzes, samt Cache. Tragen Sie server ein (einen Namen wie a.example-ns.net oder eine IP), fragt der Check genau diesen Server direkt, ohne Cache dazwischen. So sehen Sie, wenn ein einzelner Nameserver einer Gruppe ausfällt oder anders antwortet als seine Geschwister, was eine Prüfung gegen die ganze Zone nicht zeigen kann. Zusammen mit einem Querverweis zwischen zwei solchen Monitoren wird eine Abweichung zwischen zwei Servern zum Incident.

Bei Anycast erreicht jede Prüfregion den ihr nächsten Knoten, mehrere Regionen decken also mehrere physische Knoten derselben Adresse ab. Die tatsächlich erreichte Adresse steht beim Ergebnis. Meldet der Server NSID oder id.server, sehen Sie auch, welcher Knoten geantwortet hat.

Intervalle

Das Intervall stellen Sie je Monitor ein, bis hinunter zum Minimum Ihres Tarifs: Free 300 s, Pulse 60 s, Sentinel 30 s, Command 15 s, Enterprise 10 s. Das Webformular bietet 30 Sekunden bis 1 Stunde. Die REST-API und MCP setzen jedes Intervall vom Minimum Ihres Tarifs bis 24 Stunden, also auch 15 s bei Command und 10 s bei Enterprise. Die vollständigen Limit-Tabellen stehen unter Tarife und Limits.

Agent-Monitore

Der Typ agent hängt einen Monitor an einen Host-Agent: Verfügbarkeit mit Karenzzeit, CPU, Arbeitsspeicher und Festplatte gegen Schwellenwerte, dazu benannte Dienste mit Karenz gegen Flapping. Fehlende Daten gelten als ausstehend, nie als Fehlalarm. Ein Agent, der schweigt, gilt als ausgefallen.

Heartbeat-Monitore

Der Typ heartbeat dreht die Richtung um: Statt dass Perstat Ihren Dienst aufruft, meldet sich Ihr Job bei Perstat. Das ist der richtige Typ für einen Cron-Lauf, einen Stapelimport, eine Sicherung, alles ohne Adresse zum Anklopfen.

Jeder Heartbeat hat zwei Endpunkte, und Ihr Job entscheidet, welchen er ruft:

https://api.perstat.io/ping/<token>        # sauber durchgelaufen
https://api.perstat.io/ping/<token>/fail   # gelaufen, aber etwas stimmt nicht

Beide nehmen GET wie POST, ein curl im Shell-Skript genügt also. Die genaue URL eines Monitors steht auf seiner Detailseite in der App und in der API, und ein Agent erhält sie über MCP beim Anlegen des Monitors. Verdrahten Sie sie gleich nach dem Anlegen im Job: Die Abdeckung beginnt mit dem ersten Ping.

Zwei Einstellungen entscheiden, wann er bricht. period_seconds ist, wie oft Sie die Meldung erwarten, von 30 Sekunden bis 30 Tage. grace_seconds ist die Toleranz obendrauf, damit eine Sicherung, die gelegentlich länger läuft, niemanden weckt. Setzen Sie die Toleranz auf einen echten Bruchteil der Periode und nicht auf eine symbolische Minute.

• Stille über Periode plus Toleranz hinaus bricht.
• Ein Ruf auf den Fehlschlag-Endpunkt bricht bei der nächsten Auswertung, also binnen etwa einer halben Minute, statt die Periode abzuwarten.

Ein Heartbeat bleibt unbekannt, bis sein erster Ping eintrifft, denn ein Zeitplan zählt erst, wenn Ihr Job ihn bestätigt hat.

Eine Bedingung melden, die Ihr Job auswertet

Weil Ihre Seite den Endpunkt wählt, trägt ein Heartbeat jede Bedingung, die ein Skript entscheiden kann, über “der Job lief” hinaus. Ein Timer, der eine Warteschlangenlänge, eine Anzahl Datensätze oder die Größe eines Verzeichnisses prüft und dann den passenden Endpunkt ruft, macht aus einer lokalen Messung einen Incident:

if [ "$(records)" -ge 1000 ]; then
  curl -fsS -m 10 "https://api.perstat.io/ping/$TOKEN" >/dev/null
else
  curl -fsS -m 10 "https://api.perstat.io/ping/$TOKEN/fail" >/dev/null
fi

Das drückt aus, was eine Schwelle auf einem Host-Messwert nicht kann, etwa eine Anzahl, die unter ihren Sollwert gefallen ist. Ein Heartbeat trägt eine Bedingung, geben Sie also jeder Aussage ihren eigenen Monitor.

Nächste Schritte

• Quorum und Regionen: wie aus regionalen Ergebnissen ein bestätigter Zustand wird.
• Alarmierung und Rufbereitschaft: wer geweckt wird, und wie.