Proxmox VE überwachen

Node64 überwacht Proxmox-VE-Systeme – einen einzelnen Node oder einen ganzen Cluster – nur lesend über die Proxmox-API: Nodes, VMs und Container, Abstürze, Neustarts und Schwellen für CPU, RAM und Disk. Node64 startet, stoppt oder ändert in Proxmox nichts.

Überblick

Die Überwachung gehört zu den Healthchecks und liegt unter Healthchecks → Proxmox VE. Sie läuft nur, solange das Modul Healthchecks eingeschaltet ist.

• Zustand je Gast: läuft, Backup, gesperrt (Migration, Snapshot …), angehalten, suspendiert, gestoppt, abgestürzt (über qmpstatus), unbekannt.
• CPU, RAM, Disk, Netz und Laufzeit je Node und Gast, Graphen für 1 h, 24 h, 7 und 30 Tage.
• Regeln mit Vererbung System → Node → Gast und Meldungen über deine vorhandenen Benachrichtigungskanäle.
• Einzelne Gäste oder Nodes führst du auf Wunsch als normalen Check – mit Statusseiten, Uptime-Balken und Sync mit ipv64.

Einrichtung

1. Lese-Token in Proxmox anlegen

pveum acl modify / --users '<user@realm>' --roles PVEAuditor
pveum acl modify / --tokens '<user@realm!token>' --roles PVEAuditor

Auf einem Node als root ausführen, zum Beispiel unter Datacenter → Node → Shell:

pveum user add node64@pve
pveum aclmod / -user node64@pve -role PVEAuditor
pveum user token add node64@pve monitor --privsep 0

Proxmox zeigt das Secret nur einmal an – gleich kopieren. Die Token-ID lautet dann node64@pve!monitor.

Mit Privilege Separation (--privsep 1, Standard in der Proxmox-Oberfläche) hat das Token keine eigenen Rechte, auch wenn der Benutzer welche hat – und es gilt nur die Schnittmenge aus Benutzer- und Token-Rechten. Dann braucht das Token selbst die Rolle, zusätzlich zu der seines Benutzers (oben schon gesetzt):

pveum user token add node64@pve monitor --privsep 1
pveum aclmod / -token 'node64@pve!monitor' -role PVEAuditor

In neueren Versionen geht auch pveum acl modify / --tokens 'node64@pve!monitor' --roles PVEAuditor. Die Rolle PVEAuditor auf / reicht für alles, was Node64 liest. Sieht das Token keine Gäste, warnt Verbindung testen; der Hinweis auf der Systemseite zeigt die passenden Befehle für Benutzer und Token.

2. System hinzufügen

1. Adresse(n)
   https://<node>:8006 – eine reicht. Im Cluster lernt Node64 die anderen Nodes selbst und weicht bei einem Ausfall auf sie aus. Weitere Adressen (eine je Zeile) sind feste Ausweichziele.
2. Token-ID und Secret
   Das Secret wird verschlüsselt auf der Node gespeichert und nie wieder angezeigt. Beim Bearbeiten behält ein leeres Feld das gespeicherte Secret. Das gespeicherte Secret gilt nur für dieselben Adressen und denselben Pin – änderst du das Ziel, gibst du das Secret neu ein.
3. Verbindung testen
   Zeigt Version, Cluster, Nodes, Anzahl der Gäste und den SHA-256-Fingerabdruck des Zertifikats. Bei selbstsignierten Zertifikaten (Proxmox-Standard) vergleichst du ihn in Proxmox unter Node → System → Zertifikate und bestätigst Fingerabdruck stimmt – festpinnen. Bei Zertifikaten einer bekannten CA, etwa Let's Encrypt über ACME, ist das Pinning optional. Eine Option „Prüfung aus“ gibt es nicht. Das Token schickt Node64 nie an ein unbestätigtes Zertifikat: erst den Fingerabdruck bestätigen, dann noch einmal Verbindung testen.
4. Intervall
   15–300 Sekunden, Standard 30. Der Cluster-Status wird jede Minute abgefragt, der qmpstatus laufender VMs alle 2 Minuten.

Wird das Zertifikat in Proxmox neu ausgestellt, meldet die Abfrage certificate mismatch. Dann im Bearbeiten Verbindung testen und den neuen Fingerabdruck bestätigen.

Übersicht und System

Proxmox VE listet alle Systeme mit Zustand (in Ordnung, teilweise gestört, nicht erreichbar, Fehler, aus), Version, Cluster und Quorum, Nodes online, Gästen laufend bzw. gestört und der letzten Abfrage. Von hier aus bearbeitest, schaltest und löschst du Systeme. Darüber zeigen Kacheln den Stand über alle Systeme: Systeme, Nodes online, Gäste laufend und gestört, Auslastung von CPU und RAM sowie die letzte Störung.

Ein System zeigt oben Kacheln – Nodes online mit Cluster und Quorum, Gäste, laufend, gestört (als Filter klickbar) und die Auslastung von CPU, RAM und Kernen – und darunter Nodes und Gäste als Tabelle: Name, ID, Typ (VM oder Container), Node, Zustand inklusive Backup, Lock und Absturz, CPU, RAM, Disk, Netz, Laufzeit, CPU-Verlauf der letzten Stunde und den Schalter als Check. Filtern kannst du nach Zustand (u. a. „gestört“), Node, Typ und per Suche nach Name, ID oder Tags. Darunter stehen die Regeln des Systems.

Vorlagen und Gäste mit dem Proxmox-Tag nomonitor werden nicht überwacht. Hängt bei einem gestoppten Gast ein Lock, gilt er nach 4 Stunden trotzdem als gestoppt.

Auf dem Dashboard fasst eine Proxmox-Karte alle Systeme zusammen. Ein System zählt dort nur mit eigenem Problem als gestört – nicht erreichbar, Node offline oder Quorum verloren; gestörte Gäste stehen getrennt unter „Gäste gestört“.

Zeigt ein System token secret cannot be decrypted oder token secret missing, fehlt der Schlüssel für das Secret, etwa nach einem Import ohne Passwort. Das System wird dann nicht abgefragt – trag das Secret neu ein.

Gast und Node im Detail

Die Detailseite eines Gasts oder Nodes zeigt die aktuellen Werte und Graphen für 1 h, 24 h, 7 Tage und 30 Tage: CPU mit Spitze, RAM und Disk, Netz rein und raus, Disk lesen und schreiben. Darunter stehen die Regeln dieser Ebene.

Gespeichert werden 1-Minuten-Werte für 48 Stunden, 5-Minuten-Werte so lange wie Einzelmessungen aufbewahren und Stundenwerte so lange wie Stundenwerte aufbewahren – dieselben lokalen Einstellungen wie bei den Healthchecks.

Regeln und Benachrichtigung

Regeln gelten mit Vererbung System → Node → Gast, die untere Ebene überschreibt die obere. Jede Zeile zeigt, was ohne eigenen Wert gilt und woher es kommt („Standard“, „vom System geerbt“, „vom Node geerbt“).

Kanäle

Auf Systemebene wählst du wie bei einem Check bestimmte Kanäle aus; ohne Auswahl gehen die Meldungen an die Standardkanäle. Node und Gast erben die Auswahl – angezeigt mit „vom System geerbt“ bzw. „vom Node geerbt“ – oder bekommen eine eigene Auswahl (ohne Haken = Standardkanäle). Gelöschte Kanäle werden beim Senden übergangen; bleibt keiner der gewählten übrig, gehen die Meldungen an die Standardkanäle. Für Gäste als Check gelten bei Ausfall und Entwarnung die Kanäle des Checks; beim Anlegen übernimmt er die Kanäle aus den Proxmox-Regeln.

Stumm, Ruhezeiten und Wartung

Stumm schaltet die Meldungen eines Systems, Nodes oder Gasts ab. Ruhezeiten gelten für alle Proxmox-Meldungen, auch für Abstürze: Wie bei Checks werden sie in der Ruhezeit zurückgehalten und danach als eine Sammelmeldung verschickt – je Gast bzw. Node mit dem letzten Stand (noch gestört bzw. über der Schwelle, zwischendurch gestört und wieder in Ordnung, Neustart) und einem Link auf die Proxmox-Seite. In einem Wartungsfenster für alle Checks kommen keine Proxmox-Meldungen; ein Fenster für bestimmte Checks gilt für Gäste, die als Check geführt werden. Proxmox-Meldungen haben eigene Arten:

Gemeldete Störungen überstehen einen Neustart der Node: Danach kommt keine zweite Meldung, nur die Entwarnung, sobald alles wieder passt.

Als Check führen

Der Schalter als Check (je Gast und Node) legt einen normalen Healthchecks-Check vom Typ proxmox an – Name „System – Gast“, Gruppe „Proxmox VE“, Intervall wie das System. Damit greifen Statusseiten, Uptime-Balken, der Sync mit ipv64 und die Einstellungen des Checks wie Kanäle, Erinnerungen und „kritisch“. Genauso geht es unter Healthchecks → Neuer Check mit dem Typ Proxmox VE (VM, Container, Node) – siehe Check aus einem überwachten System. Der Check fragt Proxmox nicht selbst, sondern liest den letzten Stand der Abfrage:

• up: läuft, Backup, gesperrt (Gast) bzw. online (Node)
• down: pve_stopped, pve_paused, pve_suspended, pve_crashed, pve_offline, pve_unknown, pve_missing (Gast nicht mehr vorhanden), pve_unreachable (System nicht erreichbar, aus oder Stand zu alt)

Ausfall und Entwarnung kommen dann nur über den Check, Neustart und Schwellen weiter über Proxmox VE. Wie Docker-Checks laufen proxmox-Checks nur lokal auf der Node, die das System abfragt – nicht online und nicht auf andere Nodes verschiebbar. Schaltest du das System aus, pausieren seine Checks; löschst du es, verschwinden sie. Ist das System beim Einschalten von „als Check“ ausgeschaltet, wird der Check pausiert angelegt. Doppelte Meldungen gibt es nicht.

API

Unter /api/healthchecks/proxmox, Anmeldung wie bei der übrigen API:

Prometheus

Abruf über den lokalen Prometheus-Endpunkt der Node unter /api/metrics, mit API-Key wie die übrigen Kennzahlen (siehe Prometheus & Grafana):

Insgesamt höchstens 1000 Gäste, Namen höchstens 64 Zeichen, Vorlagen nicht. Alle Reihen tragen zusätzlich das Label system_id.

Export und Import

Der Export der Konfiguration enthält die Systeme mit Einstellungen und Regeln. Das Token-Secret ist nur beim Export mit Passwort dabei, verschlüsselt. Ohne Passwort wird ein System beim Import ausgeschaltet angelegt und zeigt „Secret fehlt“, bis du es einträgst. Checks „als Check“ werden auf das System der neuen Node umgestellt. Gewählte Kanäle werden wie bei Checks auf die Kanäle der neuen Node umgeschrieben; fehlt ein Kanal dort, entfällt er – bleibt keiner übrig, gelten die Standardkanäle. Gleichnamige Systeme ordnet der Import über die Adressen zu.

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