Exécuter des checks d'endpoint avec Autodiscovery

Cette traduction n'est pas à jour. Pour consulter la dernière version en anglais, cliquez ici

Fonctionnement

La fonction Check de cluster permet de découvrir automatiquement des services de cluster à charge équilibrée (p. ex., les services Kubernetes) et d’effectuer des checks sur ces derniers.

La fonction Checks d’endpoint repose sur le même principe et permet de surveiller l’ensemble des endpoints derrière des services de cluster.

L’Agent de cluster conserve les configurations et les expose aux Agents de nœud afin qu’ils puissent les lire et les convertir en checks d’endpoint.

Les checks d’endpoint sont planifiés par des Agents qui s’exécutent sur le même nœud que le ou les pods qui exposent le ou les endpoints du service surveillé.

Les Agents se connectent à l’Agent de cluster toutes les 10 secondes et récupèrent les configurations de check à exécuter. Les métriques provenant des checks d’endpoint seront envoyées avec des tags de service, de pod et de host.

Cette fonction est prise en charge par Kubernetes pour les versions 6.12.0 et ultérieures de l’Agent et les versions 1.3.0 et ultérieures de l’Agent de cluster.

À partir de la version 1.4.0 de l’Agent de cluster, chaque check pour un endpoint non exposé par un pod est converti en check de cluster classique. Pour tirer parti de cette fonctionnalité, assurez-vous d’activer les checks de cluster ainsi que les checks d’endpoint.

Exemple : trois pods NGINX exposés par le service `nginx`

# kubectl get svc nginx -o wide
NAME    TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE   SELECTOR
nginx   ClusterIP   10.3.253.165   <none>        80/TCP    1h    app=nginx

# kubectl get pods --selector app=nginx
NAME                     READY   STATUS    RESTARTS   AGE
nginx-758655469f-59q9z   1/1     Running   0          20h
nginx-758655469f-k8zrc   1/1     Running   0          20h
nginx-758655469f-lk9p6   1/1     Running   0          20h

# kubectl get ep nginx -o yaml
...
- addresses:
  - ip: 10.0.0.117
    nodeName: gke-cluster-default-pool-4658d5d4-k2sn
    targetRef:
      kind: Pod
      name: nginx-758655469f-lk9p6
      ...
  - ip: 10.0.1.209
    nodeName: gke-cluster-default-pool-4658d5d4-p39c
    targetRef:
      kind: Pod
      name: nginx-758655469f-59q9z
      ...
  - ip: 10.0.1.210
    nodeName: gke-cluster-default-pool-4658d5d4-p39c
    targetRef:
      kind: Pod
      name: nginx-758655469f-k8zrc
      ...

De par leur nature, les checks d’endpoint sont planifiés par des Agents qui s’exécutent sur le même nœud que les pods qui exposent les endpoints du service nginx. Ainsi, seuls les Agents s’exécutant sur les nœuds gke-cluster-default-pool-4658d5d4-k2sn et gke-cluster-default-pool-4658d5d4-p39c planifient les checks sur les pods nginx.

Ce fonctionnement permet d’exploiter Autodiscovery et de joindre des tags de pod et de conteneur aux métriques envoyées par ces pods.

Configuration

Configuration de l’Agent de cluster

Activez le fournisseur de configuration et le service d’écoute kube_endpoints dans l’Agent de cluster Datadog. Pour ce faire, définissez 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 Datadog. 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.

Implémentation des configurations de check via les annotations de services Kubernetes

De même qu’avec l’annotation de pods Kubernetes, les services peuvent être annotés avec la syntaxe suivante :

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>]'

La template variable %%host%% est prise en charge et remplacée par les IP des endpoints. Les tags kube_namespace, kube_service et kube_endpoint_ip sont automatiquement ajoutés aux instances.

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

La définition de service suivante expose les pods d’un déploiement my-nginx. Elle exécute ensuite un check HTTP afin de mesurer la latence du service à charge équilibrée, ainsi qu’un check NGINX sur les pods qui exposent le ou les endpoints du service dans le but de recueillir des métriques NGINX et des checks de service au niveau des pods :

apiVersion: v1
kind: Service
metadata:
    name: my-nginx
    labels:
        run: my-nginx
    annotations:
        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%%",
                "timeout": 1
              }
            ]
        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/endpoints.logs: '[{"source":"nginx","service":"webapp"}]'
spec:
    ports:
        - port: 80
          protocol: TCP
    selector:
        run: my-nginx

Dépannage

Le dépannage de checks d’endpoint est semblable au dépannage de checks de cluster. La seule différence se situe au niveau des Agents de nœud, où les checks d’endpoint planifiés apparaissent à côté du check de cluster.

Remarque : les checks d’endpoint sont planifiés par des Agents qui s’exécutent sur le même nœud que le ou les pods qui exposent le ou les endpoints du service. Si un endpoint n’est pas exposé par un pod, l’Agent de cluster convertit le check en check de cluster. Le check de cluster peut être exécuté par n’importe quel Agent de nœud.

Autodiscovery dans l’Agent de nœud

La commande configcheck de l’Agent devrait renvoyer l’instance, avec la source de endpoints-checks :

# kubectl exec <NOM_POD_AGENT_NŒUD> agent configcheck
...
=== nginx check ===
Configuration provider: endpoints-checks
Configuration source: kube_endpoints:kube_endpoint_uid://default/nginx/
Instance ID: nginx:My Nginx Service Endpoints:2f7fd6b090782d6b
name: My Nginx Endpoints
nginx_status_url: http://10.0.0.75/nginx_status/
tags:
- pod_phase:running
- kube_deployment:nginx
- kube_service:nginx
- kube_namespace:default
- kube_endpoint_ip:10.0.0.75
- cluster_name:cluster
~
Init Config:
{}
Auto-discovery IDs:
* kube_endpoint_uid://default/nginx/10.0.0.75
* kubernetes_pod://4e733448-f57e-11e9-8123-42010af001ed
State: dispatched to gke-cluster-default-pool-4658d5d4-qfnt
===

Commande status de l’Agent

La commande status de l’Agent devrait indiquer que l’instance de check est en cours d’exécution et qu’elle envoie correctement des informations.

# kubectl exec <NOM_POD_AGENT_NŒUD> agent status
...
    nginx (3.4.0)
    -------------
      Instance ID: nginx:My Nginx Service Endpoints:2f7fd6b090782d6b [OK]
      Configuration Source: kube_endpoints:kube_endpoint_uid://default/nginx/
      Total Runs: 443
      Metric Samples: Last Run: 7, Total: 3,101
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 443
      Average Execution Time : 5ms

Autodiscovery dans l’Agent de cluster

La commande clusterchecks de l’Agent devrait renvoyer l’instance, avec la source de kubernetes-endpoints :

# kubectl exec <NOM_POD_AGENT_CLUSTER> agent clusterchecks
...
===== 3 Pod-backed Endpoints-Checks scheduled =====

=== nginx check ===
Configuration provider: kubernetes-endpoints
Configuration source: kube_endpoints:kube_endpoint_uid://default/nginx/
Instance ID: nginx:My Nginx Service Endpoints:f139adc46c81828e
name: My Nginx Endpoints
nginx_status_url: http://10.0.0.75/nginx_status/
tags:
- kube_service:nginx
- kube_namespace:default
- kube_endpoint_ip:10.0.0.75
- cluster_name:cluster
~
Init Config:
{}
Auto-discovery IDs:
* kube_endpoint_uid://default/nginx/10.0.0.75
* kubernetes_pod://4e733448-f57e-11e9-8123-42010af001ed
State: dispatched to gke-cluster-default-pool-4658d5d4-qfnt
===
...