Checks de endpoint con Autodiscovery

Documentos > Monitorización de contenedores > Cluster Agent para Kubernetes > Checks de endpoint con Autodiscovery

Información general

La función de los checks de clúster ofrece la posibilidad de utilizar Autodiscovery y de realizar checks en servicios de clúster con equilibrio de carga, tales como los servicios de Kubernetes. Los checks de endpoint amplían este mecanismo para monitorizar todos los endpoints gestionados por un servicio de Kubernetes.

El Cluster Agent detecta las configuraciones de checks de endpoint basadas en anotaciones de Autodiscovery en los servicios de Kubernetes. A continuación, el Cluster Agent distribuye estas configuraciones a los Agents basados en nodos para que las ejecuten individualmente. Los checks de endpoint se distribuyen a los Agents que se ejecutan en el mismo nodo que el pod (o pods) que respalda el endpoint (o endpoints) del servicio monitorizado de Kubernetes. Gracias a esta lógica de distribución, el Agent puede añadir las etiquetas (tags) de pod y contenedor que ya ha recopilado para cada pod.

Los Agents conectan con el Cluster Agent cada diez segundos y obtienen las configuraciones de los checks que deben ejecutar. Las métricas procedentes de los checks de endpoint se envían con etiquetas de servicio, etiquetas de Kubernetes, etiquetas de host y la etiqueta kube_endpoint_ip, que se basa en la dirección IP evaluada.

Control de versiones: Kubernetes admite esta función en el caso del Datadog Agent v6.12.0 y del Datadog Cluster Agent v1.3.0 (y sus respectivas versiones posteriores). A partir del Cluster Agent v1.4.0, el Cluster Agent convierte todos los checks de endpoint de un endpoint no respaldado por un pod en checks de clúster normales. Por tanto, debes activar la función de los checks de clúster (además de la función de los checks de endpoint) para aprovechar esta funcionalidad.

Nota: Si los pods que respaldan tu servicio son estáticos, tienes que añadir la anotación ad.datadoghq.com/endpoints.resolve. El Cluster Agent programa los checks como checks de endpoint y los distribuye a ejecutores de checks de clúster. Para saber cómo usar la anotación con el servidor de la API de Kubernetes, consulta este ejemplo.

Ejemplo: servicio con endpoints

En el siguiente ejemplo, se ha creado un despliegue de Kubernetes para NGINX con tres pods.

kubectl get pods --selector app=nginx -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP           NODE
nginx-66d557f4cf-m4c7t   1/1     Running   0          3d    10.0.0.117   gke-cluster-default-pool-4658d5d4-k2sn
nginx-66d557f4cf-smsxv   1/1     Running   0          3d    10.0.1.209   gke-cluster-default-pool-4658d5d4-p39c
nginx-66d557f4cf-x2wzq   1/1     Running   0          3d    10.0.1.210   gke-cluster-default-pool-4658d5d4-p39c

También se ha creado un servicio que se enlaza con los pods a través de estos tres endpoints.

kubectl get service 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 endpoints nginx -o yaml
...
- addresses:
  - ip: 10.0.0.117
    nodeName: gke-cluster-default-pool-4658d5d4-k2sn
    targetRef:
      kind: Pod
      name: nginx-66d557f4cf-m4c7t
      ...
  - ip: 10.0.1.209
    nodeName: gke-cluster-default-pool-4658d5d4-p39c
    targetRef:
      kind: Pod
      name: nginx-66d557f4cf-smsxv
      ...
  - ip: 10.0.1.210
    nodeName: gke-cluster-default-pool-4658d5d4-p39c
    targetRef:
      kind: Pod
      name: nginx-66d557f4cf-x2wzq
      ...

Mientras que los checks de clúster basados en un servicio comprueban la dirección IP única del servicio, los checks de endpoint están programados para comprobar cada uno de los tres endpoints asociados a este servicio.

Por diseño, los checks de endpoint se distribuyen hacia los Agents que se ejecutan en el mismo nodo que los pods que respaldan los endpoints del servicio nginx. En este ejemplo, los Agents que se ejecutan en los nodos gke-cluster-default-pool-4658d5d4-k2sn y gke-cluster-default-pool-4658d5d4-p39c lanzan los checks en estos pods nginx.

Configurar la distribución de checks de endpoint

La distribución de checks de endpoint se habilita en el despliegue del Operator del Cluster Agent a través de la clave de configuración de features.clusterChecks.enabled:

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

Esta configuración habilita la distribución de los checks de clúster y de los checks de endpoint entre el Cluster Agent y los Agents.

La distribución de checks de endpoint se habilita por defecto en el despliegue de Helm del Cluster Agent a través de la clave de configuración de datadog.clusterChecks.enabled:

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

Esta configuración habilita la distribución de los checks de clúster y de los checks de endpoint entre el Cluster Agent y los Agents.

Configuración del Cluster Agent

Habilita el proveedor de configuración y el proceso de escucha kube_endpoints en el Datadog Cluster Agent. Establece las variables de entorno DD_EXTRA_CONFIG_PROVIDERS y DD_EXTRA_LISTENERS:

DD_EXTRA_CONFIG_PROVIDERS="kube_endpoints"
DD_EXTRA_LISTENERS="kube_endpoints"

Nota: Si los endpoints monitorizados no están respaldados por pods, debes habilitar los checks de clúster. Añade el proveedor de configuración y el proceso de escucha kube_services:

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

Reinicia el Agent para aplicar el cambio de configuración.

Configuración del Agent

Habilita los proveedores de configuración endpointschecks en el Agent basado en nodos. Esto puede hacerse de dos formas:

Estableciendo la variable de entorno DD_EXTRA_CONFIG_PROVIDERS. Si tienes varios valores, se necesita una cadena en la que los valores estén separados entre sí por espacios:
```
DD_EXTRA_CONFIG_PROVIDERS="endpointschecks"
```

O añadiéndolo al archivo de configuración datadog.yaml:

config_providers:
    - name: endpointschecks
      polling: true

Nota: Si los endpoints monitorizados no están respaldados por pods, debes habilitar los checks de clúster. Esto se puede hacer añadiendo el proveedor de configuración clusterchecks:

DD_EXTRA_CONFIG_PROVIDERS="endpointschecks clusterchecks"

Reinicia el Agent para aplicar el cambio de configuración.

Cómo configurar los checks

Configuración a partir de archivos de configuración estática

En la versión 1.18.0 (y posteriores) del Cluster Agent, puedes utilizar advanced_ad_identifiers y las variables de plantilla de Autodiscovery en la configuración de tu check para dirigirte a los endpoints de Kubernetes (ver ejemplo).

Ejemplo: check HTTP en endpoints de Kubernetes

Para realizar un check HTTP en los endpoints de un servicio de Kubernetes:

Utiliza el campo clusterAgent.confd para definir la configuración del check:

#(...)
clusterAgent:
  confd:
    <INTEGRATION_NAME>.yaml: |-
      advanced_ad_identifiers:
        - kube_endpoints:
            name: "<ENDPOINTS_NAME>"
            namespace: "<ENDPOINTS_NAMESPACE>"
      cluster_check: true
      init_config:
      instances:
        - url: "http://%%host%%"
          name: "<EXAMPLE_NAME>"

Integra un archivo /conf.d/http_check.yaml en el contenedor del Cluster Agent con el siguiente contenido:

advanced_ad_identifiers:
  - kube_endpoints:
      name: "<ENDPOINTS_NAME>"
      namespace: "<ENDPOINTS_NAMESPACE>"
cluster_check: true
init_config:
instances:
  - url: "http://%%host%%"
    name: "<EXAMPLE_NAME>"

Configuración a partir de anotaciones en los servicios de Kubernetes

Nota: AD Annotations v2 se introdujo en el Datadog Agent v7.36 para simplificar la configuración de la integración. Si tu versión del Datadog Agent es anterior, usa AD Annotations v1.

La sintaxis para anotar servicios es similar a la utilizada para anotar pods de Kubernetes:

ad.datadoghq.com/endpoints.checks: |
  {
    "<INTEGRATION_NAME>": {
      "init_config": <INIT_CONFIG>,
      "instances": [<INSTANCE_CONFIG>]
    }
  }  
ad.datadoghq.com/endpoints.logs: '[<LOGS_CONFIG>]'

Esta sintaxis admite una variable de plantilla %%host%% que se sustituye por la IP de cada endpoint. Las etiquetas kube_namespace, kube_service y kube_endpoint_ip se añaden automáticamente a las instancias.

Nota: La configuración personalizada de logs de los endpoints solo se admite durante la recopilación de logs con el socket de Docker, y no durante la recopilación de archivos de logs de Kubernetes.

Ejemplo: check de HTTP en un servicio respaldado por NGINX con un check de NGINX en los endpoints del servicio

Este servicio está asociado a los pods del despliegue de nginx. En función de esta configuración:

Se distribuye un check de endpoint basado en nginx para cada pod de NGINX que respalde este servicio. Este check lo ejecutan los Agents en los mismos nodos que los pods de NGINX (utilizando la IP del pod como %%host%%).
Se distribuye un check de clúster basado en http_check hacia un único Agent del clúster. Este check utiliza la IP del servicio como %%host%%, lo que equilibra automáticamente la carga en los respectivos endpoints.
Los checks se distribuyen con las etiquetas (tags) env:prod, service:my-nginx y version:1.19.0, correspondientes a las etiquetas (labels) del etiquetado de servicios unificado.

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 sintaxis para anotar servicios es similar a la utilizada para anotar pods de Kubernetes:

ad.datadoghq.com/endpoints.check_names: '[<INTEGRATION_NAME>]'
ad.datadoghq.com/endpoints.init_configs: '[<INIT_CONFIG>]'
ad.datadoghq.com/endpoints.instances: '[<INSTANCE_CONFIG>]'
ad.datadoghq.com/endpoints.logs: '[<LOGS_CONFIG>]'

Ejemplo: check de HTTP en un servicio respaldado por NGINX con un check de NGINX en los endpoints del servicio

Este servicio está asociado a los pods del despliegue de nginx. En función de esta configuración:

Se distribuye un check de endpoint basado en nginx para cada pod de NGINX que respalde este servicio. Este check lo ejecutan los Agents en los mismos nodos que los pods de NGINX (utilizando la IP del pod como %%host%%).
Se distribuye un check de clúster basado en http_check hacia un único Agent del clúster. Este check utiliza la IP del servicio como %%host%%, lo que equilibra automáticamente la carga en los respectivos endpoints.
Los checks se distribuyen con las etiquetas (tags) env:prod, service:my-nginx y version:1.19.0, correspondientes a las etiquetas (labels) del etiquetado de servicios unificado.

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

Leer más

Más enlaces, artículos y documentación útiles:

Cluster AgentDOCUMENTACIÓN

Checks de clústerDOCUMENTACIÓN

Solucionar problemas en los checks de endpointDOCUMENTACIÓN