Si votre surveillance de l'API fonctionne sur un serveur dans un seul centre de données, vous ne voyez qu'une partie du tableau. Un utilisateur du Brésil peut recevoir une erreur 500 pendant que votre tableau de bord à Moscou affiche un statut vert « tout fonctionne ». Examinons quelles 5 métriques d'accessibilité ne peuvent pas être mesurées sans une requête via une véritable IP externe d'un autre pays, et comment le faire sans infrastructure complexe.
Pourquoi la surveillance locale est trompeuse
La plupart des équipes configurent la surveillance de l'API via UptimeRobot, Pingdom ou un script cron personnalisé qui interroge le point de terminaison une fois par minute. Le problème est que ces requêtes proviennent presque toujours d'une ou deux régions - généralement des États-Unis ou d'Europe, où se trouvent les serveurs des services de surveillance. Si votre audience est en Inde, au Brésil ou en Asie du Sud-Est, les fournisseurs locaux peuvent couper le trafic, le nœud CDN peut être surchargé, et le DNS peut résoudre vers une IP obsolète.
Un autre scénario fréquent est le geo-blocking au niveau du CDN ou du WAF (Cloudflare, Akamai). Certaines règles de sécurité bloquent des plages entières d'IP provenant de certains pays, et votre API est physiquement inaccessible pour une partie des utilisateurs, même si tout fonctionne parfaitement depuis votre IP de bureau. De tels problèmes ne peuvent pas être diagnostiqués si l'on teste uniquement depuis un seul point.
Un troisième scénario est l'équilibrage de charge via Anycast ou des CDN régionaux. Une requête en provenance d'Allemagne peut atteindre un nœud, tandis qu'une requête en provenance de Singapour peut atteindre un tout autre nœud, avec une version de cache ou une configuration différente. La différence de comportement de l'API entre les régions n'est pas une théorie, mais une réalité à laquelle font face régulièrement les équipes dont les utilisateurs sont répartis dans le monde entier.
5 métriques d'accessibilité visibles uniquement via une IP externe
Voici cinq métriques qui montrent la véritable image de l'accessibilité uniquement lorsque la requête est effectuée à partir d'une adresse IP physiquement située dans le pays cible ou au moins routée à travers son réseau.
1. Temps de réponse (Latence / RTT)
Le Round-Trip Time est le temps écoulé entre l'envoi de la requête et la réception du premier paquet de réponse. Depuis un serveur en Europe, la latence jusqu'à votre API peut être de 20 ms, tandis qu'un utilisateur d'Asie du Sud-Est attendra 400-600 ms en raison de la distance géographique et du nombre de nœuds intermédiaires (hops). Si la latence n'est pas mesurée depuis différentes régions, il est facile de manquer le moment où le service devient pratiquement inutilisable pour une partie de l'audience - ce qui est particulièrement critique pour les API liées aux opérations en temps réel : enchères publicitaires, chats, transactions fintech.
2. TTFB (Time To First Byte)
Le TTFB montre combien de temps le serveur met à traiter la requête avant de commencer à envoyer la réponse. Cette métrique dépend non seulement du réseau, mais aussi de quel nœud CDN ou d'équilibreur de charge dessert une région spécifique. Il arrive souvent qu'un serveur edge dans un pays mette en cache la réponse et la renvoie en 50 ms, tandis que dans un autre pays, la requête atteint à chaque fois le serveur d'origine et est traitée à nouveau, prenant 800 ms ou plus. La différence de TTFB entre les régions est un signe certain de problèmes de configuration du CDN ou d'une couverture insuffisante des nœuds edge.
3. Temps de résolution DNS
La résolution DNS est une source distincte de latences et d'erreurs, qui dépend entièrement du résolveur local de l'utilisateur. Si vous avez configuré GeoDNS (différentes enregistrements A en fonction de la région de la requête), une erreur dans la configuration peut entraîner le fait que les utilisateurs d'un pays soient résolus vers un centre de données sur un autre continent - avec un énorme délai. Ce problème n'est visible que lors de la requête de résolution DNS à partir d'une véritable IP du pays cible, un test local sera toujours résolu « correctement » par rapport à votre propre géolocalisation.
4. Pourcentage de requêtes réussies (Uptime) par région
Un uptime de 99.9% sur le tableau de bord de surveillance, qui interroge depuis un seul point, ne garantit pas 99.9% pour les utilisateurs d'un autre pays. Les fournisseurs locaux peuvent avoir des problèmes de peering spécifiquement avec votre fournisseur d'hébergement, ce qui entraîne une partie des requêtes depuis le pays X échouant par timeout, tandis que le reste du monde ne remarque pas le problème. Pour voir le véritable uptime, il faut compter les requêtes réussies et échouées séparément pour chaque région, et non de manière agrégée.
5. Différences de contenu et de codes d'état (geo-blocking et personnalisation)
La cinquième métrique ne concerne pas la vitesse, mais le contenu même de la réponse. L'API peut renvoyer un 403 Forbidden pour certains pays en raison des règles WAF, retourner un ensemble de données réduit en raison de restrictions de licence, ou afficher une version différente du contenu en raison de tests A/B liés à la géo. Si l'on teste l'API uniquement depuis sa propre IP, de telles différences resteront complètement inaperçues - et ce sont précisément elles qui deviennent le plus souvent la source de plaintes de la part des utilisateurs de certaines régions.
Il est important de comprendre
Les cinq métriques nécessitent toutes une requête depuis une IP qui est réellement routée à travers le réseau du pays cible. Un VPN avec un seul serveur dans le pays ou un serveur cloud dans la même région donnera une image approximative, mais ne montrera pas comment le service est perçu par l'utilisateur final avec un fournisseur spécifique et ses routes vers votre API.
Comment configurer la surveillance depuis différents pays
La logique de configuration est simple : vous envoyez la même requête HTTP à votre API depuis plusieurs points simultanément, en enregistrant les cinq métriques et en comparant les résultats. Voici les étapes :
- Établissez une liste des pays prioritaires - généralement les 5 premiers pays en termes de trafic ou de revenus.
- Pour chaque pays, préparez un point de sortie avec une véritable IP de ce pays (serveur proxy ou serveur physique).
- Configurez un script ou un service qui envoie une requête identique via chaque point à un intervalle donné (par exemple, toutes les 5 minutes).
- Enregistrez toutes les 5 métriques séparément pour chaque pays dans une base de données ou un système de métriques (Grafana, Prometheus, ClickHouse).
- Configurez des alertes pour les écarts de métriques par rapport au niveau de base - par exemple, si la latence d'un pays spécifique a triplé en une heure.
Le point clé est le point 2. Sans sortie réelle vers le pays cible, toutes les autres étapes sont inutiles, car les métriques mesureront non pas ce que voit l'utilisateur, mais ce que voit votre propre serveur de surveillance.
Quel type de proxy choisir pour la surveillance
Pour construire une surveillance géographiquement distribuée, on utilise le plus souvent des serveurs proxy - c'est moins cher et plus rapide que de louer des serveurs physiques ou des VPS dans chaque pays nécessaire. Le choix du type de proxy dépend de ce que vous souhaitez mesurer.
| Type de proxy | Quand utiliser | Particularités |
|---|---|---|
| Proxies de centre de données | Vérification de base de l'accessibilité et de la latence, lorsque l'imitation d'un utilisateur réel n'est pas nécessaire | Haute vitesse, faible coût, mais l'IP est facilement identifiée comme étant de centre de données - ne convient pas pour tester le geo-blocking par fournisseur |
| Proxies résidentiels | Vérification de ce que voit un utilisateur réel avec un fournisseur résidentiel | L'IP appartient à de véritables fournisseurs dans un pays spécifique, reflète plus précisément le routage et les règles WAF |
| Proxies mobiles | Tester l'accessibilité de l'API pour les applications mobiles et le trafic mobile | IP des réseaux des opérateurs mobiles, montre les latences et les blocages spécifiques au trafic mobile |
Si votre API sert principalement le trafic web depuis des ordinateurs de bureau et des serveurs, pour construire une surveillance de base, les proxies de centre de données suffisent - ils offrent une vitesse stable et une latence prévisible. Mais si vous devez vérifier ce à quoi fait face un utilisateur réel - y compris les règles de geo-blocking configurées par ASN du fournisseur - il vaut mieux utiliser des proxies résidentiels, car ils sont routés à travers les réseaux des fournisseurs d'accès Internet ordinaires du même pays. Pour les applications mobiles et les SDK qui effectuent des requêtes à l'API, il est judicieux d'ajouter une vérification via des proxies mobiles, car les opérateurs mobiles utilisent souvent le NAT et leurs propres règles de routage, différentes de celles de l'internet domestique.
Script prêt à l'emploi en Python pour la collecte de métriques
Voici un exemple simplifié de script qui envoie une requête via un proxy dans le pays spécifié et collecte quatre des cinq métriques (les différences de contenu doivent être comparées séparément, en corrélant les réponses). Le script utilise la bibliothèque requests et le module socket pour mesurer le temps de résolution DNS.
import time
import socket
import requests
def measure_api(url, proxy, country_label):
hostname = url.split("//")[1].split("/")[0]
# 1. Temps de résolution DNS
dns_start = time.time()
try:
socket.gethostbyname(hostname)
except socket.gaierror:
pass
dns_time = time.time() - dns_start
proxies = {
"http": proxy,
"https": proxy,
}
try:
start = time.time()
response = requests.get(
url,
proxies=proxies,
timeout=10,
stream=True
)
ttfb = time.time() - start # TTFB approximatif
full_load_time = time.time() - start
status_code = response.status_code
success = status_code == 200
result = {
"country": country_label,
"dns_time_ms": round(dns_time * 1000, 2),
"ttfb_ms": round(ttfb * 1000, 2),
"total_time_ms": round(full_load_time * 1000, 2),
"status_code": status_code,
"success": success,
}
except requests.exceptions.RequestException as e:
result = {
"country": country_label,
"dns_time_ms": round(dns_time * 1000, 2),
"ttfb_ms": None,
"total_time_ms": None,
"status_code": None,
"success": False,
"error": str(e),
}
return result
# Exemple d'utilisation avec des proxies de différents pays
endpoints = [
{"label": "Allemagne", "proxy": "http://user:[email protected]:port"},
{"label": "Brésil", "proxy": "http://user:[email protected]:port"},
{"label": "Singapour", "proxy": "http://user:[email protected]:port"},
]
API_URL = "https://api.yourservice.com/health"
for ep in endpoints:
data = measure_api(API_URL, ep["proxy"], ep["label"])
print(data)
Pour une version production de ce script, il est conseillé d'ajouter l'enregistrement des résultats dans une base de données (par exemple, ClickHouse ou InfluxDB), une visualisation via Grafana et des alertes via un bot Telegram ou un webhook Slack en cas de dépassement des seuils. Il est préférable d'exécuter le script via cron ou un planificateur de tâches avec un intervalle de 5 à 15 minutes pour chaque pays.
Si vous avez besoin d'une vérification rapide sans écrire de code, une requête similaire peut être effectuée via cURL avec mesure du temps :
curl -x http://user:[email protected]:port \
-o /dev/null -s -w "DNS: %{time_namelookup}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s | HTTP: %{http_code}\n" \
https://api.yourservice.com/healthComment interpréter les résultats
Après avoir collecté des données pour tous les pays pendant au moins une semaine, un niveau de base (baseline) apparaît pour chaque région. Ensuite, il faut se concentrer non pas sur les chiffres absolus, mais sur les écarts par rapport à cette baseline. Si la latence depuis le Brésil reste stable à 350 ms - c'est normal pour cette géographie, et il convient de s'inquiéter si la valeur augmente soudainement à 1500 ms. De même pour l'uptime : 99.5% pour une région difficile avec une connexion Internet instable peut être une norme acceptable, tandis qu'une chute à 95% est déjà un signal de problème du côté du fournisseur ou du CDN.
Une attention particulière doit être accordée aux codes d'état 403 et 451 - ils indiquent presque toujours un geo-blocking de la part du WAF ou du CDN, et non un problème avec l'API elle-même. Si de tels codes apparaissent uniquement depuis un pays spécifique et uniquement lors de l'utilisation d'un proxy d'un certain type (par exemple, de centre de données), cela peut signifier que le blocage est configuré sur la base de l'indice « l'IP ressemble à celle d'un centre de données », et non sur la géolocalisation réelle - dans ce cas, un test avec des proxies résidentiels donnera une image plus honnête.
Services prêts à l'emploi vs solution sur mesure
Si vous ne souhaitez pas maintenir votre propre script, il existe sur le marché des services de surveillance synthétique avec des points de présence dans différents pays : Pingdom, Uptrends, Site24x7, Checkly. Ils vous évitent d'avoir à configurer l'infrastructure, mais sont généralement limités à un ensemble fixe de localisations et ne permettent pas de flexibilité dans le choix du type d'IP (résidentielle, mobile, centre de données) pour un test spécifique.
Une solution sur mesure basée sur des proxies offre plus de contrôle : vous pouvez tester précisément les pays qui sont importants pour votre entreprise, passer d'un type d'IP à un autre pour diagnostiquer des problèmes spécifiques (par exemple, geo-blocking par ASN) et intégrer les métriques directement dans votre système de surveillance sans intermédiaires inutiles. Une combinaison des deux approches est un équilibre raisonnable : des services prêts à l'emploi pour une surveillance SLA de base, un script personnalisé avec des proxies pour un diagnostic précis des problèmes dans des régions spécifiques.
Conclusion
La surveillance locale depuis un seul point ne montre qu'une partie de la vérité sur l'accessibilité de l'API. Pour voir la véritable image, il faut mesurer la latence, le TTFB, le temps de résolution DNS, l'uptime et les différences de contenu séparément pour chaque pays - et le faire via une IP qui est réellement routée à travers le réseau de la région cible. Sans cela, il est facile de manquer un problème qui empêche une partie des utilisateurs d'utiliser le service, pendant que le tableau de bord affiche « tout est vert ».
Pour construire une telle surveillance, les proxies résidentiels sont les plus adaptés si vous voulez voir la même chose que voit un utilisateur réel avec Internet domestique dans un pays spécifique. Pour une vérification de base moins coûteuse et plus rapide, les proxies de centre de données suffisent, et pour diagnostiquer des problèmes spécifiquement auprès du public mobile, il est judicieux d'ajouter une vérification via des proxies mobiles. Cette approche combinée offre une vue complète de la façon dont votre API apparaît depuis n'importe quel point du monde, et pas seulement depuis le serveur où elle est déployée.