Monitoring site web depuis 300+ emplacements : panne confirmée avant l’alerte

Les six cartes ci-dessus sont le point de départ de la plupart des comptes. Le catalogue complet compte quatorze types de moniteurs, qui partagent tous la même flotte d’emplacements, le même protocole de confirmation et le même routage des alertes - vous n’utilisez pas un outil pour la disponibilité et un second pour les certificats.

Les vérifications réseau s’exécutent depuis la flotte publique de 300+ emplacements. Les vérifications d’infrastructure - requête de base de données, compteur de performance et SNMP - passent plutôt par des agents dédiés, car ce dont elles ont besoin, ce sont des identifiants et un accès à votre réseau, pas de la géographie.

C’est important, car les causes les plus courantes d’un « échec » de vérification n’ont rien à voir avec votre serveur :

• Le chemin est tombé, pas le site. Un opérateur de transit réachemine mal pendant quatre-vingt-dix secondes alors que tous les autres réseaux vous atteignent encore.
• Le site est tombé, mais seulement pour certains. Un nœud CDN sert des erreurs périmées dans une région, ou une règle de pare-feu bloque un pays - et un point d’observation mal placé répond « tout va bien ».
• La sonde est tombée. Sans second avis, un mauvais nœud et un mauvais site se ressemblent.

La surveillance distribuée répond aux trois cas de la même façon : interroger plusieurs endroits sans lien entre eux, puis comparer. Pour faire cette comparaison une fois, tout de suite, utilisez la vérification HTTP gratuite depuis plusieurs emplacements.

1. Le moniteur arrive à échéance. Les intervalles vont d’une minute à 24 heures, trois par défaut, et le travail dû est pris en charge en continu plutôt que par fenêtres de traitement.
2. Un emplacement est choisi parmi les groupes que vous avez retenus. Vous choisissez des groupes, pas des machines, de sorte qu’une vérification tourne dans le groupe au lieu de se fixer sur un seul serveur.
3. La vérification s’exécute. L’emplacement effectue la vraie requête - requête HTTP, ping ICMP, prise de contact TCP, chargement de page dans un navigateur - et renvoie le résultat, le détail des temps et, le cas échéant, le corps de la réponse.
4. Un changement d’état déclenche une confirmation, pas une alerte. Seul un changement confirmé ouvre ou ferme une période d’indisponibilité.

Les groupes vers lesquels un moniteur peut être dirigé sont nommés et sélectionnables dans l’interface comme dans l’API :

Un nouveau moniteur démarre sur l’Europe de l’Ouest, l’Europe de l’Est et l’Amérique du Nord. Les groupes se combinent et se soustraient : allworld avec -russia signifie « partout sauf en Russie », ce qui permet d’écarter le routage national d’un pays de vos alertes.

Une vérification unique en échec n’envoie jamais d’alerte. Quand un résultat diverge de l’état courant du moniteur, HostTracker ouvre une session de confirmation et retient l’alerte jusqu’à la réponse d’autres emplacements :

1. Attendre dix secondes. Une cible qui vient de basculer est la dernière chose à avoir besoin d’une rafale de trafic supplémentaire, et beaucoup d’à-coups sont terminés avant la dixième seconde.
2. Répartir la revérification. Jusqu’à sept emplacements sont tirés d’un pool mélangé et lancés à deux secondes d’intervalle, de sorte que les revérifications sont étalées dans le temps comme dans la géographie. Si trop peu d’emplacements de confiance sont libres, le quorum est complété jusqu’à un minimum de trois.
3. Trier les réponses avant de les compter. Un emplacement qui n’a pas pu exécuter la vérification ne compte pas et n’est pas pénalisé. Un emplacement qui renvoie un résultat inutilisable ne compte pas non plus, est marqué, et un remplaçant est envoyé.
4. Appliquer la règle d’accord. Par défaut, la majorité décide. Par moniteur, vous pouvez exiger qu’au moins un nombre donné d’emplacements signalent une panne, exiger l’accord total dans les deux sens, ou exiger l’accord total pour une panne tandis que les rétablissements se confirment à la majorité.
5. Noter les emplacements par rapport au verdict. Un emplacement qui contredit sans cesse le verdict reçoit un point de défiance assorti d’un compte à rebours, est ignoré tant qu’il court, et regagne sa place à mesure que le compte à rebours s’épuise. C’est ainsi qu’un nœud instable se met lui-même à la retraite.
6. Si rien d’exploitable n’est revenu, personne n’est réveillé. La session se termine sans verdict et la vérification de base est retentée plus tard.

Il a aussi un interrupteur : une vérification dont le résultat est déjà définitif à elle seule (une requête de base de données a renvoyé la ligne, ou non) saute entièrement la confirmation.

Le meilleur argument en faveur de la surveillance multi-emplacements n’est pas la panne que tout le monde remarque, mais celle que seuls certains remarquent. En ligne en Europe, hors ligne en Amérique du Nord, cela ressemble à ceci :

À titre d’illustration, mais c’est la forme que prend un vrai résultat par emplacement. La règle de majorité par défaut n’y voit pas une panne mondiale, car ce n’en est pas une. Elle enregistre quels emplacements ont échoué, à quelle seconde, avec quelle erreur - des preuves horodatées, recueillies hors du réseau de votre fournisseur, ce qui les rend utilisables dans un ticket de support.

Pour être alerté d’une panne régionale au lieu de simplement la journaliser : réglez la règle de confirmation sur « au moins ce nombre d’emplacements signalent une panne », ou lancez un second moniteur limité à cette région, où la panne devient la majorité. Vous dépannez un hôte en ce moment ? Un test de ping mondial montre ce tableau en un clic.

Les alertes dépendent du délai propre à chaque contact, pas d’une règle globale. Chaque contact choisit quand il veut être informé d’une panne : immédiatement, ou après 3, 5, 15, 30 ou 60 minutes de panne continue, ou après 3, 6, 12 ou 24 heures. Cette échelle transforme une liste de contacts en politique d’escalade, sans produit d’astreinte séparé - minute 0 vers le canal de l’équipe, minute 5 vers le téléphone de l’ingénieur d’astreinte, minute 30 vers le responsable technique, heure 3 vers le propriétaire du compte.

Canaux pour chaque palier : e-mail, SMS, appel vocal, notification push du navigateur, Slack, Telegram, Discord, Viber et webhooks signés - le webhook étant le moyen par lequel les alertes atteignent un gestionnaire d’incidents, un système de tickets ou tout outil interne doté d’une URL entrante.

Une surveillance qui se contente d’alerter est un demi-produit. L’autre moitié, c’est la trace qu’elle laisse - ce que vous utilisez dans un litige d’hébergement, une demande de crédit SLA ou un retour d’expérience après incident.

• Résultats de vérification par emplacement avec statut, temps de réponse et texte d’erreur, conservés en historique et pas seulement comme état courant.
• Périodes d’indisponibilité avec un début confirmé, une fin confirmée et la trace de confirmation derrière les deux.
• Rapports de disponibilité programmés, envoyés par e-mail à la cadence que vous fixez.
• Un export SLA et un badge de disponibilité publiés directement depuis une page de statut.
• Fenêtres de maintenance, pour que les travaux planifiés ne faussent pas le chiffre de disponibilité que vous devrez défendre plus tard.

Une preuve externe a du poids précisément parce qu’elle est externe : un fournisseur peut écarter vos propres journaux serveur, mais un relevé horodaté d’échecs vus depuis plusieurs réseaux indépendants, dont aucun n’est le vôtre, est plus difficile à contester.

Le moyen le plus rapide de réduire le volume du support pendant un incident est d’arrêter de faire poser la question. Une page de statut transforme les moniteurs que vous exécutez déjà en composants publics, les met à jour à partir des mêmes résultats confirmés que ceux qui déclenchent vos alertes, et est hébergée pour vous à sa propre adresse - sans hébergement supplémentaire ni travail DNS. Les incidents et les fenêtres de maintenance y sont publiés, et les visiteurs peuvent s’abonner.

Les pages de statut sont incluses dans chaque offre, y compris la gratuite, et la publication sous votre propre domaine l’est aussi. HostTracker fait tourner la sienne sur le même mécanisme - status.host-tracker.com en est un exemple en direct - et la présentation des pages de statut couvre le reste.

Chaque affirmation de cette page peut être testée sans compte, car les outils instantanés gratuits s’exécutent sur la même flotte que les moniteurs payants. Pointez-en un vers un site dont vous savez qu’il est en bonne santé, puis vers un site dont vous savez qu’il ne l’est pas, et lisez vous-même les résultats par emplacement.

• Vérification HTTP gratuite depuis plusieurs emplacements - code de statut, temps de réponse et en-têtes par emplacement.
• Lancer un test de ping mondial - accessibilité, latence et perte de paquets au niveau réseau, là où les problèmes de routage apparaissent en premier.

Il existe onze de ces outils gratuits, chacun étant la version manuelle d’un type de moniteur que vous pourrez ensuite planifier.

Les emplacements sont un paramètre à part entière, pas un réglage enfoui dans un formulaire. Lancer une vérification depuis des régions nommées via REST :

curl -X POST https://api2.host-tracker.com/check \
  -H "Authorization: Bearer $HT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com", "type": "http", "pools": ["westeurope", "asia"]}'

Les identifiants du tableau des régions vont dans pools, et les mêmes valeurs fonctionnent quand vous créez un moniteur planifié. Autour de cette interface REST se trouvent des bibliothèques officielles pour TypeScript, Python, Go et .NET, le client en ligne de commande ht, une GitHub Action et un serveur MCP pour qu’un assistant IA puisse créer des moniteurs et lire les résultats directement - le tout généré à partir d’un seul document OpenAPI.

Trois façons d’utiliser le réseau, et la flotte est la même dans chacune - l’offre gratuite n’est pas vérifiée depuis moins d’endroits que les offres payantes.

L’essai est la façon honnête de l’évaluer : 30 jours, cent moniteurs, pas de carte - de quoi faire tourner HostTracker à côté de ce que vous utilisez aujourd’hui et comparer les alertes réellement envoyées par les deux. Limites complètes par offre : offres de monitoring de site web HostTracker.

Uniquement des colonnes vérifiables sur une page publiée. Tiré des tarifs et de la documentation de chaque éditeur, août 2026 - vérifiez tout ce dont dépend une décision.

Là où nous ne sommes pas en avance, le tableau le dit : l’offre gratuite d’UptimeRobot comprend plus de moniteurs que la nôtre, et leur serveur MCP hébergé est sorti avec OAuth avant le nôtre. Les raisons de choisir ce réseau figurent dans les trois premières lignes.

Détails du réseau, du protocole et des offres sur cette page vérifiés pour la dernière fois le 30 août 2026. HostTracker exploite ce réseau de surveillance distribué depuis 2004.