Autodiscovery Patterns

Why Autodiscovery Exists

Before containers and Kubernetes, you enabled a Postgres integration by editing a static conf.yaml with a hostname that rarely moved. Today pods reschedule hourly, IP addresses are ephemeral, and manual per-container configuration does not scale. Datadog Autodiscovery watches orchestrator events, matches templates to running workloads, and materializes concrete integration check configurations automatically.

On the Datadog Fundamentals exam, Autodiscovery questions test whether you understand templates, identifiers, configuration precedence, and verification commands—not whether you have memorized every Helm value.

Templates, Identifiers, and Resolved Checks

Autodiscovery starts with an integration template—a parameterized check configuration containing placeholders for host, port, credentials, or tags. Templates declare an Autodiscovery identifier (often called an AD identifier) such as redis or nginx. When the Agent sees a container or service whose metadata matches that identifier, it resolves the template into a live check instance attached to that workload.

If no running workload matches, the template stays idle. That is exactly what datadog-agent configcheck surfaces when it reports "No service found with this AD identifier"—the template exists, but nothing currently matches. Fixing it means aligning labels, annotations, image names, or orchestrator metadata with the identifier, not regenerating API keys.

Where Templates Live

Datadog supports multiple configuration providers; Fundamentals expects you to recognize the common ones:

In Kubernetes, operators often install the Agent with the Datadog Helm chart or Datadog Operator, then place Autodiscovery annotations on application pods so configuration travels with the workload manifest.

Configuration Precedence

Multiple sources can describe the same integration. Datadog's rule that shows up on the exam: explicit container metadata—Kubernetes annotations or Docker labels—takes precedence over auto_conf.yaml defaults. The shipped auto-configuration files are a convenience baseline; operators override them when a specific deployment needs different ports, credentials, or tags.

Getting precedence backward is a common trap. The Agent does not "randomly pick" a source at startup, and Helm does not universally override every other provider without you defining it that way.

Cluster Agent and Node Agents in Kubernetes

Large Kubernetes deployments often run a Cluster Agent deployment alongside Node Agents (DaemonSet). The Cluster Agent aggregates cluster-level metadata—services, endpoints, orchestrator tags—and helps Node Agents coordinate cluster checks and richer Autodiscovery context. Node Agents still collect host and container metrics locally; the Cluster Agent is the control-plane helper, not a replacement for every Node Agent.

Fundamentals may ask what problem the Cluster Agent solves: cluster-wide context and coordinated Autodiscovery/cluster checks, not compiling custom Agent binaries or forwarding DogStatsD over DNS.

Verification and Troubleshooting Commands

Two commands anchor troubleshooting:

• datadog-agent configcheck — shows loaded and resolved configurations; first stop for "integration enabled but no data."
• datadog-agent configcheck -v — verbose resolution detail when templates fail to match.

If Autodiscovery is wrong, flare helps support later, but configcheck answers whether the Agent even sees a resolved check—a distinction Fundamentals rewards.

Autodiscovery vs Static conf.d Configuration

Static files in conf.d/<integration>.d/conf.yaml remain valid for long-lived VMs with fixed endpoints. Autodiscovery is the dynamic counterpart for ephemeral infrastructure. Many estates use both: host integrations on bare metal via static files, application integrations on Kubernetes via annotations.

Choosing the wrong model wastes effort—editing node-level conf.yaml for every pod reschedule fights the platform; annotating a single VM that never moves is unnecessary indirection.

Exam Scenarios to Rehearse

Pods scale up, no Redis metrics. Annotations missing, wrong AD identifier, or Agent lacks access to the pod socket—run configcheck and verify the identifier matches the image or label rules.

Metrics appeared yesterday, gone after redeploy. New deployment dropped Autodiscovery annotations; the template never matched the new ReplicaSet.

Both annotation and auto_conf.yaml exist with different ports. Metadata wins; if the annotation points at the wrong port, overriding auto_conf.yaml will not help until you fix the annotation.

Autodiscovery is how Datadog keeps integrations correct when infrastructure is dynamic—master templates, identifiers, precedence, and configcheck, and you can explain why a running Agent still shows zero integration metrics.

Templates include ad_identifiers (for matching), init_config, and instances with runtime-filled variables. If identifiers fail to match, the Agent never builds a live instance.

A typical Redis pod workflow: annotate the pod, the Node Agent detects the event, matches the redis identifier, resolves host/port into a live check, and datadog-agent configcheck shows the instance. When Kubernetes reschedules the pod, Autodiscovery tears down the old check and creates a new one—no manual node-level conf.yaml edit.

Quick Review Table