Dynatrace Synthetic Monitoring : Guide complet et bonnes pratiques

Publié le : 20/11/2024 à 09:00 Vues : 556

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.

En-têtes par défaut (Default Headers)

Lorsqu'un moniteur synthétique exécute une requête, Dynatrace ajoute automatiquement un ensemble d'en-têtes HTTP par défaut pour garantir la compatibilité et l'identification du trafic :

Nom	Valeur
Accept	*/*
Connection	close
Host	<hostname>
User-Agent	DynatraceSynthetic/{version}

Même si vous définissez un User-Agent personnalisé, Dynatrace ajoute systématiquement la chaîne DynatraceSynthetic/{version} (où {version} est la version actuelle du moteur synthétique) pour s'assurer que le trafic peut être identifié. Dynatrace crée également les en-têtes x-Dynatrace-Tenant et x-Dynatrace-Test à des fins administratives internes.

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.

1. 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/).
2. 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).
3. 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 File et déclencher manuellement l'événement change sur 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.

Utilisation manuelle via variables (Header et Body)

Dans les champs où vous pouvez insérer manuellement une référence à un identifiant (comme les valeurs d'en-têtes HTTP ou le corps d'une requête), vous pouvez copier l'ID du credential depuis le vault et utiliser le format suivant selon le type de secret :

• {<credential ID>|token} : Utilisé pour insérer un jeton d'authentification.
• {<credential ID>|username} : Utilisé pour insérer un nom d'utilisateur stocké dans le Credential Vault.
• {<credential ID>|password} : Utilisé pour insérer un mot de passe associé au nom d'utilisateur.

Note importante : Vous ne pouvez copier et utiliser que les identifiants pour lesquels vous possédez des droits d'accès.

8. Scripts de pré et post-exécution (HTTP Monitors)

Automatisez des logiques complexes et le chaînage de requêtes grâce au JavaScript.

Étendre les capacités des requêtes HTTP

Pour les HTTP Monitors, Dynatrace permet d'exécuter du code JavaScript avant (Pre-execution) ou après (Post-execution) chaque étape. Cela permet de gérer des scénarios où les données sont dynamiques ou dépendent d'étapes précédentes.

Scripts de pré-exécution (Pre-execution)

Ils s'exécutent avant l'appel réseau. Leurs principaux usages sont :

• Calculer des en-têtes dynamiques (ex: signatures HMAC, jetons basés sur l'heure).
• Formater le corps de la requête (Body) en fonction de variables de session.
• Ignorer conditionnellement une requête via api.skipRequest().

Scripts de post-exécution (Post-execution) et Chaînage

Ils s'exécutent dès réception de la réponse. C'est l'outil indispensable pour le chaînage de requêtes :

• Extraction : Récupérer une valeur dans un JSON de réponse pour l'utiliser dans l'URL de l'étape suivante via api.setValue().
• Validation métier : Vérifier qu'un champ spécifique est présent dans la réponse au-delà du simple code 200.
• Signalement d'échec : Utiliser api.fail("Message") pour forcer l'échec du test si une condition logique n'est pas remplie.

L'objet API et exemples

Dynatrace expose un objet api global. Voici un exemple d'extraction de jeton dans un script de post-exécution :

// Vérifier le statut
if (response.getStatusCode() === 200) {
    var data = JSON.parse(response.getResponseBody());
    // Stocker le token pour l'étape suivante
    api.setValue("authToken", data.access_token);
    api.info("Token extrait avec succès");
} else {
    api.fail("Échec de l'authentification : " + response.getStatusCode());
}

Utilisation de la variable dans les étapes suivantes

Une fois la variable définie (ex: authToken), vous pouvez l'injecter dans n'importe quel champ des étapes suivantes (URL, En-têtes, Corps de requête) en utilisant la syntaxe entre accolades : {nom_de_la_variable}.

Exemple d'utilisation dans un en-tête :

• Key : Authorization
• Value : Bearer {authToken}

Cette méthode permet de réaliser des scénarios de test dynamiques et complexes (chaînage d'API).

Récapitulatif des méthodes de l'objet API

Voici les méthodes les plus courantes utilisables dans vos scripts de pré et post-exécution :

9. Infrastructure as Code (IaC) et API

Gérez vos moniteurs synthétiques de manière automatisée et industrielle.

Le Monitoring as Code (MaC)

Dans une démarche DevOps, il est déconseillé de créer ses moniteurs manuellement via l'interface. Dynatrace expose une API robuste (v2) permettant d'intégrer la création de tests directement dans vos pipelines CI/CD ou via des outils comme Terraform ou Monaco (Monitoring as Code).

Gestion du cycle de vie via l'API

L'endpoint /api/v2/synthetic/monitors permet de piloter l'intégralité du cycle de vie de vos tests :

• Lister : Récupérer l'ensemble des moniteurs pour audit.
• Détails : Obtenir la configuration JSON complète d'un test spécifique.
• Créer / Modifier : Déployer ou mettre à jour des scénarios via POST ou PUT.
• Supprimer : Nettoyer les tests temporaires.

Exemples de commandes cURL

Lister les moniteurs :

curl -X GET "https://{env-id}.live.dynatrace.com/api/v2/synthetic/monitors" \
-H "Authorization: Api-Token {token}"

Obtenir les détails d'un moniteur :

curl -X GET "https://{env-id}.live.dynatrace.com/api/v2/synthetic/monitors/{monitorId}" \
-H "Authorization: Api-Token {token}"

Exemple de scénario JSON (HTTP Monitor)

Voici un exemple de payload pour créer un moniteur HTTP multi-étapes. Ce fichier JSON peut être envoyé via un POST à l'API :

{
  "name": "API_Check_Production",
  "frequencyMin": 5,
  "enabled": true,
  "type": "HTTP",
  "locations": ["GEOLOCATION-8869796677937A9F"],
  "script": {
    "requests": [
      {
        "description": "Vérification Santé API",
        "url": "https://api.monsite.com/health",
        "method": "GET",
        "validation": {
          "rules": [
            { "type": "httpStatusCode", "value": "200", "passIfFound": true }
          ]
        }
      }
    ]
  }
}