Lorsque l’Agent et vos services s’exécutent sur un host réel ou virtuel, Datadog injecte la bibliothèque de tracing à partir d’une bibliothèque préchargée qui remplace les appels par execve. Tous les processus lancés récemment sont interceptés et la bibliothèque d’instrumentation indiquée est injectée dans les services.

Remarque : l’injection sous arm64 n’est pas prise en charge.

Installer à la fois l’injection de bibliothèque et l’Agent Datadog

Prérequis : vous devez disposer d’un host exécutant Linux.

Si l’Agent Datadog n’est pas encore installé sur le host, ou si vous souhaitez mettre à niveau votre installation de l’Agent Datadog, utilisez le script d’installation dédié pour installer à la fois les bibliothèques d’injection et l’Agent Datadog :

DD_APM_INSTRUMENTATION_ENABLED=host DD_API_KEY=<VOTRE_CLÉ> DD_SITE="<VOTRE_SITE>" bash -c "$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)"

Par défaut, l’exécution du script entraîne la prise en charge de Java, Node.js, Python, Ruby et .NET. Si vous souhaitez spécifier les langages à prendre en charge, définissez également la variable d’environnement DD_APM_INSTRUMENTATION_LIBRARIES (valeurs autorisées : java, js, python, ruby et dotnet). Pour spécifier plusieurs langages, séparez les valeurs par des virgules :

DD_APM_INSTRUMENTATION_LIBRARIES="java,js" DD_APM_INSTRUMENTATION_ENABLED=host DD_API_KEY=<VOTRE_CLÉ> DD_SITE="<VOTRE_SITE>" bash -c "$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)"

Quittez et ouvrez un nouveau shell pour utiliser la bibliothèque d’injection.

Installer uniquement l’injection de bibliothèque

Prérequis :

• Un host exécutant Linux
• Une installation récente de l’Agent Datadog v7.

Si l’Agent Datadog est déjà installé sur le host, vous pouvez installer uniquement les bibliothèques d’injection :

1. Vérifiez que votre Agent est en cours d’exécution.

2. Installez la bibliothèque en utilisant l’un des jeux de commandes suivants, où <LANG> correspond à java, js, dotnet, python, ruby ou all :

   Pour Ubuntu, Debian ou d’autres distributions Linux basées sur Debian :

   sudo apt-get update
   sudo apt-get install datadog-apm-inject datadog-apm-library-<LANG>
   

   Pour CentOS, RedHat ou d’autres distributions reposant sur yum/RPM :

   sudo yum makecache
   sudo yum install datadog-apm-inject datadog-apm-library-<LANG>
   

3. Exécutez la commande dd-host-install.

4. Quittez et ouvrez un nouveau shell pour utiliser la bibliothèque préchargée.

Une fois l’injection du host activée, vérifiez que les lignes suivantes se trouvent à la fin du fichier de configuration /etc/datadog-agent/datadog.yaml :

# COMMENCER LA CONFIGURATION LD PRELOAD
apm_config:
  receiver_socket: /opt/datadog/apm/inject/run/apm.socket
use_dogstatsd: true
dogstatsd_socket: /opt/datadog/apm/inject/run/dsd.socket
remote_configuration:
  enabled: true
# TERMINER LA CONFIGURATION LD PRELOAD

Si ces propriétés sont définies sur d’autres valeurs, remplacez leur valeur afin qu’elles correspondent à celles indiquées ci-dessus. Si vous ne voyez pas ces propriétés, ajoutez-les. Redémarrez ensuite l’Agent Datadog.

Étapes suivantes

Si vous ne l’avez pas déjà fait, installez votre application ainsi que les langages ou bibliothèques nécessaires.

Lorsque vous lancez une application rédigée dans un autre langage, l’injection s’effectue automatiquement, avec le tracing activé.

Configurer l’injection

Procédez de l’une des façons suivantes pour configurer l’injection de host :

• Définissez les variables d’environnement sur le processus en cours de lancement.
• Spécifiez la configuration de l’injection de host dans le fichier /etc/datadog-agent/inject/host_config.yaml.

Les valeurs des variables d’environnement remplacent les paramètres du fichier de configuration pour les processus concernés.

Fichier de configuration

Exemple

---
log_level: debug
output_paths:
  - file:///tmp/host_injection.log
env: dev
config_sources: BASIC

Variables d’environnement

Les variables d’environnement suivantes permettent de configurer l’injection de bibliothèque. Pour les passer, utilisez export via la ligne de commande (export DD_CONFIG_SOURCES=BASIC), la configuration du shell ou la commande de lancement.

Chacun des champs du fichier de configuration correspond à une variable d’environnement. Les variables d’environnement sont lues à partir de l’environnement du processus en cours de lancement et affectent uniquement ce processus.

La variable d’environnement DD_APM_INSTRUMENTATION_DEBUG peut uniquement être définie sur les valeurs true et false (valeur par défaut : false). Si vous la définissez sur true, log_level a pour valeur debug. Si vous la définissez sur false (ou ne la définissez pas), la valeur de log_level spécifiée dans le fichier de configuration est utilisée. Le niveau de log debug est le seul niveau pouvant être défini avec la variable d’environnement.

La variable d’environnement DD_INSTRUMENT_SERVICE_WITH_APM détermine si l’injection doit ou non être activée. Par défaut, sa valeur est TRUE. Définissez-la sur FALSE pour désactiver le processus d’injection de bibliothèque.

Sources de configuration

Par défaut, les paramètres suivants sont activés au sein d’un processus instrumenté :

• Le tracing
• L’injection de logs, tant que l’application applique une journalisation structurée (généralement, au format JSON). Pour que les traces s’affichent dans des logs non structurés, vous devez modifier la configuration des logs de votre application, afin d’inclure des placeholders pour l’ID de trace et l’ID de span. Consultez la section Associer les logs aux traces pour en savoir plus.
• Les métriques de santé
• Les métriques runtime

Vous pouvez modifier ces paramètres pour l’ensemble des processus instrumentés. Pour ce faire, définissez la propriété config_sources dans le fichier de configuration. Pour modifier les paramètres pour un seul processus, définissez la variable d’environnement DD_CONFIG_SOURCES du processus. Voici les paramètres autorisés pour les sources de configuration :

Les valeurs BASIC, LOCAL et BLOB doivent être écrites en majuscules.

Les valeurs des sources de configuration peuvent être séparées par des points-virgules afin de spécifier plusieurs emplacements possibles. La première configuration qui ne renvoie pas d’erreur est utilisée. Les configurations ne sont pas combinées à partir de plusieurs sources de configuration. L’exemple suivant vérifie si un compartiment S3 comporte une configuration, passe ensuite au système de fichiers local, puis utilise la configuration par défaut intégrée :

DD_CONFIG_SOURCES=BLOB:s3://config_bucket/my_process_config.yaml?region=us-east-1;LOCAL:/opt/config/my_process_config.yaml;BASIC

Prise en charge du stockage de blobs

Voici la liste des solutions de stockage de blobs prises en charge :

• Amazon S3 : définissez l’URL à l’aide du préfixe s3://. Si l’authentification est effectuée via la CLI AWS, ces identifiants sont utilisés. Consultez la documentation sur le SDK AWS (en anglais) pour en savoir plus sur la configuration d’identifiants à l’aide de variables d’environnement.
• GCP GCS : définissez l’URL avec le préfixe gs://. Les identifiants par défaut de l’application sont utilisés. L’authentification s’effectue via la commande gcloud auth application-default login. Consultez la documentation relative à l’authentification de Google Cloud pour en savoir plus sur la configuration d’identifiants à l’aide de variables d’environnement.
• Stockage Blob Azure : définissez l’URL avec le préfixe azblob://, et pointez vers un nom de conteneur de stockage. Les identifiants figurant dans AZURE_STORAGE_ACCOUNT (à savoir, le nom du compartiment), ainsi que dans AZURE_STORAGE_KEY et/ou AZURE_STORAGE_SAS_TOKEN, sont utilisés. Pour en savoir plus sur la configuration des paramètres BLOB et LOCAL, consultez la rubrique Spécifier la source de configuration.

Spécifier la source de configuration

Le fichier de configuration des paramètres LOCAL et BLOB peut être converti au format JSON :

{
    "version": 1,
    "service_language": "<LANG>",
    "tracing_enabled": true,
    "log_injection_enabled": true,
    "health_metrics_enabled": true,
    "runtime_metrics_enabled": true,
    "tracing_sampling_rate": 1.0,
    "tracing_rate_limit": 1,
    "tracing_tags": ["a=b", "foo"],
    "tracing_service_mapping": [
        { "from_key": "mysql", "to_name": "super_db"},
        { "from_key": "postgres", "to_name": "my_pg"}
    ],
    "tracing_agent_timeout": 1,
    "tracing_header_tags": [
        {"header": "HEADER", "tag_name":"tag"}
    ],
    "tracing_partial_flush_min_spans": 1,
    "tracing_debug": true,
    "tracing_log_level": "debug",
}

Ou au format YAML :

---
version: 1
service_language: <LANG>
tracing_enabled: true
log_injection_enabled: true
health_metrics_enabled: true
runtime_metrics_enabled: true
tracing_sampling_rate: 1.0
tracing_rate_limit: 1
tracing_tags:
- a=b
- foo
tracing_service_mapping:
- from_key: mysql
  to_name: super_db
- from_key: postgres
  to_name: my_pg
tracing_agent_timeout: 1
tracing_header_tags:
- header: HEADER
  tag_name: tag
tracing_partial_flush_min_spans: 1
tracing_debug: true
tracing_log_level: debug

version a toujours pour valeur 1. Il s’agit de la version du schéma de configuration utilisé, et non de la version du contenu.

Si vous connaissez le langage utilisé, définissez service_language sur l’une des valeurs suivantes :

• java
• node
• dotnet
• python
• ruby

Si plusieurs langages sont utilisés, ne définissez pas service_language.

Le tableau suivant répertorie les valeurs de configuration d’injection et les options de configuration des bibliothèques de tracing correspondantes :

Les options de configuration des bibliothèques de traceur qui ne sont pas mentionnées dans la configuration de l’injection peuvent tout de même être utilisées normalement dans les propriétés ou les variables d’environnement.

Paramètres de la configuration BASIC

Les paramètres de configuration BASIC correspondent aux paramètres YAML suivants :

---
version: 1
tracing_enabled: true
log_injection_enabled: true
health_metrics_enabled: true
runtime_metrics_enabled: true

Lancer vos services

Lancez vos services, en indiquant la configuration de bibliothèque préchargée dans la commande de lancement. Si le paramètre DD_CONFIG_SOURCES n’est pas spécifié, la valeur définie pour config_sources dans le fichier de configuration /etc/datadog-agent/inject/host_config.yaml est utilisée. Si ce paramètre n’est lui-même pas défini, DD_CONFIG_SOURCES prend pour valeur BASIC :

Exemple d’application Java :

java -jar <SERVICE_1>.jar &
DD_CONFIG_SOURCES=LOCAL:/etc/<SERVICE_2>/config.yaml;BASIC java -jar <SERVICE_2>.jar &

Exemple d’application Node :

node index.js &
DD_CONFIG_SOURCES=LOCAL:/etc/<SERVICE_2>/config.yaml;BASIC node index.js &

Exemple d’application .NET :

dotnet <SERVICE_1>.dll &
DD_CONFIG_SOURCES=LOCAL:/etc/<SERVICE_2>/config.yaml;BASIC dotnet <SERVICE_2>.dll &

Exemple d’application Python :

python <SERVICE_1>.py &
DD_CONFIG_SOURCES=LOCAL:/etc/<SERVICE_2>/config.yaml;BASIC python <SERVICE_2>.py &

Entraînez votre application afin qu’elle puisse commencer à générer des données de télémétrie, qui sont représentées sous forme de traces dans APM.

Lorsque votre Agent s’exécute sur un host et que vos services s’exécutent dans des conteneurs, Datadog injecte la bibliothèque de tracing en interceptant la création de conteneur et en configurant le conteneur Docker.

Tous les processus lancés récemment sont interceptés et la bibliothèque d’instrumentation indiquée est injectée dans les services.

Remarque : l’injection sous arm64 n’est pas prise en charge.

Installer à la fois l’injection de bibliothèque et l’Agent Datadog

Prérequis :

• Un host exécutant Linux
• Docker Engine

Si l’Agent Datadog n’est pas encore installé sur le host, ou si vous souhaitez mettre à niveau votre installation de l’Agent Datadog, utilisez le script d’installation dédié pour installer à la fois les bibliothèques d’injection et l’Agent Datadog :

DD_APM_INSTRUMENTATION_ENABLED=all DD_API_KEY=<VOTRE_CLÉ> DD_SITE="<VOTRE_SITE>" bash -c "$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)"

Par défaut, l’exécution du script entraîne la prise en charge de Java, Node.js, Python, Ruby et .NET. Si vous souhaitez spécifier les langages à prendre en charge, définissez également la variable d’environnement DD_APM_INSTRUMENTATION_LIBRARIES (valeurs autorisées : java, js, python, ruby et dotnet). Pour spécifier plusieurs langages, séparez les valeurs par des virgules :

DD_APM_INSTRUMENTATION_LIBRARIES="java,js" DD_APM_INSTRUMENTATION_ENABLED=all DD_API_KEY=<VOTRE_CLÉ> DD_SITE="<VOTRE_SITE>" bash -c "$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)"

Installer uniquement l’injection de bibliothèque

Prérequis :

• Un host exécutant Linux
• Une installation récente de l’Agent Datadog v7
• Docker Engine

Si l’Agent Datadog est déjà installé sur le host, vous pouvez installer uniquement les bibliothèques d’injection :

1. Vérifiez que votre Agent est en cours d’exécution.

2. Installez la bibliothèque en utilisant l’un des jeux de commandes suivants, où <LANG> correspond à java, js, dotnet, python, ruby ou all :

   Pour Ubuntu, Debian ou d’autres distributions Linux basées sur Debian :

   sudo apt-get update
   sudo apt-get install datadog-apm-inject datadog-apm-library-<LANG>
   

   Pour CentOS, RedHat ou d’autres distributions reposant sur yum/RPM :

   sudo yum makecache
   sudo yum install datadog-apm-inject datadog-apm-library-<LANG>
   

3. Exécutez la commande dd-host-container-install.

Une fois l’injection du host activée, vérifiez que les lignes suivantes se trouvent à la fin du fichier de configuration /etc/datadog-agent/datadog.yaml :

# COMMENCER LA CONFIGURATION LD PRELOAD
apm_config:
  receiver_socket: /opt/datadog/apm/inject/run/apm.socket
use_dogstatsd: true
dogstatsd_socket: /opt/datadog/apm/inject/run/dsd.socket
remote_configuration:
  enabled: true
# TERMINER LA CONFIGURATION LD PRELOAD

Si ces propriétés sont définies sur d’autres valeurs, remplacez leur valeur afin qu’elles correspondent à celles indiquées ci-dessus. Si vous ne voyez pas ces propriétés, ajoutez-les. Redémarrez ensuite l’Agent Datadog.

Configurer l’injection Docker

Si la configuration par défaut ne vous convient pas, vous devez modifier /etc/datadog-agent/inject/docker_config.yaml et ajoutez la configuration YAML suivante pour l’injection :

---
log_level: debug
output_paths:
- stderr
config_sources: BASIC

config_sources

Activez ou désactivez l’injection de bibliothèque et spécifiez une liste d’emplacements triée et séparée par des points-virgules où la configuration est stockée. La première valeur renvoyée sans erreur est utilisée. La configuration n’est pas unifiée à partir de toutes les sources de configuration. Voici la liste des valeurs autorisées :

• BLOB:<URL> : chargez la configuration à partir d’un stockage de blobs (compatible avec S3) situé à l’adresse <URL>.
• LOCAL:<CHEMIN> : chargez la configuration à partir d’un fichier du système de fichiers local situé à l’emplacement <CHEMIN>.
• BASIC : utilisez les valeurs par défaut. Si config_sources n’est pas spécifié, cette configuration est utilisée.
  

Les valeurs BASIC, LOCAL et BLOB doivent être écrites en majuscules.

Les valeurs des sources de configuration peuvent être séparées par des points-virgules afin de spécifier plusieurs emplacements possibles. La première configuration qui ne renvoie pas d’erreur est utilisée. La configuration n’est pas unifiée à partir de plusieurs sources de configuration. L’exemple suivant vérifie si un compartiment S3 comporte une configuration, passe ensuite au système de fichiers local, puis utilise la configuration par défaut intégrée :

config_sources: BLOB:s3://config_bucket/my_process_config.yaml?region=us-east-1;LOCAL:/opt/config/my_process_config.yaml;BASIC

Pour en savoir plus sur la configuration des paramètres BLOB ou LOCAL, consultez la rubrique Spécifier la source de configuration.

log_level

Définissez ce paramètre sur debug pour consigner en détail ce qui se passe ou sur info, warn ou error pour écrire moins d’informations.
Valeur par défaut : info

output_paths

La liste des emplacements dans lesquels les logs sont rédigés.
Valeur par défaut : stderr

Facultatif : env

Spécifie le tag DD_ENV pour les conteneurs exécutés dans Docker. Exemples : dev, prod, staging.
Valeur par défaut : aucune.

Spécifier la source de configuration

Si vous spécifiez la source de configuration BLOB ou LOCAL, créez un fichier JSON ou YAML et fournissez la configuration au format JSON :

{
    "version": 1,
    "service_language": "<LANG>",
    "tracing_enabled": true,
    "log_injection_enabled": true,
    "health_metrics_enabled": true,
    "runtime_metrics_enabled": true,
    "tracing_sampling_rate": 1.0,
    "tracing_rate_limit": 1,
    "tracing_tags": ["a=b", "foo"],
    "tracing_service_mapping": [
        { "from_key": "mysql", "to_name": "super_db"},
        { "from_key": "postgres", "to_name": "my_pg"}
    ],
    "tracing_agent_timeout": 1,
    "tracing_header_tags": [
        {"header": "HEADER", "tag_name":"tag"}
    ],
    "tracing_partial_flush_min_spans": 1,
    "tracing_debug": true,
    "tracing_log_level": "debug",
}

Ou au format YAML :

---
version: 1
service_language: <LANGAGE>
tracing_enabled: true
log_injection_enabled: true
health_metrics_enabled: true
runtime_metrics_enabled: true
tracing_sampling_rate: 1.0
tracing_rate_limit: 1
tracing_tags:
- a=b
- foo
tracing_service_mapping:
- from_key: mysql
  to_name: super_db
- from_key: postgres
  to_name: my_pg
tracing_agent_timeout: 1
tracing_header_tags:
- header: HEADER
  tag_name: tag
tracing_partial_flush_min_spans: 1
tracing_debug: true
tracing_log_level: debug

Définissez service_language sur l’une des valeurs suivantes :

• java
• node
• dotnet
• python
• ruby

Dans ce fichier de configuration, version a toujours pour valeur 1. Il s’agit de la version du schéma de configuration utilisé, et non de la version du contenu.

Le tableau suivant répertorie les valeurs de configuration d’injection et les options de configuration des bibliothèques de tracing correspondantes :

Les options de configuration des bibliothèques de traceur qui ne sont pas mentionnées dans la configuration de l’injection peuvent tout de même être utilisées normalement dans les propriétés ou les variables d’environnement.

Prise en charge du stockage de blobs

Voici la liste des solutions de stockage de blobs prises en charge :

• Amazon S3 : définissez l’URL à l’aide du préfixe s3://. Si l’authentification est effectuée via la CLI AWS, ces identifiants sont utilisés. Consultez la documentation sur le SDK AWS (en anglais) pour en savoir plus sur la configuration d’identifiants à l’aide de variables d’environnement.
• GCP GCS : définissez l’URL avec le préfixe gs://. Les identifiants par défaut de l’application sont utilisés. L’authentification s’effectue via la commande gcloud auth application-default login. Consultez la documentation relative à l’authentification de Google Cloud pour en savoir plus sur la configuration d’identifiants à l’aide de variables d’environnement.
• Stockage Blob Azure : définissez l’URL avec le préfixe azblob://, et pointez vers un nom de conteneur de stockage. Les identifiants figurant dans AZURE_STORAGE_ACCOUNT (à savoir, le nom du compartiment), ainsi que dans AZURE_STORAGE_KEY et/ou AZURE_STORAGE_SAS_TOKEN, sont utilisés. Pour en savoir plus sur la configuration des paramètres BLOB et LOCAL, consultez la rubrique Spécifier la source de configuration.

Paramètres de la configuration BASIC

Les paramètres de configuration BASIC correspondent aux paramètres YAML suivants :

---
version: 1
tracing_enabled: true
log_injection_enabled: true
health_metrics_enabled: true
runtime_metrics_enabled: true

Spécifier des tags de service unifié sur les conteneurs

Si les variables d’environnement DD_ENV, DD_SERVICE ou DD_VERSION sont spécifiées dans une image de conteneur de service, ces valeurs sont utilisées pour taguer les données de télémétrie du conteneur.

Si ces variables ne sont pas spécifiées, DD_ENV utilise, le cas échéant, la valeur env définie dans le fichier de configuration /etc/datadog-agent/inject/docker_config.yaml. DD_SERVICE est récupéré à partir du nom de l’image Docker. Pour une image my-service:1.0, le tag DD_SERVICE de my-service est appliqué.

Lancer vos services

Lancez votre Agent et vos services conteneurisés comme vous le feriez en temps normal.

Entraînez votre application afin qu’elle puisse commencer à générer des données de télémétrie, qui sont représentées sous forme de traces dans APM.

Lorsque votre Agent et vos services s’exécutent dans des conteneurs Docker distincts sur le même host, Datadog injecte la bibliothèque de tracing en interceptant la création du conteneur et en configurant le conteneur Docker.

Tous les processus lancés récemment sont interceptés et la bibliothèque d’instrumentation spécifiée est injectée dans les services.

Prérequis :

• Docker Engine

Remarque : l’injection sous arm64 n’est pas prise en charge.

Installer la bibliothèque préchargée

Utilisez le script shell install_script_agent7.sh pour installer automatiquement la prise en charge de l’injection Docker. Vous devez au préalable avoir installé Docker sur la machine du host.

DD_APM_INSTRUMENTATION_ENABLED=docker DD_NO_AGENT_INSTALL=true bash -c "$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)"

Cela permet d’installer les bibliothèques de tous les langages pris en charge. Pour installer seulement les bibliothèques de certains langages, définissez la variable d’environnement DD_APM_INSTRUMENTATION_LIBRARIES. Les valeurs java, js, python, ruby et dotnet sont autorisées :

DD_APM_INSTRUMENTATION_LIBRARIES="java:1.25.0,python" DD_APM_INSTRUMENTATION_ENABLED=docker DD_NO_AGENT_INSTALL=true bash -c "$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)"

Configurer l’injection Docker

Modifiez /etc/datadog-agent/inject/docker_config.yaml et ajoutez la configuration YAML suivante pour l’injection :

---
log_level: debug
output_paths:
- stderr
config_sources: BASIC

config_sources

Activez ou désactivez l’injection de bibliothèque et spécifiez une liste d’emplacements triée et séparée par des points-virgules où la configuration est stockée. La première valeur renvoyée sans erreur est utilisée. La configuration n’est pas unifiée à partir de toutes les sources de configuration. Voici la liste des valeurs autorisées :

• BLOB:<URL> : chargez la configuration à partir d’un stockage de blobs (compatible avec S3) situé à l’adresse <URL>.
• LOCAL:<CHEMIN> : chargez la configuration à partir d’un fichier du système de fichiers local situé à l’emplacement <CHEMIN>.
• BASIC : utilisez les valeurs par défaut. Si config_sources n’est pas spécifié, cette configuration est utilisée.
  

Les valeurs BASIC, LOCAL et BLOB doivent être écrites en majuscules.

Les valeurs des sources de configuration peuvent être séparées par des points-virgules afin de spécifier plusieurs emplacements possibles. La première configuration qui ne renvoie pas d’erreur est utilisée. La configuration n’est pas unifiée à partir de plusieurs sources de configuration. L’exemple suivant vérifie si un compartiment S3 comporte une configuration, passe ensuite au système de fichiers local, puis utilise la configuration par défaut intégrée :

config_sources: BLOB:s3://config_bucket/my_process_config.yaml?region=us-east-1;LOCAL:/opt/config/my_process_config.yaml;BASIC

Pour en savoir plus sur la configuration des paramètres BLOB ou LOCAL, consultez la rubrique Spécifier la source de configuration.

log_level

Définissez ce paramètre sur debug pour consigner en détail ce qui se passe ou sur info pour consigner moins d’informations.

output_paths

La liste des emplacements dans lesquels les logs sont rédigés.
Valeur par défaut : stderr

Facultatif : env

Spécifie le tag DD_ENV pour les conteneurs exécutés dans Docker. Exemples : dev, prod, staging.
Valeur par défaut : aucune.

Spécifier la source de configuration

Si vous spécifiez la source de configuration BLOB ou LOCAL, créez un fichier JSON ou YAML et fournissez la configuration au format JSON :

{
    "version": 1,
    "service_language": "<LANGAGE>",
    "tracing_enabled": true,
    "log_injection_enabled": true,
    "health_metrics_enabled": true,
    "runtime_metrics_enabled": true,
    "tracing_sampling_rate": 1.0,
    "tracing_rate_limit": 1,
    "tracing_tags": ["a=b", "foo"],
    "tracing_service_mapping": [
        { "from_key": "mysql", "to_name": "super_db"},
        { "from_key": "postgres", "to_name": "my_pg"}
    ],
    "tracing_agent_timeout": 1,
    "tracing_header_tags": [
        {"header": "HEADER", "tag_name":"tag"}
    ],
    "tracing_partial_flush_min_spans": 1,
    "tracing_debug": true,
    "tracing_log_level": "debug",
}

Ou au format YAML :

---
version: 1
service_language: <LANGAGE>
tracing_enabled: true
log_injection_enabled: true
health_metrics_enabled: true
runtime_metrics_enabled: true
tracing_sampling_rate: 1.0
tracing_rate_limit: 1
tracing_tags:
- a=b
- foo
tracing_service_mapping:
- from_key: mysql
  to_name: super_db
- from_key: postgres
  to_name: my_pg
tracing_agent_timeout: 1
tracing_header_tags:
- header: HEADER
  tag_name: tag
tracing_partial_flush_min_spans: 1
tracing_debug: true
tracing_log_level: debug

Définissez service_language sur l’une des valeurs suivantes :

• java
• node
• dotnet
• python
• ruby

Dans ce fichier de configuration, version a toujours pour valeur 1. Il s’agit de la version du schéma de configuration utilisé, et non de la version du contenu.

Le tableau suivant répertorie les valeurs de configuration d’injection et les options de configuration des bibliothèques de tracing correspondantes :

Les options de configuration des bibliothèques de traceur qui ne sont pas mentionnées dans la configuration de l’injection peuvent tout de même être utilisées normalement dans les propriétés ou les variables d’environnement.

Prise en charge du stockage de blobs

Voici la liste des solutions de stockage de blobs prises en charge :

• Amazon S3 : définissez l’URL à l’aide du préfixe s3://. Si l’authentification est effectuée via la CLI AWS, ces identifiants sont utilisés. Consultez la documentation sur le SDK AWS (en anglais) pour en savoir plus sur la configuration d’identifiants à l’aide de variables d’environnement.
• GCP GCS : définissez l’URL avec le préfixe gs://. Les identifiants par défaut de l’application sont utilisés. L’authentification s’effectue via la commande gcloud auth application-default login. Consultez la documentation relative à l’authentification de Google Cloud pour en savoir plus sur la configuration d’identifiants à l’aide de variables d’environnement.
• Stockage Blob Azure : définissez l’URL avec le préfixe azblob://, et pointez vers un nom de conteneur de stockage. Les identifiants figurant dans AZURE_STORAGE_ACCOUNT (à savoir, le nom du compartiment), ainsi que dans AZURE_STORAGE_KEY et/ou AZURE_STORAGE_SAS_TOKEN, sont utilisés. Pour en savoir plus sur la configuration des paramètres BLOB et LOCAL, consultez la rubrique Spécifier la source de configuration.

Paramètres de la configuration BASIC

Les paramètres de configuration BASIC correspondent aux paramètres YAML suivants :

---
version: 1
tracing_enabled: true
log_injection_enabled: true
health_metrics_enabled: true
runtime_metrics_enabled: true

Configurer l’Agent

Dans le fichier Docker Compose qui lance vos conteneurs, utilisez les paramètres suivants pour l’Agent., en définissant en toute sécurité votre propre clé d’API Datadog pour ${DD_API_KEY}

  dd-agent:
    container_name: dd-agent
    image: datadog/agent:7
    environment:
      - DD_API_KEY=${DD_API_KEY}
      - DD_APM_ENABLED=true
      - DD_APM_NON_LOCAL_TRAFFIC=true
      - DD_DOGSTATSD_NON_LOCAL_TRAFFIC=true
      - DD_APM_RECEIVER_SOCKET=/opt/datadog/apm/inject/run/apm.socket
      - DD_DOGSTATSD_SOCKET=/opt/datadog/apm/inject/run/dsd.socket
    volumes:
      - /opt/datadog/apm:/opt/datadog/apm
      - /var/run/docker.sock:/var/run/docker.sock:ro

Spécifier des tags de service unifié sur les conteneurs

Si les variables d’environnement DD_ENV, DD_SERVICE ou DD_VERSION sont spécifiées dans une image de conteneur de service, ces valeurs sont utilisées pour taguer les données de télémétrie du conteneur.

Si ces variables ne sont pas spécifiées, DD_ENV utilise, le cas échéant, la valeur env définie dans le fichier de configuration /etc/datadog-agent/inject/docker_config.yaml. DD_SERVICE est récupéré à partir du nom de l’image Docker. Pour une image my-service:1.0, le tag DD_SERVICE de my-service est appliqué.

Lancer l’Agent sur Docker

Le conteneur dd-agent doit être lancé avant tout conteneur de service. Exécutez ce qui suit :

docker-compose up -d dd-agent

Lancer vos services

Lancez vos services conteneurisés comme vous le feriez en temps normal.

Entraînez votre application afin qu’elle puisse commencer à générer des données de télémétrie, qui sont représentées sous forme de traces dans APM.

1. Ajoutez la variable d’environnement DD_INSTRUMENT_SERVICE_WITH_APM à la commande de lancement du service :

   docker run -e DD_INSTRUMENT_SERVICE_WITH_APM=false
   

   Copy
2. Redémarrez le service.

1. Désinstallez l’injection de bibliothèque locale :

   dd-container-install --uninstall
   

   Copy
2. Redémarrez Docker :

   systemctl restart docker
   

   Copy
   Sinon, utilisez une commande équivalente pour votre environnement.