Synthétique ou RUM : ce que chacun détecte
La surveillance synthétique exécute des vérifications scriptées selon un horaire, depuis des emplacements que vous choisissez ; la surveillance des utilisateurs réels enregistre des mesures de temps depuis les navigateurs des personnes qui visitent votre site. Le synthétique vous dit si le site fonctionne, la surveillance des utilisateurs réels vous dit ce que c'était pour les personnes qui étaient là.
Ce que fait chacune
La surveillance synthétique, parfois appelée surveillance active ou proactive, envoie une requête que vous avez définie depuis une machine que vous contrôlez, à un intervalle que vous fixez. Cette requête peut être aussi simple qu'une requête HTTP GET ou aussi élaborée qu'une session de navigateur scriptée qui se connecte, ajoute un article au panier et passe commande. Chaque exécution produit un résultat, que quelqu'un ait visité le site ou non.
La surveillance des utilisateurs réels, souvent abrégée RUM, est passive. Un petit script dans vos pages rapporte ce que le navigateur a mesuré pour cette visite : temps de navigation, chargements de ressources, erreurs, et les Core Web Vitals tels que le visiteur les a vécus. Elle ne produit des données qu'en proportion de votre trafic, et ne produit rien quand personne n'est présent.
Ce que le synthétique détecte et que le RUM manque
- Les pannes à 4 heures du matin, ou sur toute page à faible trafic. Si personne ne charge la page, le RUM n'a rien à rapporter, et une panne totale est précisément le cas où le signal ne peut pas être envoyé
- La disponibilité depuis des endroits où vous n'avez pas encore d'utilisateurs, ce qui est comment vous découvrez qu'un nouveau marché ne peut pas vous atteindre
- Une référence propre. Le même script, depuis le même emplacement, au même intervalle, de sorte qu'un changement dans le chiffre est un changement du site plutôt que de qui a visité par hasard
- Des parcours en plusieurs étapes que vous ne voudriez pas faire subir à de vrais utilisateurs, comme un passage en caisse qui créerait une vraie commande, ou une connexion que vous pouvez exécuter sur un compte de test
- Les échecs d'expiration et de configuration qui n'atteignent jamais un navigateur : certificats, enregistrements DNS, inscriptions sur liste noire, ports ouverts
- La première défaillance après un déploiement, avant que le trafic qui l'aurait révélée n'arrive
Ce que le RUM détecte et que le synthétique manque
- La distribution réelle des appareils, réseaux et emplacements. Une vérification synthétique depuis une connexion de centre de données ne reproduira jamais un téléphone milieu de gamme sur données mobiles
- Les scripts tiers, bandeaux de consentement et personnalisations qui ne se chargent que pour de vraies sessions avec de vrais cookies
- Les problèmes affectant un sous-ensemble d'utilisateurs : une version de navigateur, une région, une variante d'A/B test
- Quelles pages lentes comptent réellement, pondérées par le nombre de personnes qui les voient
- Les Core Web Vitals de terrain, ce que les moteurs de recherche utilisent, par opposition aux valeurs de laboratoire que produit une exécution synthétique
Quand vous avez besoin des deux
Les deux répondent à des questions différentes, donc la séparation est généralement nette. Utilisez le synthétique pour tout ce pour quoi vous alerteriez quelqu'un : la disponibilité, le temps de réponse par rapport à un seuil, l'expiration des certificats et des domaines, et les parcours critiques qui vous font gagner de l'argent. Ces éléments doivent être vrais à 4 heures du matin avec un trafic nul, et ils ont besoin d'une référence stable pour déclencher une alerte.
Utilisez le RUM pour décider quoi corriger. Quand une page est lente pour certaines personnes, le RUM vous dit lesquelles et combien, ce qui est l'information dont a besoin un argument de priorisation et qu'une vérification synthétique ne peut pas fournir.
Une configuration pratique consiste à faire piloter les alertes et le relevé de disponibilité par les vérifications synthétiques, et le carnet de performance par le RUM. Si vous ne pouvez en exécuter qu'une seule, choisissez le synthétique : une panne non surveillée coûte plus cher qu'une page lente non mesurée, et le RUM ne peut rien rapporter sur une page qui n'a pas réussi à se charger.
Où se situe la vérification de transaction
Une vérification de transaction est la surveillance synthétique dans sa forme la plus détaillée : un script de navigateur enregistré qui parcourt un vrai parcours utilisateur étape par étape et échoue sur l'étape qui a cassé, plutôt que sur le site dans son ensemble. Elle détecte la classe de défaillance qu'une simple vérification de disponibilité signale comme saine, où la page d'accueil renvoie 200 alors que le formulaire de connexion derrière elle est cassé.
Comme elle est synthétique, elle s'exécute selon un horaire sans nécessiter de trafic, et comme elle pilote un vrai navigateur, elle exerce le JavaScript, les dépendances tierces et les redirections qu'une simple vérification HTTP ignore. La surveillance de transaction de HostTracker fonctionne ainsi, et le guide de la vérification de transaction explique comment un script est enregistré et ce que chaque étape rapporte.
Transformer une mesure en alerte
Aucune des deux approches n'est utile tant que rien n'agit sur le résultat. Une vérification synthétique vaut la peine d'être mise en place parce qu'elle s'exécute que vous surveilliez ou non, et parce qu'une défaillance peut vous atteindre immédiatement : HostTracker exécute ses vérifications depuis plus de 300 points de contrôle répartis dans 158 villes, sur 13 types de moniteurs, et envoie des alertes par e-mail, SMS, appel vocal, Slack, Telegram et bien d'autres canaux quand un résultat change. Associez cela au RUM que vous collectez déjà et vous avez les deux moitiés : une alerte quand le site casse, et des preuves sur qui a subi la lenteur. Le reste de la section des concepts de surveillance couvre les termes sur lesquels ces deux approches reposent.