La surveillance synthétique est une pratique de surveillance proactive qui exécute des vérifications scriptées programmées à partir d’un réseau de lieux globaux pour simuler des parcours utilisateurs et des appels API. En exécutant des tests contrôlés contre des sites web, des applications et des API, elle vérifie la disponibilité, la performance et la correction fonctionnelle, fournissant un signal cohérent de la santé du système indépendamment du trafic utilisateur en direct. Au lieu d’attendre que les utilisateurs signalent un problème, les équipes utilisent des tests automatisés pour simuler des demandes importantes et des parcours utilisateurs tels que le chargement de pages, les connexions, les recherches, les soumissions de formulaires et les flux de paiement.
Parce que ces vérifications s’exécutent selon un calendrier, la surveillance synthétique peut détecter des problèmes même lorsque le trafic est faible ou absent. Elle est couramment utilisée pour identifier les pannes, les régressions de latence, les éléments de page cassés, les transactions échouées, les problèmes de routage régional, les problèmes SSL et les erreurs API avant qu’elles ne deviennent visibles par le biais de plaintes des clients.
La surveillance synthétique est particulièrement utile lorsque vous devez valider proactivement des parcours utilisateurs critiques, mesurer la disponibilité depuis des emplacements externes et détecter des régressions même lorsque le trafic est faible. Elle complète RUM, APM, les journaux et la surveillance de l’infrastructure en fournissant des vérifications contrôlées et répétables qui mesurent ce que les utilisateurs expérimenteraient de l’extérieur de votre infrastructure.
Comment fonctionne la surveillance synthétique ?
La surveillance synthétique fonctionne en définissant des vérifications importantes, en les exécutant depuis des emplacements sélectionnés, en mesurant chaque résultat et en alertant lorsqu’un seuil ou une condition fonctionnelle est violé.
1. Identifier les points de terminaison et les parcours critiques
Commencez par les flux qui importent le plus pour les utilisateurs et l’entreprise. Dans la plupart des environnements, cela inclut la disponibilité de la page d’accueil, la connexion, la recherche, le paiement, l’accès au compte et les API publiques clés.
Les meilleures premières vérifications sont celles directement liées à l’impact sur le client. Si un échec entraînerait une augmentation des demandes de support, une perte de revenus ou une interruption de service visible, cela devrait être en haut de la liste de surveillance.
2. Construire le bon type de test synthétique
Différents cas d’utilisation nécessitent différents types de tests.
- Les vérifications de disponibilité légères valident la connectivité de base et la réactivité.
- Les vérifications basées sur le navigateur valident le rendu, l’interactivité et le comportement des flux de travail dans un véritable navigateur.
- Les vérifications API valident le comportement des points de terminaison, la latence, les charges utiles, les en-têtes, l’authentification et la logique de réponse.
- Les vérifications de transaction valident les processus commerciaux multi-étapes de bout en bout.
Dotcom-Monitor soutient cette approche en couches avec la surveillance de la disponibilité, la surveillance par navigateur réel surveillance des applications web, surveillance des transactions web, et surveillance des API. Son enregistreur EveryStep est conçu pour capturer des interactions de navigateur réalistes telles que des clics, des saisies de formulaires, de la navigation et de l’authentification, puis exécuter ces scripts selon un calendrier depuis des emplacements globaux.
3. Exécuter des tests selon un calendrier depuis des emplacements sélectionnés
La plateforme de surveillance exécute des tests à des intervalles définis depuis des points de contrôle configurés. Dotcom-Monitor déclare qu’il exécute des vérifications depuis plus de 30 emplacements globaux, ce qui aide les équipes à comparer les performances entre les régions et à identifier les échecs localisés.
Un modèle de départ pratique ressemble à ceci :
- Vérifications de disponibilité ou de temps de fonctionnement légères : toutes les 1 à 5 minutes
- Vérifications d’API publiques pour les points de terminaison critiques : toutes les 1 à 5 minutes
- Vérifications de navigateur et de transaction pour les parcours utilisateurs à forte valeur : toutes les 5 à 15 minutes
- Flux de travail plus lourds ou à risque plus faible : moins fréquemment, en fonction de l’impact et de la valeur opérationnelle
La configuration EveryStep de Dotcom-Monitor prend en charge des fréquences de vérification de 1 à 60 minutes, ce qui donne aux équipes la possibilité d’ajuster des vérifications plus rapides pour les chemins critiques et des cadences plus lentes pour des flux de navigateur plus coûteux.
4. Mesurer les résultats techniques et fonctionnels
Chaque exécution de test peut produire des données telles que le statut de disponibilité, le statut HTTP, TTFB, le temps de chargement de la page, le timing DOM, la durée des étapes, la latence API, les résultats des assertions, le succès ou l’échec des transactions, la validité SSL et des diagnostics de soutien.
Un programme synthétique utile fait plus que confirmer qu’une demande a renvoyé une réponse. Il vérifie également si la réponse était correcte. Par exemple, une vérification API réussie peut nécessiter le code de statut attendu, un résultat d’authentification valide, des champs de réponse spécifiques, des en-têtes corrects, des assertions de contenu correspondantes ou une séquence réussie de demandes dépendantes. Les conseils de surveillance API et navigateur de Dotcom-Monitor mettent l’accent sur les assertions, la validation de contenu et le succès des flux de travail, et pas seulement sur la disponibilité seule.
5. Alerter sur des échecs significatifs
Si un test échoue, dépasse un seuil ou viole une assertion, la plateforme envoie une alerte afin que les intervenants puissent enquêter.
Une bonne règle est de ne page que sur des problèmes confirmés comme ayant un impact sur l’utilisateur et persistants. Par exemple, configurez une alerte de haute priorité pour se déclencher uniquement après qu’une vérification a échoué pendant trois exécutions consécutives ou a été confirmée depuis au moins deux emplacements de surveillance différents. Pour des dégradations comme un ralentissement régional qui ne franchit pas un seuil de défaillance, ouvrez automatiquement un ticket de priorité inférieure pour enquête.
Les conditions dignes d’alerte incluent souvent :
- Échecs répétés sur plusieurs exécutions
- Échecs confirmés depuis plusieurs emplacements
- Échecs critiques lors de la connexion, du paiement, de l’accès au compte ou des API clés
- Problèmes de validité des certificats SSL proches de l’expiration
- Grandes régressions de latence sur des points de terminaison à haute priorité
- Échecs de transaction complets où l’action commerciale ne peut pas être complétée
Les conditions dignes de ticket incluent souvent :
- Régressions de performance modérées mais soutenues
- Un ralentissement régional non critique
- Une étape de transaction qui est plus lente que prévu mais réussit toujours
- Problèmes de maintenance de script qui ne reflètent pas un incident orienté client
- Changements dans le contenu, les sélecteurs ou les assertions qui nécessitent des mises à jour de test
4 Types de tests synthétiques courants
1. Surveillance de la disponibilité et du temps de fonctionnement
La surveillance de la disponibilité utilise des tests légers pour confirmer qu’un service est accessible et répond comme prévu. En pratique, cela signifie généralement vérifier si une URL, un hôte ou un point de terminaison répond dans un seuil et renvoie le statut ou le contenu attendu.
Ce type de surveillance est utile pour confirmer la disponibilité de base, mais il ne prouve pas qu’un flux de travail utilisateur complet est sain. Une page d’accueil peut renvoyer 200 OK tandis que la connexion, le paiement ou une API en aval est cassée. Pour résoudre cela, les équipes utilisent la surveillance des transactions pour valider l’ensemble du parcours utilisateur. Alors que les vérifications de disponibilité de base confirment la connectivité, la surveillance des transactions confirme qu’un processus multi-étapes comme le paiement est fonctionnellement correct de bout en bout.
2. Surveillance par navigateur
La surveillance synthétique par navigateur exécute des actions scriptées dans un environnement de navigateur contrôlé pour tester comment une application web se comporte lors d’interactions utilisateur réalistes. Elle est utilisée pour valider le rendu, les clics, la navigation, le contenu dynamique, la soumission de formulaires et le comportement de page de bout en bout. Par exemple, un test par navigateur réel pour une page de connexion :
- Assertion : Vérifiez la connexion réussie et la redirection correcte de la page.
- Échec : Si la connexion échoue ou si la page ne se charge pas en 5 secondes, créez une alerte de haute priorité.
Dotcom-Monitor met l’accent sur la surveillance par navigateur réel pour un rendu précis et une validation des flux de travail, en particulier pour les applications dynamiques et les sites à forte transaction.
3. Surveillance des transactions
La surveillance des transactions valide les flux de travail commerciaux multi-étapes tels que la connexion, la recherche, l’accès au compte, la réservation ou le paiement. Cela est important car de nombreux échecs visibles par l’utilisateur se produisent après que la première demande de page a réussi. La surveillance des transactions de Dotcom-Monitor se concentre sur la capacité des utilisateurs à compléter réellement des actions critiques dans des flux de travail par navigateur réel et inclut des diagnostics tels que la capture vidéo et l’analyse en cascade pour montrer où la transaction a échoué. Exemple d’Assertion clé :
- Affirmez que l’article ajouté au panier est visible et que la page de paiement se charge avec le bon prix.
- Affirmez que la confirmation de paiement est réussie et que l’utilisateur atteint une page de confirmation.
4. Surveillance des API
La surveillance synthétique des API valide si les interfaces de programmation d’applications sont disponibles, suffisamment rapides et renvoient les sorties attendues. Une surveillance API solide vérifie plus que la disponibilité seule. Elle vérifie les codes de statut, la structure des charges utiles, les en-têtes, les jetons, le comportement d’authentification et la logique de demande en chaîne si nécessaire. Par exemple, lors de la surveillance d’une API REST pour la recherche de produits :
- Assertion : Confirmez que la réponse 200 OK est renvoyée avec une charge utile JSON valide contenant tous les champs de produit attendus (nom, prix, disponibilité).
Dotcom-Monitor décrit sa surveillance API en termes de disponibilité, de performance, de diagnostics au niveau des transactions, de surveillance authentifiée et de validation basée sur des assertions.
Surveillance synthétique vs. Surveillance de la disponibilité
La surveillance de la disponibilité est un sous-ensemble de la surveillance synthétique. Elle se concentre sur la validation de la connectivité de base et de la réponse, comme savoir si une page, un hôte ou un point de terminaison est disponible et répond dans un seuil acceptable.
La surveillance synthétique est plus large. Elle inclut des vérifications de disponibilité, mais elle couvre également des tests de navigateur, des assertions API et une surveillance des transactions multi-étapes. En d’autres termes, la surveillance de la disponibilité vous dit si un service semble être opérationnel. La surveillance synthétique vous dit si un parcours utilisateur critique ou un flux de travail API fonctionne réellement.
Cette distinction est importante en production. Un site peut être accessible tandis que la connexion échoue, le paiement se casse ou une API renvoie des données invalides. C’est pourquoi de nombreuses équipes utilisent la surveillance de la disponibilité pour une détection rapide et des vérifications de navigateur ou de transaction pour une vérification plus approfondie.
Surveillance synthétique vs. Surveillance des utilisateurs réels
La surveillance synthétique et la surveillance des utilisateurs réels répondent à des questions différentes.
La surveillance synthétique demande si les parcours utilisateurs et les points de terminaison prédéfinis fonctionnent correctement maintenant dans des conditions de test contrôlées. Elle est active, programmée et répétable. Elle fonctionne même lorsqu’il n’y a pas de trafic en direct.
La surveillance des utilisateurs réels mesure ce que les visiteurs réels expérimentent en production. Elle reflète de véritables navigateurs, appareils, réseaux et comportements des utilisateurs, mais uniquement lorsque les utilisateurs génèrent activement du trafic.
Une façon simple de séparer les deux est la suivante :
- La surveillance synthétique répond à la question : “Les utilisateurs peuvent-ils compléter ce parcours critique maintenant ?”
- La surveillance des utilisateurs réels répond à la question : “Comment les utilisateurs réels expérimentent-ils réellement l’application au fil du temps ?”
Pour les équipes de production, la surveillance synthétique est souvent le premier système à détecter une régression après une mise à jour ou un changement de dépendance car elle n’a pas besoin d’attendre un trafic organique pour exposer le problème.
Surveillance synthétique vs. APM et Observabilité
La surveillance des performances des applications et des outils d’observabilité plus larges aident les équipes à comprendre ce qui se passe à l’intérieur d’une application et de son infrastructure. Ils sont utiles pour tracer des demandes, analyser des journaux, mesurer la latence des services et corréler le comportement backend lors d’incidents.
La surveillance synthétique répond à une question différente. Elle montre si un utilisateur ou un consommateur d’API peut accéder avec succès et compléter un flux depuis l’extérieur du système.
En pratique, ces outils fonctionnent mieux ensemble :
- La surveillance synthétique détecte les échecs visibles par l’utilisateur depuis un point de vue externe.
- APM aide à isoler les services lents, les dépendances échouées ou les goulets d’étranglement au niveau du code.
- Les journaux fournissent un contexte détaillé des événements lors de l’enquête.
- Les métriques et les traces aident à expliquer pourquoi un échec s’est produit et à quelle échelle il s’est propagé.
La surveillance synthétique est souvent le moyen le plus rapide de détecter un problème visible par l’utilisateur. Les outils d’observabilité sont souvent le moyen le plus rapide de l’expliquer.
Que signifie la surveillance de l’extérieur vers l’intérieur ?
La surveillance de l’extérieur vers l’intérieur signifie tester des services numériques du point de vue d’un utilisateur externe, d’un navigateur ou d’un consommateur d’API plutôt que seulement de l’intérieur de la pile d’application.
Cela est important car la télémétrie interne peut montrer que l’infrastructure est saine tandis que les utilisateurs rencontrent encore des échecs. Une redirection d’authentification peut échouer, un actif CDN peut ne pas se charger, un fournisseur DNS peut échouer dans une région, ou une API tierce peut expirer. Ce sont tous des problèmes visibles par l’utilisateur que les vérifications de santé internes seules peuvent manquer.
Dotcom-Monitor utilise la surveillance de l’extérieur vers l’intérieur à travers des sites web, des applications et des API pour valider la disponibilité réelle et le comportement des transactions depuis des points de contrôle globaux.
Quelles métriques clés de surveillance synthétique suivre ?
Les métriques synthétiques les plus utiles dépendent du type de vérification, mais les équipes techniques suivent couramment :
- Disponibilité et taux de réussite
- Statut HTTP et fréquence des erreurs
- TTFB et temps de réponse total
- Temps de chargement de la page et timing DOM
- Durée des transactions au niveau des étapes
- Latence API
- Taux de réussite ou d’échec des assertions
- Validité et fenêtre d’expiration des certificats SSL
- Variance de performance régionale
- Taux d’achèvement des transactions
Ces métriques sont les plus utiles lorsqu’elles sont liées à des parcours utilisateurs spécifiques et à l’impact commercial. Une tendance de temps de réponse générique est moins exploitable que de savoir que le taux de réussite de connexion a chuté dans une région après un déploiement.
Pourquoi les équipes utilisent-elles la surveillance synthétique ?
Les équipes utilisent la surveillance synthétique pour détecter les pannes, les régressions de latence et les flux de travail cassés avant que les utilisateurs ne les remarquent. Elle est particulièrement précieuse pour les chemins critiques tels que l’authentification, la recherche, le paiement, l’accès au compte et les API publiques.
En pratique, les équipes d’ingénierie utilisent la surveillance synthétique pour :
- Valider les parcours utilisateurs clés après les déploiements
- Détecter les échecs de tiers avant que le volume de support n’augmente
- Confirmer que les SLA et SLO orientés client sont respectés depuis un point de vue externe
- Détecter les régressions en production pendant les périodes de faible trafic
- Vérifier qu’un correctif a réellement résolu un incident visible par l’utilisateur
Par exemple, après un déploiement, une équipe peut exécuter des vérifications basées sur le navigateur contre la connexion, la recherche et le paiement depuis des points de contrôle externes pour confirmer que le déploiement n’a pas cassé un flux orienté client. Les métriques internes de l’infrastructure peuvent sembler saines tandis qu’une transaction de l’extérieur vers l’intérieur échoue toujours à cause d’erreurs JavaScript, d’actifs CDN obsolètes, de redirections cassées, de problèmes d’authentification ou d’échecs de dépendances tierces.
Cas d’utilisation réels par des équipes d’entreprise
Équipes SRE et plateforme
Les équipes SRE et plateforme utilisent la surveillance synthétique pour valider les SLI visibles par l’utilisateur, détecter rapidement les échecs externes et confirmer que les atténuations ou les retours en arrière ont restauré le service.
Équipes d’ingénierie des applications
Les équipes d’application l’utilisent pour vérifier que les déploiements n’ont pas cassé les flux de connexion, de recherche, de paiement ou de gestion de compte et pour détecter les régressions frontend que les métriques de service internes peuvent ne pas faire remonter.
Équipes API et backend
Les équipes API l’utilisent pour valider les points de terminaison publics, l’authentification, l’intégrité des charges utiles et la santé des dépendances depuis une perspective externe.
Équipes de commerce électronique et d’expérience numérique
Ces équipes l’utilisent pour protéger les chemins de conversion, valider les flux de paiement et détecter les problèmes de script ou de paiement tiers avant qu’ils n’affectent les revenus à grande échelle.
Que détecte la surveillance synthétique en production ?
La surveillance synthétique est la plus utile lorsque l’échec est visible de l’extérieur mais facile à manquer de l’intérieur de la pile.
Elle est particulièrement efficace pour détecter :
- Certificats SSL expirés ou mal configurés
- Échecs DNS et problèmes de résolution de domaine
- JavaScript cassé qui empêche une page ou un bouton de fonctionner
- Échecs de connexion causés par des erreurs d’authentification ou de redirection
- Échecs de paiement et de soumission de formulaires
- Scripts et API tiers dégradés ou échoués
- Problèmes de latence ou de routage spécifiques à une région
- Incohérences de contenu et logique de réponse API incorrecte
- Rendu de page lent ou régressions au niveau des étapes après un déploiement
Les documents publiés par Dotcom-Monitor mettent l’accent sur ces modes de défaillance de l’extérieur vers l’intérieur grâce à la surveillance SSL, aux vérifications multi-localisation, à l’exécution par navigateur réel, à la validation API basée sur des assertions et à des diagnostics tels que des captures d’écran, des vidéos et des graphiques en cascade.
Défis courants de la surveillance synthétique et comment réduire le bruit des alertes ?
Même un programme de surveillance synthétique solide nécessite de la maintenance et une discipline opérationnelle.
Maintenance des scripts
Les interfaces utilisateur changent. Les sélecteurs se cassent. Les flux d’authentification évoluent. Le contenu tiers change de comportement. À mesure que les applications changent, les scripts synthétiques doivent être mis à jour pour continuer à refléter les flux de travail réels.
Bruit des alertes et oscillations
Une stratégie de surveillance mal réglée peut générer des alertes bruyantes en raison de conditions réseau transitoires, de scripts fragiles ou de seuils trop agressifs. Une bonne logique de reprise, des politiques d’alerte sensées et un design de script soigné réduisent les faux positifs.
Gaps de couverture
La surveillance synthétique ne valide que ce que vous choisissez de tester. Si un chemin commercial important est manquant de votre ensemble de surveillance, un échec dans ce chemin peut passer inaperçu.
Échelle et propriété
À mesure que les équipes ajoutent plus de régions, d’API, de parcours utilisateurs et d’environnements, la surveillance peut devenir difficile à gouverner. Une nomenclature standard, une propriété, une politique d’escalade et une discipline de tableau de bord deviennent importantes à mesure que la couverture s’élargit.
Pour réduire le bruit des alertes en pratique :
- Commencez par un petit ensemble de vérifications à forte valeur
- Exigez des échecs répétés avant de page
- Utilisez la confirmation multi-localisation pour les alertes ayant un impact sur l’utilisateur
- Séparez les conditions de ticket des conditions de page
- Ajustez les seuils en fonction de l’impact commercial, pas des benchmarks idéaux
- Examinez les scripts après des changements d’UI, d’auth ou de dépendance
Meilleures pratiques de surveillance synthétique
Commencez par un petit ensemble de vérifications à forte valeur
Commencez par trois à cinq vérifications critiques pour l’entreprise, telles que la disponibilité de la page d’accueil, la connexion, la recherche, le paiement et votre API publique la plus importante.
Utilisez une surveillance en couches
Ne vous fiez pas à un seul type de vérification. Combinez la surveillance de disponibilité légère pour la connectivité avec des vérifications de navigateur et de transaction pour la fonctionnalité réelle, plus la surveillance API pour la correction backend.
Validez les résultats commerciaux, pas seulement les réponses
Un service qui répond n’est pas la même chose qu’un service qui fonctionne correctement. Utilisez des assertions et une validation de contenu lorsque cela est possible afin que le test vérifie le comportement attendu, et pas seulement un code de statut renvoyé.
Surveillez depuis les emplacements qui comptent pour vos utilisateurs
Les tests régionaux sont les plus importants lorsqu’ils correspondent à votre base d’utilisateurs. La surveillance mondiale est la plus utile lorsque la sélection des points de contrôle reflète les géographies qui affectent réellement votre entreprise.
Définissez des intervalles et des seuils de manière intentionnelle
Des vérifications rapides et à fort impact méritent généralement des intervalles plus serrés et des seuils de page plus clairs. Les transactions plus lourdes et à risque plus faible fonctionnent souvent mieux avec des horaires moins agressifs et plus de contexte diagnostique.
Corrélez les échecs synthétiques avec la télémétrie interne
Lorsqu’une vérification synthétique échoue, les intervenants doivent comparer cet échec avec des journaux, des traces, des métriques, des événements de déploiement et des tableaux de bord de dépendance. La surveillance synthétique vous dit que les utilisateurs sont affectés de l’extérieur. La télémétrie interne aide à expliquer pourquoi.
Gardez les scripts maintenables
Commencez par un petit nombre de flux à forte valeur. Évitez de tester chaque détail de l’UI dans un seul script. Validez les points de complétion clés, examinez les scripts après des changements d’UI et d’authentification, et utilisez la confirmation multi-localisation avant de page.
Capacités de surveillance synthétique de Dotcom-Monitor
Dotcom-Monitor fournit une surveillance synthétique pour les sites web, les applications web, les API et les parcours utilisateurs multi-étapes en utilisant des tests par navigateur réel et un réseau de surveillance global. Ses capacités publiées incluent :
- Surveillance de la disponibilité pour la validation de la disponibilité et de la réponse
- Surveillance par navigateur réel pour les applications dynamiques
- Surveillance des transactions web pour les flux de connexion, de formulaire et de paiement
- Surveillance des API avec des demandes authentifiées et des assertions
- Surveillance depuis plus de 30 emplacements globaux
- Diagnostics tels que l’analyse en cascade, les captures d’écran, la capture vidéo et les rapports
- Surveillance des certificats SSL et rapports SLA
Pour les équipes techniques, la valeur ne réside pas seulement dans le fait de savoir si un service est accessible. Il s’agit de savoir s’il est utilisable, performant et fonctionnellement correct de l’extérieur.
