Leichtgewichtiges Server-Monitoring für einen VPS: Beszel vs Netdata vs Uptime Kuma vs Nezha (und wann du keines brauchst)

15. Okt. 2026 · Termalin Team vpslinuxcomparisontoolshomelab

Wenn du einen VPS oder eine Handvoll davon leichtgewichtig überwachen willst, ist die ehrliche Auswahlliste kurz, und die richtige Wahl hängt von der Frage ab, die du stellst. Willst du wissen, ob deine Kisten gesund sind, nimm Beszel. Willst du wissen, ob Nutzer deine Seite öffnen können, nimm Uptime Kuma. Für ein Flotten-Panel über mehrere Regionen nimm Nezha, für eine einzelne Kiste im Moment Glances, und für Detail im Sekundentakt während eines Vorfalls Netdata. Die meisten brauchen eines davon, manchmal zwei, selten einen vollen Observability-Stack.

Offenlegung: Wir bauen Termalin, eine der Optionen weiter unten. Die Open-Source-Tools sind nach ihren öffentlichen Docs beschrieben, geprüft am 15. Oktober 2026, und mehrere von ihnen gewinnen einzelne Zeilen klar für sich.

Dieser Beitrag behandelt, was jedes Tool überwacht, was „leichtgewichtig“ wirklich kostet, und die Teile, die die Top-Ergebnisse auslassen: wer den Monitor überwacht, wenn der VPS selbst stirbt, wie du Alarme davon abhältst, zu Lärm zu werden, ein kleines Fallback-Skript und wie du eine Kiste ohne offenen Port überwachst.

Die kurze Antwort: welches Tool für welche Frage

Beszel – „Sind meine Kisten okay?“ Ein Hub plus ein winziger Agent pro Server. Host-Metriken und Docker-Stats, mit Alarmen an Telegram und mehr. Der leichtgewichtige Standard.
Netdata – „Was ist in genau dieser Sekunde passiert?“ Metriken im Sekundentakt und tiefes Detail pro Prozess. Das datenhungrigste hier, was auch der Sinn ist.
Uptime Kuma – „Erreicht die Außenwelt meinen Dienst?“ HTTP-, TCP-, Ping- und DNS-Checks mit Statusseiten. Es überwacht nicht CPU, Speicher oder Disk.
Nezha – „Wie geht es meiner VPS-Flotte, über Anbieter und Regionen hinweg?“ Ein Panel im Probe-Stil mit Web-Terminal, beliebt für Setups über mehrere Regionen.
Glances – „Was macht diese eine Kiste gerade jetzt?“ Eine Live-Ansicht, wie htop oder btop mit mehr auf dem Schirm. Kein Alarm-Tool.
Termalin – „Überwache meine Server und alarmiere mich, ohne dass ich etwas zusätzlich installieren muss.“ Das Monitoring läuft über einen SSH-Zugriffs-Connector, den du schon hast. Kostenpflichtig, mit echten Grenzen (unten).

Was „leichtgewichtig“ beim Server-Monitoring wirklich bedeutet

„Leichtgewichtig“ wird meist als Speicher des Agenten angegeben, was die falsche Zahl ist. Zähl das Ganze:

Der Agent auf jeder Kiste – meist eine einzelne kompilierte Binärdatei, von Haus aus klein.
Der Hub oder das Dashboard – hier sitzt das Gewicht: eine Web-App, oft mit Datenbank, die irgendwo läuft und oben bleibt.
Offene Ports – jeder lauschende Port ist Angriffsfläche, die jetzt dir gehört.
Container und Dienste zum Patchen – eine weitere Sache, die du für immer aktuell halten musst.

Nach diesem Maß sind Beszel (ein Agent + ein Hub-Container) und Uptime Kuma (ein Container) wirklich leicht. Netdatas Erfassung im Sekundentakt ist in dieser Gruppe die ressourcenhungrigste bei CPU und Speicher – das ist der Handel für ihre Auflösung. Und der klassische „große Stack“ – Prometheus plus node_exporter plus Grafana plus Alertmanager – sind vier bewegliche Teile zum Ausrollen, Absichern und Patchen. Er ist exzellent, aber nicht leichtgewichtig, und für einen bis zwanzig Server meist mehr, als die Aufgabe braucht.

Die Kandidaten

Beszel

Ein Hub (auf Basis von PocketBase) plus ein kleiner Go-Agent auf jedem Server. Der Agent läuft auf zwei Arten: Der Hub verbindet sich über SSH auf Port 45876 zu ihm, oder der Agent wählt sich mit einem Token per WebSocket nach draußen zum Hub – der zweite Modus braucht keinen eingehenden Port und funktioniert hinter NAT. Er liest Host-Metriken und Docker-Container-Stats und alarmiert bei CPU, Speicher, Disk, Bandbreite, Temperatur und Up/Down-Status, an 25+ Kanäle inklusive Telegram und ntfy. MIT-lizenziert; die Docs stehen zum Zeitpunkt des Schreibens auf v0.21. Das ist das Tool, das man beim schlichten „Sind meine Kisten gesund?“ schlagen muss.

Netdata

Metriken im Sekundentakt mit einem dichten Live-Dashboard und viel automatischem Detail pro Prozess und pro Dienst. Der Agent ist kostenlos und läuft unbegrenzt auf deinen eigenen Hosts und liefert sein eigenes Dashboard lokal aus. Netdata Cloud, das Agenten zusammenbindet und Benachrichtigungen routet, ist im Community-Tier bis zu 5 verbundenen Knoten kostenlos; darüber hinaus gibt es Homelab für 90 $/Jahr (unbegrenzt, Fair Use) oder Business für 4,50 $ pro Knoten/Monat bei jährlicher Abrechnung. Greif dazu, wenn du eine Spitze debuggst und ein Ein-Minuten-Durchschnitt zu grob ist.

Uptime Kuma

Der selbst gehostete Uptime-Monitor: HTTP(s)-, TCP-, Keyword-, Ping-, DNS-, Push- und Docker-Container-Checks, 90+ Benachrichtigungsdienste und öffentliche Statusseiten. Rund 92.000 GitHub-Sterne, MIT. Eine Sache muss klar sein: Uptime Kuma erfasst keine Host-CPU, kein RAM und keine Disk – es überwacht von außen, ob Dienste antworten. Das macht es zum natürlichen Partner eines Host-Metriken-Tools, nicht zum Ersatz dafür, und die übliche Antwort auf „eine selbst gehostete Uptime-Kuma-Alternative“ ist in Wahrheit „kombiniere Kuma mit Beszel“.

Nezha

Ein Dashboard plus ein Agent, der Systemstatus meldet, HTTP/TCP/Ping-Checks und Zertifikatsablauf-Checks ausführt, Alarme auslöst, geplante Aufgaben ausführt und dir ein Web-Terminal zu jedem Host gibt. Der Agent wählt sich nach draußen zum Dashboard. Es ist das De-facto-„Probe“-Panel für VPS in den chinesisch- und koreanischsprachigen Communities, und es glänzt, wenn du viele kleine VPS bei verschiedenen Anbietern und in verschiedenen Regionen hast und eine Seite für alle willst.

Glances (und htop/btop)

Glances ist eine Live-Ansicht einer einzelnen Kiste: CPU, Speicher, Disk, Netzwerk, Prozesse und mehr auf einem Schirm, über SSH oder eine optionale lokale Web-Seite. Wie htop und btop beantwortet es „was macht diese Kiste gerade jetzt“ und nicht mehr – es gibt keine Historie und kein echtes Alarmieren. Behalt es für praktisches Debuggen im Werkzeugkasten; erwarte nicht, dass es dich alarmiert.

Die Vergleichstabelle

Tool	Was es überwacht	Alarme & Kanäle	Eingehender Port nötig?	Kosten	Am besten für
Beszel	Host-Metriken + Docker-Stats	CPU/Speicher/Disk/Bandbreite/Temp/Status; 25+ Kanäle (Telegram, ntfy)	Nein im WebSocket-Modus; ja (`45876`) im SSH-Modus	Kostenlos, MIT (selbst gehostet)	Leichtgewichtige Flotten-Gesundheit
Netdata	Host-Metriken, im Sekundentakt	Eingebaute Alarme; Benachrichtigungen über Agent oder Cloud	Lokales Dashboard auf `19999`; Cloud-Verbindung ist ausgehend	Agent kostenlos; Cloud kostenlos ≤5 Knoten, dann 90 $/Jahr oder 4,50 $ pro Knoten/Monat	Hochauflösendes Vorfall-Detail
Uptime Kuma	Uptime: HTTP/TCP/Ping/DNS/Push/Container (keine Host-Metriken)	90+ Dienste; Statusseiten	Erreicht Ziele nach außen; du hostest sein Dashboard	Kostenlos, MIT (selbst gehostet)	Externe Uptime + Statusseiten
Nezha	Systemstatus + HTTP/TCP/Ping + Zertifikatsablauf	Alarme, geplante Aufgaben; Web-Terminal	Agenten wählen sich nach draußen zum Dashboard	Kostenlos (selbst gehostet)	Multi-Region-VPS-Panel
Glances	Eine Kiste, live	Kein Alarm-Tool	Lokal; optionale Web-Ansicht	Kostenlos (selbst gehostet)	Eine einzelne Kiste, jetzt
Termalin	Host-Metriken über den Connector (kein zweiter Agent)	Alarme mit Standard-Schwellenwerten; E-Mail, iOS-Push, Telegram, Webhook	Nein – der Connector ist nur ausgehend	Pro 10 $/Monat oder 8 $/Monat jährlich; Team 15 $/Nutzer	Gesundheit + Alarme ohne Installation

Wer überwacht den Monitor, wenn der VPS stirbt?

Hier ist die Lücke, die die meisten Vergleiche auslassen. Wenn dein Hub oder Dashboard auf demselben VPS läuft, den es überwacht, stirbt es mit diesem VPS – und ein toter Server kann dir nicht sagen, dass er tot ist. „Server offline“ ist genau der Alarm, den du am meisten willst, und er funktioniert nur von einem zweiten Aussichtspunkt aus.

Drei Wege, das abzudecken:

Ein zweiter, günstiger VPS an einem anderen Standort, der die externe Prüfung ausführt. Genau das machen wir: Wir betreiben Uptime Kuma auf einem separaten, günstigen VPS, dessen einziger Job es ist, zu bemerken, wenn die Hauptkisten aufhören zu antworten.
Ein kostenloser externer Checker, der deine öffentlichen Endpunkte von außerhalb deines Netzes anpingt.
Ein gehosteter Dienst, dessen „Läuft es?“-Logik auf Infrastruktur läuft, die nicht deine ist, und der daher überlebt, wenn deine Kiste ausfällt.

Was du auch wählst, die Regel ist einfach: Das, was „offline“ erkennt, darf nicht auf der Maschine wohnen, die offline geht.

Alarme, die dich nicht darauf trainieren, sie zu ignorieren

Ein Monitor, der dich zehnmal pro Stunde alarmiert, wird binnen einer Woche stummgeschaltet – und dann ist er schlimmer als nichts. Out-of-the-box neigen Tools dazu, entweder still zu sein, bis du Regeln schreibst, oder geschwätzig, bis du sie tunst. So oder so ist die Arbeit dieselbe:

Eine Nachricht, wenn ein Problem aufkommt, eine, wenn es sich klärt – keine Erinnerung alle fünf Minuten.
Gruppierung – mehrere Probleme in derselben Minute kommen als eine Nachricht; ein wirklich kritisches geht trotzdem direkt durch.
Keine Wiederholungen am selben Tag für dasselbe Problem, außer es ist kritisch und hält an.
Ein ruhiger erster Tag, damit eine neu überwachte Kiste dir nicht jede schon vorhandene fehlgeschlagene Unit und jedes abgelaufene Zertifikat auf einmal abkippt.
Stummschalten pro Alarm, pro Server, damit ein lärmender Check dich nicht zwingt, alles stummzuschalten.

Und wähl Schwellenwerte, die etwas bedeuten: Disk bei 90 % Warnung und 95 % kritisch, oder die Prognose, dass sie binnen eines Tages voll läuft; knapp werdende Inodes; ein Out-of-Memory-Kill; eine fehlgeschlagene systemd-Unit; ein TLS-Zertifikat 14 Tage vor Ablauf (kritisch bei 3); und „offline“ erst nach ein paar Minuten, damit ein Neustart kein Alarm ist. Welches Tool du auch wählst, dieses Feintuning ist die eigentliche Arbeit beim Monitoring – mehr als die Wahl des Tools.

Die Zehn-Zeilen-Notlösung: ein Speicherplatz-Alarm an Telegram

Bevor du irgendetwas ausrollst, kannst du den häufigsten VPS-Ausfall überhaupt – eine volle Disk – mit cron, df und curl abdecken. Das ist die Antwort auf „disk space alert script linux“ und „server monitoring telegram alerts“, wenn du noch kein Dashboard willst.

Halt die Geheimnisse aus dem Skript heraus. Lies sie aus der Umgebung:

#!/usr/bin/env bash
# disk-alert.sh — warn via Telegram when a filesystem is too full.
set -euo pipefail

: "${TELEGRAM_BOT_TOKEN:?set TELEGRAM_BOT_TOKEN}"
: "${TELEGRAM_CHAT_ID:?set TELEGRAM_CHAT_ID}"
threshold="${DISK_THRESHOLD:-90}"

df -x tmpfs -x devtmpfs --output=pcent,target | tail -n +2 | while read -r pct mount; do
  used="${pct%\%}"
  [ "$used" -ge "$threshold" ] || continue
  curl -fsS --max-time 15 \
    --data-urlencode "chat_id=${TELEGRAM_CHAT_ID}" \
    --data-urlencode "text=$(hostname): ${mount} is ${used}% full" \
    "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" >/dev/null
done

Leg die echten Werte in eine nur-root-Datei, nie ins Skript oder die Crontab:

# /etc/disk-alert.env  — chmod 600, owned by root
export TELEGRAM_BOT_TOKEN=123456789:replace-with-your-bot-token
export TELEGRAM_CHAT_ID=987654321
export DISK_THRESHOLD=90

Dann führ es alle fünfzehn Minuten mit cron aus. Speichere diese Zeile als /etc/cron.d/disk-alert (dieses Format, mit Benutzername, ist für Dateien in /etc/cron.d/):

*/15 * * * * root . /etc/disk-alert.env && /usr/local/bin/disk-alert.sh

Es wiederholt sich alle fünfzehn Minuten, solange die Disk voll bleibt. Für einen Notfall-Alarm ist das Absicht; ist es zu laut, führ es stattdessen stündlich aus.

Erstell einen Bot mit @BotFather, schick ihm eine Nachricht, damit er dir antworten darf, und lies deine chat_id einmal aus getUpdates. Das ist das Ganze: kein Agent, kein Port, kein Dashboard. Es skaliert nicht über ein paar Kisten hinaus, aber es fängt den Ausfall, der die meisten VPS lahmlegt.

Monitoring hinter NAT, CGNAT oder ohne offene Ports

Eine Kiste hinter NAT oder CGNAT kann keine eingehende Verbindung annehmen, also fällt jeder Monitor weg, der funktioniert, indem er sich zur Kiste verbindet. Die, die funktionieren, haben alle eine Form gemeinsam – die Kiste reicht nach draußen:

Beszel im WebSocket-Modus: Der Agent wählt sich nach draußen zum Hub, kein eingehender Port. (Der SSH-Modus braucht eingehenden 45876, also meide ihn hier.)
Netdata: Die Verbindung des Agenten zu Netdata Cloud ist ausgehend.
Uptime Kuma: Nutz einen Push-Monitor – die Kiste ruft nach Zeitplan eine Kuma-URL auf, und Kuma alarmiert, wenn die Aufrufe ausbleiben.
Termalin: Der Connector ist nur ausgehend und lauscht nie auf einem Port.

Die allgemeine Technik – und warum „lass es nach draußen reichen“ die einzige sichere Antwort für eine private Kiste ist – steht in SSH hinter NAT ohne Portweiterleitung (auf Englisch), und die Homelab-Variante in SSH auf ein Heim-NAS oder einen Server.

Wo Termalin hineinpasst – und wo nicht

Termalins Ansatz unterscheidet sich von den Tools oben: Es fügt überhaupt keinen Monitoring-Agenten hinzu. Hat ein Server bereits einen Termalin-Connector – denselben nur-ausgehenden Agenten ohne eingehenden Port, den du für schlüssellosen SSH-Zugriff nutzt –, dann wird er schon überwacht. Es gibt keinen zweiten Agenten: Einmal pro Minute führt Termalin ein paar nur lesende Befehle (/proc, df, ps und ähnliche) über die Verbindung aus, die der Connector ohnehin hält. Der Kiste kostet das ein paar Millisekunden CPU und etwa ein Kilobyte pro Minute.

Was es liest, ist das übliche Gesundheitsbild: CPU (inklusive iowait und steal), Last und Druck, Speicher und Swap, Plattenplatz und Inodes, Disk- und Netzwerk-I/O, Sockets und offene Dateien, Prozesse, Container, fehlgeschlagene Dienste, fehlgeschlagene SSH-Anmeldungen, ausstehende Sicherheitsupdates, lauschende Ports und TLS-Zertifikate mit Tagen bis zum Ablauf. Alarme funktionieren mit Standard-Schwellenwerten und ohne Regeln, die du schreiben musst, und sie sind darauf gebaut, still zu bleiben: einmal rein, einmal raus, gruppiert, keine Wiederholungen am selben Tag, ein ruhiger erster Tag und Stummschalten pro Alarm. Sie gehen an E-Mail, iOS-Push, Telegram (ein Tipp, um den Bot zu verbinden) und einen Webhook, den Slack und Discord akzeptieren, signiert mit HMAC-SHA256. Die Historie beträgt 90 Tage auf Pro und zwei Jahre auf Team.

Weil ein KI-Assistent dieselben Daten über Termalins gehosteten MCP-Endpoint lesen kann (server_metrics und alerts_list), kannst du in Claude oder ChatGPT auch einfach fragen „Wie geht es meinen Servern?“ und bekommst die Antwort aus den gesammelten Daten. Markiere im Web-Terminal einen Fehler in der Ausgabe und wähle „Auswahl erklären“: Der Assistent schreibt eine kurze Diagnose in Klartext und schließt mit ein paar nur lesenden Prüfbefehlen, die eine Schaltfläche für dich in die Sitzung tippt. Das ganze Bild steht auf der Seite Server-Monitoring.

Jetzt die ehrlichen Grenzen, denn die Open-Source-Tools schlagen es bei mehreren davon:

Keine externen Uptime-Checks und keine Statusseiten. Das ist ein Tool für Host-Metriken und Alarme, kein Uptime-Monitor – Uptime Kuma ergänzt es weiterhin.
Kein Log-Sammeln und keine eigenen Metriken. Es ist kein Ersatz für Grafana/Prometheus.
Dashboards gibt es vorerst nur im Web-Kabinett, nicht in der Desktop-App – auch wenn die Desktop-App CPU, Speicher und Disk eines verbundenen Hosts live in der Statusleiste und im Watch Grid (auf Englisch) zeigt.
Nicht Ende-zu-Ende-verschlüsselt – diese Zahlen werden in einer Form gespeichert, die der Dienst lesen kann, weil er sie lesen muss, um Charts zu zeichnen und Alarme auszulösen.
Nicht im Free-Tarif. Es braucht einen Connector, der Teil von Pro (10 $/Monat oder 8 $/Monat bei jährlicher Abrechnung – 96 $/Jahr) und Team (15 $ pro Nutzer) ist, mit einer 14-tägigen Pro-Testphase, die keine Kreditkarte braucht.

Ist „kostenlos und selbst gehostet“ eine harte Anforderung, sind Beszel oder Uptime Kuma deine Antwort, und das ist eine faire Entscheidung. Termalins Fall ist enger: Du nutzt es ohnehin für SSH-Zugriff und würdest lieber keinen separaten Monitoring-Stack aufsetzen und babysitten, nur um Gesundheits-Charts und vernünftige Alarme zu bekommen.

Empfehlungen je nach Situation

Ein Hobby-VPS. Beszel für die Gesundheit, oder einfach das Cron-Skript von oben, wenn du nur eine volle Disk fürchtest. Füg später Uptime Kuma hinzu, wenn du eine öffentliche Seite betreibst.
5–20 VPS bei verschiedenen Anbietern (Hetzner, Contabo, Hostinger, ein, zwei Droplets). Beszel für Metriken plus Uptime Kuma für Uptime, mit der Kuma-Instanz auf einer separaten Kiste. Willst du lieber ein Panel mit Web-Terminal, Nezha. Betreibst du Termalin schon für SSH, schalte sein Monitoring ein und spar dir den zusätzlichen Stack.
Ein Homelab hinter CGNAT. Alles, was nur ausgehend ist: Beszel im WebSocket-Modus, Netdata zu Cloud oder ein Kuma-Push-Monitor – siehe den Leitfaden zu SSH hinter NAT (auf Englisch).
„Ich will, dass mein KI-Assistent ‚Wie geht es meinen Servern‘ beantwortet.“ Das ist der Termalin-Fall: dieselben Daten, die ein Mensch sieht, vom Agenten über MCP gelesen.

Häufige Fragen

Ist Netdata kostenlos? Der Agent ist kostenlos und läuft unbegrenzt auf deinen eigenen Hosts, mit seinem eigenen lokalen Dashboard. Das Community-Tier von Netdata Cloud ist bis zu 5 verbundenen Knoten kostenlos; darüber hinaus gibt es Homelab für 90 $/Jahr oder Business für 4,50 $ pro Knoten/Monat bei jährlicher Abrechnung.

Überwacht Uptime Kuma CPU, Speicher oder Disk? Nein. Uptime Kuma prüft von außen, ob Dienste antworten – HTTP, TCP, Ping, DNS, Container und Push. Für Host-CPU, -RAM und -Disk kombinierst du es mit Beszel, Netdata oder Termalin.

Beszel vs Netdata – welches ist leichter? Beszel. Es ist ein kleiner Agent pro Kiste plus ein einzelner Hub. Netdata erfasst im Sekundentakt und ist das ressourcenhungrigste dieser Gruppe; du wählst es für die Auflösung, nicht für Leichtgewicht.

Was ist das beste kostenlose VPS-Monitoring mit Telegram-Alarmen? Für Host-Gesundheit sendet Beszel an Telegram und ist kostenlos selbst zu hosten. Für Uptime tut Uptime Kuma das auch. Als Notlösung ohne Installation schickt das oben gezeigte Skript aus cron und curl direkt an Telegram, ohne dass im Hintergrund etwas läuft.

Wie überwache ich einen VPS hinter NAT oder ohne offene Ports? Nutz ein Tool, bei dem die Kiste nach draußen reicht: Beszel im WebSocket-Modus, den Netdata-Agenten zu Cloud, einen Kuma-Push-Monitor oder einen Termalin-Connector. Keines davon braucht einen eingehenden Port. Siehe SSH hinter NAT ohne Portweiterleitung (auf Englisch).

Termalin ist ein plattformübergreifender SSH-Client; auf Pro und Team wird jeder Server, der einen Connector hat, mit Charts und Alarmen mit Standard-Schwellenwerten überwacht, und nichts Zusätzliches wird auf der Kiste installiert – siehe Server-Monitoring oder lade es herunter.