Datadog - Introduction et premiers pas

Tu gères une infra en prod et tu jongles entre Prometheus pour les métriques, ELK pour les logs, Jaeger pour les traces et PagerDuty pour les alertes. Quatre interfaces, zéro corrélation, et quand un incident tombe à 3h du matin, tu perds 20 minutes juste à naviguer entre les outils avant de comprendre ce qui se passe. C’est exactement le problème que Datadog résout — et c’est pour ça qu’il est devenu le standard de facto du monitoring en entreprise.

Dans ce cours, tu vas comprendre l’architecture de l’agent Datadog, l’installer sur Ubuntu et Docker, et poser les bases d’une stratégie de monitoring solide.

Pourquoi Datadog est incontournable en production

Le monitoring fragmenté, c’est la réalité de beaucoup d’équipes. Tu as un outil pour chaque besoin — métriques infra, APM, logs, synthetics, security — mais aucun ne parle aux autres. Résultat : quand ton API ralentit, tu dois manuellement croiser les graphes CPU de Grafana avec les logs Kibana et les traces Jaeger pour trouver la cause.

Datadog unifie tout dans une seule plateforme SaaS : métriques d’infrastructure, traces distribuées, log management, tests synthétiques, monitoring de sécurité et Real User Monitoring. La vraie puissance, c’est la corrélation native — tu cliques sur un pic CPU et tu vois directement les logs et traces associés, sans changer d’outil.

Le trade-off est simple : tu paies un abonnement par host, mais tu élimines la maintenance d’une stack de monitoring self-hosted. Plus de nœuds Elasticsearch qui tombent, plus de Prometheus à scaler manuellement, plus de dashboards Grafana à maintenir.

💡 Tip DevOps : Datadog propose un trial gratuit de 14 jours avec toutes les fonctionnalités. C’est suffisant pour évaluer l’outil sur ta stack réelle avant de sortir la carte bleue.

🧠 À retenir : Datadog fait sens à partir de ~10 hosts en production. En dessous, Prometheus + Grafana reste un choix raisonnable et gratuit.

Comprendre l’architecture de l’agent

L’agent Datadog est un binaire Go léger (~50 MB RAM) qui tourne sur chaque machine que tu veux monitorer. Il est composé de trois briques essentielles.

Le Collector parcourt les intégrations configurées et collecte les métriques système — CPU, RAM, disque, réseau — ainsi que celles des services détectés automatiquement (Nginx, PostgreSQL, Redis…). Il tourne en boucle, typiquement toutes les 15 secondes.

Le Forwarder compresse les données et les envoie à l’API Datadog via HTTPS. Il intègre un buffer local qui stocke les métriques en cas de perte réseau, puis les renvoie quand la connexion revient. Tes données ne sont pas perdues si ton réseau flanche 5 minutes.

DogStatsD est un serveur StatsD embarqué qui écoute sur le port UDP 8125. C’est le point d’entrée pour tes métriques custom — ton application envoie un paquet UDP, DogStatsD l’agrège et le transmet au Forwarder.

⚠️ Attention : L’agent actuel est la version 7. Si tu tombes sur de la documentation pour la v5, ignore-la — elle est obsolète et les fichiers de configuration sont incompatibles.

Installer et configurer l’agent

Sur Ubuntu, Datadog fournit un script d’installation officiel qui ajoute le repo APT, installe le package et configure le service automatiquement. Remplace ta-clé-api par ta clé trouvée dans Organization Settings → API Keys sur app.datadoghq.eu :

DD_API_KEY="ta-clé-api" DD_SITE="datadoghq.eu" bash -c \
  "$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)"

Une fois installé, vérifie que tout tourne correctement avec ces commandes de diagnostic :

sudo datadog-agent status
datadog-agent version
sudo journalctl -u datadog-agent -f

Ton host devrait apparaître dans Infrastructure → Host Map sous 2 minutes. Si ce n’est pas le cas, vérifie les logs — c’est souvent un problème de clé API ou de connectivité HTTPS sortante.

Le fichier de configuration principal est /etc/datadog-agent/datadog.yaml. Voici une config de départ solide avec les tags, la collecte de processus et les logs activés :

api_key: ta-clé-api
site: datadoghq.eu
tags:
  - env:production
  - team:backend
  - service:api
hostname: web-prod-eu-01
process_config:
  process_collection:
    enabled: true
logs_enabled: true

Après chaque modification, redémarre l’agent :

sudo systemctl restart datadog-agent

Avec Docker, tu peux lancer l’agent en conteneur sans rien installer sur le système hôte. Les montages de volumes donnent accès aux métriques système et à la découverte des containers :

docker run -d --name datadog-agent \
  --cgroupns host --pid host \
  -e DD_API_KEY="ta-clé-api" \
  -e DD_SITE="datadoghq.eu" \
  -e DD_LOGS_ENABLED=true \
  -e DD_PROCESS_AGENT_ENABLED=true \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -v /proc/:/host/proc/:ro \
  -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro \
  gcr.io/datadoghq/agent:7

💡 Tip DevOps : Le montage de /var/run/docker.sock permet l’Autodiscovery — l’agent détecte automatiquement les containers, lit leurs labels, et configure les intégrations sans fichier de conf statique.

Le tagging est la fonctionnalité la plus importante de Datadog. Sans convention cohérente, tes dashboards et alertes seront inutilisables à l’échelle. Adopte cette convention dès le départ :

env:production|staging|dev
service:api|web|worker
team:backend|frontend|infra
version:1.2.3

Applique ces tags partout : dans datadog.yaml, dans tes labels Docker, dans tes métriques custom et dans tes traces APM. La cohérence, c’est ce qui te permet de filtrer efficacement quand tu as 200 hosts.

Cas concret : une startup e-commerce passe de 5 à 50 hosts

🔥 Cas réel : Une startup e-commerce tourne initialement sur 5 serveurs avec un monitoring artisanal — quelques dashboards Grafana, des alertes basiques par email, et des logs consultés en SSH avec tail -f. Ça marche.

Puis le Black Friday arrive. L’équipe scale à 50 hosts en une semaine. Le monitoring Grafana devient un cauchemar — les dashboards ne sont pas templatisés, les alertes se déclenchent en cascade sans contexte, et personne ne sait quel service cause le ralentissement global.

L’équipe déploie l’agent Datadog sur tous les hosts en 2 heures grâce au script d’installation automatisé via Ansible. En 30 minutes supplémentaires, ils ont un dashboard unifié avec la corrélation métriques/logs/traces. Le premier incident du Black Friday est résolu en 4 minutes au lieu des 45 habituelles — le dashboard montre directement que le pic de latence API vient d’un pool de connexions PostgreSQL saturé, visible en un clic depuis la trace lente jusqu’aux métriques du serveur de base de données.

Le coût Datadog sur le mois : ~2 500€. Le coût d’une heure de downtime e-commerce en Black Friday : 15 000€+. Le calcul est vite fait.

Pièges fréquents quand tu débutes

⚠️ Attention — La clé API vs la clé Application : Datadog utilise deux types de clés. La clé API sert à envoyer des données (agent, métriques). La clé Application sert à lire des données (API de dashboards, requêtes). Ne les confonds pas — si ton agent refuse de démarrer, vérifie que tu utilises bien la clé API et pas la clé App.

⚠️ Attention — Le site Datadog : Si tu es en Europe, ton site est datadoghq.eu, pas datadoghq.com. Une erreur de site = tes métriques partent dans le vide. L’agent démarre sans erreur mais rien n’apparaît dans l’interface. C’est le piège classique numéro un.

⚠️ Attention — Les tags incohérents : environment:prod, env:production, Env:PROD — ce sont trois tags différents pour Datadog. Définis ta convention avant de déployer sur le premier host et documente-la. Nettoyer des tags sur 50 hosts après coup, c’est une demi-journée perdue.

⚠️ Attention — Les coûts qui explosent : Chaque métrique custom, chaque log indexé, chaque host APM a un coût. Active les fonctionnalités progressivement. Commence par les métriques infra de base, puis ajoute les logs sur les services critiques, puis l’APM. Ne coche pas tout dès le jour 1.

🧠 À retenir : Lance sudo datadog-agent configcheck régulièrement — cette commande te montre exactement quelles intégrations sont détectées et si leur configuration est valide.

Exercice pratique

Installe l’agent Datadog en conteneur Docker sur ta machine de test, puis vérifie que la collecte fonctionne :

docker run -d --name dd-agent \
  -e DD_API_KEY=ta-clé-api \
  -e DD_SITE="datadoghq.eu" \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -v /proc/:/host/proc/:ro \
  -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro \
  gcr.io/datadoghq/agent:7

docker exec dd-agent agent status

Objectifs à valider :

1. L’agent apparaît dans Infrastructure → Host Map de la console Datadog
2. Les métriques system.cpu.user et system.mem.used remontent correctement
3. Crée un dashboard avec un graphe CPU, un graphe mémoire et un widget “Query Value” affichant le nombre de containers running
4. Configure un monitor qui alerte si le CPU dépasse 80% pendant 5 minutes

Si tu bloques sur l’étape 1, vérifie dans l’ordre : la clé API, le paramètre DD_SITE, et la connectivité HTTPS sortante vers *.datadoghq.eu.

🧠 À retenir :

• Datadog unifie métriques, logs, traces et alertes dans une seule plateforme — sa force c’est la corrélation native
• L’agent v7 est un binaire Go léger avec trois composants : Collector, Forwarder et DogStatsD
• Le tagging cohérent (env, service, team) est la base de tout monitoring efficace à l’échelle
• Commence par les métriques infra, puis ajoute logs et APM progressivement pour maîtriser les coûts
• datadog-agent status et configcheck sont tes deux commandes de diagnostic essentielles

Dans le prochain cours, on attaque les métriques custom avec DogStatsD et la création de dashboards avancés.