Consensus voting beim Uptime Monitoring | warum es sinnvoll ist

Klassisches Multi-Region-Monitoring senkt False Negatives, erhöht aber False Positives. Consensus-Voting löst beides. Lehrreiche Analyse des Musters.

Die Schwachstelle des Single-Region Monitorings

Single-Region Monitoring bedeutet, dass Ihr Checker an einem Standort läuft. Tritt ein Netzwerkproblem auf dem Pfad zwischen diesem Standort und Ihrem Server auf (BGP flap, Routing-Änderung, ISP-Wartung), meldet das Monitoring DOWN, obwohl der Server in Ordnung ist.

Das ist ein false positive. Sie bekommen die Benachrichtigung, wachen um 3 Uhr morgens auf, öffnen Ihren Laptop und stellen fest, dass die Seite funktioniert.

False positives sind aus zwei Gründen schädlich:

Alert fatigue. Wenn Sie Benachrichtigungen erhalten, die sich als unwahr herausstellen, beginnen Sie nach und nach, sie zu ignorieren. Auch die echten.
Vertrauensverlust ins Monitoring. Das Team reagiert nicht mehr auf Alerts, weil "es wahrscheinlich wieder nur BGP ist".

Naives Multi-Region löst ein Problem, verschlimmert das andere

Der übliche Ansatz dafür ist Multi-Region Monitoring. Der Checker läuft an mehreren Standorten und ein Alert wird ausgelöst, sobald einer von ihnen DOWN meldet.

Das verbessert die Erkennung echter Ausfälle: Wenn der Server wirklich nicht erreichbar ist, fällt nicht nur ein Checker aus, sondern gleich mehrere. So weit, so gut.

Doch das Problem mit false positives verschlimmert sich dadurch. Mit einem Checker hatten Sie eine gewisse Rate an falschen Alerts. Mit drei Checkern ist es mathematisch wahrscheinlicher, dass mindestens einer fälschlicherweise DOWN meldet. Das Ergebnis sind mehr falsche Alerts, nicht weniger.

Consensus voting löst beide Seiten

Consensus voting funktioniert anders: Beim ersten DOWN-Signal wird kein Alert ausgelöst. Zuerst werden die anderen Regionen befragt. Wenn die Mehrheit von ihnen ebenfalls DOWN meldet, ist es ein echter Ausfall. Wenn nicht, handelt es sich nur um eine Netzwerkanomalie in einer einzelnen Region.

Pseudocode:

result = check_http(monitor)  # primary region
if result.status == 'down':
    secondary_results = check_from_other_regions(monitor)
    if secondary_results:
        # Default rule: 2 of 3 regions must agree on DOWN
        if count_down(secondary_results) + 1 >= 2:
            result.status = 'down'
        else:
            result.status = 'up'
            result.note = 'consensus mismatch'

Beispielszenario:

primary  → DOWN  (one checker had a BGP flap)
region_a → UP    (other regions see the server normally)
region_b → UP

Result: UP. No alert. Entry in debug log.

Und das Gegenteil, ein echter Ausfall:

primary  → DOWN
region_a → DOWN
region_b → DOWN

Result: DOWN. Alert goes via Telegram/email/webhook.

Tradeoff: Latenz

Consensus voting hat seinen Preis: Bei einem DOWN-Signal kommen ein paar zusätzliche Sekunden Latenz hinzu, während die anderen Regionen abgefragt werden. Für die meisten Anwendungsfälle (Uptime Monitoring mit Minutenintervall) ist das vernachlässigbar. Für extrem strenge SLAs mit einer Erkennungszeit unter 30 Sekunden kann es zu einem spürbaren Kompromiss werden.

Wann Multi-Region keinen Sinn ergibt

Interne APIs auf 192.168.x.x. Niemand außerhalb Ihres Netzwerks kann sie erreichen, also ist Multi-Region aus dem Internet sinnlos. Für das LAN nutzen Sie das Pull-Agent-Pattern: Der Agent läuft in Ihrem Netzwerk und sendet die Ergebnisse per HTTPS nach außen.
Interne Single-Customer-App. Wenn nur wenige Leute sie nutzen und Sie einer davon sind, erfahren Sie vom Ausfall vor dem Monitoring.
Ein Dienst, der nur in einer Weltregion läuft. Wenn Ihr Dienst nur in der EU verfügbar ist und Sie ihn aus den USA als DOWN sehen, ist das kein false positive, sondern erwartet.

Wie wir es bei ePulz.io machen

ePulz.io hat consensus voting in der Architektur. gather_multiregion() und combine_consensus() in monitoring.py implementieren das obige Pattern. Der Schwellwert (wie viele Regionen DOWN bestätigen müssen) ist über den Parameter min_down konfigurierbar.

In der Check-Tabelle speichert jede Zeile ein Feld consensus mit CSV (z. B. "primary:up,region_a:up,region_b:down"), sodass Sie zum Debugging die exakte Aufzeichnung haben, wie die Entscheidung getroffen wurde.

Fazit

Consensus voting ist keine magische Lösung. Es liefert Ihnen keine null false positives und es rettet Sie nicht in einem echten Ausfall. Aber es ist ein besserer Kompromiss als Single-Region (hohe false positives bei Netzwerkanomalien) oder naives Multi-Region (Vervielfachung von false positives).

Schauen Sie sich ePulz.io an. 7 Tage Testphase, 3 Monitore, keine Kreditkarte.

Consensus voting beim Uptime Monitoring - warum es sinnvoll ist