Surveillance synthétique
La surveillance synthétique (synthetic monitoring) de HostTracker teste votre site selon un calendrier, depuis plus de 300 emplacements, avec le type de vérification qui convient : un parcours navigateur scénarisé, un appel API jugé par des règles, ou une simple requête HTTP. Choisissez-en un ci-dessous et soyez alerté dès qu’il ne correspond plus à ce que vous attendez.
La même forme derrière les trois : exécuter, juger, revérifier, alerter
La surveillance synthétique signifie que le trafic est généré délibérément. Plutôt que d’attendre qu’un visiteur réel rencontre un problème, un service de surveillance teste lui-même votre site web, selon un calendrier fixe, depuis l’extérieur de votre réseau, et compare ce qu’il reçoit à des règles que vous définissez. Les outils de surveillance synthétique de HostTracker couvrent trois formes de vérification - la surveillance par navigateur pour un parcours scénarisé, un appel API jugé par des règles, et une simple requête HTTP - couvrant tout, d’un parcours de paiement complet jusqu’à une simple sonde de code de statut, le tout depuis plus de 300 emplacements dans le monde.
Ce n’est pas de la surveillance des utilisateurs réels (real user monitoring). HostTracker génère lui-même chaque vérification ; il ne collecte aucune donnée de temps ou d’erreur depuis les navigateurs de vos visiteurs réels. Si vous devez savoir ce qu’ont vécu vos vrais visiteurs, c’est une discipline différente, avec un nom différent - consultez surveillance synthétique et surveillance des utilisateurs réels pour la comparaison complète. L’avantage de la surveillance synthétique va dans l’autre sens : elle fonctionne avant même que vous ayez un seul visiteur, et elle continue de fonctionner à trois heures du matin quand personne ne regarde.
Les trois types de vérification répondent à des questions différentes, et choisir le mauvais est la façon la plus courante de laisser passer un vrai problème. Ce tableau associe cinq besoins courants à la vérification qui les couvre réellement.
La plupart des comptes finissent par exécuter plusieurs lignes de ce tableau à la fois - une vérification HTTP en toile de fond, plus une vérification de transaction ou d’API sur les un ou deux parcours qui comptent le plus.
Un scénario de transaction est une séquence d’actions nommées ; un ensemble de règles API est un jeu d’assertions sur une seule réponse. Les deux se configurent, ils ne se scriptent jamais.
Transaction : un scénario en cinq étapes
0 navigate https://shop.example.com/ 1.4 s 1 type #email "[email protected]" 0.2 s 2 click #add-to-cart 0.9 s 3 waitForNavigation /checkout 1.1 s 4 checkContent "Order summary" present 0.1 s
API : un ensemble de quatre règles
status isOk header("Content-Type") contains "json" body.json.path("$.count") gt 0 time lt 5s
Chacun répond à une question différente. La plupart des comptes qui utilisent HostTracker finissent par en exécuter plus d’un.
Ouvre un vrai navigateur Chromium et parcourt jusqu’à dix étapes - se connecter, chercher, ajouter au panier, payer - puis vérifie ce qui se trouve sur la page. Détecte ce qu’un code de statut ne peut pas voir : un bouton supprimé, un envoi de formulaire cassé, une erreur JavaScript en cours de route. Surveillance de transactions
Envoie un appel HTTP et juge la réponse selon jusqu’à 20 règles d’assertion portant sur son statut, ses en-têtes, son temps de réponse et son corps JSON, XML ou texte brut. Conçu pour l’endpoint dont dépend un autre système. Surveillance d’API
Interroge une URL depuis plus de 300 points de contrôle dans 158 villes et vérifie le statut, les mots-clés du corps, le temps de réponse et le TLS. La base toujours active sur laquelle reposent les deux autres. Surveillance HTTP
La forme de la vérification change ; les points de contrôle, la logique de confirmation et les canaux d’alerte derrière elle ne changent pas.
Chaque type de vérification s’exécute depuis le même parc public de points de contrôle. Choisissez les emplacements qui correspondent à l’endroit où se trouvent réellement vos visiteurs, ou les consommateurs de votre API.
Un seul point de contrôle en échec n’ouvre jamais un incident à lui seul. La vérification est relancée depuis d’autres points de contrôle indépendants, et seul un résultat concordant la transforme en alerte.
Une vérification de transaction conserve une capture d’écran de la dernière étape, et une autre au moment où une étape échoue, de sorte que le débogage commence par ce à quoi la page ressemblait réellement.
Vérifiez du texte rendu, une valeur JSON sélectionnée par JSONPath ou XPath, ou un simple mot-clé - jusqu’à 20 règles d’assertion ou 10 correspondances de mots-clés par moniteur, selon le type de vérification.
E-mail, SMS, appel vocal, Slack, Telegram et webhooks, configurés une fois par contact, sont partagés entre les vérifications de transaction, d’API et HTTP de votre compte.
Ajoutez n’importe quel moniteur - parcours navigateur, appel API ou vérification HTTP - à la même page de statut publique, pour que vos clients voient une seule page au lieu de trois séparées.
Sites web, serveurs, API, certificats. Un type de vérification par page, avec les mêmes emplacements, alertes et rapports derrière.
Adopté par des équipes chez
Chaque chapitre s’ouvre sur place, pour que la page reste courte.
Les deux approches répondent à des questions différentes. La surveillance synthétique de sites web génère son propre trafic, depuis ses propres points de contrôle, selon un calendrier que vous contrôlez - un parcours navigateur scénarisé, un appel API, ou une simple requête HTTP. La surveillance des utilisateurs réels observe au contraire les navigateurs de vos vrais visiteurs, ce qui signifie qu’elle a besoin de trafic réel pour dire quoi que ce soit, et qu’elle ne peut pas vous dire ce qui se passera demain, seulement ce qui s’est déjà passé aujourd’hui.
HostTracker est un service de surveillance synthétique - il n’offre pas de surveillance des utilisateurs réels, et cette page ne prétendra pas le contraire. Ce que vous apporte la surveillance synthétique à la place : un site de test sans aucun visiteur est quand même vérifié ; une panne à trois heures du matin est détectée de la même façon qu’une panne à l’heure de pointe ; et comme le scénario est déterministe, le résultat nomme l’étape ou la règle exacte qui a échoué plutôt qu’un symptôme vague. Pour la comparaison complète côte à côte, consultez surveillance synthétique et surveillance des utilisateurs réels ; la page de surveillance des transactions comporte aussi un tableau détaillé si vous voulez la mécanique.
Chaque type de vérification a son propre plancher d’intervalle, parce que chacun coûte une quantité de travail différente à exécuter. Une requête HTTP est peu coûteuse et peut s’exécuter aussi souvent que toutes les minutes sur un plan payant. Un appel API ajoute l’analyse et l’évaluation des règles, mais s’exécute quand même d’une minute jusqu’à 24 heures. Une vérification de transaction ouvre un vrai navigateur et parcourt un scénario de bout en bout, d’où son plancher de 10 minutes - les vérifications par navigateur coûtent cher à exécuter et à recevoir, et associer l’une d’elles à une vérification HTTP rapide sur le même site répond à la fois à la question « est-ce joignable maintenant » et à la question « le parcours fonctionne-t-il toujours », sans faire tourner un navigateur toutes les soixante secondes.
Les trois vous laissent choisir, parmi les plus de 300 points de contrôle dans 158 villes, ceux depuis lesquels un moniteur donné s’exécute - la géographie compte plus qu’il n’y paraît, puisqu’un CDN ou un répartiteur de charge géo-routé peut être en bonne santé dans une région et en échec dans une autre.
La tentation, avec tout nouveau type de vérification, est de le brancher directement sur une alerte qui réveille quelqu’un. Résistez-y la première semaine : laissez un nouveau moniteur tourner en silence, lisez une poignée de résultats réels, et ne décidez qu’ensuite qui doit être prévenu immédiatement et qui reçoit un résumé quotidien. Une vérification de transaction qui échoue parce que le sélecteur d’une bannière marketing a changé n’a pas la même gravité qu’une vérification qui échoue parce que le paiement ne se termine plus - écrivez vos assertions de contenu sur du texte stable et significatif, pour que l’alerte que vous recevez vaille la peine d’agir.
Les alertes partent via les canaux que vous configurez par contact - e-mail, SMS, appel vocal, Slack, Telegram, webhook et plus encore - le même ensemble pour les trois types de vérification, si bien qu’un échec de transaction et un échec HTTP atteignent la même personne de la même façon. Un changement d’état n’est confirmé que lorsque d’autres points de contrôle sont d’accord, donc l’alerte que vous recevez est déjà réfléchie plutôt qu’une observation isolée et instable ; un avis de rétablissement suit dès que la vérification repasse au vert, refermant la boucle sans que vous ayez à aller vérifier vous-même.
La surveillance synthétique est une surveillance où le trafic est généré délibérément, selon un calendrier, par un service extérieur à vos propres systèmes, plutôt que d’attendre qu’un visiteur réel rencontre un problème en espérant qu’il vous le signale. La surveillance synthétique de HostTracker se présente sous trois formes : un parcours navigateur scénarisé qui suit un flux à plusieurs étapes, un appel API jugé selon des règles que vous écrivez, et une simple requête HTTP vérifiée sur le statut, le corps et le temps de réponse. Les trois s’exécutent depuis plus de 300 emplacements, utilisent les mêmes canaux d’alerte, et retiennent une alerte jusqu’à ce que d’autres points de contrôle confirment l’échec.
Non. HostTracker génère lui-même le trafic, depuis ses propres points de contrôle, selon le calendrier que vous définissez - il ne collecte aucune donnée de temps ou d’erreur depuis les navigateurs de vos vrais visiteurs. Si vous devez savoir ce qu’ont vécu vos visiteurs réels, c’est de la surveillance des utilisateurs réels, une discipline différente avec un nom différent ; consultez surveillance synthétique et surveillance des utilisateurs réels pour la comparaison complète. L’avantage de la surveillance synthétique va dans l’autre sens : elle fonctionne avant même que vous ayez un seul visiteur, et elle continue de vérifier à trois heures du matin quand personne ne navigue.
La surveillance de disponibilité, au sens strict et courant, désigne généralement exactement l’une de ces trois formes : la simple vérification HTTP qui interroge une URL et regarde le code de statut et le temps de réponse. La surveillance synthétique est le terme plus large qui couvre aussi la surveillance par navigateur - le parcours scénarisé - et la surveillance d’API synthétique, l’appel jugé par des règles. Une vérification HTTP répond à « le serveur est-il là » ; une vérification de transaction répond à « le parcours à plusieurs étapes se termine-t-il vraiment » ; la surveillance d’API synthétique répond à « la réponse correspond-elle vraiment à son contrat ». Un site peut passer toutes les vérifications HTTP alors que son paiement est cassé, et c’est exactement l’écart que comblent les deux autres.
Non. Les trois types de vérification se construisent dans l’éditeur web. Un scénario de transaction est une liste d’actions - navigate, click, type et ainsi de suite - choisies dans un menu, avec un sélecteur CSS saisi dans un champ. Les règles d’assertion d’un moniteur API tiennent chacune en une ligne de syntaxe simple et lisible, pas un script. Les mots-clés et options d’un moniteur HTTP sont des champs de formulaire. Rien ici n’est un langage de programmation, même si l’ensemble complet des actions et des règles est aussi accessible via l’API si vous voulez automatiser la configuration elle-même.
Jusqu’à dix étapes créées, dans un budget de 40 secondes pour l’exécution complète. Une navigation d’ouverture vers l’URL propre du moniteur est ajoutée automatiquement comme étape zéro, si bien que les dix étapes que vous écrivez sont dix étapes de travail réel - clics, saisies, assertions de contenu - et non neuf plus un chargement de page. Un parcours qui a vraiment besoin de plus de dix étapes gagne généralement à être scindé en deux moniteurs ; cela indique aussi quelle moitié a cassé.
Commencez par une vérification HTTP sur le site lui-même - c’est le signal le moins cher et la base toujours active que tout compte devrait avoir. Ajoutez ensuite celle des deux autres qui correspond à votre risque le plus important : une vérification de transaction si un paiement ou une connexion cassés vous coûtent directement de l’argent, une vérification API si un autre système - votre propre application, l’intégration d’un partenaire - dépend d’un endpoint qui doit répondre correctement. La plupart des comptes qui utilisent les trois exécutent la vérification HTTP le plus souvent, la vérification API ensuite, et la vérification de transaction sur l’intervalle le plus long, puisque c’est la plus coûteuse à exécuter.
Cela dépend du type de vérification, car chacune coûte une quantité de travail différente à exécuter. Les vérifications HTTP peuvent s’exécuter aussi souvent que toutes les minutes sur un plan payant. Les vérifications API s’exécutent d’une minute jusqu’à 24 heures. Les vérifications de transaction - parce que chaque exécution ouvre un vrai navigateur et parcourt un scénario de bout en bout - ont un plancher de 10 minutes. Un schéma courant associe une vérification HTTP d’une minute pour une détection rapide des pannes à une vérification de transaction ou d’API toutes les 10 à 15 minutes pour la question plus approfondie.
L’échec n’est pas pris pour argent comptant dès la première observation. HostTracker relance la vérification depuis d’autres points de contrôle indépendants, et ne confirme le changement d’état que lorsque suffisamment d’entre eux sont d’accord, de sorte qu’un chemin réseau instable ou un nœud lent ne se transforme pas en alerte à lui seul. Une fois confirmé, HostTracker alerte les contacts que vous avez configurés via les canaux choisis - e-mail, SMS, appel vocal, Slack, Telegram, webhook et plus encore - après le délai attribué à chaque contact, et un avis de rétablissement suit dès que la vérification repasse au vert.
Démarrez un essai gratuit et ajoutez une vérification de transaction, d’API ou HTTP au même compte - les mêmes 300+ emplacements et les mêmes alertes derrière les trois.
Fait partie du logiciel de monitoring site web de HostTracker.
