This page lists commonly-used configuration parameters for the Datadog Operator. For all configuration parameters, see the configuration spec in the DataDog/datadog-operator repo.

Configuration inputs

The Agent configuration the Operator generates is determined by two inputs: the DatadogAgent spec (the parameters documented on this page) and a small set of metadata annotations on the DatadogAgent.

Provider

A provider identifies an environment or platform that needs a specific set of customizations to the Agent configuration. The Operator detects the cluster provider automatically, or you can declare it with the agent.datadoghq.com/cluster-provider annotation (mirroring the Helm chart’s providers.* configuration):

metadata:
  annotations:
    agent.datadoghq.com/cluster-provider: eks

For what a provider is, how it is resolved, the full list of values, and their Helm mappings, see the providers documentation.

Example manifests

• Manifest with logs, APM, process, and metrics collection enabled
• Manifest with logs, APM, and metrics collection enabled
• Manifest with APM and metrics collection enabled
• Manifest with Cluster Agent
• Manifest with tolerations

Global options

The table in this section lists configurable parameters for the DatadogAgent resource. To override parameters for individual components (Node Agent, Cluster Agent, or Cluster Checks Runner) see override options.

For example: the following manifest uses the global.clusterName parameter to set a custom cluster name:

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    clusterName: my-test-cluster
    credentials:
      apiSecret:
        secretName: datadog-secret
        keyName: api-key
      appSecret:
        secretName: datadog-secret
        keyName: app-key

For a complete list of parameters, see the Operator configuration spec.

Override options

The following table lists parameters that can be used to override default or global settings for individual components. override is a map with the following possible keys: nodeAgent, clusterAgent, otelAgentGateway, or clusterChecksRunner. Maps and arrays have a type annotation in the table. In the parameter names, component refers to one of these component keys, and container refers to a specific container name within that component (such as agent, cluster-agent, process-agent, trace-agent, or system-probe).

For example: the following manifest overrides the Node Agent’s image and tag, in addition to the resource limits of the system probe container:

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  override:
    nodeAgent:
      image:
        name: agent
        tag: 7.41.0-rc.5
      containers:
        system-probe:
          resources:
            limits:
              cpu: "2"
              memory: 1Gi

Resource limits on high-core-count nodes

On nodes with a high logical CPU count (for example, large GPU or bare-metal hosts), the Agent’s Go runtime sizes its scheduler to the host CPU count by default. This scales memory usage proportionally with the CPU count and can cause the Agent container to be OOM-killed even with otherwise modest workloads.

Setting an explicit CPU limit on the agent container constrains the runtime to that value:

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  override:
    nodeAgent:
      containers:
        agent:
          resources:
            requests:
              cpu: "2"
              memory: 512Mi
            limits:
              cpu: "2"
              memory: 1Gi

Use an integer value for limits.cpu so the runtime can read it directly. If your cluster has node shapes with widely varying core counts, apply different limits per shape with DatadogAgentProfiles rather than setting a single global value that may be too low for small nodes or too high for large ones.

For a complete list of parameters, see the Operator configuration spec.