Descripción general

El recurso personalizado (CR) DatadogInstrumentation le permite configurar las verificaciones y los registros de Autodiscovery con un único recurso de Kubernetes en lugar de anotaciones de pod. Con este enfoque, puede habilitar, actualizar y eliminar configuraciones de integración sin editar su Agent o aplicación y activar un despliegue.

Utilice el CR DatadogInstrumentation cuando desee:

• Configure las verificaciones y los registros sin modificar los manifiestos de carga de trabajo ni agregar anotaciones.
• Utilice una especificación de recurso estructurada con validación en lugar de JSON sin formato en las anotaciones.
• Administre de forma centralizada la configuración de Autodiscovery por carga de trabajo como un recurso de Kubernetes dedicado y con control de versiones.
• Actualice o elimine la configuración de Autodiscovery sin reiniciar los pods de su aplicación.

Cuando crea o actualiza un recurso DatadogInstrumentation, el Datadog Cluster Agent valida el destino, informa el estado del recurso y aplica la configuración de Autodiscovery a la carga de trabajo seleccionada.

Requisitos

Actualice a la v7.82+ del Datadog Agent y Cluster Agent e instale el CRD DatadogInstrumentation con una de las siguientes opciones:

• Datadog Operator v1.29 o posterior.
• Datadog Helm chart v3.236.0 o posterior.

Configuración

El controlador DatadogInstrumentation se ejecuta en el Cluster Agent y está deshabilitado de forma predeterminada. Habilítelo con Datadog Operator o Helm.

helm repo update

helm upgrade datadog-operator datadog/datadog-operator

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
  annotations:
    agent.datadoghq.com/instrumentation-crd-enabled: "true"
spec:
  global:
    [...]

kubectl apply -f datadog-agent.yaml

helm repo update

datadog:
  instrumentationCrd:
    enabled: true

helm upgrade -f datadog-values.yaml <RELEASE_NAME> datadog/datadog

Asegúrese de que el CRD DatadogInstrumentation esté instalado antes de crear recursos:

kubectl get crd datadoginstrumentations.datadoghq.com

Si administra los CRD de Datadog por separado, instale o actualice el chart de Helm de los CRD de Datadog:

helm upgrade --install datadog-crds datadog/datadog-crds

Cargas de trabajo de destino

DatadogInstrumentation (DDI) para Autodiscovery consta de tres partes:

• spec.targetRef: identifica la carga de trabajo que se va a configurar, mediante apiVersion, kind y name. Su recurso personalizado y la carga de trabajo de destino deben estar en el mismo espacio de nombres.
• spec.config.checks: define las verificaciones de integración que se ejecutarán en su carga de trabajo.
• spec.config.logs: define los registros que se recopilarán de su carga de trabajo.

Puede dirigirse a los siguientes recursos de Kubernetes:

Este ejemplo configura una integración de Redis para un StatefulSet llamado redis, replicando este ejemplo basado en anotaciones.

apiVersion: datadoghq.com/v1alpha1
kind: DatadogInstrumentation
metadata:
  name: <YOUR_CR_NAME>
  namespace: <YOUR_TARGETS_NAMESPACE>
spec:
  targetRef:
    apiVersion: apps/v1
    kind: StatefulSet
    name: redis
  config:
    checks:
      - integration: redisdb
        containerName: redis
        initConfig: {}
        instances:
          - host: "%%host%%"
            port: "6379"
            password: "%%env_REDIS_PASSWORD%%"
    logs:
      - containerName: redis
        tags:
          - env:demo

Aplique el recurso:

kubectl apply -f redis-instrumentation.yaml

Verifique el estado del recurso:

kubectl describe datadoginstrumentation <YOUR_CR_NAME> -n <YOUR_TARGETS_NAMESPACE>

Cada entrada en checks acepta los siguientes campos:

integration

Obligatorio. El nombre de la integración de Datadog que se ejecutará, por ejemplo redisdb.

containerName

Obligatorio para destinos de carga de trabajo. El valor debe coincidir con un nombre de contenedor en el pod. Omita este campo para destinos de servicio.

initConfig

Opcional. La sección init_config para la integración.

instances

Opcional. Verifique la configuración de la instancia. Cada instancia puede utilizar variables de plantilla de Autodiscovery, incluyendo %%host%%.

Cada entrada en logs acepta las mismas opciones de recopilación de registros que las anotaciones de registro de Autodiscovery, tales como tags, type y path. Cada entrada requiere un containerName que coincida con un contenedor en el pod.

Servicios objetivo

Apuntar a un Service configura una verificación de punto de conexión similar a una anotación en un servicio de Kubernetes.

• Datadog programa una verificación de punto de conexión para cada punto de conexión del Servicio.
• %%host%% se resuelve a la IP del punto de conexión.
• Si un punto de conexión está respaldado por un Pod de Kubernetes, Datadog añade las etiquetas de Pod recopiladas para ese Pod.
• Si un punto de conexión no está respaldado por un Pod, Datadog convierte la verificación en una verificación de clúster regular sin etiquetas específicas de Pod.

A continuación se muestra un ejemplo de configuración de una verificación de nginx para un Service de Kubernetes:

apiVersion: datadoghq.com/v1alpha1
kind: DatadogInstrumentation
metadata:
  name: <YOUR_CR_NAME>
  namespace: <YOUR_SERVICES_NAMESPACE>
spec:
  targetRef:
    apiVersion: v1
    kind: Service
    name: nginx
  config:
    checks:
      - integration: nginx
        initConfig: {}
        instances:
          - name: "My NGINX Service Endpoints"
            nginx_status_url: "http://%%host%%:%%port%%/status/"

Precedencia

Cuando más de una fuente de configuración se aplica a una carga de trabajo, el Datadog Agent las resuelve en el siguiente orden (primero la mayor precedencia):

1. Anotaciones de Pod
2. DatadogInstrumentation recurso personalizado
3. Configuración estática, como auto-configuración o archivos montados

Si una carga de trabajo ya tiene una configuración de Autodiscovery basada en anotaciones para una verificación o recopilación de registros, su configuración de DatadogInstrumentation no la anula.

Un recurso por destino

Una carga de trabajo o un servicio puede ser el destino de solo un recurso DatadogInstrumentation dentro de un espacio de nombres. Un webhook de validación rechaza un recurso cuyo targetRef ya pertenece a otro recurso, o cuyo targetRef apunta a un tipo no admitido.

Verifique las verificaciones programadas

El estado del recurso muestra si el Cluster Agent aceptó la configuración. Para verificar que las verificaciones estén programadas, ejecute agent configcheck en el Node Agent donde se ejecuta la carga de trabajo de destino.

Las verificaciones configuradas a través de un recurso DatadogInstrumentation listan a instrumentation-checks como el proveedor de configuración y a datadoginstrumentation:<NAMESPACE>/<CR_NAME> como la fuente de configuración. El siguiente ejemplo muestra la salida para una verificación redisdb programada desde un recurso que tiene como destino una carga de trabajo de Redis:

> agent configcheck
# other configs...

=== redisdb check ===
Configuration provider: instrumentation-checks
Configuration source: datadoginstrumentation:cache/redis-instrumentation
Config for instance ID: redisdb:d5dd267b580bc10e
host: 10.244.0.7
password: "********"
port: 6379
Init Config:
{}
Log Config:
- tags:
  - env:demo
Auto-discovery IDs:
* redis

Lecturas adicionales

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

Configure integraciones con AutodiscoveryDOCUMENTACIÓN Introducción a AutodiscoveryDOCUMENTACIÓN Escenarios y ejemplos de AutodiscoveryDOCUMENTACIÓN Datadog Cluster AgentDOCUMENTACIÓN