autodiscovery: suppress configuration discovery on generic-integration namespace conflicts

[vitkyrka]

What does this PR do?

Fixes DSCVR-626: Autodiscovery's configuration-discovery feature (discovery: {} in a shipped auto_conf.yaml, e.g. krakend, haproxy, gearmand) could schedule a duplicate check on a container or host that already has a manually-configured generic openmetrics/prometheus check claiming the same (or a rooted-in) metric namespace. Both checks would then scrape the same target and submit to the same final metric name; for counter-derived metrics this doubles the reported value, since Datadog sums same-context contributions within a flush interval.

filterTemplatesDiscovery now also drops a discovery template when:

• a sibling openmetrics/prometheus template matched to the same service configures a namespace whose root matches the integration's own expected namespace root, or
• a scheduled static (non-template, host-wide) openmetrics/prometheus config claims such a namespace anywhere on the host (both tracked in the existing StaticConfigIndex, which now also indexes namespace roots — no separate index needed).

An integration's "expected namespace root" is its own check name by default, or the root of its auto_conf.yaml's discovery.metrics_prefix field when declared — see integrations-core#24861, which adds metrics_prefix for the three integrations (gearmand, krakend, prefect) whose real namespace diverges from their check name. This replaces an earlier hard-coded override map for zk/gearmand (dropped as a layering violation / maintenance burden) with a declarative, per-integration field. Only the root of metrics_prefix is used even when it's itself multi-segment (e.g. krakend's krakend.api), since a generic scraper's own namespace/rename could independently collide at a shorter prefix and there's no way to tell from the raw instance config alone.

Also detects the case where a generic config omits namespace: entirely but explicitly renames a raw metric to an already fully-qualified name (e.g. metrics: [{envoy_requests_total: envoy.requests_total}]) — with no namespace set, the check submits that name completely unprefixed, colliding with the native integration's own metric just the same.

Known gap, out of scope here

A separate race exists: an async configuration-discovery probe can take several retry cycles to complete, and a conflicting generic-integration config that appears while the probe is in flight can still get scheduled once the probe finally returns, since the synchronous check above only runs before the probe is enqueued. This is a pre-existing issue (not introduced here) that #54368 fixes generally, for every conflict rule. This PR deliberately leaves that race unfixed to avoid duplicating/competing with that fix.

Motivation

Confirmed empirically (real Docker containers, real agent build, real Datadog org) that a manual openmetrics/prometheus config and a later-discovered dedicated integration both targeting the same container/host can double-count metrics for counter-derived metrics — e.g. a synthetic counter with a known ground-truth rate of 600/min was reported at exactly 1200/min with both checks active.

Describe how you validated your changes

• Extensive unit test coverage in comp/core/autodiscovery/listeners/{common_filter,service}_test.go and comp/core/autodiscovery/integration/config_test.go: per-service sibling namespace match/mismatch, no-namespace-set sibling (no false positive), global static-config namespace match/mismatch, the metrics-rename-without-namespace case, metrics_prefix-driven detection (including the gearmand check-name/namespace divergence case, both via the sibling and the static-index path), and a digest regression test (a Discovery.MetricsPrefix-only change must change the config digest, or an auto_conf.yaml update that only adds/changes it would be silently treated as an already-tracked config).
• dda inv test --targets=./comp/core/autodiscovery/... passes locally (965 tests).
• dda inv linter.go --targets=./comp/core/autodiscovery/... passes locally.
• Reviewed with go-code-reviewer; applied all confirmed findings, including the digest bug above and a redundant lock acquisition in the common (no-metrics_prefix) path.
• Extended the krakend discovery e2e suite (test/new-e2e/tests/discovery/config_discovery_linux_test.go) with a second fake container (docker-compose.fake-krakend-conflict.yaml.tmpl) carrying a conflicting manual openmetrics config (namespace: krakend.api, rooted in krakend's own __NAMESPACE__), asserting discovery is suppressed there while the original krakend discovery test is unaffected. The two compose fixtures' previously copy-pasted fake metrics server is now a single shared file (fake-krakend-server.py), spliced into both via text/template (the same pattern already used elsewhere in this test package for Helm values). Validated via CI (new-e2e-discovery), not locally (requires real AWS infra).

Additional Notes

No changes needed to the discoverer package or any config-flag plumbing. The StaticConfigIndex shared between listeners and the config manager does double duty: it's keyed by check name for the pre-existing same-name-sibling rule, and now also by namespace root for the new namespace-conflict rule — no new data structure required.

---

PR description updated by Claude Code.

[github-actions]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6d17cf684d

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[datadog-datadog-prod-us1-2]

🎯 Code Coverage (details)
• Patch Coverage: 87.50%
• Overall Coverage: 52.40% (+0.05%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 380b584 | Docs | Datadog PR Page | Give us feedback!}

[dd-octo-sts]

Files inventory check summary

File checks results against ancestor 2f78841f:

Results for datadog-agent_7.84.0~devel.git.199.380b584.pipeline.131011016-1_amd64.deb:

No change detected

Results for datadog-iot-agent_7.84.0~devel.git.199.380b584.pipeline.131011016-1_amd64.deb:

No change detected

[dd-octo-sts]

Static quality checks

✅ Please find below the results from static quality gates
Comparison made with ancestor 2f78841
📊 Static Quality Gates Dashboard
🔗 SQG Job

Successful checks

Info

	Quality gate	Change	Size (prev → curr → max)
✅	agent_deb_amd64	+8.0 KiB (0.00% increase, -0.18% of buffer)	760.081 → 760.089 → 764.500
✅	agent_deb_amd64_fips	+8.0 KiB (0.00% increase, -0.28% of buffer)	712.942 → 712.950 → 715.740
✅	agent_heroku_amd64	+4.0 KiB (0.00% increase, -0.06% of buffer)	312.424 → 312.428 → 319.050
✅	agent_msi	+7.0 KiB (0.00% increase, -0.04% of buffer)	643.510 → 643.517 → 660.960
✅	agent_rpm_amd64	+8.0 KiB (0.00% increase, -0.18% of buffer)	760.065 → 760.073 → 764.470
✅	agent_rpm_amd64_fips	+8.0 KiB (0.00% increase, -0.28% of buffer)	712.925 → 712.933 → 715.740
✅	agent_rpm_arm64	+4.0 KiB (0.00% increase, -0.68% of buffer)	735.968 → 735.972 → 736.540
✅	agent_rpm_arm64_fips	+4.0 KiB (0.00% increase, -0.25% of buffer)	692.155 → 692.159 → 693.690
✅	agent_suse_amd64	+8.0 KiB (0.00% increase, -0.18% of buffer)	760.065 → 760.073 → 764.470
✅	agent_suse_amd64_fips	+8.0 KiB (0.00% increase, -0.28% of buffer)	712.925 → 712.933 → 715.740
✅	agent_suse_arm64	+4.0 KiB (0.00% increase, -0.68% of buffer)	735.968 → 735.972 → 736.540
✅	agent_suse_arm64_fips	+4.0 KiB (0.00% increase, -0.25% of buffer)	692.155 → 692.159 → 693.690
✅	docker_agent_amd64	+8.0 KiB (0.00% increase, -0.58% of buffer)	818.697 → 818.704 → 820.040
✅	docker_agent_arm64	+4.0 KiB (0.00% increase, -0.36% of buffer)	819.644 → 819.648 → 820.740
✅	docker_agent_jmx_amd64	+8.0 KiB (0.00% increase, -0.65% of buffer)	1009.594 → 1009.602 → 1010.800
✅	docker_agent_jmx_arm64	+4.0 KiB (0.00% increase, -0.32% of buffer)	999.194 → 999.198 → 1000.420
✅	docker_cluster_agent_amd64	+8.0 KiB (0.00% increase, -0.95% of buffer)	210.475 → 210.483 → 211.300
✅	iot_agent_deb_amd64	+8.0 KiB (0.02% increase, -0.74% of buffer)	46.467 → 46.475 → 47.530
✅	iot_agent_deb_arm64	+4.0 KiB (0.01% increase, -0.36% of buffer)	43.124 → 43.127 → 44.200
✅	iot_agent_deb_armhf	+4.0 KiB (0.01% increase, -0.36% of buffer)	43.907 → 43.910 → 44.990
✅	iot_agent_rpm_amd64	+8.0 KiB (0.02% increase, -0.74% of buffer)	46.468 → 46.476 → 47.530
✅	iot_agent_suse_amd64	+8.0 KiB (0.02% increase, -0.73% of buffer)	46.467 → 46.475 → 47.530

11 successful checks with minimal change (< 2 KiB)

	Quality gate	Current Size
✅	docker_cluster_agent_arm64	223.456 MiB
✅	docker_cws_instrumentation_amd64	7.439 MiB
✅	docker_cws_instrumentation_arm64	6.877 MiB
✅	docker_dogstatsd_amd64	39.482 MiB
✅	docker_dogstatsd_arm64	37.560 MiB
✅	docker_host_profiler_amd64	305.814 MiB
✅	docker_host_profiler_arm64	317.125 MiB
✅	dogstatsd_deb_amd64	30.224 MiB
✅	dogstatsd_deb_arm64	28.247 MiB
✅	dogstatsd_rpm_amd64	30.224 MiB
✅	dogstatsd_suse_amd64	30.224 MiB

[cit-pr-commenter-54b7da]

Regression Detector

Regression Detector Results

Metrics dashboard
Target profiles
Job ID: c4ef6c72-8fa4-4afc-8802-ba41b2a3f610

Baseline: 2f78841
Comparison: 380b584
Diff

Optimization Goals: ✅ No significant changes detected

Fine details of change detection per experiment

perf	experiment	goal	Δ mean %	Δ mean % CI	trials	links
➖	quality_gate_logs	% cpu utilization	+3.05	[+2.14, +3.95]	1	Logs bounds checks dashboard
➖	quality_gate_security_no_fs_load	memory utilization	+0.40	[+0.25, +0.54]	1	Logs bounds checks dashboard
➖	quality_gate_idle	memory utilization	+0.30	[+0.18, +0.42]	1	Logs bounds checks dashboard
➖	quality_gate_security_idle	memory utilization	+0.09	[-0.01, +0.20]	1	Logs bounds checks dashboard
➖	quality_gate_idle_all_features	memory utilization	+0.07	[+0.03, +0.11]	1	Logs bounds checks dashboard
➖	quality_gate_security_mean_fs_load	memory utilization	-0.02	[-0.09, +0.06]	1	Logs bounds checks dashboard
➖	quality_gate_private_action_runner	memory utilization	-0.36	[-0.48, -0.25]	1	Logs bounds checks dashboard
➖	quality_gate_metrics_logs	memory utilization	-0.91	[-1.15, -0.67]	1	Logs bounds checks dashboard

Bounds Checks: ✅ Passed

perf	experiment	bounds_check_name	replicates_passed	observed_value	links
✅	quality_gate_idle	intake_connections	10/10	4 = 4	bounds checks dashboard
✅	quality_gate_idle	memory_usage	10/10	173.34MiB ≤ 178MiB	bounds checks dashboard
✅	quality_gate_idle	total_bytes_received	10/10	745.57KiB ≤ 819.20KiB	bounds checks dashboard
✅	quality_gate_idle_all_features	intake_connections	10/10	4 = 4	bounds checks dashboard
✅	quality_gate_idle_all_features	memory_usage	10/10	519.93MiB ≤ 538MiB	bounds checks dashboard
✅	quality_gate_idle_all_features	total_bytes_received	10/10	1.14MiB ≤ 1.25MiB	bounds checks dashboard
✅	quality_gate_logs	intake_connections	10/10	18 ≤ 40	bounds checks dashboard
✅	quality_gate_logs	memory_usage	10/10	206.84MiB ≤ 229MiB	bounds checks dashboard
✅	quality_gate_logs	missed_bytes	10/10	0B = 0B	bounds checks dashboard
✅	quality_gate_logs	total_bytes_received	10/10	264.21MiB ≤ 292MiB	bounds checks dashboard
✅	quality_gate_metrics_logs	cpu_usage	10/10	349.95 ≤ 2000	bounds checks dashboard
✅	quality_gate_metrics_logs	intake_connections	10/10	17 ≤ 40	bounds checks dashboard
✅	quality_gate_metrics_logs	memory_usage	10/10	418.56MiB ≤ 439MiB	bounds checks dashboard
✅	quality_gate_metrics_logs	missed_bytes	10/10	0B = 0B	bounds checks dashboard
✅	quality_gate_metrics_logs	total_bytes_received	10/10	0.94GiB ≤ 1.04GiB	bounds checks dashboard
✅	quality_gate_private_action_runner	memory_usage	10/10	72.12MiB ≤ 76MiB	bounds checks dashboard
✅	quality_gate_security_idle	cpu_usage	10/10	26.53 ≤ 100	bounds checks dashboard
✅	quality_gate_security_idle	memory_usage	10/10	329.28MiB ≤ 335MiB	bounds checks dashboard
✅	quality_gate_security_mean_fs_load	cpu_usage	10/10	61.57 ≤ 200	bounds checks dashboard
✅	quality_gate_security_mean_fs_load	memory_usage	10/10	304.64MiB ≤ 314MiB	bounds checks dashboard
✅	quality_gate_security_no_fs_load	cpu_usage	10/10	20.92 ≤ 100	bounds checks dashboard
✅	quality_gate_security_no_fs_load	memory_usage	10/10	309.28MiB ≤ 343MiB	bounds checks dashboard

Explanation

Confidence level: 90.00%
Effect size tolerance: |Δ mean %| ≥ 5.00%

Performance changes are noted in the perf column of each table:

• ✅ = significantly better comparison variant performance
• ❌ = significantly worse comparison variant performance
• ➖ = no significant change in performance

A regression test is an A/B test of target performance in a repeatable rig, where "performance" is measured as "comparison variant minus baseline variant" for an optimization goal (e.g., ingress throughput). Due to intrinsic variability in measuring that goal, we can only estimate its mean value for each experiment; we report uncertainty in that value as a 90.00% confidence interval denoted "Δ mean % CI".

For each experiment, we decide whether a change in performance is a "regression" -- a change worth investigating further -- if all of the following criteria are true:

1. Its estimated |Δ mean %| ≥ 5.00%, indicating the change is big enough to merit a closer look.

2. Its 90.00% confidence interval "Δ mean % CI" does not contain zero, indicating that if our statistical model is accurate, there is at least a 90.00% chance there is a difference in performance between baseline and comparison variants.

3. Its configuration does not mark it "erratic".

CI Pass/Fail Decision

✅ Passed. All Quality Gates passed.

• quality_gate_private_action_runner, bounds check memory_usage: 10/10 replicas passed. Gate passed.
• quality_gate_idle_all_features, bounds check total_bytes_received: 10/10 replicas passed. Gate passed.
• quality_gate_idle_all_features, bounds check memory_usage: 10/10 replicas passed. Gate passed.
• quality_gate_idle_all_features, bounds check intake_connections: 10/10 replicas passed. Gate passed.
• quality_gate_security_mean_fs_load, bounds check cpu_usage: 10/10 replicas passed. Gate passed.
• quality_gate_security_mean_fs_load, bounds check memory_usage: 10/10 replicas passed. Gate passed.
• quality_gate_security_idle, bounds check cpu_usage: 10/10 replicas passed. Gate passed.
• quality_gate_security_idle, bounds check memory_usage: 10/10 replicas passed. Gate passed.
• quality_gate_logs, bounds check missed_bytes: 10/10 replicas passed. Gate passed.
• quality_gate_logs, bounds check memory_usage: 10/10 replicas passed. Gate passed.
• quality_gate_logs, bounds check intake_connections: 10/10 replicas passed. Gate passed.
• quality_gate_logs, bounds check total_bytes_received: 10/10 replicas passed. Gate passed.
• quality_gate_idle, bounds check memory_usage: 10/10 replicas passed. Gate passed.
• quality_gate_idle, bounds check intake_connections: 10/10 replicas passed. Gate passed.
• quality_gate_idle, bounds check total_bytes_received: 10/10 replicas passed. Gate passed.
• quality_gate_security_no_fs_load, bounds check cpu_usage: 10/10 replicas passed. Gate passed.
• quality_gate_security_no_fs_load, bounds check memory_usage: 10/10 replicas passed. Gate passed.
• quality_gate_metrics_logs, bounds check missed_bytes: 10/10 replicas passed. Gate passed.
• quality_gate_metrics_logs, bounds check total_bytes_received: 10/10 replicas passed. Gate passed.
• quality_gate_metrics_logs, bounds check intake_connections: 10/10 replicas passed. Gate passed.
• quality_gate_metrics_logs, bounds check memory_usage: 10/10 replicas passed. Gate passed.
• quality_gate_metrics_logs, bounds check cpu_usage: 10/10 replicas passed. Gate passed.