Monitoring ohne Ballast: Uptime Kuma im Eigenbetrieb

Für das Überwachen interner Dienste setzen wir Graylog und Zabbix ein. Aber für die eine Frage — „Läuft der Dienst von außen erreichbar?“ — gibt es etwas Schlankeres: Uptime Kuma.

Was es tut

Ein Docker-Container, der periodisch Services abklopft: HTTP(S), TCP, Ping, DNS, Docker-Healthchecks, sogar REST-APIs und MQTT. Reagiert einer nicht, schlägt eine der vielen Benachrichtigungen an: E-Mail, Telegram, Discord, Signal, Webhook.

docker run -d --name uptime-kuma -p 3001:3001 louislam/uptime-kuma:1

Das Web-Interface ist angenehm direkt. Ein Monitor pro Dienst, Intervalle ab 20 Sekunden, Heartbeat-Intervalle für Cronjobs, Zertifikatablauf-Warnungen inklusive.

Was uns überzeugt hat

Statusseite out of the box. Ein öffentlicher oder interner Status-Dashboard, konfigurierbar, mehrsprachig. Das ist für Kunden mit eigener Infrastruktur ein unterschätztes Feature.

Keine externe Abhängigkeit. Wenn das Monitoring selbst überwacht werden muss, ist ein eigenständiger Container im eigenen Netz immer noch die sauberste Lösung. Kein SaaS, keine API-Limits.

Leichtgewichtig. 100 MB RAM im Idle, kaum CPU-Last. Der Container läuft auf demselben Docker-Linux-VM wie andere kleine Dienste, ohne dass man darüber nachdenken muss.

Wo es an seine Grenzen kommt

Uptime Kuma ersetzt kein System-Monitoring. Keine Metriken über CPU, Speicher, Latenz-Perzentile — dafür brauchen Sie weiterhin Prometheus/Grafana oder Zabbix. Uptime Kuma prüft Erreichbarkeit, nicht Gesundheit.

Auch die Historie ist zweckmäßig, nicht analytisch: Sie sehen, wann ein Dienst ausgefallen war und wie lang. Trendanalysen über Monate sind nicht das Ziel.

Fazit

Uptime Kuma ist das Werkzeug, das man nebenbei aufsetzt und dann vergisst — bis es meldet. Genau so soll Monitoring sein. Wir installieren es standardmäßig auf jedem Kunden-VM-Host.