Tracer des applications PHP

Exigences de compatibilité

Pour obtenir la liste complète des versions de langage et des bibliothèques prises en charge, consultez la page Exigences de compatibilité.

Installation et démarrage

Suivre la documentation intégrée à l’application (conseillé)

Suivez les instructions de démarrage rapide fournies dans l’application Datadog pour profiter d’une expérience optimale, et notamment :

• Obtenir des instructions détaillées en fonction de la configuration de votre déploiement (hosts, Docker, Kubernetes ou Amazon ECS) ;
• Définir les tags service, env et version de façon dynamique ;
• Activer l’ingestion de 100 % des traces durant la configuration.

Pour connaître la définition des termes utilisés dans l’APM, consultez la documentation officielle.

Pour découvrir comment effectuer des contributions open source au traceur PHP, consultez le guide relatif aux contributions.

Configurer l’Agent Datadog pour APM

Installez et configurez l’Agent Datadog de façon à ce qu’il reçoive des traces à partir de votre application instrumentée. Par défaut, l’Agent Datadog est activé dans votre fichier datadog.yaml, sous apm_enabled: true, et écoute le trafic des traces sur localhost:8126. Pour les environnements conteneurisés, suivez les liens ci-dessous afin d’activer la collecte de traces au sein de l’Agent Datadog.

• Dropdown

1. Définissez apm_non_local_traffic: true dans votre fichier de configuration principal datadog.yaml.

2. Consultez les instructions de configuration spécifiques pour vous assurer que l’Agent est configuré de façon à recevoir des traces dans un environnement conteneurisé :

3. Après avoir instrumenté votre application, le client de tracing envoie, par défaut, les traces à localhost:8126. S’il ne s’agit pas du host et du port adéquats, modifiez-les en définissant les variables d’environnement ci-dessous :

DD_AGENT_HOST et DD_TRACE_AGENT_PORT.

Consultez la configuration du traceur pour découvrir comment définir ces variables.

Pour configurer l’APM Datadog dans AWS Lambda, consultez la documentation dédiée au tracing de fonctions sans serveur.

Le tracing est disponible pour un certain nombre d’environnements, tels que Heroku, Cloud Foundry, AWS Elastic Beanstalk et l'extension Azure App Services.

Pour les autres environnements, veuillez consulter la documentation relative aux intégrations pour l’environnement qui vous intéresse. Contactez l’assistance si vous rencontrez des problèmes de configuration.

Installer l’extension

Installez l’extension PHP à l’aide de l’un des paquets pré-compilés pour les distributions prises en charge.

Une fois le paquet téléchargé, installez-le avec l’une des commandes ci-dessous.

# avec le paquet RPM (RHEL/Centos 6+, Fedora 20+)
rpm -ivh datadog-php-tracer.rpm

# avec le paquet DEB (Debian Jessie ou ultérieur, Ubuntu 14.04+ sur les versions de PHP prises en charge)
dpkg -i datadog-php-tracer.deb

# avec le paquet APK (Alpine)
apk add datadog-php-tracer.apk --allow-untrusted

L’extension sera installée pour la version de PHP par défaut. Si vous souhaitez installer l’extension pour une version spécifique de PHP, utilisez la variable d’environnement DD_TRACE_PHP_BIN pour définir l’emplacement du binaire PHP cible avant de lancer l’installation.

export DD_TRACE_PHP_BIN=$(which php-fpm7)

Redémarrez PHP (PHP-FPM ou le SAPI Apache), puis consultez un endpoint de votre application pour lequel le tracing est activé. Affichez l'interface de l’APM pour visualiser les traces.

Remarque : quelques minutes peuvent s’écouler avant que les traces soient visibles dans l’interface. Si elles n’apparaissent toujours pas une fois ce délai passé, créez une page phpinfo() depuis la machine du host et faites défiler jusqu’à la section « ddtrace ». Vous y trouverez les checks de diagnostic qui ont échoué, pour vous aider à identifier les éventuels problèmes.

Si vous ne trouvez pas votre distribution, vous pouvez installer manuellement l’extension PHP.

Instrumentation automatique

Par défaut, le tracing est automatiquement activé. Une fois l’extension installée, ddtrace trace votre application et envoie les traces à l’Agent.

Par défaut, Datadog prend en charge tous les frameworks Web. L’instrumentation automatique fonctionne en modifiant l’exécution de PHP pour wrapper certaines fonctions et méthodes afin de les tracer. Le traceur PHP prend en charge l’instrumentation automatique pour plusieurs bibliothèques.

L’instrumentation automatique capture :

• Le temps d’exécution de la méthode
• Les données de trace pertinentes, telles que l’URL et les codes de réponse de statut pour les requêtes Web ou les requêtes SQL pour l’accès à la base de données
• Les exceptions non traitées, y compris les stack traces le cas échéant
• Le nombre total de traces (p. ex. les requêtes Web) transmises via le système

Remarque : si votre application n’utilise pas Composer ni un chargeur automatique enregistré avec spl_autoload_register(), définissez la variable d’environnement DD_TRACE_NO_AUTOLOADER=true pour activer l’instrumentation automatique.

Configuration

Le traceur PHP peut être configuré à l’aide de variables d’environnement.

Remarque : si vous utilisez l’instrumentation automatique du code (la méthode conseillée), rappelez-vous que le code instrumenté s’exécute avant le code utilisateur. Par conséquent, les variables d’environnement ci-dessous doivent être définies au niveau du serveur et mises à disposition de l’environnement d’exécution PHP avant l’exécution de tout code utilisateur. Par exemple, putenv() et les fichiers .env ne fonctionneraient pas.

Apache

Pour Apache avec php-fpm, utilisez le répertoire env de votre fichier de configuration www.conf pour configurer le traceur PHP. Exemple :

; Exemple pour passer la variable d'environnement de host SOME_ENV
; au processus PHP en tant que DD_AGENT_HOST
env[DD_AGENT_HOST] = $SOME_ENV
; Exemple pour passer la valeur 'my-app' au processus PHP
; en tant que DD_SERVICE
env[DD_SERVICE] = my-app

Vous pouvez également utiliser SetEnv depuis la configuration du serveur, le host virtuel, le répertoire ou le fichier .htaccess.

SetEnv DD_TRACE_DEBUG true

NGINX

Pour NGINX, utilisez la directive env dans le fichier www.conf de php-fpm. Exemple :

; Exemple pour passer la variable d'environnement de host SOME_ENV
; au processus PHP en tant que DD_AGENT_HOST
env[DD_AGENT_HOST] = $SOME_ENV
; Exemple pour passer la valeur 'my-app' au processus PHP
; en tant que DD_SERVICE
env[DD_SERVICE] = my-app

Remarque : si vous avez activé l’APM pour votre serveur NGINX, assurez-vous d’avoir correctement configuré le paramètre opentracing_fastcgi_propagate_context pour que le tracing distribué fonctionne correctement. Consultez la configuration de l’APM NGINX pour obtenir plus d’informations.

Serveur CLI PHP

Défini depuis la ligne de commande pour démarrer le serveur.

DD_TRACE_DEBUG=true php -S localhost:8888

Configuration des variables d’environnement

Noms des intégrations

Le tableau ci-dessous répertorie les noms de service par défaut pour chaque intégration. Modifiez les noms de service avec DD_SERVICE_MAPPING.

Utilisez ces noms lorsque vous définissez un paramètre pour une intégration spécifique, tel que DD_TRACE_<INTÉGRATION>_ANALYTICS_ENABLED. Exemple pour Laravel : DD_TRACE_LARAVEL_ANALYTICS_ENABLED.

Mapper les noms de ressources à une URL normalisée

Pour les intégrations de serveur et client HTTP, l’URL est utilisée afin de créer le nom de ressource de la trace, en suivant le format <MÉTHODE_REQUÊTE_HTTP> <URL_NORMALISÉE>. La chaîne de requête est supprimée de l’URL. Cela vous permet de gagner en visibilité sur les frameworks personnalisés qui ne sont pas instrumentés automatiquement en normalisant les URL et en regroupant les endpoints génériques sous une unique ressource.

Les ID numériques, les UUID (avec et sans tiret) et les hachages hexadécimaux de 32 à 512 octets sont automatiquement remplacés par le caractère ?.

Vous pouvez désactiver cette fonctionnalité avec DD_TRACE_URL_AS_RESOURCE_NAMES_ENABLED=false.

Mappage personnalisé de l’URL à la ressource

Certains cas ne sont pas couverts par la normalisation automatique appliquée.

Deux catégories de scénarios ne sont pas couvertes par la normalisation automatique :

• Le fragment de chemin à normaliser présente un format reproductible et peut se trouver partout dans l’URL, par exemple id<number> dans l’exemple ci-dessus. Ce scénario est couvert par le paramètre DD_TRACE_RESOURCE_URI_FRAGMENT_REGEX ci-dessous.
• Le fragment de chemin peut être n’importe quoi, et le fragment de chemin précédent indique qu’une valeur doit être normalisée. Par exemple, /cities/new-york nous indique que new-york doit être normalisé, car c’est le nom d’une ville. Ce scénario est couvert par les paramètres DD_TRACE_RESOURCE_URI_MAPPING_INCOMING et DD_TRACE_RESOURCE_URI_MAPPING_OUTGOING respectivement pour les requêtes entrantes et sortantes.

DD_TRACE_RESOURCE_URI_FRAGMENT_REGEX

Ce paramètre est une liste au format CSV d’expressions regex appliquées indépendamment à chaque fragment de chemin. Par exemple, si le paramètre DD_TRACE_RESOURCE_URI_FRAGMENT_REGEX est défini sur ^id\d+$ pour le premier exemple /using/prefix/id123/for/id, les expressions regex seront appliquées à tous les fragments using, prefix, id123, for et id. Le nom de ressource normalisé final sera GET /using/prefix/?/for/id.

Notez que plusieurs expressions régulières séparées par une virgule peuvent être ajoutées : ^id\d+$,code\d+$. La virgule , n’étant pas échappée, elle ne peut pas être utilisée dans l’expression régulière.

DD_TRACE_RESOURCE_URI_MAPPING_INCOMING et DD_TRACE_RESOURCE_URI_MAPPING_OUTGOING

Ce paramètre est une liste d’expressions au format CSV qui peut contenir une wildcard *. Par exemple, si vous ajoutez l’expression cities/*, cela signifie que chaque fois que le fragment cities est trouvé lors de l’analyse d’une URL, alors le fragment suivant (le cas échéant) sera remplacé par ?. Les expressions sont appliquées à toutes les profondeurs ; par conséquent, la règle suivante entraînera la normalisation de /cities/new-york et /nested/cities/new-york dans le tableau ci-dessus.

Les expressions peuvent être appliquées à une partie d’un fragment spécifique. Par exemple, path/*-fix normalisera l’URL /some/path/changing-fix/nested en /some/path/?-fix/nested

Notez que DD_TRACE_RESOURCE_URI_MAPPING_INCOMING s’applique uniquement aux requêtes entrantes (par exemple, les frameworks Web), tandis que DD_TRACE_RESOURCE_URI_MAPPING_OUTGOING s’applique uniquement aux requêtes sortantes (par exemple, les requêtes curl et guzzle).

Mise à niveau

Pour mettre à niveau le traceur PHP, téléchargez la dernière version et suivez les mêmes étapes que lors de l'installation de l’extension.

Remarque : si vous utilisez une mise en cache secondaire dans OPcache en définissant le paramètre opcache.file_cache, supprimez le dossier de cache.

Suppression

Pour supprimer le tracer PHP :

1. Pour php-fpm, arrêtez le service php-fpm ou le serveur Web Apache.
2. Dissociez les fichiers 98-ddtrace.ini and 99-ddtrace-custom.ini de votre dossier de configuration PHP.
3. Pour php-fpm, redémarrez le service php-fpm ou le serveur Web Apache.

Remarque : si vous utilisez une mise en cache secondaire dans OPcache en définissant le paramètre opcache.file_cache, supprimez le dossier de cache.

Résoudre un crash d’application

Si jamais le traceur PHP entraîne le crash de votre application, généralement en raison d’une erreur de segmentation, il est préférable d’obtenir un core dump et de contacter l’assistance Datadog.

Obtenir un core dump

Il peut s’avérer difficile d’obtenir un core dump pour les applications PHP, notamment pour PHP-FPM. Voici quelques conseils pour vous aider à obtenir un core dump :

1. Passez en revue le log d’erreur de l’application pour déterminer si PHP-FPM a généré un core dump :
   • Recherchez l’expression (SIGSEGV - core dumped), afin de trouver un message confirmant l’enregistrement d’un core dump. Exemple : WARNING: [pool www] child <pid> exited on signal 11 (SIGSEGV - core dumped) after <duration> seconds from start.
   • Recherchez l’expression (SIGSEGV), afin de trouver un message confirmant le non-enregistrement d’un core dump. Exemple : WARNING: [pool www] child <pid> exited on signal 11 (SIGSEGV) after <duration> seconds from start.
2. Accédez au core dump en exécutant cat /proc/sys/kernel/core_pattern. La valeur par défaut étant généralement core, un fichier core est donc généré dans le dossier racine Web.

Si aucun core dump n’a été généré, vérifiez les configurations suivantes et modifiez-les en fonction de vos besoins :

1. Si /proc/sys/kernel/core_pattern contient un chemin comprenant des répertoires imbriqués, assurez-vous que le chemin d’accès avec les répertoires complets existe.
2. Si l’utilisateur qui exécute les workers du pool PHP-FPM n’est pas root (www-data est généralement utilisé), attribuez à cet utilisateur des autorisations d’écriture dans le répertoire des core dumps.
3. Assurez-vous que la valeur de /proc/sys/fs/suid_dumpable n’est pas 0. Définissez-la sur 1 ou 2, sauf si vous exécutez le pool de workers PHP-FPM en tant que root. Vérifiez vos options avec votre administrateur système.
4. Assurez-vous que la valeur de rlimit_core est adéquate dans la configuration du pool PHP-FPM. Vous pouvez retirer cette limite, avec rlimit_core = unlimited.
5. Assurez-vous que la valeur de ulimit est adéquate dans votre système. Vous pouvez retirer cette limite, avec ulimit -c unlimited.
6. Si votre application s’exécute dans un conteneur Docker et que vous souhaitez modifier /proc/sys/*, vous devez effectuer les changements sur la machine du host. Contactez votre administrateur système pour découvrir les différentes options qui s’offrent à vous. Si vous le pouvez, essayez de reproduire le problème dans vos environnements staging ou test.

Pour aller plus loin

Documentation, liens et articles supplémentaires utiles:

Surveillance PHP avec l'APM et le tracing distribué de DatadogBLOG Code sourceGITHUB Explorer vos services, ressources et tracesDOCUMENTATION Utilisation avancéeDOCUMENTATION