UptimeRobot Alternative aus Deutschland

Was bedeutet ein Fünf-Minuten-Intervall für die Erkennungsdauer?

Dass ein Ausfall im Mittel zweieinhalb Minuten unbemerkt bleibt und im ungünstigsten Fall fünf. Rechnet man den üblichen Bestätigungsdurchlauf hinzu, mit dem ein einzelner Fehlschlag abgesichert wird, liegt die mittlere Erkennungsdauer bei siebeneinhalb und die maximale bei zehn Minuten. Erst danach beginnt Alarmierung, Reaktion und Behebung.

Diese Zahlen bekommen ihren Sinn erst im Verhältnis zum monatlichen Ausfallbudget. Eine Verfügbarkeit von 99,9 Prozent erlaubt 43 Minuten Ausfall im Monat, 99,95 Prozent erlauben 22 Minuten, und 99,99 Prozent erlauben 4 Minuten und 23 Sekunden. Ein Prüfverfahren, das im Mittel siebeneinhalb Minuten zur Erkennung braucht, kann die letzte dieser drei Zusagen nicht messen — der Messfehler ist größer als das gesamte Budget.

Das ist kein theoretischer Einwand. Wer Kunden gegenüber eine Quote ausweist, sollte sie mit einem Verfahren erheben, dessen Auflösung deutlich feiner ist als die Zusage. Als Faustregel taugt: Die Erkennungsdauer sollte höchstens ein Zehntel des Monatsbudgets betragen. Für 99,9 Prozent sind das vier Minuten, für 99,95 Prozent zwei, für 99,99 Prozent rund fünfundzwanzig Sekunden.

Der zweite Teil der Rechnung wird häufiger übersehen: Die Erkennungsdauer ist nur der erste Summand. Danach folgen die Zustellung des Alarms, die Reaktionszeit der geweckten Person und die eigentliche Behebung. Wer bei zehn Minuten Erkennung anfängt, hat das Budget einer 99,95-Prozent-Zusage bereits zur Hälfte verbraucht, bevor überhaupt jemand ein Kennwort eingegeben hat.

Die Gegenprobe lohnt sich ebenfalls. Ein kürzerer Takt ist nicht in jedem Fall besser: Er erhöht die Last auf dem geprüften Dienst, und er erhöht die Zahl der Fehlalarme, wenn nur aus einer Richtung geprüft wird. Sinnvoll ist ein kurzer Takt genau dort, wo eine Zusage besteht — und ein langer überall sonst.

Wann reicht eine einfache Statuspage nicht mehr aus?

Sobald sie etwas mitteilen soll, das nicht aus einer Prüfung stammt. Eine aus der Überwachung abgeleitete Statuspage kann zuverlässig anzeigen, was gemessen wurde: erreichbar oder nicht. Sie kann nicht ohne Weiteres eine Wartung ankündigen, die Störung eines Vorleisters erklären, in zwei Sprachen erscheinen oder einen Freigabeprozess abbilden, bevor etwas öffentlich wird.

Der Übergang wird meist an derselben Stelle spürbar. Ein Vorleister hat eine Störung — der Zahlungsdienstleister, der Mailversand, ein Rechenzentrum. Die eigenen Prüfungen sind grün, weil die eigene Anwendung läuft, aber Kunden können nicht bezahlen. Auf einer Seite, die ausschließlich Messwerte abbildet, gibt es für diesen Zustand keine Ausdrucksform. Der Support beantwortet dann dieselbe Frage hundertmal einzeln.

Der zweite wiederkehrende Fall ist die geplante Wartung. Sie ist kein Ausfall, sondern eine Ankündigung, sie hat einen Zeitraum und betrifft bestimmte Komponenten. Sie muss vorher sichtbar sein, während der Durchführung den Zustand überschreiben und danach ohne Spuren in der Verfügbarkeitsrechnung verschwinden. Das ist ein eigener Ablauf und keine Nebenwirkung einer Prüfung.

Der dritte ist die Abonnentenverwaltung. Sobald eine dreistellige Zahl von Menschen benachrichtigt werden will, entstehen Anforderungen, die mit Überwachung nichts zu tun haben: Auswahl einzelner Komponenten statt aller, doppelte Bestätigung der Anmeldung, Abmeldelink, Zustellbarkeit, ein Nachweis darüber, wer wann was erhalten hat. Das ist der Punkt, an dem eine Statuspage aufhört, eine Ansicht zu sein, und ein eigenes Werkzeug wird.

Solange keiner dieser drei Fälle auftritt, ist eine einfache Statuspage vollkommen ausreichend — und der Aufwand, sie durch etwas Größeres zu ersetzen, wäre nicht gerechtfertigt.

Warum ist die Zahl der Prüfstandorte wichtiger als die Zahl der Prüfungen?

Weil sie darüber entscheidet, ob ein Fehlschlag überhaupt interpretierbar ist. Eine gescheiterte Anfrage aus einer einzigen Richtung kann bedeuten, dass der Dienst ausgefallen ist — oder dass der Weg dorthin gestört war. Beides sieht identisch aus. Erst der Vergleich mehrerer gleichzeitiger Blickwinkel macht aus einem Messwert eine Aussage.

Die übliche Behelfslösung ist der Bestätigungsdurchlauf: Nach dem ersten Fehlschlag wird ein zweites Mal geprüft, erst dann alarmiert. Das filtert kurze Aussetzer wirksam heraus und verdoppelt gleichzeitig die Erkennungsdauer. Es beantwortet die eigentliche Frage nicht, weil beide Durchläufe denselben Weg nehmen — ist die Strecke gestört, scheitern beide.

Mehrere Standorte drehen das um. Wenn Frankfurt und Helsinki gleichzeitig scheitern und Wien nicht, liegt es mit hoher Wahrscheinlichkeit an einer Teilstrecke. Wenn alle drei scheitern, liegt es am Dienst — und zwar sofort, ohne Wartezeit. Eine Mehrheitsregel liefert damit gleichzeitig weniger Fehlalarme und eine kürzere Erkennungsdauer, was der Bestätigungsdurchlauf nie kann.

Für die Praxis heißt das, die Prioritäten anders zu setzen, als es die Tarifübersichten nahelegen. Vierhundert Prüfungen aus einer Richtung sind für eine Verfügbarkeitsaussage weniger wert als vierzig aus vier Richtungen. Die Zahl, nach der Tarife gestaffelt werden, ist selten die Zahl, die über die Qualität der Aussage entscheidet.

Warum wächst die Zahl der Prüfungen schneller als ihr Nutzen?

Weil Prüfungen angelegt und fast nie wieder entfernt werden. Eine Aufstellung, die über zwei Jahre gewachsen ist, enthält typischerweise Einträge für abgeschaltete Testumgebungen, umgezogene Domains und Dienste, die es nicht mehr gibt. Sie melden nichts, kosten aber ein Kontingent — und schlimmer: Sie machen die Liste unübersichtlich, in der im Ernstfall etwas gefunden werden muss.

Der Mechanismus ist harmlos und deshalb hartnäckig. Eine Prüfung anzulegen dauert eine Minute und wird von jedem gemacht, der neu dazukommt. Eine zu löschen verlangt die Gewissheit, dass sie wirklich niemand mehr braucht — und diese Gewissheit holt sich selten jemand. Die Aufstellung wächst monoton, weil der Aufwand asymmetrisch verteilt ist.

Die sichtbare Folge ist der Tarifsprung, der nicht durch neue Dienste ausgelöst wird, sondern durch alte. Die unsichtbare ist gravierender: Eine Übersicht mit dreihundert Einträgen, von denen achtzig nichts mehr überwachen, ist im Störungsfall schwerer zu lesen als eine mit zweihundertzwanzig. Genau dann zählt aber, wie schnell jemand erkennt, welche Einträge zusammengehören.

Ein einfaches Verfahren hilft und kostet einmal im Quartal eine halbe Stunde: Alle Prüfungen auflisten, die in den letzten neunzig Tagen keinen einzigen Zustandswechsel hatten. Das sind entweder sehr stabile Dienste oder tote Einträge, und der Unterschied ist an der Adresse meist sofort erkennbar. Wer dabei zusätzlich notiert, welche Prüfung zu welcher Statuspage-Komponente gehört, findet zugleich die Komponenten ohne Prüfung — die zweite verbreitete Lücke.

Der Zeitpunkt dafür ist bei einem Wechsel ohnehin gegeben. Deshalb lohnt es sich, die Aufstellung beim Übertragen nicht zu kopieren, sondern zu begründen: Für jeden Eintrag einmal die Frage beantworten, wen sein Ausfall betrifft. Einträge ohne Antwort brauchen keinen Umzug.