Información general

El Datadog Agent descubre automáticamente los contenedores y crea configuraciones de checks utilizando el mecanismo de Autodiscovery.

Los checks de clúster amplían este mecanismo para monitorizar cargas de trabajo no contenedorizadas, entre las que se incluyen:

• Almacenes de datos y endpoints ejecutados fuera del clúster (por ejemplo, RDS o CloudSQL).
• Servicios de clúster con carga equilibrada (por ejemplo, los servicios de Kubernetes).

Esto garantiza que solo se ejecute una instancia de cada check, en lugar de que todos los pods del Agent basados en nodos ejecuten el check correspondiente. El Cluster Agent almacena las configuraciones y las envía dinámicamente a los Agents basados en nodos. Los Agents se conectan al Cluster Agent cada diez segundos y recuperan las configuraciones que deben ejecutarse. Si un Agent deja de enviar información, el Cluster Agent lo elimina del grupo activo y distribuye las configuraciones a otros Agents. Esto garantiza que siempre se ejecute una (y solo una) instancia, aunque se añadan y eliminen nodos del clúster.

Las métricas, eventos y checks de servicio recopilados por los checks de clúster se envían sin nombre de host, ya que no es relevante. Asimismo, se añade una etiqueta cluster_name para permitirte dimensionar y filtrar tus datos.

Se recomienda usar checks de clúster si tu infraestructura está configurada para casos de alta disponibilidad (HA).

Configurar la distribución de checks de clúster

El proceso de configuración implica habilitar la capacidad de distribución en el Cluster Agent, así como garantizar que los Agents están preparados para recibir configuraciones del proveedor clusterchecks. Una vez hecho esto, las configuraciones pasan al Cluster Agent a través de la integración de archivos de configuración o a través de anotaciones en los servicios de Kubernetes.

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

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

Nota: Con los checks de clúster, las métricas notificadas por el Agent no se vinculan a un nombre de host determinado, ya que se supone que son métricas centradas en el clúster y no están necesariamente basadas en el host. Como resultado, estas métricas no heredan ninguna etiqueta en el host asociada a ese host, tales como las heredadas de un proveedor de servicios en la nube o las añadidas por la variable de entorno DD_TAGS del Agent. Para agregar etiquetas a las métricas de check de clúster, utiliza la variable de entorno DD_CLUSTER_CHECKS_EXTRA_TAGS.

Ejecutores de checks de clúster

El Helm chart de Datadog y el Datadog Operator ofrecen, además, la posibilidad de desplegar ejecutores de checks de clúster. Se trata del despliegue de un pequeño conjunto de Datadog Agents configurados para ejecutar únicamente los checks de clúster distribuidos, en lugar de distribuirlos a los Agents normales que se basan en nodos. Para más detalles, consulta la guía Ejecutores de checks de clúster.

Distribución avanzada

El Cluster Agent puede utilizar una lógica de distribución avanzada para los checks de clúster que tenga en cuenta el tiempo de ejecución y las muestras de las métricas de las instancias del check. Esta lógica permite que el Cluster Agent optimice la distribución entre los ejecutores de checks de clúster.

Para configurar la lógica de distribución avanzada, se debe establecer la variable de entorno DD_CLUSTER_CHECKS_ADVANCED_DISPATCHING_ENABLED como true en el Cluster Agent.

Las siguientes variables de entorno son necesarias a la hora de configurar los Agents del nodo (o los ejecutores de checks de clúster) para mostrar las estadísticas de sus checks. El Cluster Agent utiliza estas estadísticas para optimizar la lógica de distribución de los checks de clúster.

  env:
    - name: DD_CLC_RUNNER_ENABLED
      value: "true"
    - name: DD_CLC_RUNNER_HOST
      valueFrom:
        fieldRef:
          fieldPath: status.podIP

Checks personalizados

Se admite la ejecución de checks personalizados del Agent, como los checks de clúster, siempre que todos los Agents basados en nodos puedan ejecutar el check. Esto significa que el código de tu check personalizado:

• debe instalarse en todos los Agents basados en nodos en los que se haya habilitado el proveedor de configuración clusterchecks;
• no debe depender de recursos locales que no sean accesibles a todos los Agents.

Cómo configurar los checks

Configuración a partir de archivos de configuración

Cuando la URL o la IP de un determinado recurso es constante (por ejemplo, un endpoint de servicio externo o una URL pública), se puede transferir una configuración estática al Cluster Agent en forma de archivos YAML. La nomenclatura y la sintaxis de estos archivos son las mismas que las de las configuraciones estáticas del Agent basado en el nodo, excepto por la adición obligatoria de la línea cluster_check: true.

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 servicios de Kubernetes (ver ejemplo).

#(...)
clusterAgent:
  confd:
    <INTEGRATION_NAME>.yaml: |-
      cluster_check: true
      init_config:
        - <INIT_CONFIG>
      instances:
        - <INSTANCES_CONFIG>      

spec:
#(...)
  override:
    clusterAgent:
      extraConfd:
        configDataMap:
          <INTEGRATION_NAME>.yaml: |-
            cluster_check: true
            init_config:
              - <INIT_CONFIG>
            instances:
              - <INSTANCES_CONFIG>            

spec:
#(...)
  override:
    clusterAgent:
      extraConfd:
        configMap:
          name: "<NAME>-config-map"
          items:
            - key: <INTEGRATION_NAME>-config
              path: <INTEGRATION_NAME>.yaml

kind: ConfigMap
apiVersion: v1
metadata:
  name: "<NAME>-config-map"
data:
  <INTEGRATION_NAME>-config: |-
    cluster_check: true
    init_config:
      <INIT_CONFIG>
    instances:
      <INSTANCES_CONFIG>    

kind: ConfigMap
apiVersion: v1
metadata:
  name: "<NAME>-config-map"
data:
  <INTEGRATION_NAME>-config: |-
    cluster_check: true
    init_config:
      <INIT_CONFIG>
    instances:
      <INSTANCES_CONFIG>    

        volumeMounts:
          - name: <NAME>-config-map
            mountPath: /conf.d/
            # (...)
      volumes:
        - name: <NAME>-config-map
          configMap:
            name: <NAME>-config-map
            items:
              - key: <INTEGRATION_NAME>-config
                path: <INTEGRATION_NAME>.yaml
          #(...)

Ejemplo: check de MySQL en una base de datos alojada externamente

Después de configurar una base de datos alojada externamente, como CloudSQL o RDS, y un usuario de Datadog correspondiente para acceder a la base de datos, integra un archivo /conf.d/mysql.yaml en el contenedor del Cluster Agent con el siguiente contenido:

cluster_check: true
init_config:
instances:
    - server: "<PRIVATE_IP_ADDRESS>"
      port: 3306
      user: datadog
      pass: "<YOUR_CHOSEN_PASSWORD>"

Ejemplo: check HTTP en una URL externa

Si hay una URL en la que desees realizar un check HTTP por clúster, integra un archivo /conf.d/http_check.yaml en el contenedor del Cluster Agent con el siguiente contenido:

cluster_check: true
init_config:
instances:
    - name: "<EXAMPLE_NAME>"
      url: "<EXAMPLE_URL>"

Ejemplo: check HTTP en un servicio de Kubernetes

Si hay un servicio de Kubernetes en el que desees realizar un check HTTP por clúster:

#(...)
clusterAgent:
  confd:
    http_check.yaml: |-
      advanced_ad_identifiers:
        - kube_service:
            name: "<SERVICE_NAME>"
            namespace: "<SERVICE_NAMESPACE>"
      cluster_check: true
      init_config:
      instances:
        - url: "http://%%host%%"
          name: "<EXAMPLE_NAME>"      

spec:
#(...)
  override:
    clusterAgent:
      extraConfd:
        configDataMap:
          http_check.yaml: |-
            advanced_ad_identifiers:
              - kube_service:
                  name: "<SERVICE_NAME>"
                  namespace: "<SERVICE_NAMESPACE>"
            cluster_check: true
            init_config:
            instances:
              - url: "http://%%host%%"
                name: "<EXAMPLE_NAME>"            

advanced_ad_identifiers:
  - kube_service:
      name: "<SERVICE_NAME>"
      namespace: "<SERVICE_NAMESPACE>"
cluster_check: true
init_config:
instances:
  - url: "http://%%host%%"
    name: "<EXAMPLE_NAME>"

Nota: El campo advanced_ad_identifiers es compatible con el Datadog Cluster Agent v1.18 (y sus versiones posteriores).

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

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

apiVersion: v1
kind: Service
metadata:
    name: my-nginx
    labels:
        run: my-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
              }
            ]
          }
        }        
spec:
    ports:
        - port: 80
          protocol: TCP
    selector:
        run: my-nginx

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

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

Validación

El Datadog Cluster Agent distribuye cada check de clúster a un Agent de nodo para que lo ejecute. Ejecuta el subcomando clusterchecks del Datadog Cluster Agent y busca el nombre del check bajo el nombre de host del Agent de nodo:

# kubectl exec <CLUSTER_AGENT_POD_NAME> agent clusterchecks
(...)
===== Checks on default-pool-bce5cd34-ttw6.c.sandbox.internal =====

=== http_check check ===
Source: kubernetes-services
Instance ID: http_check:My service:5b948dee172af830
empty_default_hostname: true
name: My service
tags:
- kube_namespace:default
- kube_service:my-nginx
- cluster_name:example
timeout: 1
url: http://10.15.246.109
~
Init Config:
{}
===

Ahora, ejecuta el subcomando status del Agent de nodo y busca el nombre del check en la sección Checks.

# kubectl exec <NODE_AGENT_POD_NAME> agent status
...
    http_check (3.1.1)
    ------------------
      Instance ID: http_check:My service:5b948dee172af830 [OK]
      Total Runs: 234
      Metric Samples: Last Run: 3, Total: 702
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 234
      Average Execution Time : 90ms

Leer más

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

Datadog Cluster AgentDOCUMENTACIÓN Solucionar problemas en los checks de clústerDOCUMENTACIÓN Ejecutores de checks de clústerDOCUMENTACIÓN