Uptime Kuma v2: Ressourcenverbrauch und Einrichtungsleitfaden für Self-Hoster

Eine aktuelle technische Bewertung von Uptime Kuma Version 2 liefert konkrete Metriken zum Ressourcenverbrauch und Konfigurationsratschläge für Entwickler, die ihre eigene Infrastruktur betreiben. Der am 7. Oktober 2026 veröffentlichte Leitfaden beschreibt den Prozess einer Neuinstallation und hebt hervor, dass das Tool auch auf minimaler Hardware leichtgewichtig bleibt, während es in seiner zweiten Hauptversion neue Datenbankoptionen einführt.

Was passiert ist

Der Autor hat Uptime Kuma v2 über Docker Compose bereitgestellt, um den tatsächlichen Fußabdruck auf einer modernen Workstation zu messen. Das anfängliche Image-Pull erforderte 574 MB Speicherplatz, aber der Speicherverbrauch zur Laufzeit war deutlich geringer. Bei null aktiven Monitoren verbrauchte der Container 143 MB RAM. Mit drei konfigurierten aktiven Monitoren, die alle 60 Sekunden prüfen, schwankte der Speicherverbrauch zwischen 133 MB und 147 MB, während die CPU-Auslastung unter 1 % eines einzelnen Kerns blieb. Diese Werte deuten darauf hin, dass die Anwendung problemlos auf Geräten mit nur 256 MB freiem RAM laufen kann, wie etwa einem Raspberry Pi oder einem einfachen virtuellen privaten Server (VPS).

Eine bemerkenswerte Änderung in Version 2 ist die Einführung einer Datenbankauswahl während der Ersteinrichtung. Nutzer können zwischen SQLite und einer eingebetteten MariaDB-Instanz wählen. Die Bewertung empfiehlt SQLite für Installationen mit weniger als 50 Monitoren aufgrund der einfacheren Verwaltung und des geringeren Ressourcenverbrauchs. In einem zweimonatigen Test mit drei Monitoren wuchs das Datenvolumen von SQLite auf weniger als 2 MB an. Dies steht im Gegensatz zu MariaDB, das besser für großskalige Bereitstellungen mit Hunderten von Monitoren geeignet ist, aber eine komplexere Wartung erfordert.

Der Leitfaden dokumentiert auch häufige Konfigurationsfehler, die während des Tests auftraten. Der Versuch, ein privates GitHub-Repository über Standard-HTTP-Checks zu überwachen, führte zu 404-Fehlern, da dem Monitor Authentifizierungstokens fehlten. Ebenso lieferte die Prüfung eines Supabase REST-Endpoints ohne API-Schlüssel 401 Unauthorized-Antworten zurück, was fälschlicherweise Ausfallzeiten anzeigte. Der Autor rät dazu, TCP-Port-Monitore für Datenbanken und Dienste zu verwenden, die Authentifizierung erfordern, anstatt sich auf einfache HTTP-Statusprüfungen zu verlassen.

Wichtige Details

• Image-Größe: Das Docker-Image ist 574 MB groß und benötigt bei üblichen Breitbandverbindungen einige Minuten zum Herunterladen.
• Speichernutzung: Im Leerlauf werden 143 MB verwendet; mit drei aktiven Monitoren bleibt der Verbrauch zwischen 133 MB und 147 MB.
• Datenbankwahl: SQLite wird für weniger als 50 Monitore empfohlen, aufgrund der Einfachheit und der kleinen Backup-Größe (im Test unter 2 MB).
• Neustartgeschwindigkeit: Der Container startet in 1,6 Sekunden neu und stellt den Dienstverkehr innerhalb von weniger als 10 Sekunden wieder her.
• Häufige Fallstricke: HTTP-Monitore scheitern bei authentifizierten Endpoints; verwenden Sie TCP-Monitore für Datenbanken oder Keyword-/API-Monitore mit Tokens für private Repositories.
• Backup-Methode: Die Daten befinden sich in einem einzelnen benannten Volume, was einfache Backups über tar-Befehle ermöglicht.

Hintergrund

Uptime Kuma ist eine Open-Source-Alternative zu kommerziellen Uptime-Monitoring-Diensten wie UptimeRobot oder Pingdom. Es ermöglicht Nutzern, ihre eigene Statusseite und ihr eigenes Monitoring-Dashboard zu hosten, wodurch Gebühren pro Monitor und Intervallbeschränkungen entfallen. Das Tool unterstützt verschiedene Monitortypen, einschließlich HTTP-, TCP- und Ping-Prüfungen, und kann Benachrichtigungen über mehrere Kanäle senden, wenn Dienste nicht verfügbar sind.

Das Self-Hosting von Monitoring-Tools verlagert die Verantwortung für die Verfügbarkeit vom Drittanbieter auf die eigene Infrastruktur des Nutzers. Dieser Ansatz bietet mehr Kontrolle über Datenschutz und Anpassungsmöglichkeiten, führt jedoch zu einem Single Point of Failure: Wenn der Rechner, auf dem der Monitor läuft, offline geht, kann er Ausfälle anderer Dienste nicht erkennen. Daher ist die Zuverlässigkeit des Host-Rechners entscheidend für die Wirksamkeit des Monitoring-Setups.

Warum es wichtig ist

Für Teams, die kleine bis mittelgroße Infrastrukturen verwalten, ist das Verständnis der tatsächlichen Ressourcenkosten von Monitoring-Tools für die Kapazitätsplanung unerlässlich. Die Bestätigung, dass Uptime Kuma v2 effizient auf minimaler Hardware läuft, bedeutet, dass es auf vorhandenen Low-Power-Geräten oder günstigen Cloud-Instanzen bereitgestellt werden kann, ohne andere Workloads zu beeinträchtigen. Dies senkt die Einstiegshürde für umfassendes Monitoring und ermöglicht selbst kleinen Projekten, die Service-Health ohne erhebliche Budgetzuweisung zu verfolgen.

Die Unterscheidung zwischen HTTP- und TCP-Monitoring ist eine praktische Lektion für DevOps-Ingenieure. Eine fehlerhafte Konfiguration von Monitoren für authentifizierte Dienste führt zu False Positives, was Teams gegenüber Warnungen abstumpfen lassen oder Zeit für die Untersuchung nicht existierender Probleme verschwenden kann. Durch die Wahl des richtigen Monitortyps stellen Teams sicher, dass Warnungen die echte Service-Verfügbarkeit widerspiegeln und nicht Berechtigungsfehler. Diese Genauigkeit ist vital, um das Vertrauen in interne Monitoring-Systeme aufrechtzuerhalten.

Zusätzlich vereinfacht der Wechsel zu SQLite für kleinere Installationen den Betrieb. Die Verwaltung eines separaten Datenbank-Servers erhöht die Komplexität bei Backups, Updates und Sicherheits-Patching. Die Verwendung einer eingebetteten Datenbank reduziert diese operative Last und macht es kleinen Teams leichter, ihren Monitoring-Stack ohne spezielle Datenbankadministrationskenntnisse zu warten. Diese Einfachheit entspricht den Zielen vieler Self-Hoster, die Wartungsfreundlichkeit neben Funktionalität priorisieren.

Was Sie tun können

• Bereitstellung mit Docker Compose: Verwenden Sie die bereitgestellte Compose-Datei mit einem benannten Volume, um die Datenpersistenz über Container-Neuerstellungen hinweg sicherzustellen.
• Wählen Sie SQLite für kleine Setups: Wenn Sie weniger als 50 Monitore haben, wählen Sie SQLite während der Einrichtung aus, um den RAM-Verbrauch zu minimieren und Backups zu vereinfachen.
• Verwenden Sie TCP-Monitore für Datenbanken: Vermeiden Sie HTTP-Checks für Dienste, die Authentifizierung erfordern; überwachen Sie stattdessen den spezifischen Port (z. B. 5432 für Postgres), um die Konnektivität zu überprüfen.
• Sichern Sie Ihr Admin-Konto: Verwenden Sie ein starkes, einzigartiges Passwort, das von einem Passwort-Manager generiert wurde, da das Dashboard sensible Informationen über Ihre Infrastruktur enthält.
• Planen Sie regelmäßige Backups: Automatisieren Sie wöchentliche Snapshots des Datenvolumes und speichern Sie sie auf einer separaten Festplatte oder an einem anderen Ort, um Datenverlust zu verhindern.
• Stellen Sie die Host-Verfügbarkeit sicher: Führen Sie Uptime Kuma auf einem immer laufenden Rechner aus, wie z. B. einem dedizierten VPS oder einem zuverlässigen Heimserver, um kontinuierliches Monitoring zu garantieren.