agent-install

Par datadog-labs · agent-skills

Installez l'Agent Datadog sur des hôtes Linux via SSH avec la Single Step Instrumentation (SSI) activée — la SSI instrumente automatiquement les applications pour l'APM sans modification du code. À utiliser uniquement si aucun agent n'est encore installé.

npx skills add https://github.com/datadog-labs/agent-skills --skill agent-install

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 :

  1. Quels hôtes ont besoin de l'agent ? Obtenez une liste d'adresses IP ou de noms d'hôte.
  2. Comment me connecter via SSH ? Obtenez l'utilisateur SSH, le chemin de la clé, et toute configuration de jump host ou bastion.
  3. 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) avec Status: Running
  • API 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 status affiche Running, clé API valide)
  • [ ] /opt/datadog-packages/datadog-apm-inject existe 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_KEY dans 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

Skills similaires