Installer l'Agent Datadog sur Linux
Avant toute chose : Résolvez complètement toutes les variables dans
## Contexte à résoudre avant d'agir. Ne commencez pas l'étape 1 tant que chaque variable n'a pas une valeur concrète.
Déclencheurs
Invoquez cette compétence quand l'utilisateur exprime l'intention de :
- Installer l'Agent Datadog sur des hôtes ou machines virtuelles Linux
- Configurer la surveillance Datadog sur des instances Linux bare-metal ou cloud
- Préparer des hôtes Linux pour l'intégration APM
N'invoquez PAS cette compétence si :
- L'Agent est déjà installé sur tous les hôtes — vérifiez d'abord avec
datadog-agent status - La cible est un cluster Kubernetes — utilisez
dd-apm-k8s-agent-installà la place
Phase 0 : Charger les identifiants
[ -f environment ] && source environment
echo "DD_API_KEY set: $([ -n "${DD_API_KEY:-}" ] && echo yes || echo no)"
echo "DD_SITE: ${DD_SITE:-not set}"
Si DD_API_KEY est déjà défini — passez directement à la collecte des informations d'infrastructure.
Si DD_API_KEY n'est pas défini — dites à l'utilisateur :
Veuillez exécuter ce qui suit dans ce chat pour définir vos identifiants (le préfixe
!l'exécute dans cette session) :! export DD_API_KEY=your-api-key-here ! export DD_SITE=datadoghq.com
Attendez que l'utilisateur exécute les commandes, puis réexécutez la vérification ci-dessus avant de continuer.
Phase 1 : Collecter les informations d'infrastructure
Ne faites cette phase que si l'utilisateur n'a pas déjà fourni les informations. Si les identifiants SSH sont connus, passez directement à la Phase 2.
Demandez à l'utilisateur :
- Quels hôtes ont besoin de l'agent ? Obtenez une liste d'adresses IP ou de noms d'hôte.
- Comment me connecter via SSH ? Obtenez l'utilisateur SSH, le chemin de la clé, et toute configuration de jump host ou bastion.
- Certains hôtes ont-ils déjà l'Agent Datadog installé ? Si oui, ignorez l'installation pour ces hôtes et passez directement à
verify-ssi.
Claude exécute
Vérifiez que SSH fonctionne pour chaque hôte avant de continuer :
ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> "hostname"
Si cela retourne un nom d'hôte — continuez. ERREUR : Connexion refusée ou timeout — résolvez les problèmes de connectivité avant de continuer.
Une fois SSH confirmé, présentez un plan à l'utilisateur avant de continuer. Par exemple :
Voici ce que je vais faire :
1. Installer l'Agent Datadog avec SSI sur : <host1>, <host2>, ...
2. Vérifier que chaque agent est exécuté et en bonne santé
3. Découvrir les services sur chaque hôte qui ont besoin de redémarrer pour que SSI prenne effet
4. Après que vous ayez redémarré les services, vérifier que l'instrumentation fonctionne
Prêt à continuer ?
Attendez la confirmation de l'utilisateur avant de commencer les installations.
Prérequis
Par hôte — vérifiez avant d'installer :
Claude exécute
ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
"uname -m && cat /etc/os-release | grep -E '^(ID|VERSION_ID|PRETTY_NAME)='"
Si l'architecture est x86_64 ou aarch64, et l'OS est une distribution supportée (Ubuntu 16.04+, Debian 9+, RHEL/CentOS 6-9, Amazon Linux 2/2023, SUSE 12+) — continuez.
ERREUR : L'architecture est armv7l (ARM 32-bit) ou OS non supporté — arrêtez. L'Agent Datadog 7 et SSI ne supportent pas cette configuration.
Contexte à résoudre avant d'agir
| Variable | Comment résoudre |
|---|---|
DD_API_KEY |
Vérifiez d'abord echo $DD_API_KEY — si défini, utilisez-le. Sinon, demandez à l'utilisateur sa clé API depuis l'interface Datadog : Organization Settings → API Keys. Ne consignez jamais et n'affichez jamais la clé. |
DD_SITE |
Vérifiez d'abord echo $DD_SITE — si défini, utilisez-le. Sinon, demandez à l'utilisateur. Défaut : datadoghq.com. Options : datadoghq.com, us3.datadoghq.com, us5.datadoghq.com, datadoghq.eu, ap1.datadoghq.com |
SSH_KEY |
Demandez à l'utilisateur le chemin de sa clé privée SSH, ou vérifiez CLAUDE.md |
SSH_USER |
Demandez à l'utilisateur le nom d'utilisateur SSH. Défaut : root |
SSH_HOST |
Demandez à l'utilisateur le nom d'hôte ou l'IP de l'hôte cible |
SSH_PORT |
Demandez à l'utilisateur le port SSH. Défaut : 22 |
Phase 2 : Installer l'Agent Datadog avec SSI
Exécutez pour chaque hôte qui n'a pas encore l'agent installé.
Claude exécute
ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
"DD_API_KEY=${DD_API_KEY} DD_SITE=${DD_SITE} DD_APM_INSTRUMENTATION_ENABLED=host bash -c \"\$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)\""
DD_APM_INSTRUMENTATION_ENABLED=host fait en sorte que le script d'installation installe également datadog-apm-inject et les paquets de bibliothèques de langage sous /opt/datadog-packages/ en une seule passe.
Si le script se termine sans erreurs — passez à la Phase 2.
ERREUR : curl: command not found :
ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
"apt-get install -y curl 2>/dev/null || yum install -y curl"
ERREUR : Erreur de permission — assurez-vous que l'utilisateur SSH a accès à sudo. Le script d'installation nécessite root.
ERREUR : Le script échoue avec une erreur de clé GPG — réessayez ; si cela persiste, vérifiez la résolution DNS de l'hôte pour keys.datadoghq.com.
Phase 3 : Vérifier que l'Agent s'exécute et est en bonne santé
Claude exécute
ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
"sudo datadog-agent status 2>&1 | head -40"
La sortie saine affiche :
Agent (v7.XX.X)avecStatus: RunningAPI Keys status: API Key ending with XXXX: Valid
ERREUR : command not found — l'installation n'a pas été complétée. Réexécutez la Phase 1.
ERREUR : API key invalid — mettez à jour et redémarrez :
ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
"sudo sed -i 's/^api_key:.*/api_key: <NEW_API_KEY>/' /etc/datadog-agent/datadog.yaml && \
(sudo systemctl restart datadog-agent 2>/dev/null || sudo service datadog-agent restart)"
ERREUR : Le service Agent n'est pas en cours d'exécution :
ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
"sudo systemctl start datadog-agent 2>/dev/null && sudo systemctl enable datadog-agent 2>/dev/null || sudo service datadog-agent start"
Vérifiez que les paquets d'injection APM sont présents sur le disque (pas seulement enregistrés) :
ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
"ls /opt/datadog-packages/ && sudo datadog-installer status 2>/dev/null | grep apm | head -10"
Si /opt/datadog-packages/datadog-apm-inject existe — l'injection est disponible.
ERREUR : Répertoire manquant ou vide — datadog-installer status peut montrer le paquet comme enregistré alors que son répertoire est en fait vide (enregistrement obsolète). Réinstallez :
ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
"sudo datadog-installer remove datadog-apm-inject && \
DD_API_KEY=${DD_API_KEY} DD_SITE=${DD_SITE} DD_APM_INSTRUMENTATION_ENABLED=host bash -c \"\$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)\""
Vérifiez l'enregistrement du nom d'hôte — l'Agent doit résoudre et enregistrer son nom d'hôte pour que l'hôte apparaisse dans Datadog. Les échecs de résolution DNS sont courants dans les conteneurs et les machines virtuelles minimales :
ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
"sudo datadog-agent status 2>&1 | grep -iE '^\s+Hostname' | head -3"
Si Hostname: <some-name> est affiché — le nom d'hôte a été résolu. Enregistrez cela en tant que DD_HOSTNAME pour toutes les étapes suivantes.
ERREUR : Hostname: (none) ou toute erreur de résolution DNS — l'agent ne peut pas résoudre son propre FQDN. Corrigez en définissant le nom d'hôte explicitement dans datadog.yaml :
# Lisez le vrai nom d'hôte système
ACTUAL_HOSTNAME=$(ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> "hostname")
# Ajoutez à datadog.yaml seulement s'il n'est pas déjà défini
ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
"grep -q '^hostname:' /etc/datadog-agent/datadog.yaml || \
echo \"hostname: ${ACTUAL_HOSTNAME}\" | sudo tee -a /etc/datadog-agent/datadog.yaml"
# Redémarrez l'Agent
ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
"sudo systemctl restart datadog-agent 2>/dev/null || sudo service datadog-agent restart"
# Confirmez que le nom d'hôte est maintenant enregistré
ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
"sudo datadog-agent status 2>&1 | grep -iE '^\s+Hostname' | head -2"
Phase 4 : Découvrir les services qui ont besoin de redémarrer
SSI n'injecte que dans les processus au démarrage. Les processus existants continuent de s'exécuter sans instrumentation jusqu'au redémarrage. Découvrez ce qui s'exécute pour que l'utilisateur sache ce qu'il faut redémarrer.
Claude exécute
ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
"sudo ss -lntp 2>/dev/null || sudo netstat -tlnp 2>/dev/null || cat /proc/net/tcp"
Pour chaque listener au niveau de l'application (ignorez sshd, systemd, chronyd) :
ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> "
# Ligne de commande du processus
sudo cat /proc/<PID>/cmdline | tr '\0' ' '
# Gestionnaire de service (peut ne pas être disponible dans tous les environnements)
sudo systemctl status <PID> 2>/dev/null | head -3 || true
# Processus parent
PPID=\$(sudo awk '/PPid/ {print \$2}' /proc/<PID>/status)
sudo cat /proc/\$PPID/cmdline | tr '\0' ' '
"
Présentez les résultats à l'utilisateur :
J'ai trouvé les services d'application suivants sur <host> :
Port 8080 — PID 1234 — /usr/bin/python3 /app/server.py
Géré par : unité systemd flask-app.service
Port 3000 — PID 5678 — node /app/server.js
Géré par : supervisord
Ces services doivent être redémarrés pour que Datadog SSI injecte dans ceux-ci.
Redémarrez-les de la manière appropriée pour votre environnement, puis laissez-moi savoir
et je vérifierai l'instrumentation.
N'offrez pas de redémarrer les services. Ne redémarrez pas les services à moins que l'utilisateur ne le demande explicitement.
Fait
Quittez quand TOUS les éléments suivants sont vrais :
- [ ] Agent en cours d'exécution sur chaque hôte cible (
datadog-agent statusaffiche Running, clé API valide) - [ ]
/opt/datadog-packages/datadog-apm-injectexiste sur le disque sur chaque hôte - [ ] L'utilisateur a été informé de quels services doivent redémarrer
- [ ] L'utilisateur a confirmé qu'il est prêt à redémarrer les services
Passez automatiquement à enable-ssi (si les services ont besoin de labels UST configurés) ou verify-ssi (si les services ont déjà été redémarrés) — ne demandez pas la permission à l'utilisateur.
Contraintes de sécurité
- Ne jamais écrire une clé API brute dans aucun fichier ou message de chat
- Ne jamais stocker
DD_API_KEYdans l'historique shell — passez-la uniquement en ligne dans la commande SSH - Si la clé API de l'utilisateur apparaît dans une sortie quelconque, masquez-la avant d'afficher
- Confirmez toujours avant de redémarrer les services de production