Uptime- en latencymonitoring vanuit datacentersteden

Waarom monitoren vanuit datacentersteden?

Monitoren vanuit datacentersteden laat zien hoe je dienst presteert vanuit de netwerkhubs waar het verkeer van je gebruikers doorheen gaat. Een check vanuit je kantoor test maar één pad. Een check vanuit Frankfurt, Singapore of São Paulo test de route, het DNS-antwoord en de CDN-edge die aan die regio wordt geleverd.

Typische vragen die het beantwoordt:

• Antwoordt de site vanuit elke markt, of krijgt één regio fouten?
• Stuurt de CDN bezoekers uit Tokio naar een Aziatische edge, of helemaal naar Virginia?
• Heeft een DNS- of certificaatwijziging elke regio bereikt?
• Is een trage pagina een serverprobleem of een afstandsprobleem?

Een datacenter IP meet het datacenterpad, niet de last mile van een thuisgebruiker via Wi-Fi of mobiel. Dat is een feature voor herhaalbare checks, en een beperking als je echte-gebruikerstijden nodig hebt.

Wat is de minimale latency tussen twee steden?

De minimale round trip in milliseconden is ongeveer de afstand in kilometers gedeeld door 100. Licht in glasvezel reist ongeveer 200 km per milliseconde, en een round trip legt de afstand twee keer af. Echte routes zijn langer dan een rechte lijn, dus gemeten waarden zijn hoger.

De dichtstbijzijnde paren onder onze datacenterstad-pagina's, op basis van de afstanden op die pagina's:

Als een check van Amsterdam naar een server in Londen 40 ms duurt, verklaart afstand minder dan 4 ms daarvan; kijk naar routing, TLS-setup of de server. De stad-datatabel vermeldt elke stad met zijn faciliteiten en dichtstbijzijnde buur.

Hoe verandert een proxy wat ik meet?

Een proxy voegt een been toe aan elk verzoek: je checker praat met de proxy, en de proxy praat met je dienst. De totale tijd is de som van beide benen, dus een checker in Parijs met een Tokio IP meet vooral Parijs naar Tokio.

Twee zuivere manieren om de cijfers te lezen:

1. Draai de checker dicht bij de proxy. Een kleine server in dezelfde regio houdt het eerste been kort, zodat de timing de stad weerspiegelt die je hebt gekozen.
2. Meet het eerste been apart. Time een verzoek naar een licht endpoint via de proxy en trek die baseline af van je diensttiming.

Voor uptime alleen maakt het extra been niet uit: de vraag is of je dienst vanuit die stad überhaupt antwoordt, en met welke statuscode en content.

# Documentation address; use an IP, port and credentials from your account
curl -x http://USERNAME:[email protected]:8000 \
  -o /dev/null -s \
  -w "status=%{http_code} connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" \
  https://example.com/health

Hoe bouw ik een eenvoudige multi-stad-monitor?

Een eenvoudige multi-stad-monitor heeft één IP per regio, één health-URL aan jouw kant en een scheduler.