Waarom monitoring vanuit één locatie tekortschiet#

Wanneer je monitoring vanuit slechts één geografische locatie draait, mis je hele klassen storingen:

Scenario: je US-datacenter gaat onderuit

Je monitoring in de VS gaat ook onderuit (gecolloceerde infrastructuur)
Klanten zien een storing, je support team ziet een storing, maar de monitoring staat op "all green"
Tegen de tijd dat je monitoring herstelt en het incident meldt, zijn klanten al overgestapt naar concurrenten

Scenario: regionale CDN-storing

Je dienst is online in de VS en Europa
Maar de Cloudflare edge in Asia-Pacific valt uit
US-gebaseerde monitoring detecteert het niet
Aziatische klanten kunnen 2 uur lang niet bij je site
Je ontdekt het pas wanneer support tickets binnenstromen

Scenario: ISP routing-storing

Je site is overal online behalve voor Verizon-klanten in de VS
Single-location monitoring mist dit (gebruikt een andere ISP dan je klanten)
Verizon-gebruikers bellen support, gefrustreerd
Jij denkt dat het hun netwerk is, niet beseffend dat het een routing-issue is dat je had kunnen detecteren

Multi-region monitoring uitgelegd#

Multi-region monitoring betekent dat je je infrastructuur tegelijkertijd vanuit meerdere geografische locaties controleert:

Jouw infrastructuur (US East)
    ↑
    ├─ Check vanuit: VS (Virginia)
    ├─ Check vanuit: EU (Frankfurt)
    ├─ Check vanuit: APAC (Singapore)
    └─ Check vanuit: Brazilië (São Paulo)

Als zelfs ÉÉN regio je niet kan bereiken, is er een echt probleem. Als ALLE regio's falen, ligt het aan jouw infrastructuur. Als SOMMIGE falen, is het een regionaal probleem (ISP, CDN, etc.).

Soorten regionale problemen die worden gedetecteerd#

1. CDN edge-storingen

Je CDN (Cloudflare, Akamai, Fastly) heeft points-of-presence in elke regio. Als er één faalt:

Tokyo edge gaat down → Aziatisch verkeer wordt omgeleid naar secundair (langzaam)
Nova Uptime multi-region monitoring detecteert de latency-stijging direct
Jij neemt contact op met CDN-support voordat klantklachten binnenkomen

2. Routing-problemen bij ISP's

ISP's routen soms verkeer verkeerd of raken overbelast:

Verizon BGP-misconfiguratie → Verizon-klanten kunnen je niet bereiken
Vodafone congestie → Europese klanten ervaren 10x latency
Single-location monitoring mist dit volledig

3. Regionale datacenters die uitvallen

Als je globale datacenters hebt:

Storingen in een US-datacenter moeten worden gedetecteerd vanuit EU/APAC (andere infrastructuur)
Voorkomt het "monitoring is ook down"-scenario
Detecteert gedeeltelijke storingen (1 van de 3 datacenters down)

4. Latency-degradatie per regio

Performance varieert per geografie:

Normaal: VS=50ms, EU=80ms, APAC=120ms
Probleem: VS=50ms, EU=80ms, APAC=800ms
Regionale monitoring detecteert de APAC slow-down, jij gaat direct onderzoeken

5. Geofencing / DDoS mitigation

Sommige aanvallen richten zich op specifieke regio's:

Aanvaller floodt Europese ISP's → EU-monitoring detecteert hoge latency
US-monitoring laat normaal zien
Je weet dat het regionaal is, niet een wereldwijde infrastructuurstoring

Multi-region monitoring opzetten#

Stap 1: kies je monitoring-locaties#

Minimum (3 regio's):

Noord-Amerika (US East of West Coast)
Europa (UK of Duitsland)
Asia-Pacific (Singapore of Tokyo)

Uitgebreid (6+ regio's):

US East
US West
Europa (Frankfurt)
Europa (London)
Asia-Pacific (Singapore)
Asia-Pacific (Tokyo)
Australië (Sydney)
Zuid-Amerika (São Paulo)

Beslissingsraamwerk:

Klanten alleen in de VS → 2 regio's (East + West)
Klanten in VS + Europa → 3 regio's (US + EU + APAC)
Echt globale klantenbasis → 6+ regio's
SaaS met 99,99% SLA → Minimum 5 regio's

Stap 2: configureer monitoring per regio#

De meeste monitoring tools laten je regio's selecteren:

Domein: example.com
Regio's: [US-East ✓] [US-West ✓] [EU ✓] [APAC ✓]
Check Interval: 1 minuut (elke regio onafhankelijk)
Alert bij: 2+ regio's falen OF latency > 1000ms

Belangrijke instelling: Alert threshold — hoeveel regio's moeten falen om een alert te triggeren?

Strikt (1 fail): gevoelig voor alle problemen, meer false positives
Gebalanceerd (2+ fail): vangt echte problemen, negeert single ISP-blips
Soepel (alle falen): vangt alleen globale outages

Stap 3: alert routing op basis van severity#

Verschillende regels voor verschillende scenario's:

Scenario 1: 1 regio faalt
  → Page on-call (mogelijk regionale klantimpact)

Scenario 2: 2-3 regio's falen
  → Page on-call direct (infrastructuurissue)

Scenario 3: alle regio's falen
  → Page on-call + activeer incident war room

Stap 4: monitor latency per regio#

Response time varieert per geografie. Stel per-regio drempels in:

VS (target &lt; 200ms): alert bij > 500ms
EU (target &lt; 300ms): alert bij > 700ms
APAC (target &lt; 500ms): alert bij > 1000ms

Gebruik geen enkele globale drempel — geografie is bepalend.

Veelgemaakte fouten bij multi-region monitoring#

Fout 1: monitoring colloceren met je infrastructuur#

❌ FOUT: je infrastructuur in de VS. Monitoring ook in de VS.
   Resultaat: als het datacenter faalt, faalt de monitoring ook.

✅ GOED: je infrastructuur in de VS. Monitoring vanuit US + EU + APAC.
   Resultaat: EU en APAC detecteren de US-storing.

Fout 2: te veel false positives#

❌ FOUT: alert als ELKE regio om welke reden dan ook faalt
   Resultaat: 50 false alerts per dag (klant stapt over naar concurrent)

✅ GOED: alert als 2+ regio's falen OF een regio 3+ checks achter elkaar faalt
   Resultaat: alleen echte problemen

Fout 3: latency-patronen niet begrijpen#

❌ FOUT: alle regio's hebben dezelfde SLA (response &lt; 200ms)
   Resultaat: continu APAC-alerts (van nature langzamer door afstand)

✅ GOED: geografisch-bewuste SLA's (APAC &lt; 800ms)
   Resultaat: detecteer echte problemen, geen natuurkunde

Fout 4: CDN-storingen negeren#

❌ FOUT: alleen je origin server monitoren
   Resultaat: CDN gaat down, monitoring zegt "up", klanten zien 503

✅ GOED: monitoren via je CDN (publieke URL + CDN-pad testen)
   Resultaat: CDN-storingen worden gedetecteerd

Fout 5: regiodata niet correleren#

❌ FOUT: alerts van elke regio apart, geen correlatie
   Resultaat: je kunt niet zien of het regionaal is of een infrastructuurstoring

✅ GOED: alert-correlatie: als US-West faalt maar US-East + EU + APAC up zijn,
   is het US-West specifiek; als alles faalt, is het een infrastructuurstoring
   Resultaat: snellere root cause analysis

Case study: Stripe's regionale outage (2023)#

Stripe had een 30 minuten durende regionale outage in EU:

US monitoring: alles groen
EU monitoring: alles rood

Wat er gebeurde:

Stripe's Frankfurt-datacenter had een router-misconfiguratie
US infrastructuur bleef ongedeerd
EU-klanten konden geen betalingen verwerken

Als Stripe alleen US-gebaseerde monitoring had gehad:

30 minuten verloren EU-transacties
EU-klanten denken dat Stripe onbetrouwbaar is
Support overspoeld met "Is Stripe down?" tickets

Met multi-region monitoring:

Issue direct gedetecteerd
Stripe weet dat het Frankfurt-specifiek is
Activeert Frankfurt incident-protocol
2 minuten om router-issue te identificeren
5 minuten om verkeer naar secundair datacenter te rerouten

Nova Uptime multi-region monitoring#

Nova Uptime ondersteunt multi-region monitoring:

Features:

Monitoren vanuit 4+ geografische regio's tegelijk
Per-regio response time tracking
Regionale alert-drempels
Dashboard toont health per regio
Incidenthistorie laat zien welke regio's getroffen waren
API levert checkresultaten per regio

Setup:

Voeg het domein toe aan Nova Uptime
In settings: schakel multi-region monitoring in
Selecteer regio's (automatisch: US + EU + APAC; of custom)
Stel alert-drempels per regio in
Bekijk regio-specifieke metrics op het dashboard

Multi-region monitoring best practices#

Monitor vanuit verschillende ISP's: monitor niet vanuit dezelfde hosting provider als je infrastructuur
Test echte gebruikersroutes: monitor via je CDN als je een CDN voor klanten gebruikt
Stel realistische latency-SLA's in: houd rekening met geografische afstand
Correleer over regio's heen: "Waarom is EU down?" – check of het een infrastructuurissue is of EU-specifiek
Monitor ook afhankelijke services: als de EU API afhankelijk is van een US-database, monitor dan ook de US-database vanuit EU
Documenteer je regio-selectie: waarom heb je deze regio's gekozen? Documenteer het voor toekomstige maintainers
Test failover: laat een regio's monitoring opzettelijk falen om te verifiëren dat alert routing werkt
Archiveer regio-data: bewaar 12 maanden aan regio-specifieke metrics voor SLA-rapportage

Samenvatting: multi-region monitoring checklist#

Start vandaag met globale monitoring: Nova Uptime Multi-Region Monitoring. Monitor vanuit US, EU, APAC en meer. 🚀

Multi-Region Monitoring: globale dekking voor distributed teams