Monitor64

Monitor64 überwacht Systeme mit Schwellen und Verlauf: Server, NAS, Hypervisor, Container, Netzwerkgeräte, USV und Drucker. Du siehst CPU, RAM, Dateisysteme, Platten samt SMART, Netzwerk-Ports, Temperaturen, Updates und Dienste – und bekommst eine Meldung, sobald etwas eine Schwelle überschreitet. Gedacht für Homelab bis Mittelstand, bewusst leichter als CheckMK oder Zabbix.

So funktioniert es

• Das Modul ist standardmäßig aus. Ausgeschaltet läuft nichts, es ist kein Port offen und es entstehen keine Tabellen.
• Ein Host ist ein überwachtes System. Er hat einen oder mehrere Zugänge (z. B. Proxmox-API und zusätzlich der Agent für Bonding und Temperaturen).
• Jeder Zugang liefert Dienste (CPU, Dateisystem /, Platte sda, VM 100 …). Dienste werden erkannt, aber nie automatisch übernommen.
• Abgefragt wird jede Minute (je Host einstellbar von 30 Sekunden bis 15 Minuten). Die Node fragt ab – auf den Hosts läuft höchstens der kleine Agent.
• Alle Daten bleiben lokal auf deiner Node. Für Monitor64 wird kein ipv64.net-Konto gebraucht.

Einschalten und erster Host

1. Einstellungen → Module: Monitor64 einschalten. Im Menü erscheint „Monitor64“.
2. Host hinzufügen: Art wählen (Linux mit Agent, Windows, Proxmox VE, NAS, SNMP-Gerät …), Name und Adresse eintragen.
3. Der Assistent zeigt, was auf dem Host zu tun ist (Installationsbefehl, Token, Schlüssel). Verbindung testen zeigt die gefundenen Dienste.
4. Dienste auswählen, Gruppe und Tags vergeben, Host anlegen. Die ersten Werte kommen sofort.

Zugänge

Zugangsdaten (API-Token, Passwörter, SNMP-Geheimnisse) liegen verschlüsselt in der Node und werden nie wieder angezeigt. Bei selbst signierten Zertifikaten zeigt der Test den Fingerabdruck; erst nach deiner Bestätigung werden Zugangsdaten gesendet.

Monitor64-Agent

Der Agent ist ein einzelnes Programm ohne Abhängigkeiten für Linux (amd64, arm64, armv7), Windows (amd64) und FreeBSD (amd64, arm64). Getestet ist er unter FreeBSD 14; OPNsense, pfSense und TrueNAS CORE werden unterstützt, sind aber noch wenig erprobt – Rückmeldungen sind willkommen. Der Agent nimmt nur Abfragen deiner Node an (über ihren Schlüssel) und kann nur Werte liefern – keine Befehle ausführen.

Den fertigen Befehl mit dem Schlüssel deiner Node zeigt Monitor64 → Agent und der Assistent. Er sieht so aus:

curl -fsSL https://ipv64.net/node64/agent/install.sh | sudo sh -s -- \
  --base https://ipv64.net/node64/agent/ \
  --key "ssh-ed25519 AAAA… node64@node"

[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12; & ([scriptblock]::Create((irm https://ipv64.net/node64/agent/install.ps1))) -Key "ssh-ed25519 AAAA… node64@node" -Base https://ipv64.net/node64/agent/

fetch -o /tmp/install.sh https://ipv64.net/node64/agent/install.sh && \
  sh /tmp/install.sh --base https://ipv64.net/node64/agent/ --key "ssh-ed25519 AAAA… node64@node"

• Quelle der Dateien: „Internet“ (ipv64.net) oder „diese Node“ – die Node hält die signierten Dateien bereit, auch für Hosts ohne Internet.
• Fingerabdruck: Das Installationsskript zeigt den Fingerabdruck des Hosts. „Verbindung testen“ zeigt denselben Wert; danach merkt sich die Node den Schlüssel.
• Port: Die Node fragt den Agent auf 6465/TCP ab. Unter Windows legt die Installation die Firewall-Regel an.
• Hosts hinter NAT oder VPS (Push-Betrieb): Im Assistenten „Agent verbindet sich mit der Node“ wählen. Der Agent baut die Verbindung dann selbst zu Port 6466/TCP der Node auf und braucht keinen offenen Port. An der Sicherheit ändert das nichts: Die Node prüft weiter den Schlüssel des Hosts, der Agent den der Node.
• Updates: Die Node aktualisiert Agents automatisch über die bestehende Verbindung (je Host abschaltbar, „Jetzt aktualisieren“). Jede Datei ist signiert; der Agent nimmt nur Dateien mit gültiger Signatur und nie eine ältere Version an. Startet eine neue Version nicht, fällt er auf die vorige zurück.
• Windows: Ein Symbol im Infobereich der Taskleiste zeigt, dass der Agent läuft, seine Version, die letzte Abfrage und ob ein Update ansteht. Abschalten: -NoTray bei der Installation.
• Eigene Skripte: Programme im Ordner local.d des Agents liefern eigene Dienste (Zustand, Text, Messwerte). Sie müssen dem Administrator gehören und dürfen für andere nicht schreibbar sein.
• Entfernen: monitor64-agent uninstall (Linux/FreeBSD als root, Windows als Administrator aus dem Programmordner).

Linux ohne Agent (SSH)

Die Node meldet sich mit ihrem eigenen Schlüssel an und führt ein festes Abfrageskript aus. Auf dem Host legst du dafür einen Benutzer an (empfohlen monitor64) und trägst die Zeile aus dem Assistenten in dessen authorized_keys ein. Für SMART ist optional sudo smartctl nötig.

Ein Passwort ist nur als Ausnahme für Systeme ohne Schlüssel-Anmeldung gedacht. Es wird erst gesendet, nachdem du den Fingerabdruck des Hosts bestätigt hast.

Proxmox, Docker, NAS und andere Schnittstellen

• Proxmox VE / Proxmox Backup Server: API-Token mit Leserechten (Rolle PVEAuditor bzw. Audit). Ausstehende Updates liefert Proxmox VE nur mit dem Recht Sys.Modify; ohne es sagt der Dienst „Updates“, dass nicht abgefragt wird. Weitere Nodes eines Clusters schlägt der Assistent als eigene Hosts vor.
• VMs und Container: erscheinen als Dienste des Hypervisors („soll laufen“ kommt aus „beim Booten starten“ bzw. der Restart-Regel). Der RAM einer VM hat eine eigene Regel ohne Standardschwelle, weil Proxmox den Cache des Gastes mitzählt. Ein Klick macht aus einem Gast einen eigenen Host.
• Docker: lokaler Socket, TCP oder SSH.
• TrueNAS, Unraid, Redfish: API-Schlüssel bzw. Benutzer mit Leserechten.
• USV über NUT: Adresse des NUT-Servers (Port 3493), optional Benutzer und TLS.
• Prometheus-Exporter: Adresse des Exporters; node_exporter und windows_exporter werden auf dieselben Dienste abgebildet wie der Agent. Eigene Metriken lassen sich als Dienste mit Schwelle hinzufügen.

SNMP und Traps

• Versionen: v1, v2c und v3. Empfohlen ist v3 mit Authentifizierung und Verschlüsselung; v1/v2c senden die Community im Klartext.
• Profile: Die Node erkennt Geräte selbst (Synology, QNAP, TrueNAS, MikroTik, UniFi, APC, USV nach UPS-MIB, Drucker) und liefert dazu passende Dienste. Eigene OIDs lassen sich als Dienste ergänzen.
• Ports: Auslastung in Mbit/s und Prozent, Fehlerrate, Link weg, langsamer als zuvor, Halbduplex, LACP.
• Traps: Bekannte Traps (Link weg, USV auf Batterie …) lösen sofort eine Abfrage aus; andere erscheinen im Dienst „Traps“ als Warnung, bis du sie quittierst. Der Empfänger ist nur offen, wenn ein Zugang Traps nutzt. Standard ist Port 162/UDP – im Container braucht ein Port unter 1024 CAP_NET_BIND_SERVICE oder eine Port-Zuordnung wie 162→1162.

Dienste

• Neue Dienste werden als Hinweis angeboten und nie automatisch übernommen. Du entscheidest: übernehmen oder ignorieren.
• Verschwundene Dienste (Platte gezogen, Container gelöscht) bleiben als Problem stehen, bis du sie entfernst.
• Dienste, die nicht vorgeschlagen werden (einzelne Windows-Dienste, gestoppte Gäste), lassen sich jederzeit einzeln übernehmen.
• Je Dienst gibt es Verlauf, Schwellen, den Sollzustand („soll laufen“ / „darf aus sein“) und „nur anzeigen“ statt melden.

Schwellen

Drei Stufen, die genaueste gewinnt, jedes Feld erbt einzeln: Standard für alle → Abweichungen je Gruppe oder Tag → dieser Host (direkt am Dienst). Meist reicht der Standard:

• Dauer: Die Schwelle zählt erst, wenn alle Messungen im Zeitraum darüber liegen. Hysterese: 2 Punkte, damit ein Wert an der Grenze nicht hin und her springt.
• Für große Volumes gibt es statt Prozent auch „weniger als X GB frei“.
• Feste Regeln ohne Zahl: SMART FAILED, defekte Sektoren, RAID/ZFS degraded, Bond-Mitglied weg, Sicherheitsupdates, Neustart nötig, Gast läuft nicht, Windows-Dienst gestoppt, Job fehlgeschlagen, Backup zu alt und weitere. Je Regel wählbar: Kritisch, Warnung oder nicht melden.

Probleme und Wartung

• Jedes Problem hat einen Ablauf: wann geöffnet, wohin gemeldet, wer quittiert oder gelöst hat (Benutzer, API-Key oder System) – auch als CSV.
• Quittieren stoppt Erinnerungen, bis es schlimmer wird.
• Wartung für Hosts, Gruppen oder Tags: jetzt, geplant oder wiederkehrend. In der Wartung wird weiter aufgezeichnet, aber nicht gemeldet; ist danach noch etwas gestört, kommt die Meldung dann.
• Antwortet ein Host nicht mehr, gibt es eine Meldung „nicht erreichbar“ – nicht eine je Dienst.

Benachrichtigung

Monitor64 nutzt die Benachrichtigungskanäle der Node. Alles, was auf einem Host in einer Runde passiert, ist eine Meldung; die Entwarnung geht an genau die Kanäle, die das Problem bekommen haben.

• Je Stufe (Warnung/Kritisch) wählbar, welche Kanäle melden; Abweichungen je Gruppe oder Tag.
• Erinnerung, solange ein Problem offen und nicht quittiert ist (nie, alle 4 Stunden, täglich).
• Ruhezeit aus den Einstellungen der Node: danach eine Sammelmeldung. Kritisches kann trotzdem sofort melden.
• Flattert ein Dienst, kommt eine Meldung und dann Ruhe, bis er 30 Minuten stabil ist.

Statusseiten

Hosts und einzelne Dienste aus Monitor64 lassen sich auf den Statusseiten der Healthchecks zeigen. Nach außen gehen nur Bezeichnung und Zustand – keine Werte, Adressen oder Fehlertexte. Zeiten, in denen Monitor64 nicht lief, zählen weder als Störung noch als beobachtet.

Cluster

In einem Node64-Cluster überwacht je Host genau eine Node. Du wählst eine bevorzugte Node und optional Ersatz-Nodes: Fällt die zuständige Node aus, übernimmt nach etwa 2 Minuten eine Ersatz-Node und gibt nach 5 Minuten stabilem Betrieb wieder zurück. Bei getrennten Teilen entscheidet die Mehrheit, damit nichts doppelt meldet.

• Alle Nodes nutzen einen gemeinsamen Schlüssel – Agents und SSH-Hosts brauchen ihn nur einmal.
• Die Übersicht zeigt alle Hosts mit „überwacht von“; den Verlauf holt die Oberfläche von der überwachenden Node.
• Vor dem Eintragen einer Ersatz-Node prüft „Erreichbarkeit prüfen“, ob sie den Host überhaupt erreicht.

Daten, Export und Ressourcen

• Verlauf in der eigenen Datei monitor64.db im Datenverzeichnis: 1-Minuten-Werte 48 Stunden, 5-Minuten-Werte 30 Tage, Stundenwerte 1 Jahr.
• Export und Backup: Monitor64 steckt vollständig im Konfig-Export und im Backup der Node (Zugangsdaten nur mit Export-Passwort).
• Prometheus: node64_monitor_host_up, node64_monitor_state und node64_monitor_value unter /api/metrics – siehe Prometheus.
• Ressourcen: gemessen brauchen 100 Hosts mit 800 Diensten rund 30 MB RAM zusätzlich und unter 1 % eines CPU-Kerns.

Ports

Sicherheit

• Der Agent kennt nur feste Abfragen. Es gibt keine Shell und keine Möglichkeit, über die Node Befehle auf dem Host auszuführen.
• Node und Host weisen sich gegenseitig mit Schlüsseln aus. Ändert sich der Schlüssel eines Hosts, wird nicht still weitergemacht, sondern gemeldet.
• Agent-Dateien und Updates sind mit dem Release-Schlüssel von Node64 signiert.
• Passwörter und Token gehen erst an ein Ziel, dessen Fingerabdruck (SSH-Schlüssel bzw. Zertifikat) du bestätigt hast.
• Zugangsdaten liegen verschlüsselt in der Node; jede Änderung steht mit Person im Audit-Log.

Proxmox VE und Docker aus den Healthchecks

Die Überwachung von Proxmox VE und Docker mit Messwerten gehört jetzt zu Monitor64. Healthchecks prüfen weiter, ob etwas erreichbar ist. Mit dem Update auf Healthchecks 3.0.0 werden die bisherigen Proxmox- und Docker-Checks und -Systeme samt Daten gelöscht – auch bei ipv64.net und auf den anderen Nodes des Clusters. Einstellungen und Zugangsdaten werden nicht übernommen: Lege die Systeme in Monitor64 als Host neu an – der Assistent braucht dafür nur Adresse und Token.

Fragen und Wünsche zu Monitor64 gern ins Forum v64.tech.

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