Pour activer la distribution des checks de d’endpoint dans le déploiement de l’Operator de l’Agent de cluster, utilisez la clé de configuration features.clusterChecks.enabled :

kind: DatadogAgent
apiVersion: datadoghq.com/v2alpha1
metadata:
  name: datadog
spec:
  features:
    clusterChecks:
      enabled: true

Cette configuration permet à l’Agent de cluster de distribuer les checks de cluster et les checks d’endpoint aux Agents.

La distribution des checks d’endpoint est activée par défaut dans le déploiement Helm de l’Agent de cluster, via la clé de configuration datadog.clusterChecks.enabled :

datadog:
  clusterChecks:
    enabled: true
  # (...)
clusterAgent:
  enabled: true
  # (...)

Cette configuration permet à l’Agent de cluster de distribuer les checks de cluster et les checks d’endpoint aux Agents.

Configuration de l’Agent de cluster

Activez le fournisseur de configuration et le service d’écoute kube_endpoints dans l’Agent de cluster Datadog en définissant les variables d’environnement DD_EXTRA_CONFIG_PROVIDERS et DD_EXTRA_LISTENERS :

DD_EXTRA_CONFIG_PROVIDERS="kube_endpoints"
DD_EXTRA_LISTENERS="kube_endpoints"

Remarque : si les endpoints surveillés ne sont pas exposés par des pods, vous devez activer les checks de cluster. Pour ce faire, ajoutez le fournisseur de configuration et le service d’écoute kube_services :

DD_EXTRA_CONFIG_PROVIDERS="kube_endpoints kube_services"
DD_EXTRA_LISTENERS="kube_endpoints kube_services"

Redémarrez l’Agent pour prendre en compte le changement de configuration.

Configuration de l’Agent

Activez les fournisseurs de configuration endpointschecks dans l’Agent de nœud. Pour ce faire, deux solutions s’offrent à vous :

• Vous pouvez définir la variable d’environnement DD_EXTRA_CONFIG_PROVIDERS. Si plusieurs valeurs doivent être définies, séparez-les par des espaces dans la chaîne :

  DD_EXTRA_CONFIG_PROVIDERS="endpointschecks"
  

• Vous pouvez également l’ajouter dans le fichier de configuration datadog.yaml :

  config_providers:
      - name: endpointschecks
        polling: true
  

Remarque : si les endpoints surveillés ne sont pas exposés par des pods, vous devez activer les checks de cluster. Pour ce faire, ajoutez le fournisseur de configuration clusterchecks :

DD_EXTRA_CONFIG_PROVIDERS="endpointschecks clusterchecks"

Redémarrez l’Agent pour prendre en compte le changement de configuration.

Utilisez le champ clusterAgent.confd pour définir votre configuration de check :

#(...)
clusterAgent:
  confd:
    <NOM_INTÉGRATION>.yaml: |-
      advanced_ad_identifiers:
        - kube_endpoints:
            name: "<NOM_ENDPOINTS>"
            namespace: "<ESPACENOMMAGE_ENDPOINTS>"
      cluster_check: true
      init_config:
      instances:
        - url: "http://%%host%%"
          name: "<NOM_EXAMPLE>"      

Montez un fichier /conf.d/http_check.yaml avec le contenu suivant dans le conteneur de l’Agent de cluster :

advanced_ad_identifiers:
  - kube_endpoints:
      name: "<NOM_ENDPOINTS>"
      namespace: "<ESPACENOMMAGE_ENDPOINTS>"
cluster_check: true
init_config:
instances:
  - url: "http://%%host%%"
    name: "<NOM_EXEMPLE>"

Remarque : les annotations AD v2 ont été ajoutées dans l’Agent Datadog 7.36 afin de simplifier la configuration de l’intégration. Pour les versions précédentes de l’Agent Datadog, utilisez les annotations AD v1.

La syntaxe des services annotés est similaire à celle des pods Kubernetes annotés :

ad.datadoghq.com/endpoints.checks: |
  {
    "<NOM_INTÉGRATION>": {
      "init_config": <CONFIG_INIT>,
      "instances": [<CONFIG_INSTANCE>]
    }
  }  
ad.datadoghq.com/endpoints.logs: '[<CONFIG_LOGS>]'

Cette syntaxe prend en charge la template variable %%host%%, qui est remplacée par l’IP de chaque endpoint. Les tags kube_namespace, kube_service et kube_endpoint_ip sont automatiquement ajoutés aux instances.

Remarque : la configuration des logs des endpoints personnalisés est prise en charge lors de la collecte des logs du socket Docker, et non lors de celle des fichiers de log Kubernetes.

Exemple : check HTTP sur un service basé sur NGINX avec un check NGINX sur les endpoints du service

Ce service est associé aux pods du déploiement nginx et utilise cette configuration :

• Un check d’endpoint basé sur nginx est distribué pour chaque pod NGINX exposant ce service. Ce check est exécuté par les Agents se trouvant sur les mêmes nœuds respectifs que les pods NGINX (en utilisant l’adresse IP du pod avec %%host%%).
• Un check de cluster basé sur http_check est distribué à un seul Agent du cluster. Ce check utilise l’IP du service avec %%host%%, ce qui permet de répartir automatiquement la charge sur les endpoints concernés.
• Les checks sont distribués avec les tags env:prod, service:my-nginx et version:1.19.0, qui correspondent aux étiquettes du tagging de service unifié.

apiVersion: v1
kind: Service
metadata:
    name: nginx
    labels:
        app: nginx
        tags.datadoghq.com/env: "prod"
        tags.datadoghq.com/service: "my-nginx"
        tags.datadoghq.com/version: "1.19.0"
    annotations:
      ad.datadoghq.com/service.checks: |
        {
          "http_check": {
            "init_config": {},
            "instances": [
              {
                "url": "http://%%host%%",
                "name": "My Nginx",
                "timeout": 1
              }
            ]
          }
        }        
      ad.datadoghq.com/endpoints.checks: |
        {
          "nginx": {
            "init_config": {},
            "instances": [
              {
                "name": "My Nginx Service Endpoints",
                "nginx_status_url": "http://%%host%%:%%port%%/status/"
              }
            ]
          }
        }        
      ad.datadoghq.com/endpoints.logs: '[{"source":"nginx","service":"webapp"}]'
spec:
    ports:
        - port: 80
          protocol: TCP
    selector:
        app: nginx

La syntaxe des services annotés est similaire à celle des pods Kubernetes annotés :

ad.datadoghq.com/endpoints.check_names: '[<NOM_INTÉGRATION>]'
ad.datadoghq.com/endpoints.init_configs: '[<CONFIG_INIT>]'
ad.datadoghq.com/endpoints.instances: '[<CONFIG_INSTANCE>]'
ad.datadoghq.com/endpoints.logs: '[<CONFIG_LOGS>]'

Cette syntaxe prend en charge la template variable %%host%%, qui est remplacée par l’IP de chaque endpoint. Les tags kube_namespace, kube_service et kube_endpoint_ip sont automatiquement ajoutés aux instances.

Remarque : la configuration des logs des endpoints personnalisés est prise en charge lors de la collecte des logs du socket Docker, et non lors de celle des fichiers de log Kubernetes.

Exemple : check HTTP sur un service basé sur NGINX avec un check NGINX sur les endpoints du service

Ce service est associé aux pods du déploiement nginx et utilise cette configuration :

• Un check d’endpoint basé sur nginx est distribué pour chaque pod NGINX exposant ce service. Ce check est exécuté par les Agents se trouvant sur les mêmes nœuds respectifs que les pods NGINX (en utilisant l’adresse IP du pod avec %%host%%).
• Un check de cluster basé sur http_check est distribué à un seul Agent du cluster. Ce check utilise l’IP du service avec %%host%%, ce qui permet de répartir automatiquement la charge sur les endpoints concernés.
• Les checks sont distribués avec les tags env:prod, service:my-nginx et version:1.19.0, qui correspondent aux étiquettes du tagging de service unifié.

apiVersion: v1
kind: Service
metadata:
    name: nginx
    labels:
        app: nginx
        tags.datadoghq.com/env: "prod"
        tags.datadoghq.com/service: "my-nginx"
        tags.datadoghq.com/version: "1.19.0"
    annotations:
        ad.datadoghq.com/endpoints.check_names: '["nginx"]'
        ad.datadoghq.com/endpoints.init_configs: '[{}]'
        ad.datadoghq.com/endpoints.instances: |
            [
              {
                "name": "My Nginx Service Endpoints",
                "nginx_status_url": "http://%%host%%:%%port%%/nginx_status"
              }
            ]            
        ad.datadoghq.com/service.check_names: '["http_check"]'
        ad.datadoghq.com/service.init_configs: '[{}]'
        ad.datadoghq.com/service.instances: |
            [
              {
                "name": "My Nginx Service",
                "url": "http://%%host%%"
              }
            ]            
        ad.datadoghq.com/endpoints.logs: '[{"source":"nginx","service":"webapp"}]'
spec:
    ports:
        - port: 80
          protocol: TCP
    selector:
        app: nginx