Cette page couvre comment installer et configurer des intégrations pour votre infrastructure Kubernetes en utilisant une fonctionnalité de Datadog connue sous le nom de Autodiscovery. Cela vous permet d’utiliser variables comme %%host%% pour peupler dynamiquement vos paramètres de configuration. Pour une explication détaillée du fonctionnement d’Autodiscovery, consultez Getting Started with Containers: Autodiscovery. Pour des options avancées d’Autodiscovery, telles que l’exclusion de certains conteneurs d’Autodiscovery ou la tolérance des pods non prêts, consultez Container Discovery Management.

Si vous utilisez Docker ou Amazon ECS, consultez Docker et intégrations.

Configurez votre intégration

Certaines intégrations nécessitent des étapes de configuration, telles que la création d’un jeton d’accès ou l’octroi d’une autorisation de lecture à l’Agent Datadog. Suivez les instructions dans la section Setup de la documentation de votre intégration.

Intégrations communautaires

Pour utiliser une intégration qui n’est pas fournie avec l’Agent Datadog, vous devez créer une image personnalisée contenant l’intégration souhaitée. Consultez Utiliser des intégrations communautaires pour les instructions.

Configuration

Certaines intégrations couramment utilisées sont livrées avec une configuration par défaut pour Autodiscovery. Consultez Autodiscovery auto-configuration pour plus de détails, y compris une liste des intégrations auto-configurées et leurs fichiers de configuration par défaut correspondants. Si votre intégration figure dans cette liste et que la configuration par défaut est suffisante pour votre cas d’utilisation, aucune action supplémentaire n’est requise.

Sinon :

1. Choisissez une méthode de configuration (annotations de pod Kubernetes, un fichier local, un ConfigMap, un magasin clé-valeur, un manifeste Datadog Operator ou un graphique Helm) qui convient à votre cas d’utilisation.
2. Référez-vous au format de modèle pour votre méthode choisie. Chaque format contient des espaces réservés, tels que <CONTAINER_NAME>.
3. Fournissez des valeurs pour ces espaces réservés.

apiVersion: v1
kind: Pod
# (...)
metadata:
  name: '<POD_NAME>'
  annotations:
    ad.datadoghq.com/<CONTAINER_NAME>.checks: |
      {
        "<INTEGRATION_NAME>": {
          "init_config": <INIT_CONFIG>,
          "instances": [<INSTANCES_CONFIG>]
        }
      }
    ad.datadoghq.com/<CONTAINER_NAME>.logs: '[<LOGS_CONFIG>]'
    # (...)
spec:
  containers:
    - name: '<CONTAINER_NAME>'
# (...)

apiVersion: v1
kind: Pod
# (...)
metadata:
  name: '<POD_NAME>'
  annotations:
    ad.datadoghq.com/<CONTAINER_NAME>.check_names: '[<INTEGRATION_NAME>]'
    ad.datadoghq.com/<CONTAINER_NAME>.init_configs: '[<INIT_CONFIG>]'
    ad.datadoghq.com/<CONTAINER_NAME>.instances: '[<INSTANCES_CONFIG>]'
    ad.datadoghq.com/<CONTAINER_NAME>.logs: '[<LOGS_CONFIG>]'
    # (...)
spec:
  containers:
    - name: '<CONTAINER_NAME>'
# (...)

kind: ConfigMap
apiVersion: v1
metadata:
  name: "<NAME>-config-map"
  namespace: default
data:
  <INTEGRATION_NAME>-config: |-
    ad_identifiers:
      <CONTAINER_IMAGE>
    init_config:
      <INIT_CONFIG>
    instances:
      <INSTANCES_CONFIG>
    logs:
      <LOGS_CONFIG>

config_providers:
  - name: etcd
    polling: true
    template_dir: /datadog/check_configs
    template_url: '<KV_STORE_IP>:<KV_STORE_PORT>'
    username:
    password:

  - name: consul
    polling: true
    template_dir: datadog/check_configs
    template_url: '<KV_STORE_IP>:<KV_STORE_PORT>'
    ca_file:
    ca_path:
    cert_file:
    key_file:
    username:
    password:
    token:

  - name: zookeeper
    polling: true
    template_dir: /datadog/check_configs
    template_url: '<KV_STORE_IP>:<KV_STORE_PORT>'
    username:
    password:

/datadog/
  check_configs/
    <CONTAINER_IMAGE>/
      - check_names: ["<INTEGRATION_NAME>"]
      - init_configs: ["<INIT_CONFIG>"]
      - instances: ["<INSTANCES_CONFIG>"]
      - logs: ["<LOGS_CONFIG>"]
    ...

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    [...]
  features:
    [...]
  override:
    nodeAgent:
      extraConfd:
        configDataMap:
          <INTEGRATION_NAME>.yaml: |-
            ad_identifiers:
              - <CONTAINER_IMAGE>
            init_config:
              <INIT_CONFIG>
            instances:
              <INSTANCES_CONFIG>
            logs:
              <LOGS_CONFIG>

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    [...]
  features:
    clusterChecks:
      enabled: true
    [...]
  override:
    nodeAgent:
      [...]
    clusterAgent:
      extraConfd:
        configDataMap:
          <INTEGRATION_NAME>.yaml: |-
            ad_identifiers:
              - <CONTAINER_IMAGE>
            cluster_check: true
            init_config:
              <INIT_CONFIG>
            instances:
              <INSTANCES_CONFIG>
            logs:
              <LOGS_CONFIG>

datadog:
  confd:
    <INTEGRATION_NAME>.yaml: |-
      ad_identifiers:
        - <CONTAINER_IMAGE>
      init_config:
        <INIT_CONFIG>
      instances:
        <INSTANCES_CONFIG>
      logs:
        <LOGS_CONFIG>

datadog:
  clusterChecks:
    enabled: true
clusterAgent:
  enabled: true
  confd:
    <INTEGRATION_NAME>.yaml: |-
      ad_identifiers:
        - <CONTAINER_IMAGE>
      cluster_check: true
      init_config:
        <INIT_CONFIG>
      instances:
        <INSTANCES_CONFIG>
      logs:
        <LOGS_CONFIG>

Valeurs de remplacement

Fournissez les valeurs de remplacement comme suit :

<INTEGRATION_NAME>

Le nom de votre intégration Datadog, tel que etcd ou redisdb.

<CONTAINER_NAME>

Un identifiant à faire correspondre avec les noms (spec.containers[i].name, pas spec.containers[i].image) des conteneurs qui correspondent à votre intégration.

<CONTAINER_IMAGE>

Un identifiant à faire correspondre avec l’image du conteneur (.spec.containers[i].image).

Par exemple: si vous fournissez redis comme identifiant de conteneur, votre modèle d’Autodécouverte est appliqué à tous les conteneurs dont les noms d’image correspondent à redis. Si vous avez un conteneur exécutant foo/redis:latest et bar/redis:v2, votre modèle d’Autodécouverte est appliqué aux deux conteneurs.

Le paramètre ad_identifiers prend une liste, vous pouvez donc fournir plusieurs identifiants de conteneur. Vous pouvez également utiliser des identifiants personnalisés. Voir Identifiants d’autodécouverte personnalisés.

<INIT_CONFIG>

Les paramètres de configuration énumérés sous init_config dans le fichier <INTEGRATION_NAME>.d/conf.yaml.example de votre intégration. La section init_config est généralement vide.

<INSTANCES_CONFIG>

Les paramètres de configuration énumérés sous instances dans le fichier <INTEGRATION_NAME>.d/conf.yaml.example de votre intégration.

<LOGS_CONFIG>

Les paramètres de configuration énumérés sous logs dans le fichier <INTEGRATION_NAME>.d/conf.yaml.example de votre intégration.

Paramètres d’annotation avancés

En plus des annotations d’Autodécouverte de base pour les vérifications, les journaux et les instances, vous pouvez utiliser des annotations supplémentaires pour personnaliser le comportement des vérifications :

Cardinalité des tags

Définissez le niveau de cardinalité des tags pour une vérification spécifique en utilisant l’annotation check_tag_cardinality. Cela remplace le paramètre de cardinalité des tags de l’agent pour les métriques collectées par cette vérification.

apiVersion: v1
kind: Pod
metadata:
  name: '<POD_NAME>'
  annotations:
    ad.datadoghq.com/<CONTAINER_NAME>.checks: |
      {
        "<INTEGRATION_NAME>": {
          "init_config": <INIT_CONFIG>,
          "instances": [<INSTANCES_CONFIG>]
        }
      }
    ad.datadoghq.com/<CONTAINER_NAME>.check_tag_cardinality: "<low|orchestrator|high>"
spec:
  containers:
    - name: '<CONTAINER_NAME>'

Pour plus d’informations sur la cardinalité des tags, consultez Configuration des tags par vérification.

Auto-configuration

L’agent Datadog reconnaît automatiquement et fournit une configuration de base pour certaines technologies courantes. Pour une liste complète, consultez Autodiscovery auto-configuration.

Les configurations définies avec des annotations Kubernetes ont la priorité sur l’auto-configuration, mais l’auto-configuration a la priorité sur les configurations définies avec Datadog Operator ou Helm. Pour utiliser Datadog Operator ou Helm pour configurer une intégration dans la liste Auto-configuration de l’autodécouverte, vous devez désactiver l’auto-configuration.

Sécurité des intégrations

Les intégrations ont souvent besoin de lire des fichiers de configuration, des certificats ou d’autres ressources à partir du système de fichiers. Lorsque les chemins de fichiers proviennent de fournisseurs de configuration non fiables (par exemple, des annotations de pod ou l’autodécouverte de services externes), il existe un risque de traversée de chemin ou d’accès non autorisé aux fichiers.

À partir de la version 7.78.0 de l’agent Datadog, vous pouvez définir les paramètres suivants dans le datadog.yaml de l’agent pour contrôler l’accès au système de fichiers en fonction du niveau de confiance d’un fournisseur de configuration.

Ces options sont compatibles avec les versions antérieures : les valeurs par défaut préservent le comportement existant. Pour activer cette option, activez integration_ignore_untrusted_file_params et ajustez les paramètres restants pour qu’ils correspondent à votre environnement.

Exemple datadog.yaml :

integration_ignore_untrusted_file_params: true
integration_file_paths_allowlist:
  - /etc/datadog-agent/certs
  - /var/run/secrets
integration_trusted_providers:
  - file
  - remote-config
integration_security_excluded_checks:
  - <INTEGRATION_NAME>

Avec cette configuration, une intégration configurée via des annotations de pod (un fournisseur non fiable) ne peut pas référencer des chemins de fichiers en dehors de /etc/datadog-agent/certs ou /var/run/secrets, à moins que le nom de l’intégration ne figure dans integration_security_excluded_checks.

Exemple : intégration Postgres

Dans ce scénario d’exemple, vous avez déployé Postgres sur Kubernetes. Vous souhaitez configurer et mettre en place l’intégration Datadog-Postgres. Tous vos conteneurs Postgres ont des noms de conteneur contenant la chaîne postgres.

Tout d’abord, consultez la documentation de l’intégration Postgres pour toute étape de configuration supplémentaire. L’intégration Postgres nécessite que vous créiez un utilisateur en lecture seule nommé datadog et que vous stockiez le mot de passe correspondant en tant que variable d’environnement nommée PG_PASSWORD.

Si vous deviez configurer cette intégration sur un hôte, vous pourriez vous référer à postgresql.d/conf.yaml.example pour les paramètres et créer un fichier postgresql.d/conf.yaml contenant ce qui suit :

init_config:
instances:
  - host: localhost
    port: 5432
    username: datadog
    password: <PASSWORD>
logs:
  - type: file
    path: /var/log/postgres.log
    source: postgresql
    service: pg_service

Ici, <PASSWORD> correspond au mot de passe de l’utilisateur datadog que vous avez créé.

Pour appliquer cette configuration à vos conteneurs Postgres :

apiVersion: v1
kind: Pod
metadata:
  name: postgres
  annotations:
    ad.datadoghq.com/postgres.checks: |
      {
        "postgres": {
          "instances": [
            {
              "host": "%%host%%",
              "port": "5432",
              "username": "datadog",
              "password":"%%env_PG_PASSWORD%%"
            }
          ]
        }
      }
    ad.datadoghq.com/postgres.logs: |
      [
        {
          "type": "file",
          "path": "/var/log/postgres.log",
          "source": "postgresql",
          "service": "pg_service"
        }
      ]
spec:
  containers:
    - name: postgres

apiVersion: v1
kind: Pod
metadata:
  name: postgres
  annotations:
    ad.datadoghq.com/postgres.check_names: '["postgres"]'
    ad.datadoghq.com/postgres.init_configs: '[{}]'
    ad.datadoghq.com/postgres.instances: |
      [
        {
          "host": "%%host%%",
          "port": "5432",
          "username": "datadog",
          "password":"%%env_PG_PASSWORD%%"
        }
      ]
    ad.datadoghq.com/postgres.logs: |
      [
        {
          "type": "file",
          "path": "/var/log/postgres.log",
          "source": "postgresql",
          "service": "pg_service"
        }
      ]
spec:
  containers:
    - name: postgres

kind: ConfigMap
apiVersion: v1
metadata:
  name: postgresql-config-map
  namespace: default
data:
  postgresql-config: |-
    ad_identifiers:
      - postgres
    init_config:
    instances:
      - host: "%%host%%"
        port: "5432"
        username: "datadog"
        password: "%%env_PG_PASSWORD%%"
    logs:
      - type: "file"
        path: "/var/log/postgres.log"
        source: "postgresql"
        service: "pg_service"

# [...]
        volumeMounts:
        # [...]
          - name: postgresql-config-map
            mountPath: /etc/datadog-agent/conf.d/postgresql.d
        # [...]
      volumes:
      # [...]
        - name: postgresql-config-map
          configMap:
            name: postgresql-config-map
            items:
              - key: postgresql-config
                path: conf.yaml
# [...]

etcdctl mkdir /datadog/check_configs/postgres
etcdctl set /datadog/check_configs/postgres/check_names '["postgres"]'
etcdctl set /datadog/check_configs/postgres/init_configs '[{}]'
etcdctl set /datadog/check_configs/postgres/instances '[{"host": "%%host%%","port":"5432","username":"datadog","password":"%%env_PG_PASSWORD%%"}]'

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    [...]
  features:
    [...]
  override:
    nodeAgent:
      extraConfd:
        configDataMap:
          postgres.yaml: |-
            ad_identifiers:
              - postgres
            init_config:
            instances:
              - host: "%%host%%"
                port: 5432
                username: "datadog"
                password: "%%env_PG_PASSWORD%%"

datadog:
  confd:
    postgres.yaml: |-
      ad_identifiers:
        - postgres
      init_config:
      instances:
        - host: "%%host%%"
          port: 5432
          username: "datadog"
          password: "%%env_PG_PASSWORD%%"

Ces modèles utilisent des variables de modèle d’autodécouverte :

• %%host%% est peuplé dynamiquement avec l’IP du conteneur.
• %%env_PG_PASSWORD%% fait référence à une variable d’environnement nommée PG_PASSWORD telle que vue par le processus de l’Agent.

Pour plus d’exemples, y compris comment configurer plusieurs vérifications pour plusieurs ensembles de conteneurs, voir Autodécouverte : Scénarios et Exemples.

Lectures complémentaires

Documentation, liens et articles supplémentaires utiles:

Surveillez Karpenter avec DatadogBLOG Recueillir les logs de votre applicationDOCUMENTATION Recueillir les traces de votre applicationDOCUMENTATION Recueillez vos métriques PrometheusDOCUMENTATION Limitez la collecte de données à un sous-ensemble de conteneursDOCUMENTATION Attribuez des tags à toutes les données envoyées par un conteneurDOCUMENTATION Conseils et astuces Datadog : Comment écrire des annotations dans Kubernetes avec JSON pour Autodiscovery DatadogVIDÉO