senn-techMonitoring 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 öffentliches oder internes Status-Dashboard, konfigurierbar, mehrsprachig — mit eingeplanten Wartungsfenstern, damit geplante Arbeiten nicht als Ausfall in der Historie stehen. 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.
Der blinde Fleck: Wer überwacht den Wächter?
Läuft Uptime Kuma im selben Rechenzentrum wie die überwachten Dienste, sieht es einen Standort-Ausfall nicht — es ist dann selbst weg. Wir setzen die Statusüberwachung deshalb bewusst auf einen zweiten, getrennten Standort (oder einen günstigen externen VPS), damit der Ausfallalarm auch dann ankommt, wenn der Hauptstandort komplett dunkel ist.
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.
Ersetzt Uptime Kuma unser System-Monitoring mit Zabbix oder Grafana?+
Nein. Uptime Kuma prüft Erreichbarkeit, nicht Gesundheit. Es liefert keine Metriken zu CPU, Speicher oder Latenz-Perzentilen — dafür brauchen Sie weiterhin Prometheus/Grafana oder Zabbix. Auch die Historie ist zweckmäßig, nicht analytisch: Sie sehen, wann und wie lange ein Dienst ausgefallen war, aber keine Trendanalysen über Monate.
Wie erfahren wir von einem kompletten Standort-Ausfall, wenn der Monitor mit ausfällt?+
Läuft Uptime Kuma im selben Rechenzentrum wie die überwachten Dienste, sieht es einen Standort-Ausfall nicht — es ist dann selbst weg. Deshalb platzieren wir die Statusüberwachung bewusst auf einem zweiten, getrennten Standort oder einem günstigen externen VPS, damit der Alarm auch ankommt, wenn der Hauptstandort komplett dunkel ist.
Wie ressourcenhungrig ist der Betrieb und hängt er an einer Cloud?+
Uptime Kuma ist leichtgewichtig — rund 100 MB RAM im Idle, kaum CPU-Last — und läuft als einzelner Docker-Container im eigenen Netz. Kein SaaS, keine API-Limits, keine externe Abhängigkeit. Benachrichtigungen gehen wahlweise per E-Mail, Telegram, Discord, Signal oder Webhook; eine konfigurierbare Statusseite mit Wartungsfenstern ist bereits eingebaut.