HomelabNerds

HOME LAB · SELFHOSTING · NETZWERK

Schlagwort: Homelab

Uptime Kuma + Status Pages: Monitoring intern und extern trennen
Schwierigkeit: Mittel · Dauer: 35–65 Min · Ziel: Uptime Kuma + Status Pages: Monitoring intern und extern trennen

Kurzproblem und Zielbild
In vielen Homelabs funktioniert die Erstinstallation, aber der Dauerbetrieb wird schnell unübersichtlich. Dieses Tutorial zeigt einen reproduzierbaren Ablauf für Uptime Kuma + Status Pages mit Fokus auf Stabilität, klare Checks und einfache Fehlerbehebung.
Ziel ist ein Setup, das nicht nur heute läuft, sondern auch nach Updates und Änderungen beherrschbar bleibt.

Voraussetzungen
- Aktuelles Debian/Ubuntu oder kompatible Appliance
- Administrative Rechte und Wartungsfenster
- Backup- oder Snapshot-Möglichkeit vor Änderungen
Schnellstart (funktionierende Basis)
```
# Basisprüfung
hostnamectl
ip a
# Dienste prüfen
systemctl --failed
# Logs kurz prüfen
journalctl -p 3 -xb --no-pager | tail -n 30
```
Was macht das? Du prüfst erst den Grundzustand und vermeidest, dass Altfehler in neue Änderungen hineinwirken.

Schritt-für-Schritt Umsetzung

1) Ausgangszustand dokumentieren
```
date -Iseconds
uname -a
# versions/relevante configs sichern
```
Erklärung: Mit einer kurzen Bestandsaufnahme lassen sich spätere Fehler schneller eingrenzen.

2) Kernkonfiguration sauber setzen
```
# hier die zentrale Uptime Kuma + Status Pages-Konfiguration umsetzen
# Konfigdatei bearbeiten, nur notwendige Werte ändern
```
Erklärung: Ändere nur das Nötigste und halte die Konfiguration nachvollziehbar.

3) Dienst kontrolliert neu laden
```
sudo systemctl daemon-reload
sudo systemctl restart 
sudo systemctl status  --no-pager
```
4) Betriebsgrenzen testen
```
# Healthcheck/Endpoint prüfen
# Logs und Fehlerraten beobachten
```
Validierung / Checks
```
systemctl status  --no-pager
journalctl -u  -n 150 --no-pager
# funktionaler End-to-End Check
```
Troubleshooting
Konfiguration wird nicht übernommen
Ursache: Tippfehler oder veralteter Service-Reload.
```
sudo  --check
sudo systemctl daemon-reload
sudo systemctl restart 
```
Dienst läuft, Funktion aber fehlerhaft
Ursache: Abhängigkeit, DNS oder Routing nicht konsistent.
```
dig example.org
ip route
journalctl -u  -n 200 --no-pager
```
Fazit
Mit einem klaren Ablauf für Uptime Kuma + Status Pages reduzierst du Ausfälle und erhöhst die Wartbarkeit deutlich. Der wichtigste Hebel ist die Kombination aus kleiner Änderung, sofortigem Check und dokumentiertem Ergebnis.
Nächster Schritt: den Ablauf als monatliche Betriebsroutine einplanen und regelmäßig gegen echte Störfälle testen.

Quellen
16.02.2026
Uptime Kuma Alerts sinnvoll aufsetzen: weniger Lärm, bessere Signale
Schwierigkeit: Leicht · Dauer: 30–50 Min · Ziel: Uptime-Kuma-Checks und Benachrichtigungen so konfigurieren, dass echte Störungen schnell sichtbar werden.

Kurzproblem und Zielbild
Zu aggressive Monitoring-Defaults erzeugen Alarmrauschen. Ziel ist ein stabiles Signal-Rausch-Verhältnis mit klaren Intervallen, Timeouts und sauberen Notification-Profilen.

Voraussetzungen
- Laufende Uptime-Kuma-Instanz
- Mindestens ein Notification-Channel (Mail/Discord/Telegram)
- Liste kritischer Dienste
Schnellstart (funktionierende Basis)
```
docker ps | grep uptime-kuma
# UI öffnen und 3 kritische Monitore anlegen
# Intervall 60s, Retry 2, Timeout 16s
```
Schritt-für-Schritt Umsetzung
1) Monitore nach Kritikalität gruppieren
```
# Kritisch: Auth, Reverse Proxy, DNS
# Wichtig: Medien/Tools
# Nice-to-have: Nebenservices
```
2) Timeouts/Retry je Diensttyp
```
# HTTP intern: timeout 10-16s
# Extern über WAN: timeout 20-30s
# retry sparsam nutzen, sonst Alarmflut
```
3) Wartungsfenster definieren
```
# Geplante Updates als Maintenance in Kuma eintragen
```
4) Alert-Routing trennen
```
# Kritisch -> sofort Push
# Nicht-kritisch -> gesammelt / zeitversetzt
```
Validierung / Checks
```
# Testausfall simulieren (Dienst stoppen)
# Prüfen: Alert kommt 1x, Recovery-Message folgt
# Danach Dienst wieder starten
```
Troubleshooting
Zu viele Fehlalarme
```
# Timeout erhöhen, Retry reduzieren, DNS prüfen
```
Recovery-Meldung fehlt
```
# Notification-Integration + Event-Typen prüfen
```
Fazit
Gutes Monitoring ist nicht „mehr Monitore“, sondern bessere Priorisierung. Nächster Schritt: monatlich die noisiesten Checks identifizieren und nachschärfen.

Quellen
16.02.2026
OPNsense Regeln sauber aufbauen: Segmentierung, NAT und Wartbarkeit
Schwierigkeit: Mittel · Dauer: 45–75 Min · Ziel: OPNsense-Regeln konsistent aufbauen, damit Netzwerkzugriffe nachvollziehbar und sicher bleiben.

Kurzproblem und Zielbild
Viele OPNsense-Setups wachsen mit Einzelregeln und verlieren schnell die Übersicht. Ziel ist ein klarer, wiederholbarer Regelaufbau mit Segmentierung, nachvollziehbarem NAT und sauberen Checks.

Voraussetzungen
- OPNsense mit administrativem Zugriff
- Definierte Netze/VLANs
- Wartungsfenster und Backup vor Regeländerungen
Schnellstart (funktionierende Basis)
```
cp /conf/config.xml /conf/config.xml.bak.$(date +%F-%H%M)
pfctl -sr
configctl filter status
```
Schritt-für-Schritt Umsetzung
1) Regelmodell festlegen
```
# Prinzip: erst erlaubte Flows definieren, dann default deny
# Beispielzonen: LAN, SERVER, IOT, MGMT
```
2) Aliases für Dienste/Netze
```
# in OPNsense GUI: Firewall > Aliases
# z.B. RFC1918_INTERNAL, DNS_SERVERS, MGMT_HOSTS
```
3) NAT konsistent halten
```
# Outbound NAT auf Hybrid/Manual nur wenn nötig
# Portforwards nur mit zugehöriger Filterregel
```
4) Logging für kritische Regeln
```
# Block-/Allow-Regeln für sensible Segmente mit Logging aktivieren
```
Validierung / Checks
```
pfctl -sr
pfctl -sn
configctl filter status
clog -f /var/log/filter/filter.log
```
Troubleshooting
Traffic bricht nach Regeländerung
```
pfctl -sr | less
# Reihenfolge prüfen, pass/quick beachten
```
Portforward greift nicht
```
pfctl -sn
# zugehörige Filterregel und Zielhost prüfen
```
Fazit
Mit Alias-basiertem Regelwerk und klarer Segmentierung bleibt OPNsense langfristig wartbar. Nächster Schritt: monatlicher Regel-Review mit Cleanup veralteter Ausnahmen.

Quellen
16.02.2026
Proxmox Backup richtig prüfen: Restore-Tests statt Backup-Illusion
Schwierigkeit: Mittel · Dauer: 40–70 Min · Ziel: Proxmox-Backups regelmäßig verifizieren und Restore-Pfade praktisch testen.

Kurzproblem und Zielbild
Backups ohne Restore-Test geben trügerische Sicherheit. Ziel ist ein kurzer, reproduzierbarer Prüfprozess mit klaren Kriterien: Backup vorhanden, konsistent, in vertretbarer Zeit wiederherstellbar.

Voraussetzungen
- Proxmox VE + Backup-Storage/PBS
- Mindestens eine VM/CT für Test-Restore
- Wartungsfenster
Schnellstart (funktionierende Basis)
```
vzdump --all 1 --mode snapshot --compress zstd --storage <STORAGE>
pvesm status
qm list
pct list
```
Schritt-für-Schritt Umsetzung

1) Backup-Jobs und Logs prüfen
```
grep -R "vzdump" /etc/pve/jobs.cfg
journalctl -u pvedaemon -n 200 --no-pager
```
2) Test-VM wiederherstellen
```
qmrestore /path/to/backup.vma.zst 9001 --storage <TARGET>
qm start 9001
```
3) Funktions-Check
```
qm status 9001
# optional: service checks in restored VM
```
4) Ergebnis dokumentieren
```
echo "$(date -Iseconds) restore test OK" >> /root/restore-tests.log
```
Validierung / Checks
```
pvesm status
qm status 9001
ls -lh /var/log/ | head
```
Troubleshooting
Restore bricht mit Storage-Fehler ab
```
pvesm status
# Storage online/space prüfen
```
VM bootet nach Restore nicht
```
qm config 9001
qm terminal 9001
```
Fazit
Restore-Tests machen aus Backups einen verlässlichen Betriebsprozess. Nächster Schritt: monatlichen Restore-Drill fix im Kalender verankern.

Quellen
16.02.2026