HomelabNerds

HOME LAB · SELFHOSTING · NETZWERK

Schlagwort: alerts

  • 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

  • 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