Project Rebel Homebase: Teil 6 - und die Nebel lichten sich

1. Die Mission: Den Nebel lichten

In Teil 5 haben wir den Meilenstein gesetzt: Der K3s-Cluster läuft. Der Master kommandiert, und die vier Worker-Blades (die Infanterie) stehen bereit. Das "Blech" atmet, Kubernetes lebt.

Aber: Aktuell fliegen wir noch im Blindflug. Wir können zwar via kubectl sehen, dass die Nodes "Ready" sind, aber wir wissen nicht, wie sehr sie schwitzen. Monitoring ist kein Luxus, sondern die Lebensversicherung für deine Daten und die Stabilität deiner Services. Wir wollen Antworten auf Fragen wie:

• Werden die Pis zu heiß?
• Welcher Node im Cluster frisst den RAM?
• Ist das System stabil oder steht es kurz vor dem OOM (Out of Memory)?

Und ja, das machen wir jetzt mit einem kleinen bisschen Luxus.

2. Die Architektur: Der Wachturm auf dem ZimaBlade

Das ZimaBlade tut derzeit nichts, wir nutzen das also als dedizierten Monitoring-Node.

• Warum? Es wäre total unlogisch den Wächter in den Cluster zu packen, den er überwachen soll. Es ist ein x86-System, unabhängig von der ARM-Architektur der Pis. Wenn der Cluster abstürzt, bleibt der Wachturm stehen. Und meldet.
• Der Stack: Prometheus als Daten-Sammler und Grafana für eine attraktive Visualisierung. Das sind keine experimentellen Tools sondern ausgereifte Projekte, die in extrem vielen großen professionellen Infrastrukturen eingesetzt werden

3. Das Fundament: ZimaBlade Vorbereitung

Bevor wir mit dem Monitoring starten konnten, musste das ZimaBlade als stabiler Ankerpunkt im Netzwerk gefestigt werden. Als Betriebssystem kam ein frisches Ubuntu 24.04 LTS zum Einsatz, um langfristigen Support zu garantieren. Nach der Installation wurde als erste Amtshandlung der Hostname auf monitor gesetzt und eine statische IP-Konfiguration vorgenommen, damit Prometheus und Grafana immer unter derselben Adresse erreichbar bleiben.

Die wichtigsten Befehle zur Einrichtung:

# Hostnamen setzen
sudo hostnamectl set-hostname monitor

# System auf den neuesten Stand bringen
sudo apt update && sudo apt upgrade -y

# Statische IP vergeben (Beispiel via Netplan)
# Die Datei /etc/netplan/01-netcfg.yaml wurde wie folgt angepasst:
# address: 192.168.1.11/24
# gateway4: 192.168.1.1 (DreamWall)
# nameservers: [192.168.1.3, 192.168.1.4] (Unsere Pi-Holes)

sudo netplan apply

Der Identitäts-Fix: Wenn das System den Namen vergisst

Ein kurioses Problem begleitete uns: Das ZimaBlade vergaß nach jedem Neustart seine Identität. Egal was man per Befehl änderte, nach dem Reboot stand dort ja (wieder einmal) der Standard-Name. Da die Cloud-Init-Einstellungen nicht griffen, haben wir uns für die "harte Tour" entschieden und den Namen sowie den FQDN (monitor.pandolin.online) direkt in die Systemdateien geschrieben.

Die finale Lösung:

In der /etc/hosts: Hier haben wir die Brücke zwischen der lokalen IP und der Welt geschlagen. Das ist entscheidend, damit Dienste wie Grafana wissen, wer sie sind.Bash

# Datei öffnen
sudo nano /etc/hosts
# Inhalt (angepasst):
127.0.0.1       localhost
127.0.1.1       monitor.pandolin.online monitor

In der /etc/hostname: Hier haben wir den kurzen Namen fixiert.

# Datei öffnen
sudo nano /etc/hostname
# Inhalt:
monitor

Durch diesen manuellen Eingriff haben wir die automatische Namensvergabe überstimmt. Seitdem meldet sich das System nach jedem Start stolz und korrekt als monitor.pandolin.online.

4. Schritt 1: Die "Spione" installieren (Node Exporter)

Bevor der Wachturm Daten sammeln kann, brauchen wir auf jedem Gerät einen "Spion". Ein kleines Tool aus der Prometheus Familie, der Node Exporter liest Hardware-Metriken aus.

Kommando für alle Linux-Nodes (Pis & Zima & Ryzen):

sudo apt update && sudo apt install prometheus-node-exporter -y

Der Test: Im Browser http://<IP-vom-PI-Blade>:9100/metrics. Siehst du eine endlose Liste von Zahlen? Perfekt, der Spion arbeitet und castet seine Telemetrie in das Netz.

Diese Übung machen wir mit jedem Rechner im Netz den wir zukünftig überwachen wollen. Und das sollen ja alle sein. Durchlick ist essentiell wenn mal was nicht gehen sollte und unser Monitoring-Setup wird der erste Einstiegspunkt.

Bei mir sind es heute der k3s-master, k3s-w01 bis k3s-w04, das ZimaBlade selber, die beiden dns1 und dns2, zu guter Letzt kommt dann noch der Ryzen (der ist aber noch nicht in Amt und Würden) dazu.

5. Schritt 2: Den Wachturm in Portainer errichten

Auf dem ZimaBlade nutzen wir also Docker via Portainer. Portainer ist ein großartiges Werkzeug zur Verwaltung von Docker. Und Prometheus und Grafana installieren wir als Docker-Container.

Wichtig: Das Verzeichnis-Skelett anlegen! Bevor wir den Stack starten, müssen wir kurz sicherstellen, dass die Ordner auf dem ZimaBlade existieren. Docker würde sie zwar automatisch anlegen, aber oft mit den falschen Rechten (root), was später zu Problemen führt. Also einmal kurz ins Terminal:

# Ordner für Prometheus und Grafana erstellen
mkdir -p /home/axel/monitoring/prometheus
mkdir -p /home/axel/monitoring/grafana/data

Jetzt legen wir in Portainer einen neuen Stack an. Der "Monitor-Stack" (Docker Compose):

Der "Monitor-Stack" (Docker Compose):

services:
  prometheus:
    image: prom/prometheus
    container_name: prometheus
    volumes:
      - /home/axel/monitoring/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - 9090:9090
    restart: always

grafana:
    image: grafana/grafana
    container_name: grafana
    volumes:
      - /home/axel/monitoring/grafana/data:/var/lib/grafana
    ports:
      - 3000:3000
    restart: always

6. Schritt 3: Die Konfiguration (einmal YAML und zurück)

Das ist der Punkt, an dem wir heute am meisten geschwitzt haben. Die prometheus.yml sagt dem Sammler, wen er abfragen soll.

Der Fehler-Report: Wir sind in die "Line 1 Syntax-Falle" getappt. YAML verzeiht nichts. Ein falsches Leerzeichen oder ein Mix aus Schreibstilen (Bindestriche, eckige Klammern...) führt zum Fehler. Aber man hats dann irgendwann raus.

Die finale Lösung (Kommando für das Terminal): Wir nutzen cat, um die Datei ohne Editor-Fehler direkt zu schreiben:

sudo bash -c 'cat <<EOF > /home/axel/monitoring/prometheus/prometheus.yml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: "rebel-monitor"
    static_configs:
      - targets: ["192.168.1.11:9100"]

  - job_name: "rebel-k3s-nodes"
    static_configs:
      - targets:
          - "192.168.1.15:9100"
          - "192.168.1.21:9100"
          - "192.168.1.22:9100"
          - "192.168.1.23:9100"
          - "192.168.1.24:9100"
EOF'

Diese Datei habe ich dann später noch um einen Job für die beiden dns1 und dns2 ergänzt. Auch der Ryzen kommt noch dazu.

7. Schritt 4: Das Rechte-Drama (Permission Denied)

Prometheus läuft im Container als User 65534 (nobody). Wenn die Konfig-Datei deinem User axel gehört, darf Prometheus sie nicht lesen.

Die Lösung:

# Wir schenken die Datei dem Prometheus-User
sudo chown 65534:65534 /home/axel/monitoring/prometheus/prometheus.yml

# WICHTIG: Auch Grafana braucht Schreibrechte auf seinen Ordner (User ID 472)
sudo chown -R 472:472 /home/axel/monitoring/grafana

docker restart prometheus grafana

8. Schritt 5: Die Belohnung in Grafana

Jetzt verbinden wir die Punkte. Hier scheitern viele Anleitungen, weil sie davon ausgehen, dass Grafana "einfach so" Bescheid weiß. Tut es aber nicht.

A. Die Datenquelle verbinden

1. Logge dich in Grafana ein (Port 3000). (Standard-Login ist admin/admin – sofort ändern!).
2. Gehe im Menü auf Connections -> Data Sources.
3. Klicke auf + Add new data source und wähle Prometheus.
4. Im Feld Prometheus server URL gibst du die interne Adresse des ZimaBlades ein: http://192.168.1.11:9090.
5. Scrolle nach unten und klicke Save & test. Wenn ein grüner Haken erscheint ("Data source is working"), steht die Leitung.

B. Das Dashboard importieren Wir bauen das Rad nicht neu, sondern nutzen den Community-Standard.

1. Klicke oben rechts auf das Plus (+) -> Import dashboard.
2. Gib im Feld "Import via grafana.com" die ID 1860 ein (das ist das beliebte "Node Exporter Full" Dashboard).
3. Klicke auf Load.
4. Wähle unten bei "Prometheus" deine eben erstellte Datenquelle aus.
5. Klicke auf Import.

Plötzlich wird aus dem Zahlensalat eine wunderbare Cockpit-Ansicht der gesamten HomeBase. Das lässt sich später dann auch anpassen, aber im ersten Schritt reicht das erstmal.

9. Das UNAS2-Dilemma (Ausblick)

Ich habe versucht, das Unifi-NAS via SNMP einzubinden. Das Ergebnis? Ich zweifle dran, ob die Entscheidung richtig war, das zu kaufen. Ein geschlossenes System. SNMP ist hier für Netzwerk-Traffic okay, aber für echtes Speicher- und Temperatur-Monitoring bei Unifi klappt erst einmal nicht. Schade. Hat jemand von euch einen Tipp?