1. Comprendre le Synthetic Monitoring
Le concept de base du monitoring synthétique et sa place dans l'observabilité globale.
Qu'est-ce que le Synthetic Monitoring ?
Le Synthetic Monitoring (ou surveillance synthétique) consiste à utiliser des robots automatisés pour interagir avec vos applications de la même manière qu'un véritable utilisateur. Exécuté à une fréquence régulière (par exemple toutes les 5 minutes), il permet de s'assurer de la disponibilité et des performances de vos services 24h/24 et 7j/7, même lorsqu'il n'y a aucun trafic réel. C'est un outil proactif idéal pour détecter une panne avant que vos clients ne s'en aperçoivent.
Robots vs Synthetic vs Utilisateurs réels (RUM)
Dans le monde du Digital Experience Monitoring (DEM) de Dynatrace, il est crucial de différencier ces trois notions :
- Real Users (RUM) : Ce sont vos vrais visiteurs. La donnée dépend entièrement du trafic réel. S'il n'y a personne sur le site à 3h du matin, vous n'avez pas de données de performance.
- Synthetic : Ce sont vos propres scénarios automatisés (des robots "amis" et contrôlés). Ils fournissent une ligne de base constante (baseline) pour mesurer la performance dans un environnement prévisible.
- Robots / Bots : Ce sont des crawlers externes (ex: Googlebot, scripts malveillants) qui parcourent votre site. Dynatrace sait les détecter pour ne pas polluer vos statistiques RUM.
2. Les types de scénarios (Moniteurs)
Dynatrace propose plusieurs façons de tester vos applications, selon la profondeur d'analyse souhaitée.
HTTP
Très léger, le HTTP Monitor exécute de simples requêtes HTTP/HTTPS (GET, POST, etc.) sans charger de moteur de rendu visuel. Il est parfait pour vérifier la disponibilité d'une API REST, surveiller le temps de réponse d'un point d'accès backend, ou encore s'assurer de la validité d'un certificat SSL.
Browser
Le Browser Monitor lance un véritable navigateur web (comme Chrome ou Edge) en arrière-plan. Il charge la page entière, exécute le JavaScript, rend le CSS et simule un parcours utilisateur complet (clickpath). Bien que plus lourd, il est indispensable pour vérifier l'expérience visuelle, les Web Vitals et les interactions frontend (ex: ajout au panier, processus de paiement).
Network Availability
Ce type de moniteur se concentre sur la couche réseau. Le moniteur Network Availability (disponibilité réseau) exécute des tests de connectivité de base (comme des requêtes TCP ou ICMP Ping) pour s'assurer qu'un serveur ou un point de terminaison est joignable sur le réseau, indépendamment de la couche applicative. Cela permet de distinguer rapidement une panne applicative d'une panne d'infrastructure ou de routage.
3. Les localisations (Locations)
Le choix de l'origine géographique d'où vos tests sont exécutés est fondamental pour identifier les problèmes de réseau ou de CDN.
Localisations publiques vs privées
Lors de la création d'un moniteur, Dynatrace vous demande d'assigner des Locations :
- Localisations Publiques : Principalement fournies par Dynatrace et hébergées sur AWS, Azure ou GCP aux quatre coins du monde. Utiles pour tester votre site public comme le ferait un client international. Mais vous pouvez aussi déployer vos propres ActiveGates publiques si vous ne souhaitez pas utiliser (louer) ceux de Dynatrace.
- Localisations Privées (Private Locations) : Basées sur un ActiveGate installé dans votre propre infrastructure. Indispensables pour surveiller vos applications internes ou intranets qui ne sont pas exposés sur Internet, ou pour exécuter des scripts personnalisés complexes.
Note d'accessibilité réseau : Quel que soit le type de localisation choisi (publique ou privée), l'ActiveGate chargé d'exécuter le scénario doit impérativement avoir un accès réseau direct aux points de terminaison (endpoints) à tester. Pensez à bien configurer vos règles de pare-feu et de Proxy!
4. Création avec l'extension de navigateur
Comment créer facilement des scénarios complexes sans coder.
Le Dynatrace Synthetic Recorder
Créer un Browser Monitor de 20 étapes manuellement serait très chronophage. Dynatrace met à disposition une extension pour Chrome et Edge appelée Dynatrace Synthetic Recorder.
Une fois l'extension activée dans votre navigateur, il vous suffit de naviguer sur votre site web normalement. L'extension enregistre automatiquement chaque clic, saisie de texte, changement d'onglet et navigation. Une fois terminé, le scénario est généré et uploadé directement dans votre console Dynatrace, où vous pourrez ajuster les sélecteurs CSS ou ajouter des validations (assertions).
5. Comprendre la facturation du Synthetic
Le Synthetic Monitoring n'est pas gratuit ; il est important de comprendre son modèle de facturation pour optimiser les coûts.
Consommation des unités DEM
La facturation s'effectue via vos unités DEM (Digital Experience Monitoring) en fonction des Synthetic actions (actions synthétiques).
La quantité d'unités DEM dont vous avez besoin dépend du nombre de moniteurs synthétiques que vous souhaitez exécuter et du nombre de sessions utilisateurs que vous devez surveiller. Le tableau ci-dessous explique le taux de consommation des unités DEM par type de capacité et par unité de mesure.
| Unité de mesure | Capacité (Capability) | Consommation (Unités DEM) |
|---|---|---|
| Action synthétique (Synthetic action) | Browser monitors, browser clickpaths | 1.0 DEM |
| Requête synthétique (Synthetic request) | HTTP monitor | 0.1 DEM |
| Session utilisateur par application | Real User Monitoring (sans Session Replay) | 0.25 DEM |
| Session utilisateur par application | Real User Monitoring (avec Session Replay) | 1.0 DEM |
| Propriété de session (Session property) | Real User Monitoring | 0.01 DEM |
| Propriété d'action (Action property) | Real User Monitoring | 0.01 DEM |
| Résultat synthétique tiers | Ingestion d'API synthétique tierce | 0.1 DEM |
HTTP Monitor : Une exécution (même avec plusieurs requêtes chaînées basiques) consomme généralement 1 action synthétique.
Browser Monitor : La facturation est proportionnelle à la complexité. Chaque interaction (chargement de page, clic, saisie) au sein d'un scénario compte pour 1 action synthétique. Si votre parcours comporte 10 actions, exécuté depuis 2 localisations toutes les 5 minutes, cela consommera un grand nombre d'unités DEM sur le mois. Optimisez vos scénarios pour ne tester que l'essentiel !
Calcul de la consommation
Le calcul suivant vous donne une estimation de la consommation maximale possible, en supposant que toutes les actions/requêtes synthétiques ont été exécutées avec succès. La consommation réelle peut varier si certaines actions/requêtes échouent et que les étapes suivantes ne sont pas exécutées.
Actions/requêtes consommées = (Nombre d'actions/requêtes dans le moniteur) × (Nombre d'exécutions par heure) × (Nombre de localisations) × (Nombre d'heures)Voici quelques exemples pour un mois de 30 jours (720 heures) :
- HTTP Monitor basique (1 requête) : Exécuté toutes les 5 minutes (12 fois/heure) depuis 2 localisations.
Calcul : 1 requête × 12 exécutions/heure × 2 localisations × 720 heures = 17 280 requêtes.
Coût en DEM : 17 280 × 0.1 DEM = 1 728 DEM. - Browser Monitor (10 actions) : Exécuté toutes les 15 minutes (4 fois/heure) depuis 3 localisations.
Calcul : 10 actions × 4 exécutions/heure × 3 localisations × 720 heures = 86 400 actions.
Coût en DEM : 86 400 × 1.0 DEM = 86 400 DEM.
6. Cas avancé : Upload de fichiers et scripts sur ActiveGate
Comment gérer le téléversement (upload) de pièces jointes dans un scénario automatisé.
Le défi des pièces jointes
Tester un formulaire qui demande une pièce jointe (ex: envoi d'un CV ou d'une facture) dans un Browser Monitor est complexe, car le navigateur robotisé n'a pas un accès libre à un système de fichiers local aléatoire pour des raisons de sécurité.
La solution via Private ActiveGate et Scripts JavaScript
Pour contourner ce problème, vous devez impérativement utiliser une Localisation Privée hébergée sur un ActiveGate que vous contrôlez.
- Préparation de l'ActiveGate : Déposez physiquement le fichier de test (ex:
fileuploadtest.txt) dans un répertoire sécurisé du serveur hébergeant l'ActiveGate (ex:/tmp/synthetic/). - Interaction standard : Dans l'éditeur de votre Browser Monitor, ajoutez une étape de type Keystrokes (Saisie). Ciblez votre champ
<input type="file">et envoyez-lui le chemin absolu du fichier (ex:/tmp/synthetic/fileuploadtest.txt). - Utilisation de scripts (JavaScript event) : Si le framework front-end (ex: React, Angular) bloque la saisie directe, vous pouvez injecter un événement JavaScript (JavaScript event) lors de la création du scénario pour simuler l'objet
Fileet déclencher manuellement l'événementchangesur l'élément du DOM.
Cette approche garantit que le robot de test trouvera toujours le fichier nécessaire lors de son exécution locale.
Script de simulation d'upload (JavaScript event)
Dans les situations où vous ne pouvez pas déposer physiquement de fichiers locaux sur l'ActiveGate (par exemple, lors de l'utilisation de localisations publiques ou par manque de droits sur le système de fichiers), la méthode native par saisie de chemin est impossible. Pour contourner cette limitation, vous pouvez injecter un script JavaScript avancé directement dans votre scénario.
Vous pouvez utiliser ce script prêt à l'emploi en l'ajoutant comme étape JavaScript event dans votre Browser Monitor : Script de simulation d'upload de fichier (Gist).
Ce script crée programmatiquement un objet File entièrement en mémoire (avec un contenu et un nom simulés), puis l'associe à l'élément <input type=\"file\"> ciblé et déclenche les événements nécessaires (comme change) pour simuler la sélection d'un fichier par l'utilisateur, sans jamais avoir besoin d'un vrai fichier sur le disque de l'ActiveGate.
7. Cas avancé : Sécurité et Credential Vault
Comment gérer et sécuriser les mots de passe utilisés dans vos scénarios de test synthétique.
Le problème des mots de passe en clair
Lors de la création de scénarios complexes nécessitant une authentification (comme se connecter à un portail client pour vérifier le contenu), il est courant mais dangereux d'inscrire les mots de passe en dur (hardcoding) dans les étapes du Browser Monitor ou du HTTP Monitor. Cela expose vos identifiants à toute personne ayant accès à la configuration ou à la modification du scénario.
La solution : Credential Vault
Pour remédier à cela, Dynatrace intègre l'application Credential Vault (Coffre-fort d'identifiants). Cet outil centralise et chiffre vos secrets. Dans votre scénario de test, au lieu de saisir manuellement le mot de passe, vous référencez simplement l'identifiant stocké dans le Credential Vault. Le robot récupérera le mot de passe à la volée lors de l'exécution, sans jamais l'exposer dans l'interface.
👉 Pour en savoir plus sur cette application, sa synchronisation avec des outils externes (CyberArk, Azure Key Vault, Hashicorp Vault) et la gestion des droits associés, consultez l'article dédié au Credential Vault.