Installation

Vous pouvez utiliser des DaemonSets pour déployer l’Agent Datadog sur tous vos nœuds (ou sur des nœuds spécifiques en utilisant des nodeSelectors).

Pour installer l’Agent Datadog sur votre cluster Kubernetes :

1. Configurez les autorisations de l’Agent : si le contrôle d’accès basé sur des rôles (RBAC) est activé pour votre déploiement Kubernetes, configurez les autorisations RBAC pour le compte de service de votre Agent Datadog. Depuis la version 1.6 de Kubernetes, le RBAC est activé par défaut. Créez les ClusterRole, ServiceAccount et ClusterRoleBinding appropriés à l’aide de la commande suivante :

   kubectl apply -f "https://raw.githubusercontent.com/DataDog/datadog-agent/master/Dockerfiles/manifests/rbac/clusterrole.yaml"
   
   kubectl apply -f "https://raw.githubusercontent.com/DataDog/datadog-agent/master/Dockerfiles/manifests/rbac/serviceaccount.yaml"
   
   kubectl apply -f "https://raw.githubusercontent.com/DataDog/datadog-agent/master/Dockerfiles/manifests/rbac/clusterrolebinding.yaml"
   

   Remarque : ces configurations RBAC sont définies pour l’espace de nommage default. Si vous utilisez un espace de nommage personnalisé, modifiez le paramètre namespace avant d’appliquer les configurations.

2. Créez le manifeste de l’Agent Datadog. Créez le manifeste datadog-agent.yaml à partir de l’un des modèles suivants :

   Métriques	Logs	APM	Processus	NPM	Sécurité	Linux	Windows
   						Modèle de manifeste	Modèle de manifeste (sans sécurité)
   						Modèle de manifeste	Modèle de manifeste
   						Modèle de manifeste	Modèle de manifeste
   						Modèle de manifeste	Modèle de manifeste
   						Modèle de manifeste	aucun modèle
   						Modèle de manifeste	Modèle de manifeste

   Pour activer complètement la collecte de traces, des étapes supplémentaires sont requises sur la configuration du Pod de votre application. Consultez également les pages de documentation logs, APM, processus, Cloud Network Monitoring et sécurité pour apprendre à activer chaque fonctionnalité individuellement.

   Remarque : ces manifestes sont définis pour l’espace de nommage default. Si vous utilisez un espace de nommage personnalisé, modifiez le paramètre metadata.namespace avant d’appliquer les manifestes.

3. Dans le manifeste secret-api-key.yaml, remplacez PUT_YOUR_BASE64_ENCODED_API_KEY_HERE par votre clé d’API Datadog encodée en base64. Pour obtenir la version base64 de votre clé d’API, exécutez la commande suivante :

   echo -n '<Your API key>' | base64
   

4. Si vous utilisez le modèle de manifeste datadog-agent-all-features.yaml : dans le manifeste secret-cluster-agent-token.yaml, remplacez PUT_A_BASE64_ENCODED_RANDOM_STRING_HERE par une chaîne aléatoire encodée en base64. Pour obtenir sa version en base64, vous pouvez exécuter :

   echo -n 'Random string' | base64
   

   Remarque : la chaîne aléatoire doit inclure au moins 32 caractères alphanumériques, afin de sécuriser les communications entre l’Agent de cluster et l’Agent.

5. Définissez votre site Datadog sur en utilisant la variable d’environnement DD_SITE dans le manifeste datadog-agent.yaml.

   Note : Si la variable d’environnement DD_SITE n’est pas explicitement définie, la valeur par défaut est le site US datadoghq.com . Si vous utilisez l’un des autres sites, vous recevrez un message indiquant que votre clé API n’est pas valide. Utilisez le sélecteur de site de documentation pour consulter la documentation correspondant au site que vous utilisez.

6. Déployez le DaemonSet avec cette commande :

   kubectl apply -f datadog-agent.yaml
   

7. Vérification : pour vérifier que l’Agent Datadog s’exécute dans votre environnement en tant que DaemonSet, exécutez ce qui suit :

   kubectl get daemonset
   

   Si l’Agent est déployé, une sortie similaire au texte ci-dessous s’affiche. Les valeurs DESIRED et CURRENT correspondent au nombre de nœuds exécutés dans votre cluster.

   NAME      DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
   datadog   2         2         2         2            2           <none>          10s
   

Configuration

Collecte de traces

  # (...)
  containers:
  - name: trace-agent
    # (...)
    env:
    - name: DD_APM_ENABLED
      value: "true"
    - name: DD_APM_RECEIVER_SOCKET
      value: "/var/run/datadog/apm.socket"
  # (...)
    volumeMounts:
    - name: apmsocket
      mountPath: /var/run/datadog/
  volumes:
  - hostPath:
      path: /var/run/datadog/
      type: DirectoryOrCreate
  # (...)

Collecte de logs

Remarque : cette option n’est pas prise en charge sous Windows. Utilisez plutôt l’option Helm.

Pour activer la collecte de logs avec votre DaemonSet :

1. Définissez les variables DD_LOGS_ENABLED et DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL sur true dans la section env du manifeste de l’Agent datadog.yaml :

    # (...)
     env:
       # (...)
       - name: DD_LOGS_ENABLED
         value: "true"
       - name: DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL
         value: "true"
       - name: DD_CONTAINER_EXCLUDE_LOGS
         value: "name:datadog-agent"
    # (...)
   

   Note : Le réglage de DD_CONTAINER_EXCLUDE_LOGS empêche le Datadog Agent de collecter et d’envoyer ses propres journaux. Supprimez ce paramètre si vous souhaitez collecter les Datadog Agent journaux. Voir la variable d’environnement pour ignorer les conteneurs pour en savoir plus. Lorsque vous utilisez ImageStreams dans des environnements OpenShift, définissez DD_CONTAINER_INCLUDE_LOGS avec le conteneur name pour collecter les journaux. Ces deux valeurs de paramètres Exclure/Inclure prennent en charge les expressions régulières.

2. Montez le volume pointerdir pour empêcher la perte de logs de conteneur lors des redémarrages ou en cas de problèmes réseau. Montez également /var/lib/docker/containers pour recueillir des logs via le fichier de logs Kubernetes, car /var/log/pods est un lien symbolique vers ce répertoire :

     # (...)
       volumeMounts:
         # (...)
         - name: pointerdir
           mountPath: /opt/datadog-agent/run
         - name: logpodpath
          mountPath: /var/log/pods
         # Docker runtime directory, replace this path
         # with your container runtime logs directory,
         # or remove this configuration if `/var/log/pods`
         # is not a symlink to any other directory.
         - name: logcontainerpath
          mountPath: /var/lib/docker/containers
     # (...)
     volumes:
       # (...)
       - hostPath:
           path: /opt/datadog-agent/run
         name: pointerdir
       - hostPath:
           path: /var/log/pods
         name: logpodpath
       # Docker runtime directory, replace this path
       # with your container runtime logs directory,
       # or remove this configuration if `/var/log/pods`
       # is not a symlink to any other directory.
       - hostPath:
           path: /var/lib/docker/containers
         name: logcontainerpath
       # (...)
   

   Le pointerdir est utilisé pour stocker un fichier avec un pointeur vers tous les conteneurs à partir desquels l’Agent recueille des logs. Ce volume permet de s’assurer qu’aucun log n’est perdu lorsque l’Agent est redémarré ou lors d’un problème réseau.

Sans privilèges

(Facultatif) Pour exécuter une installation sans privilèges, ajoutez le bloc suivant à votre modèle de pod :

  spec:
    securityContext:
      runAsUser: <USER_ID>
      supplementalGroups:
        - <DOCKER_GROUP_ID>

<USER_ID> correspond à l’UID utilisé pour exécuter l’agent et <DOCKER_GROUP_ID> à l’ID du groupe auquel appartient le socket containerd ou docker.

Lorsque l’Agent s’exécute avec un utilisateur non root, il ne peut pas lire directement les fichiers de log contenus dans /var/lib/docker/containers. Dans la plupart des cas, il est nécessaire de monter le socket Docker sur le conteneur de l’Agent, afin de pouvoir récupérer les logs du conteneur depuis le daemon Docker.

Collecte d’événements de l’Agent de cluster

Si vous souhaitez que les événements Kubernetes soient collectés par l’Agent de cluster de Datadog, suivez les étapes suivantes :

1. Désactivez l’élection de leader dans votre Agent de nœud en définissant la variable leader_election ou la variable d’environnement DD_LEADER_ELECTION sur false.

2. Dans le fichier de déploiement de l’Agent de cluster, définissez les variables d’environnement DD_COLLECT_KUBERNETES_EVENTS et DD_LEADER_ELECTION sur true :

     - name: DD_COLLECT_KUBERNETES_EVENTS
       value: "true"
     - name: DD_LEADER_ELECTION
       value: "true"
   

En configurant l’élection de leader conformément aux étapes ci-dessus, vous aurez l’assurance que la collecte des événements est assurée par un seul Agent de cluster.

Pour recueillir les événements Kubernetes avec un Agent de nœud, il est également possible de définir les variables d’environnement DD_COLLECT_KUBERNETES_EVENTS et DD_LEADER_ELECTION sur true dans le manifeste de votre Agent.

- name: DD_COLLECT_KUBERNETES_EVENTS
  value: "true"
- name: DD_LEADER_ELECTION
  value: "true"

Variables d’environnement

Voici la liste des variables d’environnement disponibles pour l’Agent Datadog qui utilise un DaemonSet.

Options globales

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 :

Pour en savoir plus sur les paramètres de proxy, consultez la documentation sur les proxys de l’Agent v6.

DogStatsD (métriques custom)

Envoyer des métriques custom avec le protocole StatsD :

En savoir plus sur DogStatsD via les sockets de domaine Unix.

Tags

Datadog recueille automatiquement les tags courants à partir de Kubernetes. Pour extraire des tags supplémentaires, utilisez les options suivantes :

Consultez la documentation sur l’extraction de tags Kubernetes pour en savoir plus.

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.

Des exemples supplémentaires sont disponibles sur la page Gestion de la découverte de conteneurs.

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.

Autodiscovery

Divers