Présentation

La ressource personnalisée (CR) DatadogInstrumentation vous permet de configurer les checks et les logs Autodiscovery avec une seule ressource Kubernetes au lieu des annotations de pod. Grâce à cette approche, vous pouvez activer, mettre à jour et supprimer des configurations d’intégration sans modifier votre Agent ou votre application et sans déclencher de déploiement.

Utilisez la CR DatadogInstrumentation lorsque vous souhaitez :

• Configurer des checks et des logs sans modifier les manifestes de charge de travail ni ajouter d’annotations.
• Utilisez une spécification de ressource structurée avec validation au lieu de JSON brut dans les annotations.
• Gérez de manière centralisée la configuration d’Autodiscovery par charge de travail en tant que ressource Kubernetes dédiée et versionnée.
• Mettez à jour ou supprimez la configuration d’Autodiscovery sans redémarrer vos pods d’application.

Lorsque vous créez ou mettez à jour une ressource DatadogInstrumentation, le Datadog Cluster Agent valide la cible, signale le statut de la ressource et applique la configuration d’Autodiscovery à la charge de travail ciblée.

Prérequis

Passez à la v7.82+ du Datadog Agent et du Cluster Agent et installez la CRD DatadogInstrumentation avec l’une des options suivantes :

• Datadog Operator v1.29 ou version ultérieure.
• Datadog Helm chart v3.236.0 ou version ultérieure.

Configuration

Le contrôleur DatadogInstrumentation s’exécute dans le Cluster Agent et est désactivé par défaut. Activez-le avec le Datadog Operator ou Helm.

helm repo update

helm upgrade datadog-operator datadog/datadog-operator

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
  annotations:
    agent.datadoghq.com/instrumentation-crd-enabled: "true"
spec:
  global:
    [...]

kubectl apply -f datadog-agent.yaml

helm repo update

datadog:
  instrumentationCrd:
    enabled: true

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

Assurez-vous que la CRD DatadogInstrumentation est installée avant de créer des ressources :

kubectl get crd datadoginstrumentations.datadoghq.com

Si vous gérez les CRD Datadog séparément, installez ou mettez à niveau le Datadog CRDs Helm chart :

helm upgrade --install datadog-crds datadog/datadog-crds

Charges de travail ciblées

DatadogInstrumentation (DDI) pour l’Autodiscovery se compose de trois parties :

• spec.targetRef: identifie la charge de travail à configurer, par apiVersion, kind et name. Votre ressource personnalisée et la charge de travail cible doivent se trouver dans le même espace de nommage.
• spec.config.checks: définit les checks d’intégration à exécuter sur votre charge de travail.
• spec.config.logs: définit les logs à collecter depuis votre charge de travail.

Vous pouvez cibler les ressources Kubernetes suivantes :

Cet exemple configure une intégration Redis pour un StatefulSet nommé redis, en reproduisant cet exemple basé sur des annotations.

apiVersion: datadoghq.com/v1alpha1
kind: DatadogInstrumentation
metadata:
  name: <YOUR_CR_NAME>
  namespace: <YOUR_TARGETS_NAMESPACE>
spec:
  targetRef:
    apiVersion: apps/v1
    kind: StatefulSet
    name: redis
  config:
    checks:
      - integration: redisdb
        containerName: redis
        initConfig: {}
        instances:
          - host: "%%host%%"
            port: "6379"
            password: "%%env_REDIS_PASSWORD%%"
    logs:
      - containerName: redis
        tags:
          - env:demo

Appliquez la ressource :

kubectl apply -f redis-instrumentation.yaml

Vérifiez le statut de la ressource :

kubectl describe datadoginstrumentation <YOUR_CR_NAME> -n <YOUR_TARGETS_NAMESPACE>

Chaque entrée dans checks accepte les champs suivants :

integration

Requis. Le nom de l’intégration Datadog à exécuter, par exemple redisdb.

containerName

Requis pour les cibles de charge de travail. La valeur doit correspondre à un nom de conteneur dans le pod. Omettez ce champ pour les cibles de service.

initConfig

Optionnel. La section init_config pour l’intégration.

instances

Optionnel. Vérifiez les paramètres de l’instance. Chaque instance peut utiliser des variables de modèle d’Autodiscovery, y compris %%host%%.

Chaque entrée dans logs accepte les mêmes options de collecte de logs que les annotations de log d’Autodiscovery, telles que tags, type et path. Chaque entrée nécessite un containerName correspondant à un conteneur dans le pod.

Services cibles

Cibler un Service configure un check d’endpoint similaire à une annotation sur un service Kubernetes.

• Datadog planifie un check d’endpoint pour chaque endpoint du Service.
• %%host%% résout vers l’adresse IP de l’endpoint.
• Si un endpoint est pris en charge par un Pod Kubernetes, Datadog ajoute les tags de Pod collectés pour ce Pod.
• Si un endpoint n’est pas pris en charge par un Pod, Datadog convertit le check en un check de cluster classique sans tags spécifiques au Pod.

Voici un exemple de configuration d’un check nginx pour un Service Kubernetes :

apiVersion: datadoghq.com/v1alpha1
kind: DatadogInstrumentation
metadata:
  name: <YOUR_CR_NAME>
  namespace: <YOUR_SERVICES_NAMESPACE>
spec:
  targetRef:
    apiVersion: v1
    kind: Service
    name: nginx
  config:
    checks:
      - integration: nginx
        initConfig: {}
        instances:
          - name: "My NGINX Service Endpoints"
            nginx_status_url: "http://%%host%%:%%port%%/status/"

Priorité

Lorsqu’une charge de travail est soumise à plusieurs sources de configuration, le Datadog Agent les résout dans l’ordre suivant (priorité la plus élevée en premier) :

1. Annotations de Pod
2. DatadogInstrumentation ressource personnalisée
3. Configuration statique, telle que l’auto-configuration ou les fichiers montés

Si une charge de travail possède déjà une configuration d’Autodiscovery basée sur des annotations pour un check ou une collecte de logs, votre configuration DatadogInstrumentation ne la remplace pas.

Une ressource par cible

Une charge de travail ou un Service ne peut être la cible que d’une seule ressource DatadogInstrumentation au sein d’un espace de nommage. Un webhook de validation rejette une ressource dont le targetRef appartient déjà à une autre ressource, ou dont le targetRef pointe vers un type non pris en charge.

Vérifiez les checks planifiés

Le statut de la ressource indique si le Cluster Agent a accepté la configuration. Pour vérifier que les checks sont planifiées, exécutez agent configcheck sur le Node Agent où s’exécute la charge de travail cible.

Les checks configurés via une ressource DatadogInstrumentation répertorient instrumentation-checks comme fournisseur de configuration et datadoginstrumentation:<NAMESPACE>/<CR_NAME> comme source de configuration. L’exemple suivant montre le résultat pour un check redisdb planifié à partir d’une ressource ciblant une charge de travail Redis :

> agent configcheck
# other configs...

=== redisdb check ===
Configuration provider: instrumentation-checks
Configuration source: datadoginstrumentation:cache/redis-instrumentation
Config for instance ID: redisdb:d5dd267b580bc10e
host: 10.244.0.7
password: "********"
port: 6379
Init Config:
{}
Log Config:
- tags:
  - env:demo
Auto-discovery IDs:
* redis

Lectures complémentaires

Documentation, liens et articles supplémentaires utiles:

Configurez les intégrations avec AutodiscoveryDOCUMENTATION Prise en main d'AutodiscoveryDOCUMENTATION Scénarios et exemples d'AutodiscoveryDOCUMENTATION Agent de cluster DatadogDOCUMENTATION