📡 Dynatrace – APM, Observability & IA (Davis)

La plateforme Dynatrace repose sur 4 composants clés :

Les "3 Grands" de l'observabilité SaaS. Ils convergent, mais ont des philosophies différentes.

OneAgent est le "point de vente" n°1 de Dynatrace. C'est un agent logiciel unique que vous installez sur un hôte (Serveur, VM, Nœud K8s).

Fonctionnement (Auto-Instrumentation)

Une fois installé, OneAgent fait tout, automatiquement :

1. Monitoring OS : Il collecte les métriques de l'Infrastructure (CPU, RAM, Disque, Réseau).
2. Découverte : Il scanne les Processus qui tournent sur l'hôte (ex: il trouve un process "Java", "Nginx", "MySQL").
3. Auto-Injection (Magie) : Il s'injecte automatiquement (au niveau binaire/bytecode) dans les processus supportés (Java, .NET, PHP, Node.js...) pour activer l'APM (Distributed Tracing).
4. Collecte Logs : Il détecte et collecte les fichiers logs (.log).
5. Injection RUM : Si c'est un serveur web, il injecte l'agent Browser (RUM) (JavaScript) dans le HTML.

Avantage : Zéro configuration (ou presque). 1 agent = 5 types de monitoring (Infra, APM, Logs, RUM, Topologie).

L'ActiveGate est un composant (installé sur un serveur dédié dans votre réseau) qui sert de proxy/gateway sécurisé entre vos agents et le cluster Dynatrace (SaaS ou Managed).

Rôles de l'ActiveGate

• Proxy (Sécurité) : (Usage principal) Au lieu que 1000 OneAgents parlent à Internet, seul l'ActiveGate parle à Dynatrace (SaaS). Les OneAgents (internes) parlent uniquement à l'ActiveGate.
• Collecteur (Cloud) : C'est lui qui exécute le "polling" des APIs Cloud (AWS, Azure) ou VMware, car il est "dans" votre réseau.
• Collecteur (K8s) : L'ActiveGate tourne dans Kubernetes pour collecter les métriques du cluster.
• Collecteur (Synthetics) : Peut exécuter des tests Synthetics "privés" (depuis votre LAN).
• Buffer : Met en cache les données si la connexion au cluster Dynatrace est perdue.

Smartscape est la carte topologique (visualisation) en temps réel de Dynatrace. C'est le résultat de l'auto-découverte du OneAgent.

Flux de Dépendance

Il montre toutes les dépendances (verticales et horizontales) de votre application :

[ Application (MonApp) ]
       │
       ▼ (Dépend de)
[ Service (Frontend-API) ] <── (Communique avec) ──► [ Service (Backend-Auth) ]
       │                                                      │
       ▼ (Tourne sur)                                         ▼ (Tourne sur)
[ Processus (Node.js) ]                                [ Processus (Java) ]
       │                                                      │
       ▼ (Tourne sur)                                         ▼ (Tourne sur)
[ Hôte (Serveur 1) ]                                   [ Hôte (Serveur 2) ]
       │                                                      │
       ▼ (Tourne sur)                                         ▼ (Tourne sur)
[ Data Center (AWS eu-west-1) ]                        [ Data Center (AWS eu-west-1) ]

Avantage : C'est cette cartographie qui permet à l'IA (Davis) de comprendre qu'un "CPU Élevé" (Hôte 2) est la cause d'une "Erreur 500" (Frontend-API).

L'APM est le produit phare historique de Dynatrace. C'est un outil (Couche 7) qui analyse la performance de votre code de l'intérieur.

Objectif : Répondre à la question "Pourquoi cette page est-elle lente ?".

Auto-Instrumentation (OneAgent)

L'agent APM (ex: pour Java, .NET, PHP, Node.js, Python, Go) s'attache au runtime de votre application. Il "observe" (instrumente) automatiquement les fonctions clés :

• Frameworks Web (Spring, Symfony, Express)
• Appels de Base de Données (JDBC, PDO)
• Appels Externes (API REST, gRPC)
• Bibliothèques (Redis, Kafka)

Métriques Clés (Dashboard APM)

• Response Time (Temps de réponse) : (ex: 200ms) Le temps moyen d'une transaction.
• Throughput (Débit) : (ex: 1000 rpm) Requêtes par minute.
• Error Rate (Taux d'erreur) : (ex: 0.5%) Pourcentage de requêtes échouées (5xx, Exceptions).
• Apdex Score : Score de satisfaction (0-1).

L'agent APM (ex: php_newrelic) instrumente les pilotes de BDD (PDO, MySQLi) pour chronométrer chaque requête.

Rapports Disponibles (APM -> Databases)

• Response Time : Temps moyen de réponse de la BDD.
• Throughput : Requêtes BDD par minute.
• Slowest Queries (Requêtes Lentes) : Le rapport le plus utile. Liste les requêtes (ex: SELECT * ...) qui prennent le plus de temps (ex: > 500ms).
• Problème N+1 : Dynatrace détecte les "N+1 Query Problems" (ex: une boucle foreach qui exécute 100 requêtes SELECT au lieu d'un seul JOIN).

RUM répond à la question : "Comment mes utilisateurs réels (Real Users) perçoivent-ils la performance (côté client) ?"

Fonctionnement (Agent Browser)

L'agent APM (back-end) injecte automatiquement (via OneAgent) un snippet JavaScript dans le <head> des pages HTML.

Ce JS s'exécute dans le navigateur du client et collecte des métriques (LCP, INP, Erreurs JS) puis les envoie aux Collectors Dynatrace.

Métriques Clés (Front-End)

• Core Web Vitals : (Voir 4.2) LCP, INP, CLS.
• Temps de chargement de page (Page Load Time) : Décomposé (Network, DOM Processing, Page Rendering).
• Erreurs JavaScript (JS Errors) : Agrégation des erreurs (ex: TypeError: 'null' is not an object) avec stack trace.
• Requêtes AJAX : Suivi des appels fetch() (Temps de réponse, Erreurs).
• Corrélation : Connecte la trace Front-end (RUM) à la trace Back-end (PurePath) pour une vue "full-stack".

Session Replay (Relecture de Session) est une fonctionnalité avancée du RUM. Elle capture visuellement la session d'un utilisateur (mouvements de souris, clics, défilement) et la transforme en "vidéo" de débogage.

Usage (Diagnostic)

Problème : Un client se plaint : "J'ai cliqué sur Payer et rien ne s'est passé !". L'erreur JS dit "Bouton indéfini".

Solution : L'équipe N2/N3 regarde le "Session Replay" de ce client. Ils voient que l'utilisateur a cliqué 10 fois sur le bouton *avant* que le script de paiement ne soit chargé (condition de course), ce qui a causé l'erreur.

Attention (RGPD/Confidentialité) : Cette fonction capture tout. Dynatrace doit être configuré pour masquer (mask) automatiquement les champs sensibles (mots de passe, cartes de crédit, noms) pendant l'enregistrement.

Problème : L'APM et le RUM sont réactifs (ils attendent un utilisateur pour détecter une panne). Que se passe-t-il si votre site tombe à 3h du matin (zéro trafic) ?

Solution : Synthetics. C'est un monitoring proactif (robotisé). Dynatrace utilise des "locations" (robots) depuis des datacenters mondiaux pour tester votre site 24/7 (ex: toutes les 5 min).

(Exemple de script Clickpath)
1. Aller sur /login
2. Entrer "user@test.com"
3. Entrer "password"
4. Cliquer sur "Connexion"
5. Vérifier que le texte "Tableau de bord" est présent
6. Cliquer sur "Ajouter au Panier"
7. Vérifier que le panier contient "1"

(Si l'étape 5 échoue -> Alerte !)

Le produit New Relic Infrastructure (NRI) (inclus dans OneAgent) supervise l'Hôte (Host) : le serveur (VM, bare-metal, ou conteneur) sur lequel tourne votre application.

Métriques Collectées (Exemples)

• Système : Load Average (1, 5, 15 min), Uptime.
• CPU : % Utilisation (Total, User, System, I/O Wait).
• Mémoire : % Utilisation (RAM totale, utilisée, cache).
• Disque : % Utilisation (Espace disque), I/O (opérations/sec).
• Réseau : Trafic (Octets entrants/sortants), Erreurs.
• Processus : Liste des processus (ex: nginx) et leur consommation CPU/RAM.

Le monitoring de Kubernetes est une brique essentielle de l'observabilité moderne. New Relic fournit une intégration K8s complète (généralement installée via un Helm Chart).

Composants

• OneAgent Operator : Un "opérateur" K8s qui gère le déploiement de OneAgent (en mode DaemonSet) sur chaque Nœud (Node) du cluster.
• Intégration API K8s : Récupère les métriques du Control Plane (état des Deployments, Pods, Services...).
• Pixie (eBPF) : (Acquisition récente) Utilise eBPF (au niveau Kernel Linux) pour tracer toutes les communications (Réseau, HTTP, DNS) entre les Pods, sans avoir besoin d'installer un agent APM dans chaque application (Auto-instrumentation).

C'est la solution de Log Aggregation (type ELK/Splunk) de Dynatrace. Les logs sont stockés dans la base Grail.

Ingestion (Forwarding)

• OneAgent (Défaut) : L'agent (via config YAML) "tail" (suit) les fichiers (ex: /var/log/nginx/access.log) et envoie les nouvelles lignes.
• OpenTelemetry (OTel) : Support natif du standard OTel.
• Plugins (Fluentd, Logstash) : Vous pouvez configurer vos pipelines de logs existants pour "forwarder" les logs vers l'API d'ingestion Dynatrace.

Logs in Context (La "Magie")

C'est la fonctionnalité la plus puissante. L'agent APM (OneAgent) enrichit automatiquement les logs (ex: Monolog) en y injectant l'ID de la Trace (PurePath).

Log (Standard) :
[2025-11-08] ERROR: Failed to process payment.

Log (Enrichi par Dynatrace) :
[2025-11-08] ERROR: Failed to process payment.
(dt.trace_id=abc-123, dt.span_id=def-456)

Résultat : Lorsque vous regardez une Trace PurePath (abc-123) qui a échoué, l'interface vous montre automatiquement tous les logs (ERROR, INFO...) qui ont été générés pendant cette transaction spécifique.

Davis est le moteur d'IA (Causal AI) au cœur de Dynatrace. C'est le différenciateur n°1 de la plateforme.

Causation vs. Corrélation

La plupart des outils (Monitoring classique) font de la Corrélation (Ex: "Tempête d'alertes" : 50 alertes en même temps -> CPU, RAM, Erreurs, Latence...). L'humain (N2/N3) doit trier pour trouver la cause.

Davis (IA Causale) utilise la topologie (Smartscape) et les dépendances (PurePath) pour trouver la Causation (Root Cause Analysis - RCA).

Alerte "Corrélation" (Classique) :
(100 ALERTES)
- Erreur 500 sur /api/login
- Latence élevée sur API Gateway
- CPU 100% sur Hôte A
- CPU 100% sur Hôte B
- Erreurs "Timeout" sur Service Auth

Alerte "Causation" (Davis) :
(1 ALERTE)
Problème #123: Augmentation Taux Erreur
CAUSE RACINE (RCA) :
Un "Bad Deployment" (Événement) sur le Service Auth
a introduit une boucle (N+1) dans la BDD (Trace),
causant une saturation CPU (Infra).

L'Analyse de Cause Racine (RCA) est le produit final de l'IA Davis. Au lieu de vous donner 100 alertes, Davis les consolide en 1 seul "Problème" actionnable.

Processus d'Analyse (Simplifié)

1. Détection (Baseline) : Davis détecte une Anomalie (ex: le temps de réponse de /login dévie de la norme).
2. Corrélation (Smartscape) : Davis analyse toutes les métriques (MELT) de tous les composants liés à /login (via Smartscape/PurePath). (ex: L'Hôte, le Pod K8s, les appels BDD, les appels API externes...).
3. Causation (IA) : Davis utilise son IA causale pour trouver l'événement (ex: un déploiement) ou la métrique (ex: une saturation CPU) qui est la cause la plus probable de l'anomalie.
4. Rapport (Problème) : Davis génère 1 ticket "Problème" (au lieu de 100 alertes) indiquant la cause racine.

Grail est le nom de la base de données (Data Lakehouse) propriétaire de Dynatrace. C'est le "backend" de stockage unifié pour toutes les données (MELT).

Avantages

• Massivement Scalable : Conçu pour ingérer des pétaoctets de données de télémétrie.
• Sans Schéma (Schemaless) : Peut ingérer n'importe quel type de log ou d'événement.
• Index-less : (Surtout pour les logs) Ne nécessite pas d'indexation lourde (comme Elasticsearch), permettant des requêtes rapides sur des volumes massifs (stockage "froid" rapide).
• DQL : C'est le moteur qui exécute le DQL (Dynatrace Query Language).

DQL est le langage de requête (similaire à NRQL ou PromQL) utilisé pour explorer (Observabilité) les données stockées dans Grail.

Il est utilisé pour créer des Dashboards et des Alertes personnalisées.

Syntaxe (Pipe-based)

DQL utilise une syntaxe "pipe" (|), similaire à Splunk ou KQL (Azure).

-- 1. Récupérer les logs
fetch logs
| filter log.level == "ERROR"
| summarize count() by bin(timestamp, 1h), host.name

-- 2. Récupérer les spans (traces)
fetch spans
| filter http.status_code == 500
| summarize avg(duration), p90(duration) by http.target

-- 3. Métriques (TIMESERIES)
fetch metrics, from: "builtin:host.cpu.usage"
| filter dt.entity.host == "HOST-123"
| timeseries avg(value), by: [dt.entity.host]

Dynatrace Application Security est un module (intégré au OneAgent) qui combine l'APM avec la sécurité (similarité avec Datadog Cloud Security Management).

Fonctionnalités

• SCA (Software Composition Analysis) : L'agent (APM) scanne vos dépendances (package.json, pom.xml) et les compare à des bases de données (CVEs) pour trouver les librairies vulnérables (ex: "Log4j").
• RASP (Runtime Application Self-Protection) : L'agent (APM) surveille activement l'exécution du code (via PurePath) pour détecter et (optionnellement) bloquer les attaques L7 (ex: Injection SQL, OS Command Injection) en temps réel.