🐶 Partie 2 : Pilier 1 - Métriques & Dashboards

Comprendre les 4 types de métriques est essentiel pour savoir *comment* les interroger et les agréger (avg, sum, p95...).

Note (p95) : Le HISTOGRAM est vital. Se baser sur la avg (moyenne) d'une latence est dangereux (ex: avg=200ms). Le p95 (95ème percentile) vous dit la vérité : "95% des utilisateurs ont une latence < 350ms, mais 5% ont > 350ms" (c'est souvent là que se cachent les problèmes).

C'est la collecte "out-of-the-box". L'Agent exécute des "Checks" (scripts Python) pour interroger les services standards (Postgres, NGINX, Redis, Kafka, etc.) et envoyer leurs métriques.

Cela se configure dans le dossier /etc/datadog-agent/conf.d/ (sur l'hôte) ou via Autodiscovery (sur K8s/Docker) (Voir Partie 1).

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

init_config:

# Configuration pour CHAQUE instance Postgres à monitorer
instances:
  - host: my-db-instance.rds.amazonaws.com # Endpoint de la DB
    port: 5432
    username: datadog
    password: "VOTRE_PASSWORD_SECURISE"
    
    # Active le "Database Monitoring" (produit avancé)
    dbm: true 
    
    # Ajoute ces tags à TOUTES les métriques de CETTE instance
    tags:
      - env:production
      - service:postgres-primary
      - db:shop-db
    

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

init_config:

instances:
  - nginx_status_url: http://localhost/nginx_status/
    
    tags:
      - env:production
      - service:nginx-ingress
    

Les intégrations sont bien pour l'infrastructure (le "système"), mais vous avez besoin de métriques **applicatives (business)** (ex: "commandes passées", "paniers abandonnés").

Pour cela, on utilise DogStatsD. C'est un service (basé sur StatsD) qui tourne à l'intérieur de l'Agent et écoute sur un port (8125 par défaut) en UDP.

Votre application (Python, Java, Go...) envoie des paquets UDP "fire-and-forget" à l'Agent local. C'est asynchrone et ultra-rapide (votre code ne bloque pas).

Exemple (DogStatsD en Python)

Utilisation de la bibliothèque datadog pour envoyer des métriques custom depuis un script Python (ex: une API Flask/Django).

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

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

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

def handle_payment(user_id, cart_value, payment_provider):
    
    tags = [
        f"env:{os.environ.get('ENV')}",
        f"payment_provider:{payment_provider}"
    ]
    
    # 1. COUNT (Incrémente)
    # "Un paiement a réussi"
    statsd.increment(
        "ecommerce.payment.success",
        tags=tags
    )

    # 2. HISTOGRAM (Distribution)
    # "Ce paiement valait 45.50 €"
    statsd.histogram(
        "ecommerce.payment.value",
        cart_value,
        tags=tags
    )
    
    # 3. SET (Compte les utilisateurs uniques)
    statsd.set(
        "ecommerce.users.active",
        user_id,
        tags=tags
    )
    

Les Dashboards sont le "point de rencontre" de toutes vos métriques (et logs/traces). DataDog en propose deux types :

Widgets Principaux (dans l'éditeur "drag-and-drop")

• Timeseries : Le graphique linéaire (le plus utilisé).
• Query Value : Un seul chiffre (ex: "CPU Actuel", "P95 Latence").
• Top List : Classement (ex: "Top 5 hosts par CPU", "Top 10 utilisateurs par erreurs").
• Heat Map : Distribution (ex: "Latence p95 par service" ou "par région").
• Host Map : Visualisation de votre infrastructure (1 carré = 1 host, coloré par CPU/Mem).
• Log Stream : Affiche les logs (filtrés) en direct.
• Service Map : Affiche la carte des dépendances (APM).

C'est la partie la plus importante pour *utiliser* DataDog. 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 (pour un Widget Timeseries)

1. CPU Moyen (Global) :
   Affiche 1 ligne (le CPU moyen de *tous* les hosts en prod).

   avg:system.cpu.user{env:prod}

2. CPU Moyen par Host :
   Affiche N lignes (1 ligne par host).

   avg:system.cpu.user{env:prod} by {host}

3. Trafic NGINX (Total) :
   Affiche la somme (RATE) des requêtes/s sur *tous* les NGINX taggués service:web.

   sum:nginx.requests.per.second{service:web, env:prod}

4. Latence p99 (Custom Histogram) :
   Affiche la latence p99 (99% des requêtes sont plus rapides que X) pour le paiement Stripe.

   p99:ecommerce.payment.latency_ms{payment_provider:stripe} by {region}

5. Calcul (Formule) :
   Affiche le "Taux d'Erreur" (APM Traces).

   # (Requête 'a' : Erreurs)
   sum:trace.http.request.errors{env:prod, service:api-payment}.as_count() 
   
   # (Requête 'b' : Total)
   sum:trace.http.request.hits{env:prod, service:api-payment}.as_count()
   
   # (Formule: a / b * 100)
   (a / b) * 100