Uptime Kuma Alternative aus Deutschland

Warum erzeugt ein einzelner Blickwinkel Fehlalarme?

Weil eine fehlgeschlagene Anfrage zwei völlig verschiedene Dinge bedeuten kann: Der Dienst ist ausgefallen — oder der Weg dorthin ist es. Von einem einzigen Standort aus lassen sich diese Fälle nicht unterscheiden. Ein überlasteter Netzknoten, eine kurze Routenänderung oder ein DNS-Aussetzer beim eigenen Anbieter sehen exakt aus wie ein Ausfall.

Die Folgen sind zwei, und beide sind teuer. Die erste ist der Weckruf um drei Uhr nachts für ein Problem, das nie existiert hat. Ein einzelner solcher Fall ist ärgerlich; eine Serie davon führt dazu, dass Alarme abgeschaltet oder ignoriert werden — und ab dann ist auch der echte Ausfall unsichtbar. Die zweite ist die Verfälschung der Verfügbarkeitszahl. Wer Kunden gegenüber eine Quote ausweist, weist mit einem Blickwinkel eine Zahl aus, die die eigene Anbindung mitmisst.

Die verbreitete Gegenmaßnahme ist ein Wiederholungszähler: erst nach drei fehlgeschlagenen Durchläufen wird alarmiert. Das hilft gegen kurze Aussetzer und verlängert gleichzeitig die Erkennungsdauer um das Dreifache. Es tauscht ein Problem gegen ein anderes, weil es die eigentliche Frage nicht beantworten kann — ob das Problem beim Dienst liegt oder auf dem Weg.

Mehrere Standorte beantworten sie. Wenn Frankfurt, Wien und Helsinki gleichzeitig scheitern, ist es der Dienst. Wenn nur Warschau scheitert, ist es die Strecke. Diese Unterscheidung ist der Grund, warum verteilte Prüfung überhaupt existiert, und sie ist mit einem einzelnen Knoten grundsätzlich nicht herstellbar — unabhängig davon, wie gut die Software ist.

Fairerweise: Für viele Anwendungsfälle spielt das keine Rolle. Wer interne Dienste überwacht, die ohnehin nur aus dem eigenen Netz erreichbar sind, hat gar keinen zweiten Blickwinkel zur Auswahl, und ein Wiederholungszähler ist dort die richtige und ausreichende Antwort.

Was kostet ein kostenloses Werkzeug wirklich?

Die Lizenz nichts, den Betrieb etwas. Realistisch sind ein kleiner Server ab etwa fünf Euro im Monat, dazu die laufende Arbeit für Aktualisierungen, Sicherungen, TLS-Zertifikate und die Zustellbarkeit der Warn-E-Mails. Bei zwei Stunden im Quartal und einem üblichen Stundensatz liegt das Jahresergebnis über dem, was ein bezahlter Tarif in vergleichbarer Größenordnung kostet.

Diese Rechnung wird oft als Verkaufsargument vorgetragen und ist dann meist unehrlich, weil sie die Arbeitszeit übertreibt. Uptime Kuma ist genügsam: Ein Container, ein Datenverzeichnis, gelegentlich ein neues Abbild. Wer ohnehin Server betreibt, hat den Aufwand faktisch schon bezahlt, und die zusätzlichen Kosten liegen dann tatsächlich nahe null.

Der Posten, der regelmäßig unterschätzt wird, ist ein anderer: die Zustellbarkeit der Warnmeldungen. Eine Alarm-E-Mail aus einer selbst betriebenen Instanz landet ohne korrekt gesetzte SPF-, DKIM- und DMARC-Einträge im Spam-Ordner — und zwar genau bei den großen Anbietern, bei denen die Empfänger tatsächlich sind. Die Meldung wird verschickt, sie kommt an, und trotzdem sieht sie niemand. Das ist ein Ausfall der Alarmierung, der sich nicht als Fehler zeigt.

Für Statuspage-Abonnenten gilt derselbe Punkt mit größerer Reichweite. Sobald an eine dreistellige Zahl von Empfängern verschickt wird, ist Zustellbarkeit ein eigenes Thema mit Aufwärmphase, Rückläuferbehandlung und Abmeldeverwaltung. Das ist der Punkt, an dem die meisten Eigenbauten einen Fremdanbieter zukaufen — und ab da ist die Rechnung nicht mehr null.

Ehrlich bleibt: Für unter zehn Dienste und ein internes Publikum ist der Gesamtaufwand tatsächlich vernachlässigbar. Die Rechnung kippt dort, wo externe Empfänger dazukommen und wo ein Ausfall der Überwachung selbst nicht mehr hinnehmbar ist.

Wie viele Dienste verträgt Uptime Kuma?

Deutlich mehr als die meisten Installationen brauchen, aber nicht beliebig viele. Standardmäßig speichert Uptime Kuma in SQLite; ab Version 2 lässt sich MariaDB als Datenbank hinterlegen. Mit SQLite berichten Betreiber ab etwa hundert bis hundertfünfzig Diensten mit kurzen Intervallen von einer träge werdenden Oberfläche, und Schreibspitzen sind der begrenzende Faktor.

Die Schreibspitze ist der interessante Teil, weil sie genau im falschen Moment auftritt. Im Normalbetrieb schreibt jeder Durchlauf ein Ergebnis — gleichmäßig verteilt und unkritisch. Fällt dagegen etwas Großes aus, wechseln viele Dienste innerhalb weniger Sekunden ihren Zustand, und jeder Wechsel erzeugt zusätzliche Schreibvorgänge und Benachrichtigungen. Die Last ist dann am höchsten, wenn die Oberfläche gebraucht wird.

Die Umstellung auf MariaDB in Version 2 entschärft genau das und ist für größere Installationen die richtige Wahl. Sie fügt allerdings einen Dienst hinzu, der ebenfalls gesichert, aktualisiert und überwacht werden will — der Aufwand aus dem vorigen Abschnitt wächst mit.

Für die Praxis ergibt sich eine einfache Faustregel: Unter fünfzig Diensten ist die Standardkonfiguration unproblematisch. Zwischen fünfzig und einigen hundert lohnt sich der Umstieg auf MariaDB und eine ehrliche Prüfung der Intervalle — viele Dienste vertragen sechzig Sekunden statt zwanzig, ohne dass jemand den Unterschied bemerkt. Darüber hinaus wird die Frage nach der Bauform grundsätzlicher als die nach der Datenbank.