🐶 DataDog – Le Guide Ultime de l'Observabilité

DataDog est une plateforme **SaaS (Software as a Service)** de **monitoring et d'observabilité** pour les applications cloud modernes.

Son objectif principal est de fournir un **"Single Pane of Glass"** (un tableau de bord unifié) où les équipes (Dev, Ops, Securité) peuvent voir la santé complète de leur système.

Il unifie ce qu'on appelle les **3 Piliers de l'Observabilité** (voir 1.2).

Avant DataDog, les entreprises utilisaient des outils "en silo" (ex: Prometheus pour les Métriques, ELK/Splunk pour les Logs, Jaeger pour les Traces). La force de DataDog est de **corréler** les 3 piliers grâce aux **Tags** (voir 2.2).

Diagramme : Corrélation (Le Workflow de Dépannage)

(ALERTE: CPU > 90%)
      | (Métrique)
      ▼
(Dashboard: Service "API-Payment")
      | (Trace / APM)
      ▼
(Flame Graph: Endpoint "/charge")
      | (Trace / APM)
      ▼
(Span: "validate_payment" (5 sec))
      | (Log / Trace Corrélation)
      ▼
(Log: "ERROR: Timeout API Banque X")

L'Agent DataDog est le "collecteur" (un binaire léger écrit en Go) que vous installez sur **chaque** machine (Host, VM, Nœud K8s) ou en tant que "sidecar" (conteneur).

Il n'effectue **aucun** calcul (zéro agrégation). C'est un "agent de transfert" (forwarder) dont le seul rôle est de :

• Collecter les 3 piliers (Métriques, Traces, Logs).
• Tagger ces données (voir 2.2).
• Envoyer (flush) ces données (via HTTPS/TLS) à l'endpoint de votre organisation DataDog (ex: api.datadoghq.eu).

Diagramme : Architecture de l'Agent (Simplifié)

(Votre Machine Hôte: VM, Nœud K8s)
+-----------------------------------------------------------+
| +-------------------------------------------------------+ |
| | Agent DataDog (Binaire 'datadog-agent')               | |
| +-------------------------------------------------------+ |
| | 1. Collecteur (Host) | 2. DogStatsD  | 3. APM Agent     | |
| | (CPU, Mem, Disk...)  | (Port 8125/UDP) | (Port 8126/TCP)  | |
| +----------------------+---------------+----------------+ |
| | 4. Collecteur (Logs) | 5. Intégrations (conf.d)       | |
| | (Tail /var/log/...)  | (Ex: postgres.d, nginx.d)      | |
| +----------------------+--------------------------------+ |
| | 6. Autodiscovery (Docker/K8s)                         | |
| +-------------------------------------------------------+ |
|             | (HTTPS / DD_API_KEY)                      |
|             ▼                                           |
| +-------------------------------------------------------+ |
| | DataDog SaaS Platform (Cloud)                         | |
+-----------------------------------------------------------+

L'installation dépend de votre infrastructure. DD_API_KEY et DD_SITE (ex: datadoghq.eu) sont requis.

# (La commande "one-liner" fournie par DataDog)
DD_AGENT_MAJOR_VERSION=7 DD_API_KEY="VOTRE_API_KEY" DD_SITE="datadoghq.eu" \
bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/install_script.sh)"

# (Démarre l'agent)
sudo systemctl start datadog-agent

docker run -d --name datadog-agent \
   --cgroupns host \
   -v /var/run/docker.sock:/var/run/docker.sock:ro \
   -v /proc/:/host/proc/:ro \
   -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro \
   -e DD_API_KEY="VOTRE_API_KEY" \
   -e DD_SITE="datadoghq.eu" \
   -e DD_APM_ENABLED="true" \
   -e DD_LOGS_ENABLED="true" \
   -e DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL="true" \
   gcr.io/datadoghq/agent:latest

# 1. Ajouter le repo Helm
helm repo add datadog https://helm.datadoghq.com
helm repo update

# 2. Installer
helm install datadog-agent datadog/datadog \
    --set datadog.apiKey="VOTRE_API_KEY" \
    --set datadog.site="datadoghq.eu" \
    --set datadog.clusterName="mon-cluster-prod" \
    --set logs.enabled="true" \
    --set logs.containerCollectAll="true" \
    --set apm.enabled="true"

Commandes vitales (sur l'hôte/pod de l'Agent) pour vérifier que la collecte fonctionne.

Exemple Console (datadog-agent status)

$ sudo datadog-agent status
[...]
Checks
======
  nginx (nginx.d/conf.yaml)
  -------------------------
    Instance ID: nginx: [...] [OK]
    Metrics: 7, Events: 0, Service Checks: 1

  postgres (postgres.d/conf.yaml)
  -------------------------------
    Instance ID: postgres: [...] [ERROR]
    Error: "Connection error: ..."
    (-> ERREUR: L'agent ne peut pas se connecter à Postgres)
            

Les **Tags** (key:value) sont le concept le plus important. C'est le "ciment" qui lie les Métriques, Traces et Logs.

DataDog unifie les données grâce à 3 tags (réservés) :

• env : L'environnement (ex: env:prod, env:staging).
• service : Le microservice (ex: service:api-payment, service:frontend).
• version : La version de l'application (ex: version:1.5.2).

Si une Métrique (cpu.load), une Trace (http.request) et un Log (error) partagent le tag service:api-payment, DataDog peut les corréler automatiquement.

La configuration principale (/etc/datadog-agent/datadog.yaml) définit les paramètres globaux (Clé API, Site, Tags, APM, Logs).

Exemple (datadog.yaml)

# Fichier: /etc/datadog-agent/datadog.yaml

# 1. Clés (requis)
api_key: VOTRE_CLE_API_32_CHAR
site: datadoghq.eu

# 2. TAGGING GLOBAL (Le plus important !)
# Ces tags seront ajoutés à TOUTES les données (CPU, Logs, Traces)
tags:
  - env:production
  - region:eu-west-1
  - project:ecommerce

# 3. Activation APM (Traces)
apm_config:
  enabled: true
  # (Les traces hériteront des tags 'env', 'region', 'project')

# 4. Activation Logs
logs_enabled: true
    

En environnement dynamique (Kubernetes), on utilise l'Autodiscovery. L'Agent écoute l'API K8s/Docker et applique des configurations basées sur les Annotations (K8s) ou Labels (Docker) des conteneurs.

Exemple (Annotation K8s Deployment.yaml)

# (deployment-nginx.yaml)
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    metadata:
      annotations:
        # (Instructions pour l'Agent DataDog (Autodiscovery))
        
        # 1. Logs: Applique ces tags aux logs 'stdout' de ce pod
        "ad.datadoghq.com/nginx.logs": |
          [
            {
              "source": "nginx",
              "service": "frontend-web"
            }
          ]
        
        # 2. Métriques: Applique ce "check" d'intégration à ce pod
        "ad.datadoghq.com/nginx.checks": |
          {
            "nginx": {
              "instances": [
                {
                  "nginx_status_url": "http://%%host%%/nginx_status/"
                }
              ]
            }
          }
    spec:
      containers:
      - name: nginx
        image: nginx:latest

Comprendre les 4 types de métriques est essentiel pour savoir *comment* les interroger.

Une "Intégration" est un "check" (script) que l'Agent exécute pour collecter des métriques/logs spécifiques à une technologie (ex: NGINX, Postgres, Redis, Kafka...).

On les configure dans /etc/datadog-agent/conf.d/[nom_integration].d/conf.yaml (ou via Autodiscovery, voir 2.4).

Exemple (postgres.d/conf.yaml)

# Fichier: /etc/datadog-agent/conf.d/postgres.d/conf.yaml
init_config:

instances:
  - host: my-db-instance.rds.amazonaws.com # Endpoint de la DB
    port: 5432
    username: datadog
    password: "VOTRE_PASSWORD_SECURISE"
    dbm: true # (Active Database Monitoring)
    
    # (Tags cruciaux)
    tags:
      - env:production
      - service:postgres-primary
      - db:shop-db

DogStatsD (basé sur StatsD) est le service (inclus dans l'Agent) qui écoute (sur un port UDP, 8125) les métriques custom (applicatives/business) de vos applications.

Exemple (Python)

# (Nécessite: pip install datadog)
from datadog import initialize, statsd

initialize() # (Se connecte à l'Agent local: localhost:8125)

# --- Cas d'usage : Un utilisateur finalise un paiement ---

tags = ["env:prod", "payment_provider:stripe"]

# 1. COUNT (Incrémente)
statsd.increment(
    "ecommerce.order.completed",
    tags=tags
)

# 2. HISTOGRAM (Distribution)
statsd.histogram(
    "ecommerce.payment.value",
    cart_value, # (ex: 45.50)
    tags=tags
)

# 3. SET (Compte les utilisateurs uniques)
statsd.set(
    "ecommerce.users.active",
    user_id,
    tags=tags
)

Les Dashboards sont l'interface "drag-and-drop" pour visualiser les métriques (et logs/traces).

• Timeboards (Défaut) : Axe X = Temps. (Pour l'investigation).
• Screenboards : Grille libre (layout fixe). (Pour les "Status Boards", ex: TV).

Widgets Principaux

• Timeseries : Le graphique linéaire (le plus utilisé).
• Query Value : Un seul chiffre (ex: "CPU Actuel").
• Top List : Classement (ex: "Top 5 hosts par CPU").
• Heat Map : Distribution (ex: "Latence p95 par service").
• Host Map : Visualisation de votre infrastructure (1 carré = 1 host).
• Log Stream : Affiche les logs (filtrés) en direct.

La syntaxe de requête des widgets est standardisée.

Diagramme : Anatomie d'une Requête

  avg:system.cpu.user{env:prod, service:api-users} by {host}
  \__/ \_____________/ \_________________________/    \______/
    |         |                   |                     |
    |         |                   |                     |
 1. Aggregator  2. Metric Name      3. Filter (Scope)     4. Group By (Dimension)
 (avg, sum,    (Ce qu'on mesure)   (WHERE)               (GROUP BY)
  max, min,
  p95, ...)
    

Exemples de Requêtes

# 1. CPU Moyen (Global) (1 ligne)
avg:system.cpu.user{env:prod}

# 2. CPU Moyen par Host (N lignes)
avg:system.cpu.user{env:prod} by {host}

# 3. Latence p99 (Histogram) du paiement Stripe
p99:ecommerce.payment.latency_ms{payment_provider:stripe} by {region}

# 4. (Fonctions)
# (Moyenne mobile (smoothing) sur la latence p95)
smooth(p95:trace.http.request.latency{service:api-payment})

# (Alerte si le taux d'erreur (roll-up) est > 5%)
sum:trace.http.request.errors{service:api-payment}.as_count() / \
sum:trace.http.request.hits{service:api-payment}.as_count() > 0.05

L'APM (Application Performance Monitoring) est le processus qui suit une requête **à travers** votre application et **à travers** les microservices (Tracing Distribué).

• Trace : L'ensemble du "voyage" d'une requête (ex: GET /api/checkout).
• Span : Une "unité de travail" (une opération) **à l'intérieur** d'une Trace (ex: db.query, http.request).

Diagramme : Anatomie d'une Trace Distribuée

(Trace ID: 123)
+--- Service: Frontend (Span A: 1100ms)
|    |
|    +---- [Span B: Appel API /api/users (1000ms)] -------------------------------+
|    |                                                                         |
|    |                                Service: API-Users (Span C: 950ms)     |
|    |                                |                                      |
|    |                                +--- [Span D: Auth Check (500ms)] -----+
|    |                                |                                   |
|    |                                |    Service: DB-Auth (Span E: 450ms)|
|    |                                |                                   |
|    |                                +-----------------------------------+
|    |                                |                                      |
|    |                                +--- [Span F: Business Logic (400ms)]
|    |                                |                                      |
|    |                                +--------------------------------------+
|    |                                                                         |
|    +-------------------------------------------------------------------------+

L'APM (Tracing) nécessite : 1. L'Agent (local) (DD_APM_ENABLED=true). 2. La bibliothèque (lib) de tracing dans votre app.

Cette lib utilise l'**Auto-Instrumentation** : elle "monkey-patche" les bibliothèques courantes (Flask, Django, requests, Redis...) pour qu'elles émettent des Spans.

# 1. Installer
pip install dd-trace

# 2. Configurer (Tags unifiés)
export DD_ENV="production"
export DD_SERVICE="api-users"
export DD_VERSION="1.2.0"

# 3. Lancer (Ex: app Flask)
# (dd-trace-run patche automatiquement Flask, requests, ...)
dd-trace-run gunicorn myapp:app

# Lancer l'application .jar
java -javaagent:./dd-java-agent.jar \
     -Ddd.env="production" \
     -Ddd.service="api-payments" \
     -Ddd.version="1.2.0" \
     -jar /path/to/my-app.jar

# 1. Installer
npm install dd-trace

# 2. Initialiser (index.js - TOUT EN HAUT)
const tracer = require('dd-trace');
tracer.init({
    env: 'production',
    service: 'api-frontend'
});

// (Reste du code... ex: require('express'))
const express = require('express');

L'auto-instrumentation (4.3) ne voit pas votre **logique métier**. (Où sont passées les 450ms entre le début de la requête et l'appel DB ?). On utilise Spans Custom (via décorateur) pour profiler la logique métier.

Exemple (Python - Décorateur @tracer.wrap())

from ddtrace import tracer

# 1. Instrumentation Custom
@tracer.wrap(
    name="ecommerce.validation",  // (Nom du Span)
    service="api-checkout"        // (Tag 'service')
)
def validate_cart(cart):
    
    # 2. Récupérer le Span (optionnel)
    span = tracer.current_span()
    
    # 3. Ajouter des Tags Custom (CRUCIAL)
    # (Permet de rechercher/filtrer les traces)
    span.set_tag("cart.id", cart.id)
    span.set_tag("user.id", cart.user_id)
    
    try:
        # (Logique métier...)
        if cart.value > 10000:
            span.set_tag("cart.review_required", True)
        
    except Exception as e:
        # 4. Reporter les erreurs
        span.set_tag("error", True)
        span.set_exc_info(type(e), e, e.__traceback__)
        raise
        
    return True

Activer la collecte de logs (logs_enabled: true dans datadog.yaml) et définir les sources.

La Règle d'Or : Loguez en JSON ! Si vous loguez en JSON, DataDog parse automatiquement les attributs. Si vous loguez en texte brut (ex: NGINX), DataDog doit utiliser un "Pipeline de Parsing" (Grok) pour extraire les attributs (plus lent, coûteux).

Diagramme : Pipeline de Log (Simplifié)

(Log Brut Reçu)
"10.1.2.3 - - [10/Oct/2025:13:55:36] "GET /api/v1/user" 200"

      |
      ▼
+------------------------------------------------+
| Pipeline (Matching 'source:nginx')             |
+------------------------------------------------+
| 1. Parser (Grok)                               |
| (Extrait "GET", "/api/v1/user", 200)           |
|      |                                         |
|      ▼                                         |
| 2. Remapper (Attributs)                        |
| ('http.status_code' = 200)                     |
| ('http.method' = "GET")                        |
|      |                                         |
|      ▼                                         |
| 3. Create Facets (Indexation)                  |
| (Rendre '@http.status_code' filtrable)         |
+------------------------------------------------+

Attribut vs Facet : Un Attribut (ex: user.id) est stocké. Une Facet (ex: @user.id) est un attribut que vous avez "promu" (indexé) pour permettre le filtrage et l'agrégation.

L'interface "Log Explorer" permet de rechercher et de filtrer (via les "Facets") tous les logs.

Syntaxe de Recherche

# 1. Full-text
"payment failed"

# 2. Facets (Tags)
status:error service:api-payment

# 3. Facets (Attributs parsés)
# (Nécessite Facet sur 'http.status_code')
env:prod @http.status_code:[500 TO 599]

# 4. (Recherche + Facets)
env:prod service:api-users "user_id:123"

# 5. (Wildcards)
@http.url_path:"/api/v1/users/*/profile"

Patterns (Modèles) : DataDog regroupe automatiquement les logs similaires (ex: User {id} failed login [Count: 1M]) pour réduire le bruit.

C'est la fonctionnalité la plus puissante. L'APM (dd-trace) **injecte** le trace_id et span_id dans vos logs (s'ils sont en JSON, ou si DD_LOGS_INJECTION=true).

Exemple (Log Python JSON)

{
  "timestamp": "2024-10-27T10:30:05Z",
  "level": "ERROR",
  "message": "Payment failed for user 123",
  "service": "api-payment",
  
  // (Injecté par dd-trace)
  "dd": {
    "trace_id": "4567890123456",
    "span_id": "9876543210987"
  }
}

Résultat :
1. (Vue "Trace" -> "Logs") : Vous regardez un Flame Graph (Trace APM) d'une requête /checkout lente. L'onglet "Logs" vous montre uniquement les logs de *cette requête précise*.
2. (Vue "Log" -> "Trace") : Vous trouvez ce Log d'erreur. Vous cliquez sur le trace_id. DataDog vous amène au Flame Graph complet, vous montrant ce qui s'est passé *avant* et *après* l'erreur.

Le RUM est l'APM du **Frontend** (Navigateur). On l'installe via npm install @datadog/browser-rum ou un <script> (voir Partie 5).

Il capture :

• Core Web Vitals : LCP, FID, CLS (performance perçue).
• Ressources : Temps de chargement (JS, CSS, Images, fetch/XHR).
• Erreurs JS : (ex: TypeError: 'price' of undefined).
• Actions Utilisateur : (ex: "Clic sur #btn-checkout").
• Session Replay : Enregistrement (vidéo) de la session utilisateur.

Corrélation RUM <-> APM : Le RUM injecte les headers x-datadog-trace-id dans les appels fetch/XHR. L'APM (backend) les reçoit et continue la Trace. (Voir Projet 6.4).

DataDog analyse les M-T-L pour la sécurité.

Un Monitor est une règle (ex: seuil, anomalie) qui se déclenche (Alert, Warn) et envoie une notification (ex: Slack, PagerDuty, E-mail).

Exemples de Monitors

• Métrique (Seuil) : avg(last_5m):system.cpu.user{env:prod} > 90
• Métrique (Anomalie) : anomaly(last_1h):nginx.requests.total{service:web} > 3 (Détection (ML) de pic inhabituel).
• Log (Count) : logs("status:error service:api-payment").index("payment_failed").count() > 10
• APM (Latence) : avg(last_10m):trace.http.request.p95{env:prod,service:frontend} > 2000ms
• RUM (Erreur JS) : rum("error").count_by("error.message").rollup("10m") > 100

Scénario : "Les clients se plaignent que le checkout est lent !" (Alerte RUM > 8 secondes)

1. RUM (Frontend) - "Où est la latence ?"

On filtre sur l'action RUM click on #btn-checkout. On voit que 99% du temps (7950ms) est passé en "Backend (Réseau)" sur la requête POST /api/checkout.
Pivot : On clique sur "View Trace".

2. APM (Backend) - "Où est le goulot d'étranglement ?"

On voit le Flame Graph de la trace. Le span flask.request (7950ms) contient un span custom ecommerce.validation (7500ms), qui contient un span postgres.query (7200ms).
Diagnostic : L'INSERT dans la DB prend 7.2 secondes.
Pivot : On clique sur l'onglet "Logs" (corrélés) de cette trace.

3. Logs (Détail) - "Y a-t-il une erreur ?"

Les logs (filtrés sur trace_id) montrent : INFO: Checkout initiated, WARN: Slow query detected (7200ms) for statement: INSERT INTO orders...
Diagnostic : Pas d'erreur, mais une requête INSERT très lente. Hypothèse : Verrou (Lock).
Pivot : On clique sur le tag service:db-postgres-primary (associé au span/log).

4. Métriques (Infra) - "La DB est-elle saine ?"

On arrive au Dashboard de l'Intégration Postgres. On regarde la métrique postgresql.locks (groupée by {lock_mode}) au moment de l'incident.
Cause Racine : On voit un pic massif de access_exclusive_lock.
Action : Un autre service (ex: service:reporting-batch) exécute un TRUNCATE ou VACUUM FULL sur la table orders, bloquant tous les INSERT de l'API de paiement.

Ressources pour apprendre et travailler avec DataDog.