Consensus voting beim Uptime Monitoring - warum es sinnvoll ist

Klassisches Multi-Region Monitoring reduziert false negatives, erhöht aber false positives. Consensus voting löst beides. Eine erklärende Aufschlüsselung des Patterns.

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 mehrere. Soweit gut.

Aber das Problem mit false positives verschlimmert sich. 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. Sie bekommen mehr falsche Alerts, nicht weniger.

Consensus voting löst beide Seiten

Consensus voting funktioniert anders: Beim ersten DOWN-Signal lösen Sie keinen Alert aus. Sie fragen zuerst die anderen Regionen. Wenn die Mehrheit von ihnen ebenfalls DOWN meldet, ist es ein echter Ausfall. Wenn nicht, handelt es sich um eine Netzwerkanomalie in einer 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 einen Preis - bei einem DOWN-Signal kommen ein paar Sekunden Latenz hinzu, um die anderen Regionen abzufragen. Für die meisten Anwendungsfälle (Uptime Monitoring mit Minutenintervall) ist das vernachlässigbar. Für extrem strenge SLAs mit Erkennungszeit unter 30 Sekunden kann es ein Kompromiss sein.

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 LAN nutzen Sie das Pull-Agent-Pattern - der Agent läuft in Ihrem Netzwerk und sendet Ergebnisse per HTTPS.
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 - es ist 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.

Für das Self-Hosting eines Workers in einer anderen Region hat das Admin-Panel einen WireGuard-Bundle-Generator - er erzeugt eine tar.gz mit Konfiguration für einen neuen Worker-Knoten und fügt ihn zu worker_urls hinzu.

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.