En esta página se enumeran las opciones de configuración para la página de Contenedores en Datadog. Para obtener más información sobre la página de contenedores y sus capacidades, consulta la documentación de la Vista de contenedores.

Opciones de configuración

Incluir o excluir contenedores

Incluye y excluye contenedores de la recopilación en tiempo real:

• Excluye contenedores al pasar la variable de entorno DD_CONTAINER_EXCLUDE o al añadir container_exclude: en tu archivo de configuración principal datadog.yaml.
• Incluye contenedores al pasar la variable de entorno DD_CONTAINER_INCLUDE o al añadir container_include: en tu archivo de configuración principal datadog.yaml.

Ambos argumentos toman un nombre de imagen como valor. También se admiten expresiones regulares.

Por ejemplo, para excluir todas las imágenes de Debian excepto los contenedores con un nombre que comience con frontend, añade estas dos líneas de configuración en tu archivo datadog.yaml:

container_exclude: ["image:debian"]
container_include: ["name:frontend.*"]

Nota: En el caso del Agent 5, en lugar de incluir lo anterior en el archivo de configuración principal datadog.conf, añade de manera explícita un archivo datadog.yaml a /etc/datadog-agent/, ya que el Process Agent requiere todas las opciones de configuración aquí. Esta configuración solo excluye los contenedores de la recopilación en tiempo real, no de Autodiscovery.

Eliminación de información confidencial de manifiestos

Para evitar la filtración de datos confidenciales, el Agent puede configurarse para depurar manifiestos YAML recopilados en Kubernetes. Esta función de depuración se aplica a:

• Valores de anotación
• Valores de etiquetas (labels)
• Configuraciones de sonda (cabeceras y comandos HTTP)
• Variables de entorno
• Comandos de ejecución de contenedores

El algoritmo de depuración intenta detectar pares clave-valor que contengan secretos basándose en un conjunto de palabras clave sensibles, sustituyendo los valores correspondientes por ********. Esta lógica se aplica a pares clave-valor estructurados (como variables de entorno), así como a valores que parecen contenido JSON o YAML, que pueden contener pares clave-valor dentro del contenido.

La depuración se activa por defecto utilizando las siguientes palabras clave sensibles:

• password
• passwd
• mysql_pwd
• access_token
• auth_token
• api_key
• apikey
• pwd
• secret
• credentials
• stripetoken

Puedes proporcionar palabras clave sensibles adicionales proporcionando una lista delimitada por espacios en la variable de entorno: DD_ORCHESTRATOR_EXPLORER_CUSTOM_SENSITIVE_WORDS. Esto se añade a las palabras por defecto y no las sobrescribe. Para utilizar esta variable de entorno, debes configurarla para los siguientes Agents:

• Agent núcleo
• Agent del clúster

env:
    - name: DD_ORCHESTRATOR_EXPLORER_CUSTOM_SENSITIVE_WORDS
      value: "customword1 customword2 customword3"

Nota: Cualquier palabra confidencial adicional debe proporcionarse como cadena en minúsculas. El Agent convierte el texto a minúsculas antes de buscar palabras confidenciales. Si la palabra confidencial es password, MY_PASSWORD=1234 se convierte en MY_PASSWORD=********, ya que el Agent convierte MY_PASSWORD en my_password, lo que significa que la palabra confidencial PASSWORD no coincide con nada.

Por ejemplo, como password es una palabra confidencial, el limpiador cambia <MY_PASSWORD> en cualquiera de los siguientes casos por una cadena de asteriscos, ***********:

password <MY_PASSWORD>
password=<MY_PASSWORD>
password: <MY_PASSWORD>
password::::== <MY_PASSWORD>
config={"password":"<MY_PASSWORD>"}

Sin embargo, el limpiador no limpia rutas que contengan palabras confidenciales. Por ejemplo, no sobrescribe /etc/vaultd/secret/haproxy-crt.pem con /etc/vaultd/******/haproxy-crt.pem aunque secret sea una palabra confidencial.

Configurar Orchestrator Explorer

Matriz de compatibilidad de recopilación de recursos

En la siguiente tabla se presenta la lista de recursos recopilados y las versiones mínimas del Agent, Cluster Agent y Helm chart para cada uno.

Nota: Después de la versión 1.22, la numeración de la versión del Cluster Agent sigue la numeración del Agent, a partir de la versión 7.39.0.

Añadir etiquetas (tags) personalizadas a los recursos

Puedes añadir etiquetas personalizadas a los recursos de Kubernetes para facilitar el filtrado en la vista de recursos de Kubernetes.

Se añaden etiquetas adicionales a través de la variable de entorno DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS.

Nota: Estas etiquetas solo aparecen en la vista de recursos de Kubernetes.

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <DATADOG_API_KEY>
      appKey: <DATADOG_APP_KEY>
  features:
    liveContainerCollection:
      enabled: true
    orchestratorExplorer:
      enabled: true
  override:
    agents:
      containers:
        processAgent:
          env:
            - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
              value: "tag1:value1 tag2:value2"
    clusterAgent:
      env:
        - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
          value: "tag1:value1 tag2:value2"

kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml

agents:
  containers:
    processAgent:
      env:
        - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
          value: "tag1:value1 tag2:value2"
clusterAgent:
  env:
    - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
      value: "tag1:value1 tag2:value2"

- name: DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS
  value: "tag1:value1 tag2:value2"

Recopilar recursos personalizados

Por defecto, Kubernetes Explorer recopila automáticamente definiciones de recursos personalizados (CRD).

Matriz automática de compatibilidad de recopilaciones de recursos personalizados

Cuando los siguientes CRD están presentes en tu clúster, el Agent recopila automáticamente sus recursos personalizados (CR). Si un CRD que utilizas no aparece en esta lista o su versión de Agent es anterior, sigue los pasos de configuración manual que se indican a continuación.

Configuración manual

Para los demás CRD, sigue estos pasos para recopilar los recursos personalizados que definen estos CRD:

1. En Datadog, abre el Kubernetes Explorer. En el panel izquierdo, en Select Resources (Seleccionar recursos), selecciona Kubernetes > Custom Resources > Resource Definitions (Kubernetes > Recursos personalizados > Definiciones de recursos).

2. Localiza el CRD que define el recurso personalizado que quieres visualizar en el Explorer. En la columna Versions (Versiones), haz clic en la etiqueta version para la que quieres configurar la indexación.

   Aparece un modal:

3. Sigue las instrucciones de la sección Set up Datadog Agent (Configurar el Datadog Agent) del modal para actualizar la configuración del Agent para los clústeres que no están recopilando recursos personalizados. El modal enumera todos los cústeres de este tipo, ya sea porque el Agent no está configurado para recopilar recursos personalizados o porque no hay ninguno disponible en ese clúster. Si el Agent está configurado y no existen recursos personalizados, no se requiere ninguna acción.

   1. Añade la siguiente configuración a datadog-values.yaml:

      datadog:
        #(...)
        orchestratorExplorer:
          customResources:
            - <CUSTOM_RESOURCE_NAME>
      

   2. Actualiza tu Helm chart:

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

   1. Instala ek Datadog Operator con una opción que conceda al Datadog Agent permiso para recopilar recursos personalizados:

      helm install datadog-operator datadog/datadog-operator --set clusterRole.allowReadAllResources=true
      

   2. Añade la siguiente configuración a tu manifiesto DatadogAgent, datadog-agent.yaml:

      apiVersion: datadoghq.com/v2alpha1
      kind: DatadogAgent
      metadata:
        name: datadog
      spec:
        #(...)
        features:
          orchestratorExplorer:
            customResources:
              - <CUSTOM_RESOURCE_NAME>
      

   3. Aplica tu nueva configuración:

      kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml
      

   Cada <CUSTOM_RESOURCE_NAME> debe utilizar el formato group/version/kind.

4. En el modal, en Select indexed fields for filtering/sorting (Seleccionar campos indexados para filtrar/clasificar), selecciona los campos que quieres indexar del recurso personalizado para filtrar y clasificar. Para algunos CRD, Datadog proporciona una configuración por defecto. Puedes seleccionar campos adicionales, si es necesario.

   Una vez configurado el Datadog Agent, recopila automáticamente los recursos personalizados disponibles. La indexación de campos es opcional.

   Para matrices de objetos, consulta la sección Indexación de tipos complejos.

5. Selecciona Update Fields (Actualizar campos) para guardar.

Una vez indexados los campos, puedes añadirlos como columnas en el Explorer y ordenarlos, o incluirlos en Saved Views (Vistas guardadas). También puedes filtrar los campos indexados utilizando el prefijo field#.

Indexación de tipos complejos

Para las matrices de objetos, existen dos estrategias de agrupación:

• No field: Los campos anidados del objeto se indexan únicamente por el nombre del campo anidado.
• Campo (por ejemplo: type, status, etc.): Los campos anidados del objeto se indexan en función de cada valor de campo único.

Ejemplo: Filtrado de recursos personalizados DatadogPodAutoscaler

Considera estos dos recursos personalizados:

Recurso personalizado 1 (CR1):

status:
    conditions:
        - type: HorizontalAbleToScale
          status: 'True'
        - type: VerticalAbleToApply
          status: 'False'

Recurso personalizado 2 (CR2):

status:
    conditions:
        - type: VerticalAbleToApply
          status: 'True'
        - type: HorizontalAbleToScale
          status: 'False'

Las posibilidades de filtrado en status.conditions se basan en las dos estrategias de indexación:

status:
    conditions:
        type: [HorizontalAbleToScale, VerticalAbleToApply]
        status: ['True', 'False']

status:
    conditions:
        type: [VerticalAbleToApply, HorizontalAbleToScale]
        status: ['True', 'False']

field#status.conditions.status:"False"

field#status.conditions.status:"False" AND field#status.conditions.type:VerticalAbleToApply

status:
    conditions:
        - HorizontalAbleToScale:
              status: 'True'
        - VerticalAbleToApply:
              status: 'False'

status:
    conditions:
        - VerticalAbleToApply:
              status: 'True'
        - HorizontalAbleToScale:
              status: 'False'

field#status.conditions.HorizontalAbleToScale.status:"False"

Recopilar métricas de recursos personalizados utilizando el check Kubernetes State Core

Puedes utilizar el check kubernetes_state_core para recopilar métricas de recursos personalizados al ejecutar el Datadog Cluster Agent.

1. Escribe definiciones para tus recursos personalizados y los campos que se convertirán en métricas de acuerdo con el siguiente formato:

   #=(...)
   collectCrMetrics:
     - groupVersionKind:
         group: "crd.k8s.amazonaws.com"
         kind: "ENIConfig"
         version: "v1alpha1"
       commonLabels:
         crd_type: "eniconfig"
       labelsFromPath:
         crd_name: [metadata, name]
       metricNamePrefix: "userPrefix"
       metrics:
         - name: "eniconfig"
           help: "ENI Config"
           each:
             type: gauge
             gauge:
               path: [metadata, generation]
     - groupVersionKind:
         group: "vpcresources.k8s.aws"
         kind: "CNINode"
         version: "v1alpha1"
         resource: "cninode-pluralized"
       commonLabels:
         crd_type: "cninode"
       labelsFromPath:
         crd_name: [metadata, name]
       metrics:
         - name: "cninode"
           help: "CNI Node"
           each:
             type: gauge
             gauge:
               path: [metadata, generation]
   

   Por defecto, los nombres de recursos RBAC y API se derivan del tipo en groupVersionKind convirtiéndolo a minúsculas y añadiendo un sufijo “s” (por ejemplo, Kind: ENIConfig → eniconfigs). Si la definición del recurso personalizado (CRD) utiliza una forma en plural diferente, puedes anular este comportamiento especificando el campo del recurso. En el ejemplo anterior, CNINode anula el predeterminado estableciendo el recurso: “cninode-pluralized”.

   Los nombres de las métricas se producen siguiendo las siguientes reglas:

   • Sin prefijo: kubernetes_state_customresource.<metrics.name>
   • Con prefijo: kubernetes_state_customresource.<metricNamePrefix>_<metric.name>

   Para obtener más detalles, consulta Métricas del estado de los recursos personalizados.

2. Actualiza la configuración de tu Helm o Datadog Operator:

   1. Añade la siguiente configuración a datadog-values.yaml:

      datadog:
        #(...)
        kubeStateMetricsCore:
          collectCrMetrics:
            - <CUSTOM_RESOURCE_METRIC>
      

      Sustituye <CUSTOM_RESOURCE_METRIC> por las definiciones que escribiste en el primer paso.

   2. Actualiza tu Helm chart:

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

   This functionality requires Agent Operator v1.20+.

   1. Instala el Datadog Operator con una opción que conceda al Datadog Agent permiso para recopilar recursos personalizados:

      helm install datadog-operator datadog/datadog-operator --set clusterRole.allowReadAllResources=true
      

   2. Añade la siguiente configuración a tu manifiesto DatadogAgent, datadog-agent.yaml:

      apiVersion: datadoghq.com/v2alpha1
      kind: DatadogAgent
      metadata:
        name: datadog
      spec:
        #(...)
        features:
          kubeStateMetricsCore:
            collectCrMetrics:
              - <CUSTOM_RESOURCE_METRIC>
      

      Sustituye <CUSTOM_RESOURCE_METRIC> por las definiciones que escribiste en el primer paso.

   3. Aplica tu nueva configuración:

      kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml
      

Referencias adicionales

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

Ver todos los hosts/contenedores con el mapa de infraestructurasDOCUMENTACIÓN Comprender lo que sucede en cualquier nivel del sistemaDOCUMENTACIÓN