This page lists configuration options for the Containers page in Datadog. To learn more about the Containers page and its capabilities, see Containers View documentation.

Configure Kubernetes Explorer

Resource collection compatibility matrix

The following table presents the list of collected resources and the minimal Agent, Cluster Agent, and Helm chart versions for each.

Note: After version 1.22, Cluster Agent version numbering follows Agent release numbering, starting with version 7.39.0.

Add custom tags to resources

You can add custom tags to Kubernetes resources to ease filtering inside the Kubernetes resources view.

Additional tags are added through the DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS environment variable.

Note: These tags only show up in the Kubernetes resources view.

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"

Collect custom resources

The Kubernetes Explorer automatically collects Custom Resource Definitions (CRDs) by default.

Automatic custom resource collection compatibility matrix

When the following CRDs are present in your cluster, the Agent automatically collects their Custom Resources (CRs). If a CRD you use is not listed here—or your Agent version is older—follow the manual configuration steps below.

Manual Configuration

For the other CRDs, follow these steps to collect the custom resources that these CRDs define:

1. In Datadog, open Kubernetes Explorer. On the left panel, under Select Resources, select Kubernetes > Custom Resources > Resource Definitions.

2. Locate the CRD that defines the custom resource you want to visualize in the explorer. Under the Versions column, click the version tag you want to configure indexing for.

   A modal appears:

3. Follow the instructions in the modal’s Set up Datadog Agent section to update the Agent configuration for clusters that are not collecting custom resources. The modal lists all such clusters, either because the Agent is not configured to collect custom resources, or because none are available in that cluster. If the Agent is configured and no custom resources exist, no action is required.

   1. Add the following configuration to datadog-values.yaml:

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

   2. Upgrade your Helm chart:

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

   1. Install the Datadog Operator with an option that grants the Datadog Agent permission to collect custom resources:

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

   2. Add the following configuration to your DatadogAgent manifest, datadog-agent.yaml:

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

   3. Apply your new configuration:

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

   Each <CUSTOM_RESOURCE_NAME> must use the format group/version/kind.

4. In the modal, under Select indexed fields for filtering/sorting, select the fields you want to index from the custom resource for filtering and sorting. For some CRDs, Datadog provides a default configuration. You can select additional fields if needed.

   After the Datadog Agent is set up, it collects available custom resources automatically. Indexing fields is optional.

   For arrays of objects, see the Indexing complex types section.

5. Select Update Fields to save.

After the fields are indexed, you can add them as columns in the explorer and sort them, or include them in Saved Views. You can also filter on indexed fields using the prefix field#.

Indexing complex types

For arrays of objects, two group-by strategies are available:

• No field: Object’s nested fields are indexed solely on nested field name.
• Field (for example: type, status, etc.): Object’s nested fields are indexed based on each unique field value.

Example: Filtering on DatadogPodAutoscaler custom resources

Consider these two custom resources:

Custom Resource 1 (CR1):

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

Custom Resource 2 (CR2):

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

You have the filtering possibilities on status.conditions based on the two indexing strategies:

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"

Collect custom resource metrics using Kubernetes State Core check

You can use the kubernetes_state_core check to collect custom resource metrics when running the Datadog Cluster Agent.

1. Write definitions for your custom resources and the fields to turn into metrics according to the following format:

   #=(...)
   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]
   

   By default, RBAC and API resource names are derived from the kind in groupVersionKind by converting it to lowercase, and adding an “s” suffix (for example, Kind: ENIConfig → eniconfigs). If the Custom Resource Definition (CRD) uses a different plural form, you can override this behavior by specifying the resource field. In the example above, CNINode overrides the default by setting resource: “cninode-pluralized”.

   Metric names are produced using the following rules:

   • No prefix: kubernetes_state_customresource.<metrics.name>
   • Prefix: kubernetes_state_customresource.<metricNamePrefix>_<metric.name>

   For more details, see Custom Resource State Metrics.

2. Update your Helm or Datadog Operator configuration:

   1. Add the following configuration to datadog-values.yaml:

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

      Replace <CUSTOM_RESOURCE_METRIC> with the definitions you wrote in the first step.

   2. Upgrade your Helm chart:

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

   This functionality requires Agent Operator v1.20+.

   1. Install the Datadog Operator with an option that grants the Datadog Agent permission to collect custom resources:

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

   2. Add the following configuration to your DatadogAgent manifest, datadog-agent.yaml:

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

      Replace <CUSTOM_RESOURCE_METRIC> with the definitions you wrote in the first step.

   3. Apply your new configuration:

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

Further reading

お役に立つドキュメント、リンクや記事:

See all of your hosts/containers with the Infrastructure MapDOCUMENTATION Understand what is going on at any level of your systemDOCUMENTATION