Monitoring fürs Homelab in 15 Minuten: Netdata + Claude als MCP-Server

Netdata bringt seit Version 2.6 einen eigenen MCP-Server mit — ganz ohne Zusatzinstallation. Wer ein Homelab oder eine kleine Umgebung mit ein paar Nodes betreibt, hat in gut 15 Minuten ein vollständiges Monitoring mit Hunderten Metriken pro Sekunde, plus einen KI-Assistenten, der die Daten tatsächlich versteht: Claude fragt "Warum ist der Server langsam?" nicht mehr rhetorisch, sondern zieht sich die echten Zahlen. Installation, erste Ansicht, MCP-Anbindung, eine Beispielfrage — und ein Hinweis, worauf zu achten ist, sobald man das Ganze von außerhalb des eigenen Netzes erreichbar machen will.

Netdata installieren, das Dashboard einmal ansehen, Claude als MCP-Client anschließen — fertig. Kein Cloud-Konto nötig, keine Konfigurationsdatei, die erst verstanden werden muss.

Netdata-Dashboard mit CPU-, RAM- und Netzwerk-Kacheln

Für die meisten Homelabs und kleinen Setups — ein Server, ein NAS, ein paar Raspberry Pis, vielleicht ein Handvoll Container — ist professionelles Monitoring bisher an zwei Dingen gescheitert: entweder es brauchte eine eigene Prometheus/Grafana-Installation mit Zeit, die man an einem Wochenende nicht wirklich übrig hat, oder es war eine der leichteren Lösungen, die dann doch nur eine Handvoll Kennzahlen zeigen. Netdata liegt dazwischen — und bringt seit Kurzem etwas mit, das den Unterschied macht: einen eingebauten MCP-Server, über den ein KI-Assistent wie Claude direkt auf die Live-Metriken zugreifen kann.

Installation: ein Befehl

Netdata hat ein offizielles Installationsskript, das auf so gut wie jeder gängigen Linux-Distribution funktioniert (Debian, Ubuntu, Raspberry Pi OS, Fedora, Arch — auch auf ARM, also problemlos auf einem Raspberry Pi):

curl -Ss https://get.netdata.cloud/kickstart.sh | bash

Das Skript erkennt die Distribution selbst, installiert die passenden Pakete und startet den Netdata-Dienst direkt im Anschluss. Nach ein bis zwei Minuten ist das Dashboard erreichbar:

http://<deine-server-ip>:19999

Kein Login, kein Cloud-Konto nötig — das Dashboard funktioniert vollständig lokal und zeigt sofort an, was gerade passiert: CPU pro Kern, Arbeitsspeicher, Netzwerkdurchsatz, Festplatten-I/O, laufende Prozesse, und bei den meisten Distributionen automatisch erkannt auch Docker-Container, laufende Datenbanken oder Webserver, falls welche installiert sind.

Die erste Ansicht

Das Dashboard sammelt ab der ersten Sekunde und aktualisiert sich laufend — pro Sekunde, nicht alle fünf Minuten wie bei den meisten klassischen Lösungen. Das merkt man sofort, wenn ein kurzer CPU-Spike auftaucht: er ist als einzelner Zacken sichtbar, nicht als geglättete Linie, die den eigentlichen Moment verschluckt.

Alerts-Ansicht mit einem ausgelösten Alarm

Netdata bringt außerdem von Haus aus rund 300 vordefinierte Alarme mit — Festplatte fast voll, Swap-Nutzung zu hoch, ein Dienst nicht erreichbar, und so weiter. Die muss man nicht selbst konfigurieren; sie laufen von Anfang an mit und tauchen im Reiter „Alerts" auf, sobald einer davon anschlägt.

Claude als MCP-Client anschließen

Das ist der Teil, der den Unterschied macht. Ab Netdata Agent Version 2.6.0 läuft automatisch ein MCP-Server mit — ohne jede Zusatzinstallation, ohne eigenen Prozess, ohne Konfigurationsdatei. Erreichbar ist er unter:

http://<deine-server-ip>:19999/mcp

In Claude Desktop (oder Claude Code) trägt man diesen Endpunkt als benutzerdefinierten Connector ein:

Nach dem Verbinden stehen Claude gut ein Dutzend Werkzeuge zur Verfügung: Metriken durchsuchen, Anomalien der letzten Stunden finden, Alarme auflisten, Knoten-Details abrufen, laufende Prozesse einsehen. Alles live, alles echte Daten vom eigenen Server.

Eine Beispielfrage

Statt selbst durchs Dashboard zu klicken, kann man jetzt einfach fragen:

„Warum war mein Server heute Nachmittag zwischen 14 und 16 Uhr langsam?"

Claude sucht sich über die MCP-Werkzeuge selbstständig zusammen, welche Metriken in diesem Zeitraum ungewöhnlich waren, ob es einen CPU- oder Speicher-Ausreißer gab, und ob ein Alarm ausgelöst wurde — und antwortet mit der tatsächlichen Ursache statt mit einer allgemeinen Vermutung. Das Dashboard bleibt trotzdem da — für den Blick aufs große Bild ist die grafische Ansicht weiterhin die bessere Wahl, für die gezielte Nachfrage danach ist der MCP-Server der schnellere Weg.

Wenn's über das eigene Netz hinausgehen soll

Für ein Homelab mit Claude auf demselben Rechner oder im selben WLAN reicht das oben Beschriebene komplett aus. Sobald der MCP-Server aber von claude.ai oder der Claude-Desktop-App aus erreichbar sein soll, während man selbst unterwegs ist, ändert sich eine Sache grundlegend: Der Verbindungsversuch kommt dann nicht mehr vom eigenen Gerät, sondern aus der Cloud-Infrastruktur von Anthropic — eine Adresse, die nur im eigenen (V)LAN oder nur im eigenen VPN erreichbar ist, funktioniert von dort aus nicht, egal wie korrekt sie sonst konfiguriert ist. Für diesen Fall braucht es einen öffentlich erreichbaren HTTPS-Endpunkt und einen echten Zugriffsschutz (Token oder OAuth) davor — das sprengt für unter fünf Nodes den Rahmen dieses Artikels, ist aber der Punkt, an dem man aufpassen muss, bevor man sich wundert, warum die Verbindung „einfach nicht geht", obwohl lokal alles funktioniert.

Zusammengefasst

Ein Installationsbefehl, zwei Minuten Wartezeit, ein Connector-Eintrag in Claude — und ein Homelab mit weniger als fünf Nodes hat ein vollständiges, sekundengenaues Monitoring samt KI-Assistent, der die eigenen Metriken tatsächlich versteht. Kein Grafana-Stack, kein Yaml, kein Cloud-Zwang.