Surveillance de l'uptime et de la latence depuis des villes datacenter

Pourquoi surveiller depuis des villes datacenter ?

Surveiller depuis des villes datacenter montre comment votre service se comporte depuis les hubs réseau par lesquels passe le trafic de vos utilisateurs. Une vérification depuis votre bureau ne teste qu'un seul chemin. Une vérification depuis Francfort, Singapour ou São Paulo teste la route, la réponse DNS et le edge CDN servis à cette région.

Questions typiques auxquelles cela répond :

• Le site répond-il depuis chaque marché, ou une région reçoit-elle des erreurs ?
• Le CDN envoie-t-il les visiteurs de Tokyo vers un edge asiatique, ou jusqu'en Virginie ?
• Un changement de DNS ou de certificat a-t-il atteint chaque région ?
• Une page lente est-elle un problème de serveur ou de distance ?

Une IP datacenter mesure le chemin du datacenter, pas le dernier kilomètre d'un utilisateur à domicile en Wi-Fi ou en mobile. C'est un atout pour des vérifications reproductibles, et une limite si vous avez besoin de timings d'utilisateurs réels.

Quelle est la latence minimale entre deux villes ?

L'aller-retour minimal en millisecondes est d'environ la distance en kilomètres divisée par 100. La lumière dans la fibre optique parcourt environ 200 km par milliseconde, et un aller-retour couvre la distance deux fois. Les routes réelles sont plus longues qu'une ligne droite, donc les valeurs mesurées sont plus élevées.

Les paires les plus proches parmi nos pages de villes datacenter, d'après les distances indiquées sur ces pages :

Si une vérification d'Amsterdam vers un serveur à Londres prend 40 ms, la distance n'en explique que moins de 4 ms ; regardez le routage, la configuration TLS ou le serveur. Le tableau des données par ville liste chaque ville avec ses installations et son voisin le plus proche.

Comment un proxy modifie-t-il ce que je mesure ?

Un proxy ajoute un segment à chaque requête : votre vérificateur parle au proxy, et le proxy parle à votre service. Le temps total est la somme des deux segments, donc un vérificateur à Paris utilisant une IP à Tokyo mesure surtout Paris-Tokyo.

Deux façons claires d'interpréter les chiffres :

1. Exécutez le vérificateur près du proxy. Un petit serveur dans la même région garde le premier segment court, donc le timing reflète la ville que vous avez choisie.
2. Mesurez le premier segment séparément. Chronométrez une requête vers un endpoint léger via le proxy et soustrayez cette référence de votre timing de service.

Pour l'uptime seul, le segment supplémentaire n'a pas d'importance : la question est de savoir si votre service répond depuis cette ville, et avec quel code de statut et quel contenu.

# 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

Comment construire un moniteur multi-villes simple ?

Un moniteur multi-villes simple nécessite une IP par région, une URL de santé de votre côté et un planificateur.