Vérifier APM SSI sur Linux

Avant toute chose : Résolvez complètement toutes les variables dans ## Context to resolve before acting. 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 :

• Confirmer que SSI fonctionne après l'installation de l'Agent Datadog sur Linux
• Vérifier si un processus Linux est instrumenté
• Vérifier que le tracer s'exécute et rapporte la télémétrie

N'invoquez PAS cette compétence si :

• SSI n'a pas encore été activé — exécutez d'abord agent-install
• Les services n'ont pas été redémarrés depuis l'installation de l'agent — redémarrez-les d'abord, puis vérifiez

Prérequis

• [ ] agent-install est terminé
• [ ] Les services applicatifs ont été redémarrés depuis l'installation de l'agent

pup-cli: vérifier, installer et s'authentifier

Claude exécute

pup --version

Si non trouvé :

Claude exécute

brew tap datadog-labs/pack
brew install pup

Vérifier l'authentification :

pup auth status --site <DD_SITE>

Si non authentifié :

Claude exécute

pup auth login --site <DD_SITE>

Cela ouvre un onglet navigateur pour OAuth. Complétez la connexion là-bas — Claude continuera une fois que la commande se sera terminée.

Si token valide — procédez. ERREUR : Aucun navigateur disponible : export DD_APP_KEY=<your-app-key>

Contexte à résoudre avant d'agir

Étape 1 : Confirmer que le Processus est Injecté

Utilisez /proc/<pid>/maps — c'est la vérification faisant autorité. Elle affiche les bibliothèques partagées réellement chargées dans le processus en cours d'exécution, ce qui est le seul moyen de confirmer que les fichiers .so du launcher et du tracer ont réellement été chargés.

Claude exécute

ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
  "pgrep -a -f '<SERVICE_NAME>' | head -5"

Utilisez le PID ci-dessus :

ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
  "sudo cat /proc/<PID>/maps | grep -E 'launcher|apm-library|datadog'"

Si la sortie inclut à la fois le launcher (par ex. launcher.preload.so) et une bibliothèque de langage (par ex. apm-library-python) — l'injection a réussi pour ce processus.

ERREUR : Launcher présent mais pas de bibliothèque de langage — le launcher s'est exécuté mais n'a pas pu injecter. Vérifier les erreurs d'injection :

Claude exécute

pup apm troubleshooting list --hostname <DD_HOSTNAME> --timeframe 1h

ERREUR : Aucun des deux présent — le processus n'a pas été injecté. Vérifier /etc/ld.so.preload :

ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> "cat /etc/ld.so.preload"

Si vide — l'installation n'a pas configuré le launcher. Réexécutez le script d'installation avec DD_APM_INSTRUMENTATION_ENABLED=host. Si non-vide mais le processus n'est toujours pas injecté — le processus a été démarré avant l'installation du launcher. Redémarrez le service et revérifiez.

Étape 2 : Confirmer que l'Agent Reçoit les Traces

Claude exécute

ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
  "sudo datadog-agent status 2>&1 | grep -A 15 'APM Agent'"

Une sortie saine affiche :

• feature_auto_instrumentation_enabled: true
• Receiver (previous minute) avec > 0 traces

ERREUR : feature_auto_instrumentation_enabled: false — SSI non actif sur l'agent. Vérifier apm_config dans /etc/datadog-agent/datadog.yaml.

ERREUR : Receiver (previous minute): 0 — agent en cours d'exécution mais pas de traces encore. Générer du trafic d'abord (voir Étape 3), puis revérifier.

Étape 3 : Confirmer que le Service est Visible dans Datadog

Claude exécute

DD_SITE=<DD_SITE> pup apm services list --env <ENV> --from 1h

Si <SERVICE_NAME> apparaît avec isTraced: true — les traces atteignent le backend Datadog.

Note de nommage Flask / ddtrace v3 : Avec ddtrace >=3.x, les spans Flask sont émis en tant que service:flask plutôt que service:<DD_SERVICE>. La valeur DD_SERVICE apparaît comme base_service sur les spans. Si vous définissez DD_SERVICE=my-app, recherchez service:flask dans l'interface APM — la liste des services affichera flask, pas my-app. Vérifiez la balise base_service pour confirmer qu'elle correspond à votre DD_SERVICE.

ERREUR : Service manquant — générer du trafic pour déclencher la création de traces :

Claude exécute

ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
  "sudo ss -tlnp 2>/dev/null | grep <PID> || sudo netstat -tlnp 2>/dev/null | grep <PID>"

Utilisez le port ci-dessus :

ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
  "for i in \$(seq 1 10); do curl -s -o /dev/null http://localhost:<PORT>/; done"

Attendre 30 secondes, puis réessayer :

DD_SITE=<DD_SITE> pup apm services list --env <ENV> --from 10m
DD_SITE=<DD_SITE> pup traces search --query "service:<SERVICE_NAME>" --from 10m --limit 5

ERREUR : Toujours manquant — vérifier les erreurs d'injection et aller à troubleshoot-ssi :

pup apm troubleshooting list --hostname <DD_HOSTNAME> --timeframe 1h

Terminé

Quittez quand TOUTES les conditions suivantes sont vraies :

• [ ] Étape 1 : launcher + bibliothèque de langage tous deux visibles dans /proc/<PID>/maps
• [ ] Étape 2 : récepteur APM de l'agent affiche > 0 traces/min
• [ ] Étape 3 : service apparaît dans pup apm services list

Si une vérification échoue, aller à troubleshoot-ssi.

Quand toutes les étapes réussissent, procédez automatiquement à onboarding-summary maintenant — ne demandez pas la permission à l'utilisateur.

Contraintes de sécurité

• Ne jamais écrire une clé API brute dans un fichier ou message de chat
• Toujours confirmer avant de redémarrer les services en production