Présentation

Le tagging de service unifié permet de lier les données de télémétrie Datadog entre elles via trois tags réservés : env, service et version.

Avec ces trois tags, vous pouvez :

• Déterminer l’impact d’un déploiement grâce à des métriques de trace et de conteneur filtrées par version
• Explorer facilement vos traces, métriques et logs à l’aide de tags cohérents
• Consulter les données de service en fonction de l’environnement ou de la version de manière unifiée

Remarque : à défaut de configuration de log Autodiscovery, le service officiel d’un log est défini sur le nom raccourci du conteneur. Pour remplacer le service officiel d’un log, ajoutez des annotations de pod ou étiquettes Docker Autodiscovery. Exemple : "com.datadoghq.ad.logs"='[{"service": "service-name"}]'.

Prérequis

• Vous devez configurer la version 6.19.x/7.19.x ou une version ultérieure de l’Agent Datadog pour pouvoir utiliser le tagging de service unifié.

• Le tagging de service unifié nécessite une version du traceur qui prend en charge les nouvelles configurations des tags réservés. Vous trouverez davantage d’informations pour chaque langage dans les instructions de configuration.

• Vous devez maîtriser la configuration de tags pour pouvoir utiliser le tagging de service unifié. En cas de doute, consultez les sections Débuter avec les tags et Assigner des tags avant de procéder à la configuration.

Configuration

Pour commencer la configuration du tagging de service unifié, choisissez votre environnement :

• Environnement conteneurisé
• Environnement non conteneurisé

Environnement conteneurisé

Dans les environnements conteneurisés, les tags env, service et version sont définis via les variables d’environnement du service ou à l’aide d’étiquettes (par exemple, les étiquettes de pod et de déploiement Kubernetes ou encore les étiquettes des conteneurs Docker). L’Agent Datadog détecte cette configuration de tagging et l’applique aux données recueillies à partir des conteneurs.

Pour configurer le tagging de service unifié dans un environnement conteneurisé :

1. Activez Autodiscovery pour permettre à l’Agent Datadog d’identifier automatiquement les services qui s’exécutent sur un conteneur donné et de recueillir des données à partir de ces services afin de mapper les variables d’environnement avec les tags env, service et version.

2. Si vous utilisez Docker, assurez-vous que l’Agent peut accéder au socket Docker de votre conteneur. Cela permet à l’Agent de détecter les variables d’environnement et de les mapper avec les tags standard.

3. Configurez votre environnement en fonction de votre service d’orchestration de conteneurs en suivant la procédure de configuration complète ou partielle détaillée ci-dessous.

Configuration

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    tags.datadoghq.com/env: "<ENV>"
    tags.datadoghq.com/service: "<SERVICE>"
    tags.datadoghq.com/version: "<VERSION>"
...
template:
  metadata:
    labels:
      tags.datadoghq.com/env: "<ENV>"
      tags.datadoghq.com/service: "<SERVICE>"
      tags.datadoghq.com/version: "<VERSION>"
  containers:
  -  ...
     env:
          - name: DD_ENV
            valueFrom:
              fieldRef:
                fieldPath: metadata.labels['tags.datadoghq.com/env']
          - name: DD_SERVICE
            valueFrom:
              fieldRef:
                fieldPath: metadata.labels['tags.datadoghq.com/service']
          - name: DD_VERSION
            valueFrom:
              fieldRef:
                fieldPath: metadata.labels['tags.datadoghq.com/version']

template:
  metadata:
    labels:
      tags.datadoghq.com/env: "<ENV>"
      tags.datadoghq.com/service: "<SERVICE>"
      tags.datadoghq.com/version: "<VERSION>"

tags.datadoghq.com/<nom-conteneur>.env
tags.datadoghq.com/<nom-conteneur>.service
tags.datadoghq.com/<nom-conteneur>.version

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    tags.datadoghq.com/env: "<ENV>"
    tags.datadoghq.com/service: "<SERVICE>"
    tags.datadoghq.com/version: "<VERSION>"
spec:
  template:
    metadata:
      labels:
        tags.datadoghq.com/env: "<ENV>"
        tags.datadoghq.com/service: "<SERVICE>"
        tags.datadoghq.com/version: "<VERSION>"

containers:
-  ...
    env:
        - name: DD_ENV
          valueFrom:
            fieldRef:
              fieldPath: metadata.labels['tags.datadoghq.com/env']
        - name: DD_SERVICE
          valueFrom:
            fieldRef:
              fieldPath: metadata.labels['tags.datadoghq.com/service']
        - name: DD_VERSION
          valueFrom:
            fieldRef:
              fieldPath: metadata.labels['tags.datadoghq.com/version']

ENV DD_SERVICE <SERVICE>
ENV DD_VERSION <VERSION>

LABEL com.datadoghq.tags.service="<SERVICE>"
LABEL com.datadoghq.tags.version="<VERSION>"

docker run -e DD_ENV=<ENV> -l com.datadoghq.tags.env=<ENV> ...

docker run -e DD_ENV="<ENV>" \
           -e DD_SERVICE="<SERVICE>" \
           -e DD_VERSION="<VERSION>" \
           -l com.datadoghq.tags.env="<ENV>" \
           -l com.datadoghq.tags.service="<SERVICE>" \
           -l com.datadoghq.tags.version="<VERSION>" \
           ...

com.datadoghq.tags.env
com.datadoghq.tags.service
com.datadoghq.tags.version

"environment": [
  {
    "name": "DD_ENV",
    "value": "<ENV>"
  },
  {
    "name": "DD_SERVICE",
    "value": "<SERVICE>"
  },
  {
    "name": "DD_VERSION",
    "value": "<VERSION>"
  }
],
"dockerLabels": {
  "com.datadoghq.tags.env": "<ENV>",
  "com.datadoghq.tags.service": "<SERVICE>",
  "com.datadoghq.tags.version": "<VERSION>"
}

"dockerLabels": {
  "com.datadoghq.tags.env": "<ENV>",
  "com.datadoghq.tags.service": "<SERVICE>",
  "com.datadoghq.tags.version": "<VERSION>"
}

Environnement non conteneurisé

Selon la façon dont vous créez et déployez les binaires ou les exécutables de vos services, plusieurs options peuvent s’offrir à vous pour définir les variables d’environnement. Étant donné que vous pouvez exécuter un ou plusieurs services par host, Datadog vous conseille de limiter ces variables d’environnement à un seul processus.

Afin de former un point de configuration unique pour l’ensemble des données de télémétrie émises directement depuis le runtime de vos services pour les traces, les logs, les ressources RUM, les tests Synthetic, les métriques StatsD ou les métriques système, vous pouvez :

1. Exporter les variables d’environnement dans la commande de votre exécutable :

   DD_ENV=<env> DD_SERVICE=<service> DD_VERSION=<version> /bin/my-service
   

2. Ou utiliser Chef, Ansible ou un autre outil d’orchestration pour ajouter les variables d’environnement DD au fichier de configuration systemd ou initd d’un service. Le processus du service aura accès à ces variables une fois lancé.

   Lors de la configuration de vos traces pour le tagging de service unifié :

   1. Configurez le Traceur de l’APM avec DD_ENV pour que la définition de env soit plus proche de l’application qui génère les traces. Cette méthode permet au tag env de provenir automatiquement d’un tag dans les métadonnées de span.

   2. Configurez des spans avec DD_VERSION pour ajouter un tag version à toutes les spans relevant du service qui appartient au traceur (généralement DD_SERVICE). Ainsi, si votre service crée des spans avec le nom d’un service externe, ces spans ne reçoivent pas de tag version.

      Tant que le tag version figure dans les spans, il est ajouté aux métriques de trace générées à partir de ces spans. Le tag version peut être ajouté manuellement dans le code ou automatiquement par le traceur APM. Une fois les spans configurées, elles sont utilisées par APM et les clients DogStatsd pour appliquer les tags env, service et version aux données de trace et aux métriques StatsD. S’il est activé, le traceur APM injecte également les valeurs de ces variables dans vos logs.

      Remarque : il ne peut y avoir qu’un seul service par span. Les métriques de trace sont généralement associées à un seul service également. Toutefois, si un service différent est défini dans les tags de vos hosts, ce tag service configuré apparaît dans toutes les métriques de trace émises par ce host.

   Si vous associez vos logs à vos traces, activez l’injection automatique dans les logs si cette fonctionnalité est prise en charge par votre traceur d’APM. Le traceur d’APM injecte alors automatiquement les tags env, service et version dans vos logs, éliminant ainsi le besoin de configurer manuellement ces champs ailleurs.

   Remarque : le traceur PHP ne prend pas actuellement en charge la configuration du tagging de service unifié pour les logs.

   Si vous associez vos données RUM à vos traces, spécifiez l’application Browser dans le champ service, définissez l’environnement dans le champ env et énumérez les versions dans le champ version de votre fichier d’initialisation.

   Lorsque vous créez une application RUM, confirmez les noms env et service.

   Si vous associez vos tests Browser Synthetic à vos traces, spécifiez l’URL à laquelle envoyer les en-têtes dans la section APM Integration for Browser Tests de la page Integration Settings.

   Vous pouvez utiliser le caractère * comme wildcard, par exemple : https://*.datadoghq.com.

   Les tags sont ajoutés en mode append-only pour les métriques custom StatsD. Par exemple, si vous avez deux valeurs différentes pour env, les métriques sont taguées avec les deux environnements. L’ordre dans lequel un tag remplace un autre du même nom est aléatoire.

   Si votre service a accès à DD_ENV, DD_SERVICE et DD_VERSION, alors le client DogStatsD ajoute automatiquement les tags correspondants à vos métriques custom.

   Remarque : les clients Datadog DogStatsD pour .NET et PHP ne prennent pas en charge cette fonctionnalité.

   Vous pouvez ajouter les tags env et service à vos métriques d’infrastructure. Dans les environnements non conteneurisés, la configuration du tagging des métriques de service se fait au niveau de l’Agent.

   Étant donné que cette configuration ne change pas à chaque invocation du processus d’un service, l’ajout du tag version n’est pas recommandé.

   Service unique par host

   Définissez la configuration suivante dans le fichier de configuration principal de l’Agent :

   env: <ENV>
   tags:
     - service:<SERVICE>
   

   Avec cette configuration, les tags env et service resteront cohérents pour toutes les données émises par l’Agent.

   Plusieurs services par host

   Définissez la configuration suivante dans le fichier de configuration principal de l’Agent :

   env: <ENV>
   

   Pour obtenir des tags service uniques sur les métriques de processeur, de mémoire et d’E/S disque au niveau du processus, configurez un check de processus dans le dossier de configuration de l’Agent (par exemple, dans le fichier process.d/conf.yaml du dossier conf.d) :

   init_config:
   instances:
       - name: web-app
         search_string: ["/bin/web-app"]
         exact_match: false
         service: web-app
       - name: nginx
         search_string: ["nginx"]
         exact_match: false
         service: nginx-web-app
   

   Remarque : si vous avez déjà un tag service défini globalement dans le fichier de configuration principal de votre Agent, les métriques de processus sont taguées avec deux services. Puisque cela peut nuire à l’interprétation des métriques, il est conseillé de configurer le tag service uniquement dans la configuration du check de processus.

Environnement sans serveur

Pour en savoir plus sur les fonctions AWS Lambda, découvrez comment associer vos données de télémétrie Lambda à l’aide de tags.

Pour aller plus loin

Documentation, liens et articles supplémentaires utiles:

Apprendre à utiliser les tags dans l'application DatadogDOCUMENTATION Utiliser des tags version dans l'APM Datadog pour surveiller les déploiementsDOCUMENTATION En savoir plus sur AutodiscoveryBLOG