Le monitoring multi-localisations consiste à poser la même question HTTP depuis plusieurs endroits. On ne traduit rien. On cherche si le site est injoignable pour tout le monde, ou seulement depuis un réseau, une ville, un résolveur DNS. Une sonde unique ne peut pas faire cette distinction : quand elle échoue, vous ne savez pas si c’est votre origine ou son chemin jusqu’à vous.
D’où part la requête
Chaque point de mesure a son propre résolveur, son transit, et parfois une vue différente d’un DNS anycast. Deux sondes peuvent donc recevoir deux adresses IP pour le même nom, surtout si un CDN ou un hébergeur répartit le trafic. C’est voulu. Le contrôle compare des parcours, pas une machine unique.
Ce que chaque sonde doit relever est identique, pour que la comparaison ait un sens : code HTTP final, échec TLS, délai, et la même chaîne de contenu. Si une sonde cherche un texte et l’autre se contente du code 200, leurs « succès » ne décrivent pas la même chose. La liste des mesures est celle de la définition du monitoring de site web.
Un seul point, placé dans le même centre de données que l’hébergeur, est le cas le plus trompeur. Il traverse peu de réseau. Il annonce le site disponible pendant qu’un opérateur, ailleurs, n’arrive plus à joindre l’adresse anycast.
Majorité, et incident régional
Fixez la règle avant la première alerte.
- Échec majoritaire. Deux sondes sur trois, ou trois sur cinq, n’obtiennent pas le contrat (code, certificat, contenu). Traitez ça comme un incident du site : origine, certificat, déploiement.
- Échec isolé. Une sonde échoue, les autres passent. Enregistrez-le. N’ouvrez pas le même incident. Cherchez un problème de chemin : DNS local à cette sonde, poP de CDN, pare-feu qui filtre une plage d’adresses.
- Lenteur isolée. Les codes sont bons, un seul délai sort de la fourchette. C’est une dégradation régionale, utile à suivre, rarement une astreinte immédiate.
Attendre que toutes les sondes échouent cache les pannes régionales : le site peut être inutilisable dans un pays et « vert » sur le tableau parce qu’une sonde lointaine répond encore. Alerter à la première sonde, à l’inverse, réveille l’astreinte pour un résolveur qui expire.
Le nombre de points suit le risque. Deux réseaux distincts suffisent à écarter une partie des faux échecs. Au-delà, ajoutez un lieu seulement si vous avez des visiteurs ou un CDN qui y terminent vraiment le trafic. Multiplier les capitales sans règle de majorité multiplie les courbes, pas la décision.
Ne pas confondre avec les langues du site
Un site servi en français depuis Paris, Lyon et un second opérateur est un sujet multi-localisations, même s’il n’a qu’une langue. Un site /fr/ et /en/ contrôlé depuis un seul réseau est un sujet de contenu par locale. Les deux se cumulent quand l’audience est répartie, mais les réglages ne sont pas interchangeables. Le guide du site international couvre textes attendus et fuseaux.
La page de statut et l’historique doivent garder le lieu du relevé. « Indisponible » sans dire depuis où ne se compare pas d’un mois à l’autre. Lors d’un doute, un test d’URL depuis votre propre accès reste un point de plus, pas une sonde neutre : votre bureau peut être dans le même cas que la sonde qui échoue, ou dans le cas inverse.
SiteGarde juge la réponse HTTP. Quand plusieurs origines de mesure existent, lisez-les avec la règle de majorité ci-dessus plutôt qu’en moyenne. Une moyenne de délais masque la ville qui ne répond plus.