Mein Homelab zu überwachen wurde zum Zweitjob, und bezahlt werde ich dafür nicht mal

Es fing an, wie es immer anfängt: ein paar Proxmox-Nodes, ein Synology-NAS und eine Handvoll Linux- und Windows-VMs. Simpel, sauber, macht Spaß.

Dann tauchte der Monitoring-Stack auf, und irgendwie wurde das Monitoring des Homelabs mehr Arbeit als der Betrieb des Homelabs selbst. Wenn Ihnen das bekannt vorkommt, sind Sie nicht allein.

Wenn die Werkzeuge zum Problem werden

Am Anfang war das Ziel vernünftig:

• SNMP-Daten
• Systemzustand
• Grundlegende Traffic-Statistiken
• Ein Ort, um alles zu sehen

Kein Enterprise-Monster und kein Booster für den DevOps-Lebenslauf, nur etwas Leichtgewichtiges und Zuverlässiges, das man nicht bemuttern muss.

Mit der Zeit wuchs der Stack aber zu einer seltsamen Kombination zusammengeschusterter Tools. Eine kleine Netzwerkänderung, und schon geht wieder etwas kaputt. Eine IP verschiebt sich, ein Service zieht um, und plötzlich ist die Hälfte der Graphen leer. Sie debuggen dann nicht mehr Ihr NAS, sondern das Monitoring Ihres NAS, und ab da beginnt die Spirale.

Stack Creep ist real

Wenn Sie lange genug dabeibleiben, rollen die Vorschläge herein:

• Prometheus
• Grafana
• Alertmanager
• Loki
• Telegraf
• VictoriaMetrics
• Alloy
• Vector

Und das alles, bevor jemand Zabbix, Icinga, Influx oder PRTG erwähnt. Überwältigend, und ein Kommentator brachte es perfekt auf den Punkt: Je mehr er sich umschaut, desto verwirrter wird er.

Die meisten dieser Tools lösen leicht unterschiedliche Probleme. Wenn man neu ist, verschwimmen sie aber zu einem einzigen riesigen „Monitoring-Ökosystem", und plötzlich fühlt sich das Wochenendhobby an wie der Entwurf einer Enterprise-Observability-Plattform. Für sechs VMs.

Das Alloy-Versprechen: alles bündeln, die Wildwucherung reduzieren

Eine starke Empfehlung war Grafana Alloy, und der Reiz liegt auf der Hand.

Traditionell sieht ein Prometheus-Setup so aus:

• Node Exporter
• SNMP Exporter
• Blackbox Exporter
• Prometheus Server
• Alertmanager
• Grafana

Jedes davon ist eine eigene Komponente mit eigener Config und eigenen Deployment-Kopfschmerzen. Alloy bündelt viele dieser Exporter in einem einzigen Agenten, von SNMP über Blackbox und Node-Metriken bis zu Syslog und Datenbank-Metriken. Statt fünf kleine Services zu orchestrieren, deployen Sie einen.

Für ein Homelab zählt diese Konsolidierung: weniger Angriffsfläche, weniger bewegliche Teile und weniger Dinge, die kaputtgehen, wenn Sie um Mitternacht VLANs ändern.

Selbst der „einfache" Stack ist nicht so einfach

Der empfohlene Stack lautet oft: Alloy sammelt, Prometheus dient als Backend, Grafana visualisiert, und Alertmanager übernimmt die Alerts. Dazu kommt vielleicht Remote Write zu Grafana Cloud, damit Sie benachrichtigt werden, wenn Ihr Monitoring-Stack selbst stirbt.

Das ist solider Rat, aber eben auch vier oder fünf Komponenten tief. Genau so werden Homelabs schleichend zu Produktions-Clustern. Man fängt mit „leichtgewichtig und zuverlässig" an und landet bei Alert-Routing-Regeln und Slack-Integrationen.

Der DNS-Realitätscheck

Ein Kommentar durchschnitt die ganze Tooling-Diskussion: Wenn Netzwerkänderungen Ihr Monitoring kaputtmachen, brauchen Sie vielleicht DNS.

Das ist der Rat, der sich offensichtlich anfühlt, sobald ihn jemand ausgesprochen hat. Wenn Sie überall IPs fest codieren und Tabellen als „Source of Truth" jonglieren, rettet Sie kein Monitoring-Tool. Schlechte IP-Hygiene macht alles brüchig.

Fragil ist das Monitoring also nicht, weil Prometheus kompliziert wäre, sondern weil die Infrastruktur darunter fragil ist. Eine bittere Pille, die meistens zutrifft.

Die Zabbix- und Icinga-Fraktion

Nicht jeder will modulare Observability-Legosteine zusammenbauen. Manche Leute sagen einfach: „Ich liebe PRTG." Oder: „Ich mag Icinga, Zabbix."

Diese Plattformen sind meinungsstärker und monolithischer und lassen sich für SNMP-lastige Umgebungen oft schneller zum Laufen bringen. Für ein Homelab, das vor allem Folgendes braucht, können sie völlig ausreichen:

• Gerätestatus
• Uptime
• Interface-Traffic
• Festplattenzustand

Prometheus glänzt dagegen, wenn Sie flexible Metriken, eigene Exporter, eine Aufteilung über Labels und langfristige Zeitreihenanalyse wollen. Lautet Ihr Hauptziel aber „das Ding nicht bemuttern müssen", gewinnt manchmal das integriertere Tool.

Der minimalistische Rat, der hart trifft

Eine der praktischsten Antworten war die einfachste: Fangen Sie mit Node Exporter auf allen Unix-Maschinen an, dazu Prometheus und Grafana, und nutzen Sie das Standard-Node-Exporter-Dashboard.

Allein dieser Stack deckt die Ursachen von 90 bis 95 % der Probleme auf, also CPU-Spitzen, Speicherdruck, Festplattenauslastung und Netzwerkanomalien.

Logs, Traces, synthetische Checks und verteilte Telemetrie-Pipelines brauchen Sie dafür nicht. Sie müssen wissen, ob Ihre Kiste erstickt, und das vergessen wir manchmal.

Die Gefahr, es „sehr ausgefallen" zu treiben

Ein anderer Kommentator brachte es unverblümt auf den Punkt: Man kann es damit sehr ausgefallen treiben, doch bei Homelab-Monitoring gewinnt Einfachheit.

Darin liegt die zentrale Spannung. Homelabs sind Spielplätze, Monitoring-Stacks sind Puzzles. Aufwendige Pipelines zu bauen macht Spaß, bis man merkt, dass man mehr Zeit in die Pflege des Monitorings steckt als in die Workloads. Wenn Ihr Monitoring öfter ausfällt als Ihr NAS, stimmt etwas nicht.

Warum das passiert

Monitoring befriedigt ein anderes Bedürfnis als Infrastruktur. Bei Infrastruktur geht es um Stabilität, bei Monitoring um Sichtbarkeit, und Sichtbarkeits-Tools machen süchtig.

Sobald Sie CPU-Graphen pro Kern, Histogramme der Festplatten-Latenz, Aufschlüsselungen des Netzwerkdurchsatzes, automatisiertes Alert-Routing und in Slack integrierte Dashboards sehen, hören Sie schwer wieder auf.

Jedes neue Feature bringt aber auch Konfigurationskomplexität, Netzwerkabhängigkeiten, Entscheidungen über Labels und Retention sowie Alert-Tuning mit sich. Und Komplexität summiert sich schneller, als man erwartet.

Die versteckten Kosten des „Stack-Lernens"

Es gibt noch einen anderen Blickwinkel in der Diskussion. Jemand mit einem funktionierenden Zabbix-Setup wollte trotzdem Grafana und Prometheus lernen, und das ist ehrlich. Bei Homelabs geht es neben der Uptime auch um Kompetenzaufbau.

Einen modernen Observability-Stack zu lernen ist allerdings, als öffnete man eine Werkzeugkiste mit 50 verschiedenen Schraubenschlüsseln: Prometheus, Grafana, Loki, Telegraf, VictoriaMetrics, Alloy, Vector. Jedes Tool löst ein Stück des Puzzles, zusammen können sie sich wie Chaos anfühlen.

Wenn Sie keine Grenze ziehen, wird das Lab am Ende zum Lab für Ihren Monitoring-Stack.

Was ist also die eigentliche Antwort?

Wenn sich das Monitoring Ihres Homelabs wie ein zweiter unbezahlter Job anfühlt, hilft diese unbequeme Checkliste:

1. Sammeln Sie zu viel?
2. Betreiben Sie mehrere Exporter, die Sie eigentlich nicht nutzen?
3. Codieren Sie IPs fest, statt DNS zu verwenden?
4. Jagen Sie Features hinterher, statt Probleme zu lösen?
5. Lernen Sie Tooling aus Neugier und lassen es dabei in Komplexität auf Produktionsniveau kippen?

Gegen einen vollständigen Stack aus Prometheus, Grafana und Alertmanager ist nichts zu sagen. Verwechseln Sie nur nicht „kann" mit „sollte".

Monitoring sollte langweilig sein

Die besten Monitoring-Setups verschwinden im Hintergrund. Sie überleben Netzwerkänderungen, Neustarts und Upgrades, alarmieren, wenn es nötig ist, und bleiben ansonsten still.

So ein Setup braucht kein wöchentliches Tuning, geht nicht kaputt, weil Sie VLANs umsortiert haben, und muss nicht bemuttert werden.

Wenn Ihr Homelab-Monitoring lauter ist als Ihr Homelab selbst, haben Sie eine Grenze überschritten. Die Lösung heißt dann meist Subtraktion, auch wenn der Reflex ein weiterer Exporter wäre. Der fortgeschrittenste Schachzug in einem Homelab ist manchmal die Entscheidung, dass Sie genug hinzugefügt haben.