🐶 DataDog – La Plateforme d'Observabilité Unifiée

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

(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 (écrit en Go) que l'on installe sur **chaque** machine (Host, VM, Kuberenetes Node, Container).

Il collecte les Métriques (Host, Intégrations), les Logs (Tailing), et les Traces (APM) et les envoie (via HTTPS) à l'API DataDog (SaaS).

L'installation (DD_API_KEY) est fournie dans l'interface DataDog.

# (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" \
   gcr.io/datadoghq/agent:latest

# (Ajouter le repo Helm)
helm repo add datadog https://helm.datadoghq.com

# (Installer)
helm install datadog-agent \
    --set datadog.apiKey="VOTRE_API_KEY" \
    --set datadog.site="datadoghq.eu" \
    datadog/datadog

La configuration de l'Agent se trouve (sous Linux) dans /etc/datadog-agent/.

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.

Configuration (datadog.yaml)

# (Configuration globale des tags pour cet Agent)
tags:
  - env:production
  - region:us-east-1
  - service:backend-api

# (Configuration APM)
apm_config:
  enabled: true
  env: production # (Hérité)

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, AWS).

On les configure dans /etc/datadog-agent/conf.d/[nom_integration].d/conf.yaml.

# (Collecte les métriques de connexion,
# le nombre de "slow queries", etc.)
init_config:

instances:
  - host: localhost
    port: 5432
    username: datadog
    password: "VOTRE_PASSWORD"
    dbm: true # (Active Database Monitoring)
    
    # (Ajoute ces tags à TOUTES les métriques)
    tags:
      - service:postgres-main
      - env:production

# (Nécessite 'stub_status' activé dans NGINX)
init_config:

instances:
  - nginx_status_url: http://localhost/nginx_status/
  
    # (Tags)
    tags:
      - service:frontend-web

L'Agent collecte (par défaut) toutes les métriques système (CPU, Mémoire, Disque, Réseau). C'est le "Core" de DataDog.

Types de Métriques :

• GAUGE : Une valeur ponctuelle (ex: system.cpu.user).
• COUNT : Un compteur (ex: nginx.requests.total).
• HISTOGRAM : Mesure la distribution (p95, p99, avg).

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

Exemple (Python)

# (pip install datadog)
from datadog import initialize, statsd

initialize(api_key="...", app_key="...")

# (Métriques business)
# (Type: COUNT)
statsd.increment(
    "ecommerce.order.completed",
    tags=["env:prod", "payment:stripe"]
)

# (Type: GAUGE)
statsd.gauge(
    "ecommerce.cart.value",
    120.50, // (Valeur)
    tags=["env:prod"]
)

# (Type: HISTOGRAM)
statsd.histogram(
    "ecommerce.checkout.time_ms",
    1500, // (Temps en ms)
    tags=["env:prod"]
)

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

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

Widgets Courants

• Timeseries : Graphique (ex: avg:system.cpu.user{env:prod} by {host}).
• Query Value : Une seule valeur (ex: le p95 des 5 dernières minutes).
• Heat Map : Distribution (ex: latence par host).
• IFrame : Intégrer d'autres sites (ex: Grafana).

DataDog ingère, parse, et indexe les logs de toute votre stack.

Configuration (datadog.yaml)

# (Activer la collecte de logs)
logs_enabled: true

# (Option 1: Collecte (Tail) de fichiers)
logs_config:
  - type: file
    path: "/var/log/nginx/access.log"
    service: nginx
    source: nginx
    
# (Option 2: Collecte (Socket/Port))
# (Ex: pour Python logging handler)
logs_config:
  - type: tcp
    port: 10518
    service: python-app
    source: python

En conteneurs (K8s/Docker), l'Agent écoute (Autodiscovery) les logs stdout/stderr (Standard Out) des conteneurs.

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

Les **Facets** sont des attributs (tags ou JSON) sur lesquels on peut filtrer/grouper (ex: @http.status_code, @user.id).

Syntaxe de Recherche

// 1. Recherche "Full Text"
"payment failed"

// 2. Recherche (Tags/Facets)
// (Statut 500 ET service 'api')
status:error service:api-payment

// 3. (Recherche + Full Text)
env:prod service:api-users "user_id:123"

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

Patterns (Modèles) : DataDog regroupe automatiquement les logs similaires pour réduire le bruit (ex: 1 million de logs User {id} login sont regroupés en 1 "Pattern").

Corrélation (trace_id) : Si l'APM (voir 5.1) est activé, DataDog **injecte** un trace_id dans les logs. Cela permet de voir **exactement** les logs (ex: 'error') associés à une trace (ex: requête /checkout lente).

APM (Application Performance Monitoring) est le "profiling" (analyse de performance) de votre code, en production et distribué.

L'APM capture les **Traces** (le cycle de vie d'une requête) et les **Spans** (les opérations dans la requête).

La plupart des intégrations APM (Python, Java, Node.js) utilisent l'**Auto-Instrumentation** : elles "patch_ent" (modifient) automatiquement les bibliothèques courantes (Flask, Django, requests, psycopg2) pour qu'elles envoient des Spans.

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

# 1. Installer la lib
pip install dd-trace

# 2. Exécuter l'application (ex: Gunicorn/Flask)
# (dd-trace-run patche automatiquement Flask, requests, ...)
dd-trace-run gunicorn myapp:app

# (L'Agent Java s'attache à la JVM au démarrage)
java -javaagent:/path/to/dd-java-agent.jar \
     -Ddd.service=mon-app-java \
     -Ddd.env=production \
     -jar mon-app.jar

Trace : La requête entière (ex: GET /api/user/123) (composée de Spans).

Span : Une "unité de travail" dans la trace (ex: db.query, http.request, auth.check).

Distributed Tracing : DataDog propage les "headers" (x-datadog-trace-id) entre les services (ex: Frontend -> API -> DB). Il peut ainsi reconstruire la requête **complète** (Service Map) et l'afficher en "Flame Graph" (waterfall) pour voir qui est lent.

Le RUM (Monitoring Utilisateur Réel) est l'APM du **Frontend** (Navigateur).

On installe le SDK (JavaScript) dans le <head> de l'application (ou via npm install @datadog/browser-rum).

Il capture :

• Core Web Vitals : LCP, FID, CLS (performance perçue).
• Ressources : Temps de chargement (JS, CSS, Images).
• Erreurs JS : (ex: TypeError: undefined is not a function).
• Actions Utilisateur : (ex: "Clic sur #bouton-checkout").

DataDog utilise les 3 Piliers (M-T-L) pour offrir une plateforme de sécurité (DevSecOps).

L'Observabilité ne sert à rien sans **Alerting**. C'est le rôle des **Monitors**.

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 : avg(last_5m):system.cpu.user{env:prod} > 90 (Seuil).
• Anomalie : anomaly(last_1h):nginx.requests.total{service:web} > 3 (Détection (ML) de pic inhabituel).
• Log : logs("status:error service:api-payment").index("payment_failed").count() > 10 (Nb d'erreurs).
• APM : avg(last_10m):trace.http.request.p95{env:prod,service:frontend} > 2000ms (Latence p95).

Objectif : Monitorer une app E-commerce (React + API Python + DB Postgres) sur Kubernetes, tagguée par env:production.

1. (Cluster K8s) : Installer l'Agent DataDog (Helm Chart). Il collecte automatiquement les métriques (CPU/Mem) des Nœuds et des Pods.
2. (App React) : Installer RUM (@datadog/browser-rum).
   • Résultat : On voit la performance (LCP) par pays, et les erreurs JS (ex: "Cannot read property 'price' of undefined").
3. (API Python) : Installer APM (dd-trace-py).
   • Résultat : On voit les traces (ex: POST /checkout). On voit que la trace est lente (3s). Le Flame Graph montre que le Span db.query prend 2.8s.
4. (DB Postgres) : Configurer l'Intégration (postgres.d/conf.yaml) (via Autodiscovery K8s).
   • Résultat : On voit les métriques de Postgres. La métrique postgresql.connections est à 100% (max).
5. (Logs) : L'Agent K8s collecte les stdout des pods API (Python).
   • Résultat : On filtre sur service:api-python status:error. On voit "FATAL: too many connections".

Conclusion (grâce au Tagging unifié) : Le RUM (Frontend) est lent, car l'APM (Backend) est lent, car le Span (DB) est lent, car les Métriques (DB) montrent une saturation, car les Logs (DB) confirment "too many connections".

Ressources pour apprendre et travailler avec DataDog.