Pour surveiller la perte de paquets et la latence entre régions, exécutez les mêmes sondes vers les mêmes cibles depuis plusieurs emplacements qui reflètent la répartition de vos utilisateurs, puis comparez chaque région à sa propre référence plutôt qu'à une valeur globale unique. Suivez les percentiles et la gigue plutôt que les moyennes, envoyez suffisamment de paquets par vérification pour mesurer la perte de façon fiable, et ne déclenchez une alerte que lorsqu'un schéma se confirme sur plusieurs sondes ou persiste dans le temps.
Choisir des régions de sonde adaptées à vos utilisateurs
Partez des données de trafic, pas d'une carte. Si la plupart des sessions proviennent d'Europe de l'Ouest, de la côte est des États-Unis et d'Asie du Sud-Est, ce sont vos régions de sonde principales ; ajoutez des régions secondaires là où vous avez des SLA contractuels. Prévoyez au moins deux sondes par marché important afin qu'un problème local sur une sonde ne ressemble jamais à une panne régionale.
Gardez à l'esprit que les sondes hébergées en datacenter empruntent des chemins plus propres que les connexions résidentielles ou mobiles : considérez leurs mesures comme le meilleur scénario possible.
Définir des références par région, fondées sur la physique
La lumière parcourt environ 200 km par milliseconde dans la fibre : chaque tranche de 100 km de câble ajoute donc environ 1 ms de temps aller-retour, avant même toute mise en file d'attente. Les routes réelles sont plus longues que la ligne droite, d'où les plages typiques suivantes :
| Trajet | RTT typique |
|---|---|
| Même agglomération ou même région cloud | 1–5 ms |
| Au sein de l'Europe de l'Ouest | 10–30 ms |
| Est des États-Unis vers ouest des États-Unis | 60–75 ms |
| Est des États-Unis vers Europe de l'Ouest | 75–95 ms |
| Europe de l'Ouest vers Singapour | 150–190 ms |
| Europe de l'Ouest vers Sydney | 250–300 ms |
Une mesure de 180 ms depuis Singapour vers un serveur à Francfort est normale ; la même valeur depuis Amsterdam est un incident. Construisez vos références à partir d'au moins une semaine de données par région et alertez sur les écarts, par exemple lorsque le p95 dépasse de 30 à 50 % sa norme sur sept jours.
Mesurer la perte et la latence avec rigueur statistique
Une vérification qui envoie trois pings ne peut indiquer que 0, 33, 67 ou 100 % de perte, une granularité trop grossière pour détecter les 1 à 2 % de perte qui dégradent déjà le débit TCP. Recommandations pratiques :
- Envoyez 10 à 20 paquets par vérification, ou agrégez plusieurs vérifications sur une fenêtre glissante de cinq minutes avant de calculer la perte.
- Publiez le p50 pour l'expérience typique et le p95 pour la traîne dont se plaignent les utilisateurs. Les moyennes masquent les pics.
- Suivez la gigue, c'est-à-dire la variation entre des mesures RTT consécutives. Au-delà d'environ 20 à 30 ms, elle dégrade le trafic temps réel même lorsque la latence semble saine.
- Associez l'ICMP à des vérifications TCP sur le port du service, car certains routeurs limitent le débit ICMP et affichent une perte que le trafic applicatif ne subit jamais.
Le monitoring ping d'UpScanX prend en charge les vérifications ICMP, TCP et UDP depuis plus de 15 emplacements dans le monde, ce qui permet d'exécuter des sondes identiques par région et de les comparer côte à côte.
Comparer les régions pour isoler la cause
La comparaison entre régions est le moyen le plus rapide de localiser un problème :
- Toutes les régions se dégradent en même temps : le problème se situe probablement à l'origine ou chez son fournisseur amont.
- Une seule région se dégrade, les autres sont stables : soupçonnez un opérateur de transit, un point de peering ou un FAI régional sur ce chemin.
- Seuls les points de terminaison derrière un CDN se dégradent dans une région : vérifiez le point de présence qui dessert cette région plutôt que votre origine.
- La perte n'apparaît qu'en ICMP : il s'agit probablement d'une limitation de débit sur un routeur intermédiaire, sans impact réel pour les utilisateurs.
Lorsqu'une région se dégrade, lancez un traceroute ou un MTR depuis cette sonde et comparez-le au chemin d'une région saine. Repérez l'endroit où la latence augmente et reste élevée sur tous les sauts suivants ; un pic sur un seul saut intermédiaire qui disparaît ensuite signifie généralement qu'un routeur dépriorise simplement ses réponses. Joignez les traces à l'incident pour montrer précisément à un fournisseur où le chemin s'est dégradé.
Alerter par quorum, rapporter par région
Les alertes fondées sur une seule sonde génèrent du bruit. Déclenchez une alerte lorsqu'au moins deux sondes d'une même région, ou une majorité de régions, dépassent le seuil sur deux ou trois vérifications consécutives. Utilisez un avertissement pour un marché isolé et une alerte critique lorsque plusieurs régions concordent, acheminées vers Slack, Microsoft Teams, l'e-mail, Telegram ou un webhook.
Dans vos rapports, publiez par région la latence p95, la perte et la gigue aux côtés de la disponibilité. Les rapports IA d'UpScanX détectent les anomalies, corrèlent les alertes liées et envoient des synthèses planifiées par e-mail. Pour approfondir le RTT et la conception des seuils, consultez notre guide du monitoring de la latence réseau.
Points clés
- Placez les sondes là où se trouvent vos utilisateurs, avec au moins deux par marché important.
- Établissez une référence distincte pour chaque région ; la distance impose un plancher physique à la latence.
- Envoyez suffisamment de paquets par vérification et suivez le p95 et la gigue plutôt que les moyennes.
- Comparez les régions et tracez les routes pour distinguer les problèmes d'origine, de FAI et de CDN.
- Alertez selon le quorum et la persistance, et publiez les indicateurs par région.