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.
La distribución de checks de clúster 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
# (...)
Esto habilita la configuración de checks de clúster en el Cluster Agent y le permite procesar configuraciones desde las anotaciones de los servicios de Kubernetes (kube_services
).
La distribución de checks de clúster se habilita en el despliegue del Operator del Cluster Agent mediante el uso de la clave de configuración spec.features.clusterChecks.enabled
:
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
features:
clusterChecks:
enabled: true
Esto habilita la configuración de checks de clúster en el Cluster Agent y permite procesar configuraciones desde las anotaciones de los servicios de Kubernetes (kube_services
).
Cluster Agent
Una vez que tu Cluster Agent esté en ejecución, debes realizar los siguientes cambios en su despliegue:
- Establece la variable de entorno
DD_CLUSTER_CHECKS_ENABLED
como true
. - Transfiere el nombre de tu clúster a
DD_CLUSTER_NAME
. Para ayudarte entender el contexto de tus métricas, Datadog inserta el nombre del clúster como una etiqueta (tag) de instancia cluster_name
en todas las configuraciones. - Si el nombre del servicio es diferente al parámetro
datadog-cluster-agent
predeterminado, asegúrate de que la variable de entorno DD_CLUSTER_AGENT_KUBERNETES_SERVICE_NAME
refleja el nombre del servicio. - Para permitir que el Cluster Agent procese las configuraciones de las anotaciones de servicios de Kubernetes, establece estas dos variables de entorno,
DD_EXTRA_CONFIG_PROVIDERS
y DD_EXTRA_LISTENERS
, como kube_services
.
Agent
Habilita el proveedor de configuración clusterchecks
en el Agent del nodo de Datadog. Esto se puede hacer de dos maneras:
Recomendado: Estableciendo la variable de entorno DD_EXTRA_CONFIG_PROVIDERS
en el DaemonSet de tu Agent. Si tienes varios valores, se necesita una cadena en la que los valores estén separados entre sí por espacios:
DD_EXTRA_CONFIG_PROVIDERS="clusterchecks"
O añadiéndolo al archivo de configuración datadog.yaml
:
config_providers:
- name: clusterchecks
polling: 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).
Con Helm, estos archivos de configuración se pueden crear dentro de la sección clusterAgent.confd
.
#(...)
clusterAgent:
confd:
<INTEGRATION_NAME>.yaml: |-
cluster_check: true
init_config:
- <INIT_CONFIG>
instances:
- <INSTANCES_CONFIG>
Nota: Esto es independiente de la sección datadog.confd
, en la que los archivos se crean en los Agents basados en nodos. El parámetro <INTEGRATION_NAME>
debe coincidir exactamente con el check de integración que quieres ejecutar.
Con el Datadog Operator, estos archivos de configuración se pueden crear dentro de la sección spec.override.clusterAgent.extraConfd.configDataMap
:
spec:
#(...)
override:
clusterAgent:
extraConfd:
configDataMap:
<INTEGRATION_NAME>.yaml: |-
cluster_check: true
init_config:
- <INIT_CONFIG>
instances:
- <INSTANCES_CONFIG>
Si lo prefieres, puedes crear un ConfigMap para almacenar el archivo de configuración estática e integrar dicho ConfigMap en el Cluster Agent utilizando el campo spec.override.clusterAgent.extraConfd.configMap
:
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>
Con el método manual, debes crear un ConfigMap para almacenar los archivos de configuración estática que quieras y, luego, integrar dicho ConfigMap en el archivo /conf.d
correspondiente del contenedor del Cluster Agent. Se sigue el mismo enfoque para integrar ConfigMaps en el contenedor del Agent. Ejemplo:
kind: ConfigMap
apiVersion: v1
metadata:
name: "<NAME>-config-map"
data:
<INTEGRATION_NAME>-config: |-
cluster_check: true
init_config:
<INIT_CONFIG>
instances:
<INSTANCES_CONFIG>
A continuación, en el manifiesto para el despliegue del Cluster Agent, define los parámetros volumeMounts
y volumes
según tu ConfigMap
y la clave correspondiente de tus datos.
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
#(...)
Esto crea un archivo en el directorio /conf.d/
del Cluster Agent correspondiente a la integración. Ejemplo: /conf.d/mysql.yaml
o /conf.d/http_check.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:
Utiliza el campo clusterAgent.confd
para definir la configuración del check:
#(...)
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>"
Utiliza el campo spec.override.clusterAgent.extraConfd.configDataMap
para definir la configuración del check:
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>"
Integra un archivo /conf.d/http_check.yaml
en el contenedor del Cluster Agent con el siguiente contenido:
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
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/service.checks: |
{
"<INTEGRATION_NAME>": {
"init_config": <INIT_CONFIG>,
"instances": [<INSTANCE_CONFIG>]
}
}
Esta sintaxis admite una variable de plantilla %%host%%
, que se sustituye por la IP del servicio. Las etiquetas kube_namespace
y kube_service
se añaden automáticamente a la instancia.
Ejemplo: check HTTP en un servicio respaldado por NGINX
La siguiente definición de servicio expone los pods desde el despliegue de my-nginx
y ejecuta un check HTTP para medir la latencia del servicio de carga equilibrada:
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
Además, debería monitorizar cada pod con el check de NGINX, dado que así se podrían monitorizar también todos los workers y el servicio agregado.
La sintaxis para anotar servicios es similar a la utilizada para anotar pods de Kubernetes:
ad.datadoghq.com/service.check_names: '[<INTEGRATION_NAME>]'
ad.datadoghq.com/service.init_configs: '[<INIT_CONFIG>]'
ad.datadoghq.com/service.instances: '[<INSTANCE_CONFIG>]'
Esta sintaxis admite una variable de plantilla %%host%%
, que se sustituye por la IP del servicio. Las etiquetas kube_namespace
y kube_service
se añaden automáticamente a la instancia.
Ejemplo: check HTTP en un servicio respaldado por NGINX
La siguiente definición de servicio expone los pods desde el despliegue de my-nginx
y ejecuta un check HTTP para medir la latencia del servicio de carga equilibrada:
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
Además, debería monitorizar cada pod con el check de NGINX, dado que así se podrían monitorizar también todos los workers y el servicio agregado.
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
Additional helpful documentation, links, and articles: