HomelabNerds

HOME LAB · SELFHOSTING · NETZWERK

Kategorie: Monitoring & Observability

Monitoring, Logging, Alerting und Metriken.

  • Nginx Proxy Manager mit Let’s Encrypt: saubere Reverse-Proxy-Basis

    Nginx Proxy Manager mit Let’s Encrypt: saubere Reverse-Proxy-Basis

    Schwierigkeit: Mittel · Dauer: 45–90 Min · Ziel: Nginx Proxy Manager mit Let's Encrypt: saubere Reverse-Proxy-Basis

    Kurzproblem und Zielbild

    In diesem Guide setzt du Nginx Proxy Manager mit Let’s Encrypt: saubere Reverse-Proxy-Basis mit reproduzierbaren Schritten, klaren Checks und belastbaren Recovery-Pfaden um.

    Voraussetzungen

    • Linux-/CLI-Grundlagen
    • Admin-Zugriff auf die Zielsysteme
    • Snapshot/Backup vor Änderungen

    Schnellstart (funktionierende Basis)

    hostnamectl
ip a
systemctl --failed
journalctl -p 3 -xb --no-pager | tail -n 30

    Schritt-für-Schritt Umsetzung

    1) Ausgangszustand dokumentieren

    date -Iseconds
uname -a
# aktuelle Versionen und relevante Konfig-Pfade notieren

    2) Kernkonfiguration sauber setzen

    docker compose up -d
docker logs --tail 100 nginx-proxy-manager
curl -I http://localhost:81

    3) Dienst/Funktion gezielt prüfen

    curl -I https://deine-domain.tld
docker exec -it nginx-proxy-manager ls -lah /etc/letsencrypt/live

    4) Betriebsgrenzen testen

    # Gezielten Failover-/Negativtest ausführen
# Reaktionszeit und Fehlerbild protokollieren
# Danach Service normalisieren und Zustand erneut verifizieren

    Validierung / Checks

    curl -I https://deine-domain.tld
docker exec -it nginx-proxy-manager ls -lah /etc/letsencrypt/live
# End-to-End Test mit klaren Sollwerten durchführen und Ergebnis dokumentieren

    Troubleshooting

    Konfiguration wird nicht übernommen

    Ursache: Syntax-/Reload-Fehler oder falscher Parameterpfad.

    journalctl -n 120 --no-pager
# betroffenen Dienst gezielt reload/restarten
# Konfigurationsdatei auf Syntax prüfen

    Dienst läuft, Funktion aber fehlerhaft

    Ursache: Abhängigkeiten, Routing, Rechte oder Versionen inkonsistent.

    ip a
ip route
ss -tulpn
# Berechtigungen und Abhängigkeiten gegenprüfen

    Fazit

    Mit einem klaren Ablauf, harten Checks und dokumentierten Grenzwerten bleibt das Setup wartbar statt zufällig stabil. Nächster Schritt: den Ablauf als monatliche Betriebsroutine einplanen.

    Quellen

  • Docker Compose Healthchecks richtig nutzen: depends_on, retries, startup-order

    Docker Compose Healthchecks richtig nutzen: depends_on, retries, startup-order

    Schwierigkeit: Mittel · Dauer: 45–90 Min · Ziel: Docker Compose Healthchecks richtig nutzen: depends_on, retries, startup-order

    Kurzproblem und Zielbild

    In diesem Guide setzt du Docker Compose Healthchecks richtig nutzen: depends_on, retries, startup-order mit reproduzierbaren Schritten, klaren Checks und belastbaren Recovery-Pfaden um.

    Voraussetzungen

    • Linux-/CLI-Grundlagen
    • Admin-Zugriff auf die Zielsysteme
    • Snapshot/Backup vor Änderungen

    Schnellstart (funktionierende Basis)

    hostnamectl
ip a
systemctl --failed
journalctl -p 3 -xb --no-pager | tail -n 30

    Schritt-für-Schritt Umsetzung

    1) Ausgangszustand dokumentieren

    date -Iseconds
uname -a
# aktuelle Versionen und relevante Konfig-Pfade notieren

    2) Kernkonfiguration sauber setzen

    cat docker-compose.yml
docker compose config
docker compose up -d
docker inspect --format "{{json .State.Health}}" CONTAINER

    3) Dienst/Funktion gezielt prüfen

    docker compose ps
docker inspect --format "{{.Name}} {{.State.Health.Status}}" $(docker ps -q)

    4) Betriebsgrenzen testen

    # Gezielten Failover-/Negativtest ausführen
# Reaktionszeit und Fehlerbild protokollieren
# Danach Service normalisieren und Zustand erneut verifizieren

    Validierung / Checks

    docker compose ps
docker inspect --format "{{.Name}} {{.State.Health.Status}}" $(docker ps -q)
# End-to-End Test mit klaren Sollwerten durchführen und Ergebnis dokumentieren

    Troubleshooting

    Konfiguration wird nicht übernommen

    Ursache: Syntax-/Reload-Fehler oder falscher Parameterpfad.

    journalctl -n 120 --no-pager
# betroffenen Dienst gezielt reload/restarten
# Konfigurationsdatei auf Syntax prüfen

    Dienst läuft, Funktion aber fehlerhaft

    Ursache: Abhängigkeiten, Routing, Rechte oder Versionen inkonsistent.

    ip a
ip route
ss -tulpn
# Berechtigungen und Abhängigkeiten gegenprüfen

    Fazit

    Mit einem klaren Ablauf, harten Checks und dokumentierten Grenzwerten bleibt das Setup wartbar statt zufällig stabil. Nächster Schritt: den Ablauf als monatliche Betriebsroutine einplanen.

    Quellen

  • k3s Worker Node hinzufügen: Join, Labels, Drain und sichere Wartung

    k3s Worker Node hinzufügen: Join, Labels, Drain und sichere Wartung

    Schwierigkeit: Mittel · Dauer: 35–65 Min · Ziel: k3s Worker Node hinzufügen: Join, Labels, Drain und sichere Wartung

    Kurzproblem und Zielbild

    In vielen Homelabs funktioniert die Erstinstallation, aber der Dauerbetrieb wird schnell unübersichtlich. Dieses Tutorial zeigt einen reproduzierbaren Ablauf für k3s Worker Node hinzufügen 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

    sudo cat /var/lib/rancher/k3s/server/node-token
curl -sfL https://get.k3s.io | K3S_URL=https://SERVER_IP:6443 K3S_TOKEN=TOKEN sh -
kubectl get nodes -o wide
kubectl label node WORKER1 workload=apps tier=edge

    Erklärung: Änderungen gezielt umsetzen, danach direkt den Dienst-/Funktionszustand prüfen.

    3) Dienst kontrolliert neu laden

    sudo systemctl daemon-reload
sudo systemctl restart 
sudo systemctl status  --no-pager

    4) Betriebsgrenzen testen

    kubectl cordon WORKER1
kubectl drain WORKER1 --ignore-daemonsets --delete-emptydir-data
kubectl get nodes
kubectl uncordon WORKER1

    Validierung / Checks

    kubectl get nodes -o wide
kubectl describe node WORKER1 | sed -n "1,180p"
systemctl status k3s-agent --no-pager
journalctl -u k3s-agent -n 150 --no-pager

    Troubleshooting

    Konfiguration wird nicht übernommen

    Ursache: Syntax-, Reload- oder Parameterfehler.

    nc -vz SERVER_IP 6443
cat /etc/rancher/k3s/config.yaml
journalctl -u k3s-agent -n 200 --no-pager

    Dienst läuft, Funktion aber fehlerhaft

    Ursache: Abhängigkeiten, Routing oder Berechtigungen sind inkonsistent.

    kubectl get pdb -A
kubectl get pods -A -o wide | grep WORKER1
kubectl describe pod POD -n NAMESPACE

    Fazit

    Mit einem klaren Ablauf für k3s Worker Node hinzufügen 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

  • Uptime Kuma + Status Pages: Monitoring intern und extern trennen

    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

    docker run -d --name uptime-kuma -p 3001:3001 -v uptime-kuma:/app/data --restart unless-stopped louislam/uptime-kuma:1
# In der UI: Monitor-Gruppen internal/external trennen
# Status Page nur mit externen Checks veröffentlichen

    Erklärung: Änderungen gezielt umsetzen, danach direkt den Dienst-/Funktionszustand prüfen.

    3) Dienst kontrolliert neu laden

    sudo systemctl daemon-reload
sudo systemctl restart 
sudo systemctl status  --no-pager

    4) Betriebsgrenzen testen

    docker ps --filter name=uptime-kuma
docker logs --tail 100 uptime-kuma
curl -I http://127.0.0.1:3001

    Validierung / Checks

    docker inspect uptime-kuma --format "{{json .HostConfig.RestartPolicy}}"
# UI-Check: Nur externe Gruppe auf Status Page sichtbar

    Troubleshooting

    Konfiguration wird nicht übernommen

    Ursache: Syntax-, Reload- oder Parameterfehler.

    # Monitor-Visibility und Public Group in Uptime-Kuma prüfen
# interne Monitore auf private setzen

    Dienst läuft, Funktion aber fehlerhaft

    Ursache: Abhängigkeiten, Routing oder Berechtigungen sind inkonsistent.

    dig your-service.example.com
docker logs --tail 200 uptime-kuma

    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

  • Docker Logs unter Kontrolle: Rotation, Retention und schnelle Analyse

    Docker Logs unter Kontrolle: Rotation, Retention und schnelle Analyse

    Schwierigkeit: Mittel · Dauer: 35–65 Min · Ziel: Docker Logs unter Kontrolle: Rotation, Retention und schnelle Analyse

    Kurzproblem und Zielbild

    In vielen Homelabs funktioniert die Erstinstallation, aber der Dauerbetrieb wird schnell unübersichtlich. Dieses Tutorial zeigt einen reproduzierbaren Ablauf für Docker Logs unter Kontrolle 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

    sudo mkdir -p /etc/docker
cat <<'EOF' | sudo tee /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {"max-size": "10m", "max-file": "5"}
}
EOF
sudo systemctl restart docker
docker info | grep -E "Logging Driver|Docker Root Dir"

    Erklärung: Änderungen gezielt umsetzen, danach direkt den Dienst-/Funktionszustand prüfen.

    3) Dienst kontrolliert neu laden

    sudo systemctl daemon-reload
sudo systemctl restart 
sudo systemctl status  --no-pager

    4) Betriebsgrenzen testen

    docker ps --format "table {{.Names}}	{{.Status}}"
docker inspect -f "{{.Name}} -> {{.HostConfig.LogConfig.Type}} {{json .HostConfig.LogConfig.Config}}" $(docker ps -q)
sudo du -sh /var/lib/docker/containers/*/*-json.log | sort -h | tail -n 10

    Validierung / Checks

    docker info | grep "Logging Driver"
docker system df
systemctl status docker --no-pager

    Troubleshooting

    Konfiguration wird nicht übernommen

    Ursache: Syntax-, Reload- oder Parameterfehler.

    docker inspect -f "{{.Name}} {{json .HostConfig.LogConfig}}" CONTAINER
docker compose up -d --force-recreate

    Dienst läuft, Funktion aber fehlerhaft

    Ursache: Abhängigkeiten, Routing oder Berechtigungen sind inkonsistent.

    docker system df
du -sh /var/lib/docker/volumes/* | sort -h | tail -n 10
journalctl --disk-usage

    Fazit

    Mit einem klaren Ablauf für Docker Logs unter Kontrolle 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

  • Uptime Kuma Alerts sinnvoll aufsetzen: weniger Lärm, bessere Signale

    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

    # 1) Kuma-Container und Health prüfen
docker ps --filter name=uptime-kuma
curl -fsS http://127.0.0.1:3001 >/dev/null && echo "Kuma UI erreichbar"

# 2) Gezielten Ausfall simulieren (Beispielservice)
docker stop reverse-proxy
sleep 90

# 3) Prüfen: genau 1 Alert + Recovery nach Wiederanlauf
docker start reverse-proxy
sleep 90

# 4) Kuma-Logs auf Flapping/Fehler prüfen
docker logs --since 10m uptime-kuma | tail -n 120

    Troubleshooting

    Zu viele Fehlalarme

    # DNS/Latenz prüfen
dig +short example.local
ping -c 4 example.local

# Host-Antwortzeit testen
curl -o /dev/null -s -w "HTTP:%{http_code} TIME:%{time_total}\n" https://example.local

# Danach in Kuma: Timeout +5s, Retry -1

    Recovery-Meldung fehlt

    # Notification-Test in Kuma auslösen
# Settings -> Notifications -> Test

# Container-Logs nach Sendefehlern durchsuchen
docker logs --since 30m uptime-kuma | grep -Ei "notify|telegram|discord|smtp|error" | tail -n 80

    Fazit

    Gutes Monitoring ist nicht „mehr Monitore“, sondern bessere Priorisierung. Nächster Schritt: monatlich die noisiesten Checks identifizieren und nachschärfen.

    Quellen