Schwierigkeit: Mittel · Dauer: 45–90 Min · Ziel: Uptime Kuma Multi-Location Checks: Latenzvergleich und echte SLA-Sicht
Kurzproblem und Zielbild
In diesem Guide setzt du Uptime Kuma Multi-Location Checks: Latenzvergleich und echte SLA-Sicht 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 30Schritt-für-Schritt Umsetzung
1) Ausgangszustand dokumentieren
date -Iseconds
uname -a
# aktuelle Versionen und relevante Konfig-Pfade notieren2) Kernkonfiguration sauber setzen
docker ps --filter name=uptime-kuma
docker logs --tail 100 uptime-kuma
# mehrere Push Probes/Locations konfigurieren3) Dienst/Funktion gezielt prüfen
# Latenzvergleich in Status Page prüfen
# Alerting nur bei Mehrheitsfehlern auslösen4) Betriebsgrenzen testen
docker ps --filter name=uptime-kuma
docker logs --tail 200 uptime-kuma | egrep -i "timeout|dns|connect|tls"
curl -m 5 -I https://dein-endpunkt.tld || trueValidierung / Checks
# Latenzvergleich in Status Page prüfen
# Alerting nur bei Mehrheitsfehlern auslösen
curl -I http://127.0.0.1:3001
docker logs --tail 100 uptime-kumaTroubleshooting
Konfiguration wird nicht übernommen
Ursache: Syntax-/Reload-Fehler oder falscher Parameterpfad.
docker logs --tail 200 uptime-kuma
nslookup dein-endpunkt.tld
curl -vk https://dein-endpunkt.tldDienst läuft, Funktion aber fehlerhaft
Ursache: Abhängigkeiten, Routing, Rechte oder Versionen inkonsistent.
traceroute dein-endpunkt.tld
ss -ltnp | grep 3001
docker inspect uptime-kuma --format '{{.State.Status}}'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.
