Datadog - Métriques custom et dashboards avancés

Pourquoi les métriques custom changent la donne

L’agent Datadog collecte des centaines de métriques système dès l’installation : CPU, mémoire, disque, réseau. C’est indispensable, mais ça ne raconte qu’une partie de l’histoire. Les métriques qui comptent vraiment — le nombre de commandes traitées, la latence de ton endpoint de paiement, la taille de ta queue de jobs — celles-là, c’est à toi de les créer.

Les métriques custom sont le pont entre l’infrastructure et le métier. Elles permettent de répondre à des questions comme “est-ce que mon API de checkout est plus lente depuis le dernier déploiement ?” plutôt que simplement “est-ce que le CPU est haut ?”. En DevOps, cette visibilité applicative est ce qui fait la différence entre réagir aux problèmes et les anticiper.

🧠 À retenir — Chaque combinaison unique (nom de métrique + valeurs de tags) compte comme une custom metric facturée. Avant d’instrumenter, réfléchis à la cardinalité de tes tags.

Les cinq types de métriques Datadog

Choisir le bon type de métrique est essentiel — un mauvais choix peut fausser tes graphiques ou gonfler ta facture. Datadog propose cinq types, chacun adapté à un cas d’usage précis.

Le Count compte les occurrences d’un événement sur un intervalle (nombre de requêtes, d’erreurs). Le Gauge capture une valeur ponctuelle qui monte ou descend (taille de queue, connexions actives). Le Histogram mesure la distribution statistique d’une valeur et génère automatiquement 5 métriques (avg, count, median, max, p95) — parfait pour les latences. La Distribution est similaire à l’histogram mais calcule les percentiles côté serveur, plus précis en environnement multi-host. Le Set compte les valeurs uniques (utilisateurs distincts sur un intervalle).

from datadog import initialize, statsd

initialize(statsd_host='localhost', statsd_port=8125)

# Count — nombre d'événements
statsd.increment('myapp.requests.count', tags=['endpoint:/api/users', 'method:GET'])

# Gauge — valeur instantanée
statsd.gauge('myapp.queue.size', 42, tags=['queue:emails'])

# Histogram — distribution (génère avg, count, median, max, p95)
statsd.histogram('myapp.request.duration', 0.320, tags=['endpoint:/api/users'])

# Distribution — percentiles calculés côté serveur (multi-host)
statsd.distribution('myapp.api.latency', 0.150, tags=['service:payment'])

# Set — valeurs uniques
statsd.set('myapp.users.unique', user_id, tags=['env:prod'])

💡 Tip DevOps — En cas de doute entre histogram et distribution, utilise distribution. C’est plus précis quand tu as plusieurs instances d’application (pods Kubernetes, fleet de serveurs) et les percentiles sont calculés globalement, pas par agent.

DogStatsD : envoyer des métriques depuis ton code

DogStatsD est le serveur StatsD intégré à l’agent Datadog. Il écoute sur localhost:8125 en UDP et reçoit les métriques de tes applications. L’avantage de l’UDP : c’est fire-and-forget, ton application ne bloque jamais même si l’agent est indisponible.

En Python, on utilise le client officiel datadog. En Go et Node.js, les clients sont tout aussi simples. L’essentiel est de toujours taguer tes métriques avec au minimum env, service et version :

// Client Go — production-ready
package main

import (
    "github.com/DataDog/datadog-go/v5/statsd"
    "log"
)

func main() {
    client, err := statsd.New("127.0.0.1:8125",
        statsd.WithNamespace("myapp."),
        statsd.WithTags([]string{"env:prod", "service:api"}),
    )
    if err != nil { log.Fatal(err) }
    defer client.Close()

    client.Incr("requests.count", []string{"endpoint:/api"}, 1)
    client.Gauge("connections.active", 42, nil, 1)
    client.Histogram("request.duration", 0.250, []string{"method:GET"}, 1)
}

Pour des scripts bash ou des tests rapides, tu peux envoyer des métriques directement en UDP sans SDK — pratique pour instrumenter des jobs cron ou des pipelines CI :

# Format StatsD : metric.name:value|type|#tag1:val1,tag2:val2
echo "myapp.deploy.count:1|c|#env:prod,version:1.2.3" | nc -u -w1 localhost 8125
echo "myapp.queue.size:42|g|#queue:emails" | nc -u -w1 localhost 8125
echo "myapp.request.time:0.320|h|#endpoint:api" | nc -u -w1 localhost 8125

Pour les environnements serverless (Lambda) ou les pipelines CI/CD où l’agent n’est pas disponible, l’API HTTP est ton alternative :

curl -X POST "https://api.datadoghq.eu/api/v2/series" \
  -H "DD-API-KEY: ${DD_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "series": [{
      "metric": "deploy.duration",
      "type": 0,
      "points": [{"timestamp": '$(date +%s)', "value": 45.2}],
      "tags": ["env:prod", "service:api", "version:1.2.3"]
    }]
  }'

⚠️ Attention — Évite les tags à haute cardinalité comme user_id, request_id ou session_id. Chaque valeur unique crée une nouvelle custom metric. Un tag user_id sur une métrique avec 100K utilisateurs = 100K custom metrics facturées. Utilise des tags bornés : status:200, method:GET, region:eu.

Dashboards avancés : de la donnée à l’insight

Un bon dashboard raconte une histoire. Il ne s’agit pas d’empiler des graphiques, mais de structurer l’information pour que n’importe quel membre de l’équipe puisse comprendre l’état du service en 5 secondes.

Les widgets essentiels : Timeseries pour les tendances (latence, throughput), Query Value pour les KPIs clés (uptime, error rate), Top List pour identifier les outliers (endpoints les plus lents, hosts les plus chargés), Heatmap pour la distribution temporelle des latences.

Les formules permettent de combiner des métriques pour des insights plus riches. Le taux d’erreur, par exemple, se calcule en divisant les erreurs par le total de requêtes :

# Taux d'erreur en pourcentage
(sum:myapp.errors{env:prod}.as_rate() / sum:myapp.requests{env:prod}.as_rate()) * 100

# Fonctions utiles :
# .as_rate()    → convertit un count en rate (par seconde)
# .rollup(avg, 60) → agrège sur 60 secondes
# anomalies()   → détection automatique d'anomalies
# forecast()    → prédiction de tendance

Les template variables rendent un dashboard dynamique et réutilisable. Au lieu de créer un dashboard par environnement ou par service, tu crées un seul dashboard avec des filtres :

Variable: $env     → Tag group: env     → Default: prod
Variable: $service → Tag group: service → Default: *
Variable: $host    → Tag group: host    → Default: *

Chaque widget utilise {env:$env, service:$service} dans ses requêtes. Un clic suffit pour passer de la vue production à staging.

🔥 Cas réel — Une équipe SRE gérait 45 dashboards quasi-identiques (un par microservice). En passant à un seul dashboard avec template variables $service et $env, ils ont réduit la maintenance à zéro et amélioré l’adoption par les devs qui trouvaient facilement “leur” vue.

Dashboard as Code avec Terraform

Les dashboards cliqués à la main sont impossibles à maintenir sur la durée : pas de versioning, pas de review, pas de reproductibilité. Terraform permet de gérer les dashboards comme du code, avec les mêmes pratiques que l’infrastructure.

resource "datadog_dashboard" "api_overview" {
  title       = "[Backend] API - Overview"
  description = "Vue d'ensemble des performances API"
  layout_type = "ordered"

  widget {
    timeseries_definition {
      title = "Request Rate"
      request {
        q            = "sum:myapp.requests.count{env:$env}.as_rate()"
        display_type = "line"
        style { palette = "dog_classic" }
      }
    }
  }

  widget {
    timeseries_definition {
      title = "Error Rate (%)"
      request {
        q            = "(sum:myapp.errors{env:$env}.as_rate() / sum:myapp.requests{env:$env}.as_rate()) * 100"
        display_type = "line"
        style { palette = "warm" }
      }
    }
  }

  widget {
    toplist_definition {
      title = "Slowest Endpoints"
      request {
        q = "top(avg:myapp.request.duration{env:$env} by {endpoint}, 10, 'mean', 'desc')"
      }
    }
  }

  template_variable {
    name = "env"; prefix = "env"; default = "prod"
  }
  template_variable {
    name = "service"; prefix = "service"; default = "*"
  }
}

Convention de nommage pour garder l’ordre quand tu as des dizaines de dashboards :

[Team] Service - Type
[Backend] API - Overview
[Backend] API - Performance Deep Dive
[Infra] Kubernetes - Cluster Health
[Frontend] Web - Core Web Vitals

💡 Tip DevOps — Utilise les Notebooks Datadog pour l’investigation et le postmortem. Contrairement aux dashboards (vue temps réel), les notebooks combinent graphiques, texte explicatif et snapshots dans un document collaboratif figé dans le temps.

Bonnes pratiques et pièges à éviter

Convention de nommage stricte — Adopte un format {app}.{module}.{metric} dès le départ et documente-le. myapp.api.request.duration est clair et scopé. request.count est ambigu et finira en conflit avec un autre service.

Tags essentiels — Toujours inclure env, service et version. Ajoute endpoint, method, status selon le contexte. Ne jamais utiliser de valeurs non bornées (timestamps, UUIDs, IDs utilisateur).

Les pièges classiques :

• Mettre des timestamps dans les noms de métriques (myapp.requests.2026_03) — ça crée une nouvelle métrique chaque mois
• Oublier .as_rate() sur les counts — un count brut n’est pas comparable entre des intervalles de flush différents
• Créer un dashboard par environnement au lieu d’utiliser des template variables
• Ne pas surveiller le coût dans Plan & Usage → Usage — les custom metrics explosent vite

⚠️ Attention — Un histogram génère automatiquement 5 métriques (avg, count, max, median, p95). Si tu as un histogram avec 10 combinaisons de tags, ça fait 50 custom metrics. Multiplie par le nombre de métriques histogram et ça monte vite.

🧠 À retenir — Les métriques custom sont le pont entre ton infrastructure et ton métier. Cinq types à maîtriser, DogStatsD pour l’envoi, des dashboards structurés avec template variables et du code Terraform pour la maintenabilité. La clé : instrumenter ce qui compte pour le business, pas tout ce qui est techniquement possible.