Multiregio-monitoring: zo elimineer je false-positive storingen

Valse alarmen leren een team alerts te negeren. Een multiregio cross-check meldt een storing pas wanneer meerdere onafhankelijke probes die bevestigen.

Waarom single-region monitoring liegt

Klassieke monitoring heeft één observatiepositie (één server of cloudregio). Krijgt die probe geen antwoord, dan meldt hij een storing. De oorzaak kan echter een van de volgende zijn:

Een probleem in het netwerk van de probe zelf (route flap, een peering-probleem bij zijn provider)
Een kortstondige DNS-glitch aan de kant van de probe
Een geografisch beperkte storing (een CDN-edge in één land viel uit)
Rate limiting of een IP-blokkade aan de kant van jouw infrastructuur

Vanuit het perspectief van echte gebruikers kan de site helemaal in orde zijn - alleen onbereikbaar voor één specifieke monitoring-host.

Het gevolg: alert fatigue

Een team dat 3 "storing"-meldingen per week krijgt, waarvan er 2 vals alarm (false-positive) zijn, stopt geleidelijk met reageren. Komt er dan een echte storing, dan is de reactie te laat of merkt niemand het op. Dit verschijnsel heet alert fatigue (alertmoeheid) en is goed gedocumenteerd in de devops-literatuur.

Het doel is de best mogelijke signaal-ruisverhouding (signal-to-noise ratio). Beter 1 melding per maand die altijd echt is dan 10 meldingen waarvan er 7 ruis zijn.

Het multiregio-patroon: consensus van N probes

Het principe:

Je hebt 3 worker-nodes in 3 steden (primary in Liptovský Hrádok, eu2 in Liptovský Mikuláš, eu1 in Bratislava). De standaarddrempel = 2 van 3, wat een echte consensus geeft (niet unaniem). De architectuur ondersteunt een willekeurig aantal nodes; bij uitbreiding worden ze toegevoegd aan het bestaande consensusmechanisme.
Bij elk interval testen alle probes het endpoint parallel.
Je voegt het resultaat samen: een storing is bevestigd als M van N probes hem melden (typisch M = 2 of meer).
Het uitvallen van één probe triggert geen alarm - meldt één probe "down" maar de andere "up", dan blijft het systeem in de UP-staat.

Dit is het zogenaamde consensus algorithm (consensusalgoritme), vergelijkbaar met Raft of Paxos - de beslissing valt bij meerderheid van stemmen.

Praktische instelling

In het ePulz.io-adminpaneel wordt multiregio met één schakelaar ingeschakeld en geconfigureerd via:

Actieve regio's - de lijst met workers, doorgaans 3-5
Consensusdrempel - hoeveel regio's DOWN moeten zeggen (standaard: 2)
Worker token - een gedeeld geheim (shared secret) tussen de hoofdserver en de workers voor verificatie

Bij elke controle benadert de hoofdserver alle workers parallel via de HTTP API. Een worker voert een lokale HTTP-, TCP- of ping-test uit en geeft het resultaat terug. De hoofdserver evalueert de consensus en escaleert de alert pas wanneer de drempel wordt overschreden.

Trade-offs

Pluspunten:

Drastisch minder valse alarmen
Geografische visualisatie - je ziet vanuit welke regio's de site niet werkt
Detectie van regionale storingen (probleem met een Cloudflare-PoP, foutieve routing bij een ISP)

Minpunten:

Iets langere latentie tussen de echte storing en de alert (er wordt gewacht op consensus uit meerdere bronnen)
Hogere infrastructuureisen en een hoger prijsplan
Beschikbaarheid van de workers - als de helft van de workers zelf onbereikbaar is, is de drempel mogelijk niet haalbaar (de oplossing is een dynamische drempel = M van de momenteel actieve probes)

Voorbeeld van een consensusberekening

Configuratie van 3 daadwerkelijk uitgerolde worker-nodes: primary in Liptovský Hrádok (SK), eu2 in Liptovský Mikuláš (SK), eu1 in Bratislava (SK), drempel = 2.

Scenario	primary (Liptov)	eu1 (Bratislava)	eu2 (Liptov)	Alert?
Alles OK	UP	UP	UP	Nee
BGP flap tussen Liptov en je hosting	DOWN	UP	UP	Nee (1 van 3)
HW-storing van de primary-machine	DOWN	UP	DOWN	Ja (2 van 3)
Echte storing van je server	DOWN	DOWN	DOWN	Ja

Hoe je je eigen workers uitrolt

Een worker is een eenvoudige service die controle-taken via HTTPS ontvangt, de test uitvoert en het resultaat teruggeeft. ePulz.io ondersteunt eigen workers via een WireGuard-tunnel, zodat ze op elke VPS zonder publiek IP kunnen draaien en met de hoofdserver via een versleutelde tunnel communiceren.

Het configureren van één worker duurt in de praktijk ongeveer 10 minuten (apt install wireguard, peer-config kopiëren, systemctl enable). Zo krijg je werkelijk onafhankelijke observatieposities die geografische diversiteit (verschillende steden) combineren met hardwareredundantie (verschillende machines in dezelfde stad).

Conclusie

Multiregio-monitoring is niet zomaar een marketingkreet. Het is een concreet engineeringpatroon (quorum, oftewel consensus) dat monitoring tilt van het niveau "ik zie wat één netwerkpositie ziet" naar "ik zie wat het internet ziet". Voor kritieke bedrijfsapplicaties is dat vandaag de standaard.

Elimineer false-positive alerts

Multiregio cross-check in de basisplannen (centraal beheerd). 7 dagen gratis.

Monitoring starten →