Configuration avancée de l'Agent Datadog sur Kubernetes

Présentation

Une fois l’Agent Datadog installé dans votre environnement Kubernetes, d’autres options de configuration sont disponibles.

Activez Datadog pour recueillir les données suivantes :

Autres fonctionnalités

Configurations supplémentaires

Activer APM et le tracing

Si vous avez installé Kubernetes avec l’Operator Datadog ou avec Helm, la solution APM est activée par défaut.

Pour en savoir plus, consultez la section Collecte de traces APM avec Kubernetes.

Activer la collecte d’événements Kubernetes

Utilisez l’Agent de cluster Datadog pour recueillir vos événements Kubernetes.

La collecte d’événements est activée par défaut par l’Operator Datadog. Pour configurer cette fonctionnalité, utilisez le paramètre features.eventCollection.collectKubernetesEvents dans votre fichier de configuration datadog-agent.yaml.

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <CLÉ_API_DATADOG>
    site: <SITE_DATADOG>

  features:
    eventCollection:
      collectKubernetesEvents: true

Pour recueillir des événements Kubernetes avec l’Agent de cluster Datadog, assurez-vous que les options clusterAgent.enabled, datadog.collectEvents et clusterAgent.rbac.create sont définies sur true dans votre fichier datadog-values.yaml.

datadog:
  collectEvents: true
clusterAgent:
  enabled: true
  rbac: 
    create: true

Si vous ne souhaitez pas utiliser l’Agent de cluster, vous pouvez vous servir d’un Agent de nœud pour recueillir les événements Kubernetes en définissant les options datadog.leaderElection, datadog.collectEvents et agents.rbac.create sur true dans votre fichier datadog-values.yaml.

datadog:
  leaderElection: true
  collectEvents: true
agents:
  rbac:
    create: true

Pour les configurations reposant sur un DaemonSet, consultez la documentation relative à la collecte d’événements avec l’Agent de cluster et un Daemonset.

Activer la collecte de données NPM

Dans votre fichier datadog-agent.yaml, définissez features.npm.enabled sur true.

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <CLÉ_API_DATADOG>

  features:
    npm:
      enabled: true

Ensuite, appliquez la nouvelle configuration :

kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml

Modifiez votre fichier datadog-values.yaml en indiquant la configuration suivante :

datadog:
  # (...)
  networkMonitoring:
    enabled: true

Mettez ensuite à niveau votre chart Helm :

helm upgrade -f datadog-values.yaml <NOM_VERSION> datadog/datadog

Pour en savoir plus, consultez la section Network Performance Monitoring.

Activer la collecte de logs

Dans votre fichier datadog-agent.yaml, définissez features.logCollection.enabled et features.logCollection.containerCollectAll sur true.

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <CLÉ_API_DATADOG>

  features:
    logCollection:
      enabled: true
      containerCollectAll: true

Ensuite, appliquez la nouvelle configuration :

kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml

Modifiez votre fichier datadog-values.yaml en indiquant la configuration suivante :

datadog:
  # (...)
  logs:
    enabled: true
    containerCollectAll: true

Mettez ensuite à niveau votre chart Helm :

helm upgrade -f datadog-values.yaml <NOM_VERSION> datadog/datadog

Pour en savoir plus, consultez la section Collecte de logs Kubernetes.

Activer la collecte de processus

Dans votre fichier datadog-agent.yaml, définissez features.liveProcessCollection.enabled sur true.

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <CLÉ_API_DATADOG>

  features:
    liveProcessCollection:
      enabled: true

Ensuite, appliquez la nouvelle configuration :

kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml

Modifiez votre fichier datadog-values.yaml en indiquant la configuration suivante :

datadog:
  # (...)
  processAgent:
    enabled: true
    processCollection: true

Mettez ensuite à niveau votre chart Helm :

helm upgrade -f datadog-values.yaml <NOM_VERSION> datadog/datadog

Pour en savoir plus, consultez la section Live processes.

Agent de cluster Datadog

L’Agent de cluster Datadog simplifie la collecte de données de surveillance au niveau des clusters grâce à une approche centralisée. Datadog vous recommande fortement d’utiliser l’Agent de cluster pour surveiller Kubernetes.

À partir de la version 1.0.0 de l’Operator Datadog et de la version 2.7.0 du chart Helm, l’Agent de cluster est activé par défaut. Aucune configuration supplémentaire n’est requise.

À partir de la version 1.0.0 de l’Operator Datadog, l’Agent de cluster est activé par défaut. L’Operator crée les autorisations RBAC nécessaires et déploie l’Agent de cluster. Les deux Agents utilisent la même clé d’API.

L’Operator génère automatiquement un token aléatoire dans un Secret Kubernetes. Ce token est partagé avec l’Agent Datadog et l’Agent de cluster afin de sécuriser leurs communications.

Vous pouvez spécifier ce token dans le champ global.clusterAgentToken de votre fichier datadog-agent.yaml :

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <CLÉ_API_DATADOG>
      appKey: <CLÉ_APPLICATION_DATADOG>
  clusterAgentToken: <TOKEN_AGENT_CLUSTER_DATADOG>

Il est également possible de spécifier ce token en faisant référence au nom d’un Secret existant et au nom de la clé de données contenant ce token :

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <CLÉ_API_DATADOG>
      appKey: <CLÉ_APPLICATION_DATADOG>
  clusterAgentTokenSecret: 
    secretName: <NOM_SECRET>
    keyName: <NOM_CLÉ>

Remarque : lorsque le token est défini manuellement, il doit être composé de 32 caractères alphanumériques.

Ensuite, appliquez la nouvelle configuration :

kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml

À partir de la version 2.7.0 du chart Helm, l’Agent de cluster est activé par défaut.

Pour vous assurer que l’Agent de cluster est bien activé, vérifiez que clusterAgent.enabled est défini sur true dans votre fichier datadog-values.yaml :

clusterAgent:
  enabled: true

Helm génère automatiquement un token aléatoire dans un Secret Kubernetes. Ce token est partagé avec l’Agent Datadog et l’Agent de cluster afin de sécuriser leurs communications.

Vous pouvez spécifier ce token dans le champ clusterAgent.token de votre fichier datadog-agent.yaml :

clusterAgent:
  enabled: true
  token: <TOKEN_AGENT_CLUSTER_DATADOG>

Il est également possible de spécifier ce token en faisant référence au nom d’un Secret existant comportant la clé token comportant le token :

clusterAgent:
  enabled: true
  tokenExistingSecret: <NOM_SECRET>

Pour en savoir plus, consultez la documentation relative à l’Agent de cluster Datadog.

Serveur de métriques custom

Pour utiliser le serveur de métriques custom de l’Agent de cluster, vous devez fournir une clé d’application Datadog et activer le fournisseur de métriques.

Dans le fichier datadog-agent.yaml, spécifiez une clé d’application sous spec.global.credentials.appKey et définissez features.externalMetricsServer.enabled sur true.

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <CLÉ_API_DATADOG>
      appKey: <CLÉ_APPLICATION_DATADOG>

  features:
    externalMetricsServer:
      enabled: true

Ensuite, appliquez la nouvelle configuration :

kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml

Dans le fichier datadog-values.yaml, spécifiez une clé d’application datadog.appKey et définissez clusterAgent.metricsProvider.enabled sur true.

datadog:
  apiKey: <CLÉ_API_DATADOG>
  appKey: <CLÉ_APPLICATION_DATADOG>

  clusterAgent:
    enabled: true
    metricsProvider:
      enabled: true

Mettez ensuite à niveau votre chart Helm :

helm upgrade -f datadog-values.yaml <NOM_VERSION> datadog/datadog

Intégrations

Dès lors que votre Agent s’exécute dans votre cluster, vous pouvez utiliser la fonctionnalité Autodiscovery de Datadog pour recueillir automatiquement des métriques et des logs à partir de vos pods.

Vue des conteneurs

Pour pouvoir vous servir de la vue Container Explorer de Datadog, vous devez activer l’Agent de processus. L’Operator Datadog et le chart Helm activent par défaut l’Agent de processus. Aucune configuration supplémentaire n’est requise.

L’Operator Datadog active par défaut l’Agent de processus.

Pour vous assurer que l’Agent de processus est bien activé, vérifiez que features.liveContainerCollection.enabled est défini sur true dans votre datadog-agent.yaml :

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <CLÉ_API_DATADOG>
      appKey: <CLÉ_APPLICATION_DATADOG>
  features:
    liveContainerCollection:
      enabled: true

Le chart Helm active par défaut l’Agent de processus.

Pour vous assurer que l’Agent de processus est bien activé, vérifiez que processAgent.enabled est défini sur true dans votre fichier datadog-values.yaml :

datadog:
  # (...)
  processAgent:
    enabled: true

Dans certaines configurations, il arrive que l’Agent de processus et l’Agent de cluster ne parviennent pas à détecter automatiquement un nom de cluster Kubernetes. Lorsque c’est le cas, la fonctionnalité ne démarre pas et l’avertissement suivant s’affiche dans le log de l’Agent de cluster : Orchestrator explorer enabled but no cluster name set: disabling. Vous devez alors définir datadog.clusterName sur le nom de votre cluster dans le fichier values.yaml.

datadog:
  #(...)
  clusterName: <NOM_CLUSTER>
  #(...)
  processAgent:
    enabled: true

Consultez la documentation relative à la vue des conteneurs pour obtenir des informations supplémentaires.

Orchestrator Explorer

L’Operator Datadog et le chart Helm activent par défaut la vue Orchestrator Explorer de Datadog. Aucune configuration supplémentaire n’est requise.

L’Operator Datadog active par défaut l’Orchestrator Explorer.

Pour vous assurer que cette vue est bien activée, vérifiez que le paramètre features.orchestratorExplorer.enabled est défini sur true dans votre fichier datadog-agent.yaml :

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <CLÉ_API_DATADOG>
      appKey: <CLÉ_APPLICATION_DATADOG>
  features:
    orchestratorExplorer:
      enabled: true

Le chart Helm active par défaut l’Orchestrator Explorer.

Pour vous assurer que cette vue est bien activée, vérifiez que le paramètre orchestratorExplorer.enabled est défini sur true dans votre fichier datadog-values.yaml :

datadog:
  # (...)
  processAgent:
    enabled: true
  orchestratorExplorer:
    enabled: true

Consultez la section Orchestrator Explorer pour obtenir des informations supplémentaires.

Variables d’environnement

Les variables d’environnement suivantes servent à configurer l’Agent Datadog.

Paramètre (v2alpha1)Description
global.credentials.apiKeyPermet de configurer votre clé d’API Datadog.
global.credentials.apiSecret.secretNameAu lieu d’utiliser global.credentials.apiKey, spécifiez le nom d’un Secret Kubernetes contenant votre clé d’API Datadog.
global.credentials.apiSecret.keyNameAu lieu d’utiliser global.credentials.apiKey, spécifiez la clé du Secret Kubernetes fourni dans global.credentials.apiSecret.secretName.
global.credentials.appKeyPermet de configurer votre clé d’application Datadog. Si vous utilisez le serveur de métriques externes, vous devez définir une clé d’application Datadog afin de pouvoir consulter vos métriques.
global.credentials.appSecret.secretNameAu lieu d’utiliser global.credentials.apiKey, spécifiez le nom d’un Secret Kubernetes contenant votre clé d’application Datadog.
global.credentials.appSecret.keyNameAu lieu d’utiliser global.credentials.apiKey, spécifiez la clé du Secret Kubernetes fourni dans global.credentials.appSecret.secretName.
global.logLevelDéfinit le niveau de détail de la journalisation. Ce paramètre peut être remplacé par le conteneur. Niveaux de log valides : trace, debug, info, warn, error, critical et off. Valeur par défaut : info.
global.registryRegistre d’images à utiliser pour toutes les images d’Agent. Valeur par défaut : gcr.io/datadoghq.
global.sitePermet de définir le site d’admission Datadog vers lequel les données de l’Agent sont envoyées. Votre site est (assurez-vous que le SITE sélectionné à droite est correct).
global.tagsLa liste des tags à appliquer à l’ensemble des métriques, événements et checks de service recueillis.

Pour obtenir la liste complète des variables d’environnements pour l’Operator Datadog, consultez la spécification v2alpha1 de l’Operator. Pour les versions antérieures, consultez la spécification v1alpha1 de l’Operator.

HelmDescription
datadog.apiKeyPermet de configurer votre clé d’API Datadog.
datadog.apiKeyExistingSecretAu lieu d’utiliser datadog.apiKey, spécifiez le nom d’un Secret Kubernetes existant contenant votre clé API Datadog, qui est définie par la clé api-key.
datadog.appKeyPermet de configurer votre clé d’application Datadog. Si vous utilisez le serveur de métriques externes, vous devez définir une clé d’application Datadog afin de pouvoir consulter vos métriques.
datadog.appKeyExistingSecretAu lieu d’utiliser datadog.appKey, spécifiez le nom d’un Secret Kubernetes existant contenant votre clé d’application Datadog, qui est définie par la clé app-key.
datadog.logLevelDéfinit le niveau de détail de la journalisation. Ce paramètre peut être remplacé par le conteneur. Niveaux de log valides : trace, debug, info, warn, error, critical et off. Valeur par défaut : info.
registryRegistre d’images à utiliser pour toutes les images d’Agent. Valeur par défaut : gcr.io/datadoghq.
datadog.sitePermet de définir le site d’admission Datadog vers lequel les données de l’Agent sont envoyées. Votre site est (assurez-vous que le SITE sélectionné à droite est correct).
datadog.tagsLa liste de tags à appliquer à l’ensemble des métriques, événements et checks de services recueillis.

Pour obtenir la liste complète des variables d’environnement pour le chart Helm, consultez la liste des options pour le fichier datadog-values.yaml.

Variable d’environnementDescription
DD_API_KEYVotre clé d’API Datadog (obligatoire).
DD_ENVPermet de définir le tag global env pour toutes les données générées.
DD_HOSTNAMELe hostname à utiliser pour les métriques (si la détection automatique échoue).
DD_TAGSTags de host séparés par des espaces. Exemple : simple-tag-0 tag-key-1:tag-value-1.
DD_SITESite auquel vos métriques, traces et logs sont envoyés. Votre DD_SITE est . Valeur par défaut : datadoghq.com.
DD_DD_URLParamètre facultatif permettant de remplacer l’URL pour l’envoi de métriques.
DD_URL (6.36+/7.36+)Alias pour DD_DD_URL. Ce paramètre est ignoré si DD_DD_URL est déjà défini.
DD_CHECK_RUNNERSL’Agent exécute par défaut tous les checks simultanément (par défaut, avec 4 exécuteurs). Pour exécuter les checks de façon séquentielle, définissez la valeur 1. Si vous devez exécuter un grand nombre de checks (ou des checks lents), le composant collector-queue peut prendre du retard et faire échouer le check de santé. Vous pouvez augmenter le nombre d’exécuteurs afin d’exécuter simultanément les checks.
DD_LEADER_ELECTIONSi plusieurs instances de l’Agent s’exécutent dans votre cluster, définissez cette variable sur true pour éviter de dupliquer la collecte d’événements.

Configurer DogStatsD

DogStatsD peut envoyer des métriques custom via UDP avec le protocole StatsD. L’Operator Datadog et Helm activent par défaut DogStatsD. Consultez la documentation relative à DogStatsD pour en savoir plus.

Les variables d’environnement suivantes servent à configurer DogStatsD avec un DaemonSet :

Variable d’environnementDescription
DD_DOGSTATSD_NON_LOCAL_TRAFFICEffectue une écoute des paquets DogStatsD issus d’autres conteneurs (requis pour envoyer des métriques custom).
DD_HISTOGRAM_PERCENTILESLes centiles à calculer pour l’histogramme (séparés par des espaces). Valeur par défaut : 0.95.
DD_HISTOGRAM_AGGREGATESLes agrégations à calculer pour l’histogramme (séparées par des espaces). Valeur par défaut : "max median avg count".
DD_DOGSTATSD_SOCKETLe chemin vers le socket Unix à écouter. Doit être dans le volume rw monté.
DD_DOGSTATSD_ORIGIN_DETECTIONActive la détection des conteneurs et le tagging pour les métriques de socket Unix.
DD_DOGSTATSD_TAGSLes tags supplémentaires à ajouter à l’ensemble des métriques, événements et checks de service reçus par ce serveur DogStatsD. Exemple : "env:golden group:retrievers".

Configurer le mappage des tags

Datadog recueille automatiquement les principaux tags Kubernetes.

Vous pouvez également mapper les étiquettes de nœud, les étiquettes de pod et les annotations Kubernetes avec des tags Datadog. Les variables d’environnement suivantes servent à configurer ce mappage :

Paramètre (v2alpha1)Description
global.namespaceLabelsAsTagsPermet de mapper les étiquettes d’espace de nommage Kubernetes avec des tags Datadog. Format : <ÉTIQUETTE_ESPACE_NOMMAGE_KUBERNETES>: <CLÉ_TAG_DATADOG>.
global.nodeLabelsAsTagsPermet de mapper les étiquettes de nœud Kubernetes avec des tags Datadog. Format : <ÉTIQUETTE_NŒUD_KUBERNETES>: <CLÉ_TAG_DATADOG>.
global.podAnnotationsAsTagsPermet de mapper les annotations Kubernetes avec des tags Datadog. Format : <ANNOTATION_KUBERNETES>: <CLÉ_TAG_DATADOG>.
global.podLabelsAsTagsPermet de mapper les étiquettes Kubernetes avec des tags Datadog. Format : <ÉTIQUETTE_KUBERNETES>: <CLÉ_TAG_DATADOG>.

Exemples

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <CLÉ_API_DATADOG>
    namespaceLabelsAsTags:
      env: environment
      # <ÉTIQUETTE_ESPACE_NOMMAGE_KUBERNETES>: <CLÉ_TAG_DATADOG>
    nodeLabelsAsTags:
      beta.kubernetes.io/instance-type: aws-instance-type
      kubernetes.io/role: kube_role
      # <ÉTIQUETTE_NŒUD_KUBERNETES>: <CLÉ_TAG_DATADOG>
    podLabelsAsTags:
      app: kube_app
      release: helm_release
      # <ÉTIQUETTE_KUBERNETES>: <CLÉ_TAG_DATADOG>
    podAnnotationsAsTags:
      iam.amazonaws.com/role: kube_iamrole
       # <ANNOTATIONS_KUBERNETES>: <CLÉ_TAG_DATADOG>
HelmDescription
datadog.namespaceLabelsAsTagsPermet de mapper les étiquettes d’espace de nommage Kubernetes avec des tags Datadog. Format : <ÉTIQUETTE_ESPACE_NOMMAGE_KUBERNETES>: <CLÉ_TAG_DATADOG>.
datadog.nodeLabelsAsTagsPermet de mapper les étiquettes de nœud Kubernetes avec des tags Datadog. Format : <ÉTIQUETTE_NŒUD_KUBERNETES>: <CLÉ_TAG_DATADOG>.
datadog.podAnnotationsAsTagsPermet de mapper les annotations Kubernetes avec des tags Datadog. Format : <ANNOTATION_KUBERNETES>: <CLÉ_TAG_DATADOG>.
datadog.podLabelsAsTagsPermet de mapper les étiquettes Kubernetes avec des tags Datadog. Format : <ÉTIQUETTE_KUBERNETES>: <CLÉ_TAG_DATADOG>.

Exemples

datadog:
  # (...)
  namespaceLabelsAsTags:
    env: environment
    # <ÉTIQUETTE_ESPACE_NOMMAGE_KUBERNETES>: <CLÉ_TAG_DATADOG>
  nodeLabelsAsTags:
    beta.kubernetes.io/instance-type: aws-instance-type
    kubernetes.io/role: kube_role
    # <ÉTIQUETTE_NŒUD_KUBERNETES>: <CLÉ_TAG_DATADOG>
  podLabelsAsTags:
    app: kube_app
    release: helm_release
    # <ÉTIQUETTE_KUBERNETES>: <CLÉ_TAG_DATADOG>
  podAnnotationsAsTags:
    iam.amazonaws.com/role: kube_iamrole
     # <ANNOTATIONS_KUBERNETES>: <CLÉ_TAG_DATADOG>

Utiliser des secrets

Les identifiants des intégrations peuvent être conservés dans des secrets Docker ou Kubernetes et utilisés dans les modèles Autodiscovery. Pour en savoir plus, consultez la section Gestion des secrets.

Ignorer des conteneurs

Vous pouvez exclure des conteneurs de la collecte de logs, de la collecte de métriques et d’Autodiscovery. Par défaut, Datadog exclut les conteneurs pause de Kubernetes et d’OpenShift. Ces listes d’inclusion et d’exclusion s’appliquent uniquement à Autodiscovery. Elles n’ont aucun impact sur les traces ni sur DogStatsD. Il est possible d’utiliser des expressions régulières pour les valeurs de ces variables d’environnement.

Consultez la section Gestion de la découverte de conteneurs pour obtenir des exemples.

Remarque : ces paramètres n’ont aucun effet sur les métriques kubernetes.containers.running, kubernetes.pods.running, docker.containers.running, .stopped, .running.total et .stopped.total, qui prennent en compte l’ensemble des conteneurs.

Paramètres de proxy

Depuis la version 6.4.0 de l’Agent (et 6.5.0 de l’Agent de trace), vous pouvez remplacer les paramètres de proxy de l’Agent via les variables d’environnement suivantes :

Variable d’environnementDescription
DD_PROXY_HTTPURL HTTP à utiliser comme proxy pour les requêtes http.
DD_PROXY_HTTPSURL HTTPS à utiliser comme proxy pour les requêtes https.
DD_PROXY_NO_PROXYListe d’URL, séparées par des espaces, pour lesquelles aucun proxy ne doit être utilisé.
DD_SKIP_SSL_VALIDATIONOption permettant de tester si l’Agent a des difficultés à se connecter à Datadog.

Divers

Variable d’environnementDescription
DD_PROCESS_AGENT_CONTAINER_SOURCERemplace la détection automatique des sources de conteneurs par une source unique, comme "docker", "ecs_fargate" ou "kubelet". Cela n’est plus nécessaire depuis la version 7.35.0. de l’Agent.
DD_HEALTH_PORTDéfinissez cette variable sur 5555 pour exposer le check de santé de l’Agent sur le port 5555.
DD_CLUSTER_NAMEDéfinissez un identifiant de cluster Kubernetes personnalisé pour éviter les conflits entre les alias de host. Le nom du cluster peut contenir jusqu’à 40 caractères correspondants à des lettres minuscules, des chiffres et des traits d’union. Il doit également commencer par une lettre et se terminer par un chiffre ou une lettre.
DD_COLLECT_KUBERNETES_EVENTSActive la collecte d’événements via l’Agent. Si vous exécutez plusieurs instances de l’Agent dans votre cluster, définissez également DD_LEADER_ELECTION sur true.

Vous pouvez ajouter d’autres écouteurs et fournisseurs de configuration à l’aide des variables d’environnement DD_EXTRA_LISTENERS et DD_EXTRA_CONFIG_PROVIDERS. Elles viennent s’ajouter aux variables définies dans les sections listeners et config_providers du fichier de configuration datadog.yaml.

PREVIEWING: alai97/reorganize-some-sections-in-dora-metrics