Integration Check Precedence Conflict Between datadog.yaml and conf.d/<check>.yaml in Datadog Agent 7.x

Answer

When the same parameter appears in both datadog.yaml and conf.d/.yaml, the value from the check‑specific file (conf.d/.yaml) is the one the Agent applies at runtime for that integration.

Confirmed facts

• datadog.yaml holds agent‑wide settings (e.g., api_key, logs_config, process_config).
• conf.d/.yaml holds the integration’s init_config and instances blocks.
• The Agent loads datadog.yaml first, then overlays each conf.d file, so later values win for overlapping keys.

Likely explanation

Because the loader merges configurations in this order, any key that exists in both files will be overridden by the conf.d value. This behavior is the same for built‑in core checks and user‑defined custom checks, as both are processed by the same config merger. Autopilot/auto‑configuration does not silently replace manual entries in conf.d during a 6→7 upgrade; manual values remain authoritative unless explicitly managed by an external automation tool.

Verification steps

1. Run the Agent’s config dump to see the effective settings for the check:

   datadog-agent config dump

   Look for the section of the check and note the value of the parameter in question.
2. Restart the Agent after changing the value in only one file and observe which change appears in the next check run (via datadog-agent check or the Agent logs).
3. Check the Agent startup logs for lines like "Loaded configuration from" to confirm the merge order.

Missing diagnostic detail

If you need absolute certainty for a particular key (e.g., min_collection_interval or a custom option), please provide the exact parameter name so I can confirm which file’s value is being used in your environment.