Server-Surveillance – Monitoring von Proxmox und Raspberry Pi auf einem Dashboard

Der Ausgangspunkt

Einen Heimserver baut man nicht einmal auf, richtet ihn ein und ist dann fertig. Der laufende Betrieb ist ein fortlaufender Prozess: prüfen, ob alles sauber läuft, Engpässe früh erkennen, Ausfälle bemerken, Lasten einordnen. Genau dafür braucht es sauberes Monitoring als Grundlage.

Das Problem: Viele bestehende Monitoring-Lösungen sind für deutlich größere Umgebungen gebaut. Mehr Server, mehr Rollen, mehr Betriebsaufwand. Sie sind mächtig und flexibel, bringen aber entsprechend auch einiges mit: Exporter, Datenbanken, Dashboards, laufende Pflege, regelmäßige Updates. Für ein privates Setup ist das schnell mehr Infrastruktur zur Überwachung der eigentlichen Infrastruktur, als das eigene Setup vernünftig rechtfertigt.

Mein Ziel war deshalb deutlich einfacher: eine einzige Webseite, die mir beim Öffnen sofort zeigt, was gerade los ist. Proxmox-Host, alle VMs, alle LXCs, die GPU in der KI-VM, der Raspberry Pi im Flur, die relevanten Services – alles auf einen Blick, ohne dritte Dienste und ohne Cloud-Abhängigkeit.

Was Proxmox mitbringt – und was nicht

Proxmox bringt bereits eine eigene Monitoring-Oberfläche mit. Für CPU, RAM und Storage pro Node oder Guest reicht das für viele Fälle auch aus. Für meinen konkreten Anwendungsfall fehlen aber ein paar Dinge:

GPU-Monitoring: Die RTX PRO 2000 ist per PCIe-Passthrough an eine VM übergeben. Proxmox sieht diese GPU aus Sicht des Hypervisors deshalb nicht mehr sinnvoll als eigene Ressource. Temperatur, VRAM-Auslastung und laufende Prozesse bekommt man daher nicht über Proxmox selbst, sondern nur direkt in der VM – in meinem Fall per SSH und nvidia-smi.
Raspberry Pi: Der Pi ist kein Proxmox-Guest und taucht dort entsprechend auch nicht auf.
Service-Health: Ob Ollama, Faster-Whisper, Piper TTS oder Algroveon-News gerade erreichbar sind, zeigt Proxmox ebenfalls nicht.
Stromkosten: Intel RAPL, GPU-Leistungsaufnahme und Strompreis zu einer laufenden Kostenschätzung zu verbinden, gehört nicht zum Standardumfang.

Server-Surveillance schließt genau diese Lücken – nicht als Ersatz für Proxmox, sondern als ergänzendes Dashboard, das die relevanten Ebenen an einer Stelle zusammenbringt.

Der Ansatz: SSR + HTMX statt SPA

Die technische Grundentscheidung war ähnlich wie bei Algroveon-News: serverseitige Darstellung mit HTMX für reaktive Updates, aber ohne JavaScript-Framework.

Das Dashboard rendert beim ersten Aufruf eine vollständige HTML-Seite über Jinja2. Danach lädt HTMX in festen Abständen nur noch einzelne Partials nach – also kleine HTML-Fragmente, die jeweils nur den Inhalt einer Karte aktualisieren. Node, GPU, VMs, Pi und Services sind dabei jeweils eigene Partials mit eigenem Endpunkt.

Der praktische Vorteil ist simpel: Es braucht kein JavaScript-Build-System, keinen Frontend-Overhead und kein separates SPA-Deployment. Eine Python-Umgebung und ein laufender uvicorn-Prozess reichen aus.

Datenquellen: Drei verschiedene Wege

Das Monitoring kombiniert drei grundsätzlich unterschiedliche Wege beim Datenzugriff:

1. Proxmox REST-API

Über proxmoxer wird die Proxmox-API abgefragt: Node-Status, VM-Liste, LXC-Liste sowie CPU- und RAM-Auslastung der Guests. Die Verbindung läuft über einen eigens angelegten Read-only-API-Token (monitor@pve), also bewusst nur mit lesendem Zugriff und ohne Ausführungsrechte.

2. SSH auf den Proxmox-Host und die GPU-VM

Was die Proxmox-API nicht liefert, kommt per SSH. Dazu gehören zum Beispiel Per-Core-CPU-Last aus /proc/stat, Taktfrequenzen aus /proc/cpuinfo, Temperaturen über sensors – und auf der GPU-VM nvidia-smi für die relevanten GPU-Metriken.

Der SSH-Zugriff läuft über einen dedizierten monitor-User. Dieser Nutzer hat kein Sudo, sondern nur die Rechte, die für das Lesen der benötigten Informationen nötig sind, plus die Möglichkeit, nvidia-smi auszuführen. Genau darum ging es: so wenig Rechte wie nötig.

Der Intel-RAPL-Energiezähler (/sys/class/powercap/intel-rapl:0/energy_uj) wird zweimal mit einer Sekunde Abstand gelesen. Aus der Differenz lässt sich die aktuelle Leistungsaufnahme ableiten. Das passiert direkt über den Hardware-Zähler und ohne zusätzliche Hilfsskripte.

3. Pi-Agent

Der Raspberry Pi ist kein Proxmox-Guest und bringt deshalb auch keinen Mechanismus mit, über den Proxmox seine Daten einsammeln könnte. Die Lösung war ein bewusst kleiner FastAPI-Service direkt auf dem Pi.

Der Agent umfasst nur rund 60 Zeilen Python und nutzt psutil als zentrale Abhängigkeit. Er stellt GET /metrics für CPU, RAM, Disk, Temperatur und Uptime bereit sowie GET /health als einfachen Liveness-Check.

Die Entscheidung für einen eigenen kleinen HTTP-Service statt für einen klassischen Prometheus-Exporter oder node_exporter war bewusst pragmatisch. Für einen einzelnen Pi im Heimnetz wäre ein kompletter Prometheus-Ansatz unnötiger Overhead gewesen. Gleichzeitig ist so ein kleiner eigener Dienst in diesem Fall leichter zu verstehen, leichter anzupassen und leichter zu warten.

Stromkosten: Näherung aus Messwerten und Schätzungen

Das Stromkosten-Feature war einer der interessanteren Teile des Projekts. Wichtig ist dabei aber die Einordnung: Das System misst den Gesamtverbrauch des Servers nicht physikalisch exakt. Es kombiniert einzelne Messwerte mit festen Annahmen und Näherungen. Das Ergebnis ist deshalb bewusst eine laufende Kostenschätzung – keine exakte Strommessung auf Hardware-Ebene.

Die Gesamtschätzung setzt sich aus drei Quellen zusammen:

CPU: Intel RAPL liefert einen laufenden Messwert für den Prozessor. Dazu kommt ein konfigurierbarer Fixwert für den restlichen Grundverbrauch des Systems, also etwa Board, RAM, SSDs, Lüfter und andere Dauerverbraucher. Genau dieser Teil ist bereits keine direkte Messung mehr, sondern eine Annäherung über Mittelwerte und Erfahrungswerte.

GPU: nvidia-smi liefert die aktuelle Leistungsaufnahme direkt über den NVIDIA- Treiber. Gerade bei der KI-VM ist das interessant, weil Lastspitzen dort sehr klar sichtbar werden.

Pi: Für den Raspberry Pi gibt es in diesem Setup keinen separaten Hardware- Energiezähler. Deshalb nutze ich dort eine einfache Näherung: ein Grundwert im Leerlauf plus ein lastabhängiger Zuschlag. Auch das ist keine exakte Messung, sondern bewusst eine praktikable Schätzung für den Heimgebrauch.

Aus diesen Werten berechnet der Collector Kilowattstunden über 24 Stunden, 30 Tage und seit dem letzten Server-Start. Multipliziert mit dem hinterlegten Strompreis in €/kWh ergibt das eine laufende Kostenschätzung. Im 24h-Report werden zusätzlich Peak-Werte wichtiger Metriken angezeigt.

Collector: Zweiphasiges Sampling

Würde der Collector alle 10 Sekunden sämtliche Metriken in die Datenbank schreiben, kämen auf Dauer sehr viele Datenpunkte zusammen. Für einen Privatserver ist das in aller Regel nicht nötig und belastet SQLite eher unnötig.

Die Lösung ist deshalb ein zweiphasiger Collector.

Ruhemodus (alle 180 Sekunden): Wenn alle konfigurierten Trigger-Schwellen unterschritten sind – also normale Last, keine nennenswerte GPU-Aktivität, keine auffällige VM – wird nur alle 3 Minuten ein Datenpunkt geschrieben. Für Langzeit- Trends und den 30-Tage-Report reicht das gut aus.

Aktivmodus (alle 30 Sekunden): Sobald eine definierte Schwelle überschritten wird, wechselt der Collector in einen engeren Takt. Das kann zum Beispiel GPU-Last sein, wenn gerade eine Ollama-Inferenz läuft. Nach einer gewissen Zeit ohne neuen Trigger fällt das System wieder in den Ruhemodus zurück.

Das Ergebnis ist ein sinnvoller Kompromiss: genug Datenpunkte für Lastspitzen und Tagesauswertungen, aber keine unnötig aufgeblähte SQLite-Datenbank im Normalbetrieb.

Alerting

Konfigurierbare Schwellenwerte für die überwachten Metriken – etwa CPU, RAM, Disk, GPU-Temperatur, VRAM oder Pi-Temperatur – werden bei jedem Collector-Tick geprüft. Wird ein Grenzwert überschritten, wird ein Alert mit Zeitstempel, Quelle und Schweregrad (warning / error) in der alert_log-Tabelle erfasst. Sobald der Wert wieder im normalen Bereich liegt, wird der Alert automatisch geschlossen.

Das ist bewusst kein großes Alerting-System mit Eskalationslogik oder externer Benachrichtigung. Für den Heimgebrauch war mir zunächst wichtiger, Probleme sichtbar und nachvollziehbar zu machen, statt sofort ein vollständiges Notification-System aufzubauen.

Warum eine eigene Instanz sinnvoll ist

Die entscheidende Designentscheidung war, Server-Surveillance bewusst eigenständig zu halten. Das System kennt die Proxmox-API, die SSH-Zugänge und die lokalen Quellen für RAPL- und GPU-Metriken.

Der praktische Vorteil: Wenn eine VM Probleme hat oder ein Dienst innerhalb der überwachten Infrastruktur ausfällt, bleibt das Dashboard selbst davon möglichst unberührt, weil es separat auf dem Host läuft. Fällt Algroveon-Agent aus, sieht man das im Service-Status. Hat die GPU-VM ein Problem, wird genau das sichtbar.

Ein Monitoring-System, das vollständig innerhalb der zu überwachenden Infrastruktur mitläuft – etwa als eigener Stack in einer VM – hätte diesen Vorteil in dieser Form nicht.