El Cluster Agent puede enviar dos tipos de checks: checks de endpoint y checks de clúster. Los checks son ligeramente diferentes.

Los checks de endpoint se envían específicamente al Datadog Agent regular en el mismo nodo que los endpoints del pod de aplicación. La ejecución de los checks de endpoint en el mismo nodo que el endpoint de la aplicación permite el correcto etiquetado de las métricas.

Los checks de clúster monitorizan servicios de Kubernetes internos, así como servicios externos como bases de datos gestionadas y dispositivos de red, y pueden despacharse con mucha más libertad. El uso de Cluster Check Runners es opcional. Cuando se utiliza Cluster Check Runners, un pequeño conjunto dedicado de Agents ejecuta los checks de clúster, dejando los checks de endpoint a los Agents normales. Esta estrategia puede ser útil para controlar el envío de checks de clúster, en especial cuando aumenta la escala de tus checks de clúster.

Configuración

En primer lugar, despliega el Cluster Agent.

A continuación, despliega el Cluster Check Runner utilizando Datadog Operator o Helm:

Con el Operador, puedes lanzar y gestionar todos estos recursos con un único manifiesto. Por ejemplo:

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <DATADOG_API_KEY>
      appKey: <DATADOG_APP_KEY>
    clusterAgentToken: <DATADOG_CLUSTER_AGENT_TOKEN>
  features:
    clusterChecks:
      enabled: true
      useClusterChecksRunners: true
  override:
    clusterAgent:
      replicas: 2

Despliega estos recursos en tu clúster:

kubectl apply -f datadog-agent-with-dca-clusterchecksrunner.yaml

Si ves el siguiente resultado, confirma que la configuración se ha aplicado correctamente:

datadogagent.datadoghq.com/datadog created

Consulta el repositorio de Datadog Operator para obtener más información sobre Datadog Operator.

Puedes actualizar las secciones pertinentes del gráfico para habilitar checks de clúster, el Cluster Agent y el Cluster Check Runner al mismo tiempo. Por ejemplo:

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

clusterAgent:
  enabled: true
  #(...)

clusterChecksRunner:
  enabled: true
  replicas: 2

Nota: Tanto Datadog Operator como la tabla de Helm utilizan podAntiAffinity para evitar tener múltiples Cluster Check Runners en el mismo nodo. Esto es importante porque el Cluster Agent identifica los Cluster Check Runners por sus nombres de nodo. Usar podAntiAffinity evita tener nombres repetidos.

PREVIEWING: antoine.dussault/service-representation-ga-docs-us1