Healthchecks

Mit den Healthchecks überwachst du Webseiten, APIs, DNS-Einträge, Server, Ports, Zertifikate, Domains (WHOIS/RDAP), Cronjobs und Docker-Container. Node64 prüft lokal in deinem Netz – und mit einem verknüpften ipv64.net-Account auf Wunsch zusätzlich von außen. Hier findest du alle Check-Typen, Optionen und Standardwerte.

Überblick

Die Healthchecks sind ein Modul von Node64. Du schaltest es unter Einstellungen → Module ein, danach erscheint der Menüpunkt Healthchecks. Dort siehst du:

• die Liste aller Checks mit Gruppen, Ziel, Zustand und einem Countdown bis zur nächsten Messung,
• Filter nach Suche, Zustand, Typ, Tag und Gruppe, dazu Sortierung und Massenaktionen (pausieren, fortsetzen, jetzt prüfen, löschen, Tag setzen oder entfernen),
• die Seiten Docker (alle Container des Hosts) und Proxmox VE,
• die Störungsliste über alle Checks und die Wartungsfenster,
• die öffentlichen Statusseiten.

Lokale Checks laufen komplett ohne Account und ohne Internet. Für Online- und Hybrid-Checks verknüpfst du die Node mit ipv64.net – siehe Mit ipv64.net verknüpfen.

Ersten Check anlegen

1. Modul einschalten
   Unter Einstellungen → Module die Healthchecks aktivieren.
2. Neuen Check anlegen
   Unter Healthchecks → Neuer Check den Typ wählen, einen Namen vergeben und das Ziel eintragen, zum Beispiel https://www.example.com/.
3. Intervall und Alarmierung prüfen
   Die Standardwerte passen für die meisten Fälle: Messung alle 60 Sekunden, ein Fehlversuch wird wiederholt, nach drei Erfolgen in Folge gilt der Check wieder als OK.
4. Kanäle wählen
   Ohne Auswahl bekommt der Check alle Standardkanäle. Kanäle legst du unter Benachrichtigungen an.
5. Speichern
   Ab jetzt misst Node64 im eingestellten Intervall. Mit Jetzt prüfen stößt du jederzeit eine zusätzliche Messung an.

Check-Typen

Node64 kennt elf Check-Typen, dazu kommt proxmox aus der Proxmox-Überwachung. Der Name in Klammern ist der Wert für die API.

Check aus einem überwachten System: Unter Neuer Check stehen beim Typ Proxmox VE (VM, Container, Node) und Docker-Container. Danach wählst du das Proxmox-System bzw. den Docker-Host und die Maschine bzw. den Container aus dem letzten Abruf; schon geführte Einträge sind markiert und gesperrt. Angelegt wird wie mit Als Check führen: Intervall, Gruppe und Kanäle kommen aus den Regeln des Systems, Meldungen kommen nicht doppelt. Der Name ist optional (leer = „System – Name“); Gruppe, Tags, Messstellen und Meldungs-Optionen sind dabei ausgeblendet. Danach bearbeitest du den Check wie jeden anderen.

HTTP(S)

Ruft eine URL auf und prüft den Statuscode. Bei HTTPS liest Node64 immer Ablaufdatum, Aussteller und TLS-Version des Zertifikats mit; die Meldung zeigt, bis wann das Zertifikat gültig ist. Node64 nutzt mindestens TLS 1.2, keine Keep-Alive-Verbindungen, keinen Proxy und den User-Agent node64.

Beispiel: Der Check Firmenwebseite prüft https://www.example.com/ online von Nürnberg und Falkenstein, warnt unter 21 Tagen Restlaufzeit und misst IPv4 und IPv6 getrennt.

Keyword

Wie HTTP(S), zusätzlich sucht Node64 einen Begriff in den ersten 1 MiB der Antwort. Mit Begriff darf nicht vorkommen (keyword_absent) drehst du die Prüfung um – praktisch, um etwa eine Fehlermeldung auf einer Seite zu erkennen.

Beispiel: Der Check Nextcloud ruft https://cloud.example.com/status.php auf und sucht den Begriff "installed":true.

JSON (API)

Wie HTTP(S) mit allen Optionen, zusätzlich liest Node64 die Antwort als JSON und prüft Bedingungen. Im Formular steht eine Bedingung je Zeile: Pfad Vergleich Wert. Standardmäßig müssen alle erfüllt sein; mit Eine erfüllte Bedingung genügt (json_any) reicht eine.

Der Wert der ersten Bedingung steht in der Meldung (z. B. HTTP 200, queue = 42), als Zahl auch in den Messdetails. In der API heißen die Bedingungen json_rules (Liste aus path, op, value).

Beispiel: Der Check Home Assistant ruft http://homeassistant.local:8123/api/ mit dem Header Authorization: Bearer … auf und prüft message == API running.

DNS

Fragt einen Namen ab und prüft die Antwort; gemessen wird die Antwortzeit. Das Ziel ist der Name, bei PTR auch eine IP-Adresse.

Beispiel: Der Check DynDNS zu Hause fragt home.example.com (A) bei den zuständigen Nameservern ab und erwartet, dass der Name auf die öffentliche IP der Node zeigt.

Ping (ICMP)

Sendet ICMP-Echo-Pakete über IPv4 oder IPv6 im Abstand von 300 ms.

Node64 versucht zuerst unprivilegiertes Ping und fällt sonst auf einen Raw-Socket zurück. Im Container braucht es dafür eine der beiden Einstellungen:

services:
  node:
    # Variante 1: unprivilegiertes Ping erlauben (empfohlen)
    sysctls:
      - net.ipv4.ping_group_range=0 65535
    # Variante 2: Raw-Sockets erlauben
    # cap_add:
    #   - NET_RAW

Beispiel: Der Check FritzBox pingt fritz.box mit 3 Paketen und höchstens 50 % Verlust.

TCP

Prüft, ob sich eine TCP-Verbindung aufbauen lässt. Optional sendet Node64 danach etwas und prüft die Antwort.

Beispiel: Der Check Mailserver SMTP verbindet sich mit mail.example.com auf Port 25 und erwartet die Antwort 220.

Port

Prüft den Zustand eines Ports und unterscheidet offen, geschlossen (Verbindung abgelehnt), gefiltert (keine Antwort) und nicht erreichbar.

Beispiele: NAS (Synology DSM) erwartet Port 5001 auf nas.lan offen. RDP von außen gesperrt prüft online, dass Port 3389 auf vpn.example.com geschlossen bleibt.

Zertifikat

Prüft das TLS-Zertifikat eines Servers: abgelaufen, noch nicht gültig, Kette gegen die System-CAs, passender Hostname und Restlaufzeit. Die Detailseite zeigt Subject, Aussteller, Gültigkeit, Resttage, DNS-Namen und TLS-Version.

Beispiel: Der Check Zertifikat Shop prüft shop.example.com auf Port 443 mit mindestens 14 Tagen Restlaufzeit.

WHOIS / RDAP

Prüft die Registrierungsdaten einer Domain (example.de), einer IP-Adresse bzw. eines Netzes (192.0.2.1, 2001:db8::/32) oder einer AS-Nummer (AS3320). Zuerst fragt Node64 per RDAP beim zuständigen Server (über den IANA-Bootstrap), sonst per klassischem WHOIS über Port 43 – über whois.iana.org zur Registry, bei .de etwa zur DENIC.

• Gestört, wenn die Abfrage scheitert („WHOIS/RDAP-Abfrage fehlgeschlagen“), die Domain nicht (mehr) registriert ist („nicht registriert“), sie bald abläuft oder abgelaufen ist („Domain läuft bald ab“, „Domain abgelaufen“) oder eine erwartete Angabe fehlt („erwartete Angabe fehlt“). Die Gründe für die API: whois_failed, whois_not_found, whois_expiring, whois_expired, whois_mismatch.
• Letzte Messung zeigt, was gefunden wurde: bei Domains Registrar, Status, Nameserver, Erstellt, Geändert, Ablauf und Tage bis Ablauf; bei Netzen und AS Netzname, CIDR bzw. Bereich, AS, Organisation, Land, Stadt und Abuse-Kontakt.
• Rücksicht auf die Server: WHOIS- und RDAP-Server begrenzen Abfragen. Der Check läuft deshalb höchstens stündlich (Intervall ab 3600 s), im gestörten Zustand alle 10 Minuten (ab 600 s); die Antwort darf höchstens 256 KB groß sein.
• Läuft lokal und online bei ipv64; online nur gegen öffentliche Server. Den Typ gibt es auch im ipv64-Portal mit eigenem Formular (Quelle, Warnung vor Ablauf, erwartete Angaben) und über die API v2 mit params.source, min_days und contains – mit denselben Grenzen.

Beispiel: Der Check Domain example.de warnt 30 Tage vor Ablauf und erwartet nameserver: ns1.example.org und status: connect.

Push / Heartbeat

Hier misst nicht Node64, sondern dein Dienst meldet sich selbst – ideal für Backups, Cronjobs und Skripte. Bleibt der Aufruf länger als Periode plus Kulanz aus, ist der Check gestört.

Nach dem Speichern zeigt die Detailseite die Push-URL und einen fertigen curl-Aufruf. Es gibt zwei Adressen:

• Lokal (diese Node): /api/push/{token} an deiner Node, im eigenen Netz erreichbar und ohne Anmeldung. Der Push zählt auch, wenn das Internet weg ist.
• Online über ipv64: mit verknüpfter Node zusätzlich eine Adresse, die von überall erreichbar ist. ipv64 reicht den Push an deine Node weiter, solange sie verbunden ist.

# Alles in Ordnung melden
curl -fsS -m 10 http://node64.lan:8080/api/push/DEIN_PUSH_TOKEN

# Selbst eine Störung melden, mit kurzer Meldung (max. 200 Zeichen)
curl -fsS -m 10 "http://node64.lan:8080/api/push/DEIN_PUSH_TOKEN?status=down&msg=backup+fehlgeschlagen"

# Daten mitschicken: der Body (max. 4 KiB, JSON oder Text) wird an der Messung gespeichert
curl -fsS -m 10 -X POST --data '{"files": 1200}' http://node64.lan:8080/api/push/DEIN_PUSH_TOKEN

Beispiel Backup-Job (Push): Periode 86 400 s (ein Tag), Kulanz 3600 s. Der Cronjob meldet sich nur, wenn das Backup erfolgreich war, und meldet sonst selbst eine Störung:

# Jede Nacht um 02:30 – Erfolg melden oder Störung melden
30 2 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 http://node64.lan:8080/api/push/DEIN_PUSH_TOKEN >/dev/null || curl -fsS -m 10 "http://node64.lan:8080/api/push/DEIN_PUSH_TOKEN?status=down&msg=backup+fehlgeschlagen" >/dev/null

Docker-Container

Docker hat eine eigene Seite: Docker überwachen – die Überwachung aller Container eines Hosts, der Check-Typ docker (Ziel: Name oder ID des Containers, nur lokal), der Zugriff auf den Docker-Socket und Docker-Hosts aus der Ferne.

Zugriff auf den Docker-Socket und docker-socket-proxy: siehe Docker → Zugriff auf den Docker-Socket.

Docker-Hosts per SSH, TLS oder TCP: siehe Docker → Docker-Hosts aus der Ferne.

Intervalle, Timeouts und Alarmierung

Diese Optionen gelten für alle Check-Typen. Beim Push-Check ersetzen Periode und Kulanz das Intervall.

Damit nicht alle Checks gleichzeitig messen, verteilt Node64 die Messungen mit 10 % Zufallsabweichung vom Intervall. Standardmäßig laufen höchstens 20 Messungen parallel.

Lokal, online oder hybrid

Unter Messstellen und Bewertung legst du fest, wer einen Check misst. Online und Hybrid brauchen eine mit ipv64.net verknüpfte Node.

Messstellen und Bewertungsregel

• Online-Standorte (locations): Die Liste kommt von ipv64. Mehrere Standorte gibt es ab der Account-Klasse Supporter (siehe ipv64.net/pricing).
• Messende Nodes (nodes): Mehrere Nodes deines Accounts können denselben Check messen, etwa an verschiedenen Standorten oder über VPN. Jede Node erscheint als eigene Messstelle.
• Gestört, wenn … (policy): all – alle Messstellen gestört melden (Standard), any – eine Messstelle gestört meldet, majority – die Mehrheit gestört meldet.
• Teilweise gestört: Meldet nur ein Teil der Messstellen eine Störung, ohne dass die Regel greift, ist der Check „teilweise gestört“. Eine Nachricht dazu gibt es nur, wenn du Auch bei „teilweise gestört“ benachrichtigen (notify_degraded) einschaltest.
• Messstellen ohne frische Daten (älter als drei Intervalle, mindestens 5 Minuten) zählen nicht mit.

 # Messstellen                    # Gesamtzustand (Regel „alle“)
 Diese Node (innen)   OK       ──┐
 Nürnberg             gestört  ──┼──►  Teilweise gestört
 Falkenstein          gestört  ──┘     Diagnose: Internetanbindung,
                                       Portweiterleitung, DNS oder Firewall

Diagnose innen und außen

Bei Hybrid-Checks vergleicht die Detailseite die Messstellen in deinem Netz mit denen von ipv64 und zeigt eine Diagnose:

Beispiel: Der Hybrid-Check Nextcloud wird von deiner Node sowie von Nürnberg und Falkenstein gemessen.

Private Ziele und Kontingent

• Private Ziele (private IP-Adressen, Loopback, Link-Local, .local, localhost) kann ipv64 von außen nicht erreichen. Node64 lehnt Online und Hybrid für solche Ziele ab – sie bleiben lokal.
• Nur öffentliche Adressen: ipv64 prüft bei jeder Online-Messung die tatsächliche Zieladresse beim Verbindungsaufbau – auch nach der DNS-Auflösung, nach Weiterleitungen und beim eigenen DNS-Server eines DNS-Checks. Zeigt ein Hostname, eine Weiterleitung oder ein DNS-Server auf eine interne oder reservierte Adresse (privat, CGNAT, Loopback, Link-Local, ULA, Multicast, Dokumentationsbereiche, NAT64, 6to4, Teredo), ist die Messung gestört mit „target resolves to a private or reserved address“. Solche Ziele misst du lokal.
• Grenzen online: Bei ipv64 gelten höchstens 30 s Verbindungs- und 60 s Gesamt-Timeout; längere Werte werden für die Online-Messung gekürzt, lokal bleiben sie. Im gestörten Zustand misst ipv64 frühestens alle 20 s.
• Missbrauchsbremse je Ziel: Je Zielhost gibt es über alle Konten eine Obergrenze (600 Läufe pro Minute je ipv64-Server). Darüber hinaus fällt ein Lauf aus, ohne den Zustand zu ändern. Im Normalbetrieb wird die Grenze nicht erreicht.
• Lokale Messungen zählen nie gegen das Healthcheck-Limit deiner Account-Klasse, nur Online-Messstellen.
• Das Formular zeigt vorab, wie viele Online-Messungen ein Check pro Tag verbraucht, und rechnet den ganzen Account hoch. Ist das Tageskontingent erreicht, bekommst du eine Benachrichtigung; Online-Messungen und Push-Auswertung bei ipv64 pausieren dann bis Mitternacht – oder bis zu einem Upgrade der Account-Klasse, das sofort freigibt. Die lokalen Messungen laufen weiter.
• Von ipv64 testen: Bevor du einen Check auf online oder hybrid umstellst, misst der Knopf im Formular die Eingabe einmal von den ipv64-Standorten aus und zeigt das Ergebnis je Standort. Gespeichert wird dabei nichts. Bei „Lokal auf Nodes“ sind der Knopf und die Online-Standorte ausgeblendet.
• Standorte, die deine Account-Klasse nicht enthält, sind im Formular gesperrt; es zeigt, wie viele Online-Messstellen schon belegt sind, und prüft das Limit beim Speichern – genau wie im ipv64-Portal.
• Über der Check-Liste zeigt eine Konto-Leiste deine Account-Klasse, belegte und erlaubte Online-Messstellen, die Zahl der Checks je Ausführungsort (online, lokal, hybrid) und wie viele Nodes gerade online sind. Die Liste lässt sich außerdem nach Ausführungsort und nach Node filtern.
• Unter der Check-Tabelle zeigt die Karte Online-Messungen heute (Tageskontingent) den Verbrauch von heute als Balken und rechnet aus den aktiven Online- und Hybrid-Checks (Intervall × Standorte, Push nicht) bis Mitternacht hoch. Reicht das Kontingent nicht, steht dort, wann es voraussichtlich erreicht ist; ist es erreicht, sind Online-Messungen bis Mitternacht oder bis zu einem Upgrade pausiert, die lokalen laufen weiter. Braucht ein ganzer Tag mehr als das Kontingent, weist die Karte darauf hin und verlinkt die Tarife. Die Karte erscheint nur bei Klassen mit Tageskontingent (Free, Home/Supporter).
• Online-Checks kannst du auch ohne Sync direkt über die ipv64 API v2 mit deinem API-Key verwalten (anlegen, ändern, pausieren, prüfen, löschen). Hybrid, Live-Zustände und Benachrichtigungen über ipv64 brauchen den Sync.

Wenn die Verbindung zu ipv64 fehlt

Die Node baut die Verbindung zu ipv64 selbst auf, ausgehend und verschlüsselt – eine Portfreigabe ist nicht nötig. Es gibt zwei gleichwertige ipv64-Server in Deutschland (Nürnberg und Falkenstein); fällt einer aus, wechselt die Node zum anderen. Fehlt die Verbindung ganz, läuft die Node eigenständig weiter: Sie misst, speichert Messwerte und Ereignisse lokal, benachrichtigt über ihre eigenen Kanäle und lädt alles nach, sobald die Verbindung wieder steht.

Zustände

Zu jeder Messung speichert Node64 einen Grund wie Zeitüberschreitung, DNS-Fehler, TLS-Fehler, Falscher HTTP-Status, Schlüsselwort fehlt, Paketverlust, Zertifikat läuft bald ab, Push ausgeblieben oder Container ungesund. Mit ipv64.net verknüpft meldet ipv64 bei „Nicht überwacht“ aktiv, dass der Check nicht mehr geprüft wird – und später, dass er wieder geprüft wird.

Wartungsfenster

Während eines Wartungsfensters laufen die Checks weiter, es gibt aber keine Alarme. Die Messpunkte sind markiert und zählen nicht gegen die Verfügbarkeit. Du findest die Fenster unter Healthchecks → Wartungsfenster.

Mit ipv64.net verknüpft und im Cluster werden Wartungsfenster automatisch abgeglichen.

Gruppen und Tags

• Gruppe (group, bis 100 Zeichen): ein frei wählbarer Name wie „Heimnetz“, „Webseiten“ oder „Docker“. Checks mit gleicher Gruppe stehen in der Liste zusammen.
• In den Gruppen Proxmox VE und Docker gibt es je Proxmox-System bzw. Docker-Host eine aufklappbare Untergruppe mit Zählern. Ihr Name kommt live aus der Überwachung – bei Proxmox der Clustername aus dem letzten Abruf, sonst der Systemname, bei Docker der Hostname. Dafür trägt jeder Check, der aus Proxmox VE oder Docker „als Check“ geführt wird, den Systemnamen in params.system; die Node hält ihn bei jedem Abruf aktuell, und er geht per Sync an ipv64. So erscheinen auch Checks anderer Nodes unter ihrem Systemnamen (Docker: „Name · Node“). Ob eine Untergruppe auf- oder zugeklappt ist, merkt sich der Browser. Auch das ipv64-Portal zeigt die Gruppen aufklappbar, mit Untergruppen je System bzw. Host; in der API v2 ist system optional und dient nur der Anzeige.
• Tags (tags): beliebig viele Stichworte je Check, z. B. cloud, ssl oder kritisch (ohne Komma). Über die Massenaktion setzt oder entfernst du einen Tag bei vielen Checks auf einmal.
• Liste und Filter arbeiten mit beiden: Suche, Zustand, Typ, Tag und Gruppe lassen sich kombinieren.
• Mit Klonen legst du eine Kopie eines Checks an. Die Kopie ist zunächst pausiert.

Übergeordnete Checks

Fällt dein Router aus, sind auch alle Geräte dahinter nicht erreichbar. Damit du dann nicht zehn Nachrichten bekommst, gibst du diesen Checks einen übergeordneten Check (parent). Ist er gestört, alarmieren die abhängigen Checks nicht selbst, sondern stehen auf „Abhängig gestört“. Diese Messpunkte zählen nicht gegen die Verfügbarkeit.

Beispiel: FritzBox ist der übergeordnete Check für Home Assistant, Proxmox VE und NAS (Synology DSM). Die Detailseite der FritzBox listet ihre abhängigen Checks auf. Kreise – A hängt von B ab und B von A – lehnt Node64 ab.

Historie und Verfügbarkeit

Die Detailseite eines Checks zeigt:

• die Ereignisse als farbige Kennzeichen (z. B. gestört, wieder OK, flattert, nicht überwacht) – mit ipv64.net verknüpft auch die Ereignisse, die ipv64 selbst bewertet hat (mit Wolken-Symbol, z. B. nicht überwacht, wieder geprüft, teilweise gestört); bei Störungen mit Dauer und Grund (ebenso in der Störungsliste),
• ein Diagramm je Messstelle (diese Node, andere Nodes, ipv64-Standorte). Ein Klick auf einen Eintrag der Legende zeigt nur diese Messstelle, mit Strg-Klick mehrere.
• Zeiträume 1 h, 6 h, 24 h, 7 Tage, 30 Tage und 1 Jahr,
• die Verfügbarkeit in Prozent und die Antwortzeit (min, Ø, max),
• Ereignisse mit Grund und HTTP-Code, Störungen mit Beginn, Ende, Dauer und Grund sowie Wartungsfenster,
• die letzte Messung im Detail als JSON.

Unter Healthchecks → Störungen siehst du alle Störungen über alle Checks, filterbar nach Tagen und „nur offene“.

Ereignisse und abgeschlossene Störungen folgen den Stundenwerten; Tageswerte bleiben unbegrenzt. Eingestellt wird unter Einstellungen → Daten & Sicherung (Übersicht).

Mit ipv64.net verknüpft lädt die Node den Verlauf fremder Messstellen vom Server nach: Einzelmessungen der letzten 2 Tage und Stundenwerte für 90 Tage.

Statusseiten

Mit einer Statusseite zeigst du Besuchern, Kunden oder der Familie, ob deine Dienste laufen – öffentlich und ohne Zugang zur Oberfläche. Du findest sie unter Healthchecks → Statusseiten. Eine Seite zeigt beliebig viele Checks, gegliedert nach den Gruppen der Healthchecks. Zustand, Tagesbalken und Verfügbarkeit rechnet Node64 aus den Messungen, die ohnehin laufen.

Was auf der Seite steht

• Im Kopf dein Logo neben dem Titel; es dient auch als Favicon im Browser-Tab. Ohne eigenes Logo zeigt der Tab das Node64-Logo.
• Oben ein Gesamtbanner: alle Systeme betriebsbereit, teilweise gestört, Störung oder Wartung.
• Gruppen – immer die Gruppen der Healthchecks wie „Webseiten“ oder „Heimnetz“, in „Proxmox VE“ und „Docker“ mit dem Systemnamen (etwa „Proxmox VE · Cluster“); Checks ohne Gruppe stehen unter „Weitere“. Gruppen mit Problemen bleiben aufgeklappt, Probleme stehen oben.
• Je Eintrag der Zustand, Tagesbalken für 30, 60 oder 90 Tage und auf Wunsch die Verfügbarkeit in Prozent. Ein Tag ist grün, gelb bei einer Teilstörung, rot bei einer Störung, blau bei einer Wartung und grau ohne Daten.
• Ein Klick auf einen Eintrag zeigt die Verfügbarkeit über 24 Stunden, 7 und 30 Tage, die durchschnittliche Latenz, 24 Stundenbalken und die letzten Störungen.
• Störungen und Wartungsfenster erscheinen von selbst: laufende Wartungen oben, geplante der nächsten 7 Tage als Hinweis. Der Grund einer Störung steht nur allgemein da, etwa „nicht erreichbar“ oder „Zeitüberschreitung“.
• Ankündigungen schreibst du selbst – siehe Ankündigungen.
• Optional ein Verlauf mit den Störungen und Ankündigungen der letzten 30 Tage.

Online-Checks zählen mit: Gibt es für einen Tag keine eigenen Messungen der Node, nimmt die Seite die Messungen von ipv64 (bei „beides“ ohne doppelt zu zählen). Fehlen Daten ganz, steht „–“. Die Seite passt sich an jede Größe an, vom Handy bis zum 4K-Monitor – in der Ansicht Kacheln wachsen Schrift und Kacheln auf großen Bildschirmen maßvoll mit, Liste und Kompakt bleiben gut lesbar und werden nicht übergroß.

Ein gelöschter Check verschwindet von der Seite, ein pausierter steht auf „pausiert“.

Seite anlegen

Einträge sind eine einfache Liste mit Name, Gruppe, Anzeigename und Entfernen. Gruppiert wird auf der Seite immer nach den Gruppen der Healthchecks; die Gruppen legst du am Check fest (siehe Gruppen und Tags).

Checks hinzufügen ist eine gemeinsame Liste für alle Checks und dazu für Nodes, VMs, LXC und Container aus der Proxmox- und Docker-Überwachung, die noch keinen Check haben. Die Suche findet auch den Systemnamen, filtern kannst du nach Gruppe und Tag; Sichtbare auswählen markiert alle gefilterten, Ausgewählte hinzufügen übernimmt sie.

Hat ein Node, Gast oder Container noch keinen Check (Badge „neuer Check“), legt Node64 ihn beim Hinzufügen an wie mit „Als Check führen“ – mit den Benachrichtigungen aus den Proxmox- bzw. Docker-Regeln und ohne doppelte Meldungen; Systeme ohne Daten zeigen „Noch keine Daten“. Wird ein Check gelöscht – auch über eine andere Node, über ipv64 oder durch Abschalten von „Als Check führen“ –, verschwindet er von allen Statusseiten.

Ansichten

Ansicht „Kacheln“ für den Monitor an der Wand – Probleme springen sofort ins Auge.

Auf dem Handy

Einbetten ist bei Seiten ohne Passwort von überall erlaubt; mit Passwort nur von derselben Adresse.

<iframe src="https://status.example.com/" width="100%" height="220"
        style="border:0" title="Status"></iframe>

Veröffentlichen

Eine neue Seite ist aus und kostet nichts. Eingeschaltet steht sie standardmäßig direkt auf dem Port der Node; eine eigene Domain über PROXY64 ist der optionale Weg. Erst wenn jemand die Seite abruft, rechnet Node64 sie aus, hält das Ergebnis 30 Sekunden im Zwischenspeicher und liefert es komprimiert aus. Viele Besucher belasten die Node so kaum.

Soll die Seite nur über die eigene Domain erreichbar sein, schaltest du „Auf dem Node-Port veröffentlichen“ aus.

status.json, Badges und Feed

Jede Seite hat dazu feste Pfade. Sie hängen an der Adresse der Seite – bei eigener Domain an /, auf dem Node-Port an /status/<slug>/.

Die Antworten sind 30 Sekunden zwischengespeichert. Ist die Seite mit einem Passwort geschützt, gibt es diese Pfade erst nach der Anmeldung (sonst 401).

# Zustand als JSON, ohne Anmeldung
curl -s https://status.example.com/status.json

# Badge in einer README (Markdown)
![Status](https://status.example.com/badge.svg)
![Blog](https://status.example.com/badge/4.svg?type=uptime)

Ankündigungen

Für geplante Arbeiten oder ein Problem, das die Checks nicht sehen – etwa „Mailversand verzögert“ –, schreibst du eine Ankündigung. Du findest sie in der Liste der Statusseiten beim Megafon-Symbol.

• Titel (bis 200 Zeichen), Text in einfachem Markdown (bis 5000 Zeichen) und eine Stufe: Info, Warnung oder Störung.
• Eine offene Ankündigung steht oben auf der Seite, bis du sie als erledigt markierst.
• Mit Update anhängen ergänzt du den Stand, z. B. „Ursache gefunden“ oder „läuft wieder“. Die Updates erscheinen als Zeitleiste, die Stufe kannst du dabei ändern.
• Als erledigt markieren nimmt sie von oben weg. Mit eingeschaltetem Verlauf bleibt sie 30 Tage unter „Frühere Ankündigungen“ sichtbar, in der Verwaltung 90 Tage unter „Erledigt“.
• Ankündigungen stehen auch im Feed (feed.atom) und in status.json.

Export und Import

Unter Einstellungen → Daten & Sicherung exportierst du die Konfiguration als JSON-Datei. Für die Healthchecks enthält sie alle Checks, Wartungsfenster, Proxmox-Systeme und die Statusseiten mit Einträgen und Logo, aber keine Messdaten. Den Passwort-Hash einer geschützten Statusseite enthält nur der Export mit Passwort, sonst kommt die Seite ausgeschaltet an; Ankündigungen bleiben auf der Node.

• Geheimnisse wie Tokens und Passwörter lässt du entweder weg oder verschlüsselst sie mit einem Passwort (mindestens 8 Zeichen).
• Beim Import gleicht Node64 Checks über ihren Token ab, Kanäle und Wartungsfenster über den Namen, Statusseiten über den Slug. Es wird nichts gelöscht.
• Importierte Checks zeigen auf die passenden Kanäle der Ziel-Node.

Ein vollständiges Backup mit allen Messdaten erstellst du im selben Bereich – mehr dazu unter Update & Backup.

API-Kurzüberblick

Alles, was die Oberfläche kann, geht auch per JSON-API. Du meldest dich mit einem API-Key an (Authorization: Bearer …) – Details und Beispiele stehen unter Lokale API. Die vollständige Referenz liegt in deiner Node unter /api/docs, die OpenAPI-3.1-Beschreibung unter /api/openapi.json.

# Hybrid-Check „Nextcloud“ anlegen
curl -X POST http://node64.lan:8080/api/checks \
  -H "Authorization: Bearer DEIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Nextcloud", "type": "keyword",
    "target": "https://cloud.example.com/status.php",
    "params": {"keyword": "\"installed\":true"},
    "execution": "both", "locations": ["nbg", "fsn"], "policy": "all",
    "group": "Webdienste", "tags": ["cloud"]
  }'

# Verfügbarkeit der letzten 24 Stunden
curl -H "Authorization: Bearer DEIN_API_KEY" \
  "http://node64.lan:8080/api/checks/CHECK_TOKEN/stats?range=24h"

Für stats gibt es die Zeiträume 1h, 24h, 7d, 30d und 1y. Im JSON eines Checks zeigt state.unchecked: true den Zustand „Nicht überwacht“ an.

Prometheus

Node64 stellt unter GET /api/metrics (mit Anmeldung) Metriken für Prometheus bereit. Für die Healthchecks sind das je Check unter anderem Zustand, up/down, Wartung, Zeitpunkt der letzten Messung, Latenz, Fehlversuche in Folge, Intervall und der Ablauf von Zertifikaten – dazu die Anzahl der Checks je Zustand und die offenen Störungen. Einrichtung und Grafana-Tipps findest du unter Prometheus & Grafana.

Etwas unklar, fehlt etwas oder hast du eine Frage zu Node64? Frag im offiziellen Forum v64.tech.