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, hier geht es um 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. Jeder Hop wird vor dem Abruf gegen SSRF-Ziele geprüft: 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, misst also 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. Erst dann fällt auf, wenn ein einzelner Nameserver einer Gruppe ausfällt oder anders antwortet als seine Geschwister; eine Prüfung gegen die Zone kann das nie zeigen. Zusammen mit einem Querverweis zwischen zwei solchen Monitoren wird eine Abweichung zwischen zwei Servern zum Vorfall.

Bei Anycast bleibt die Frage ehrlich, die Antwort ist aber ortsabhängig: Jede Prüfregion erreicht den ihr nächsten Knoten, mehrere Regionen decken also mehrere physische Knoten derselben Adresse ab. Die tatsächlich erreichte Adresse steht beim Ergebnis. Welcher Knoten geantwortet hat, lässt sich nur unterscheiden, wenn der Server NSID oder id.server meldet.

Intervalle

Das Intervall stellen Sie je Monitor ein; wie kurz es sein darf, hängt vom Tarif ab: Free 300 s, Pulse 60 s, Sentinel 30 s, Command 15 s, Enterprise 10 s. 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 wir Ihren Dienst rufen, ruft Ihr Job uns. 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. Sie verdrahten sie nach dem Anlegen in den Job, und das lohnt sich sofort: ein Heartbeat, den niemand ruft, sieht aus wie Abdeckung, ohne welche zu sein.

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. Das ist Absicht: ein Fahrplan, den niemand bestätigt hat, kann nicht verletzt werden.

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, nicht nur “der Job lief”. 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 deckt ab, was eine Schwelle auf einem Host-Messwert nicht ausdrücken kann, etwa eine Anzahl, die unter ihren Sollwert gefallen ist. Ein Heartbeat trägt eine Bedingung, geben Sie unterschiedlichen Aussagen also unterschiedliche Monitore, statt sie in einen Ping zu falten.