fix(gpu): disable deprecated eBPF probes by default

[mbertrone]

What does this PR do?

Re-lands #54053, which flipped system_probe.gpu_monitoring.enable_ebpf_probes from true to false. The two behavioral lines are identical to the original; everything else here is the test coverage that was missing the first time.

• pkg/config/setup/system_probe_settings.go — default true → false
• pkg/config/schema/yaml/system-probe_schema.yaml — default true → false
• test/new-e2e/tests/gpu/testdata/config/system_probe_config.yaml — the GPU e2e suite now sets enable_ebpf_probes: true explicitly instead of inheriting it
• pkg/collector/corechecks/gpu/nvidia/collector_test.go — new TestMetricNamesWithoutEBPFProbes, pinning the metric surface of the default configuration
• test/new-e2e/tests/gpu/capabilities.go — curl --fail in QuerySysprobe
• release note — adds an upgrade section naming the metric that stops being collected

Motivation

The eBPF probes for GPU Monitoring are deprecated. Some customers still have the previously recommended gpu.privilegedMode enabled, and these probes have caused crashes on NVIDIA GB300 Grace Blackwell Ultra machines: the arm64 uprobe single-step handler intermittently resumes the probed process at the wrong PC, corrupting whatever GPU process the probe fired in.

#54053 was auto-reverted in #54180 because it broke new-e2e-gpu on main:

TestGPUHostSuiteUbuntu2204/TestVectorAddProgramDetected
  Error:    "0" is not greater than "0"
  Messages: no metric values found for metric gpu.process.core.usage

gpu.process.core.usage is the one GPU metric produced only by the eBPF collector — every other metric has an NVML source. The suite relied on the default being true, so it now asks for the probes by name and keeps covering that path.

The default configuration is covered instead by a unit test that asserts turning the probes off costs exactly the metrics declared eBPF-only and nothing else. That inverts the failure mode: the next accidental metric drop fails in its own PR rather than on main.

The job didn't run on #54053 because .on_gpu_or_e2e_changes doesn't include pkg/config/**, and that PR touched nothing else. This PR touches test/new-e2e/tests/gpu/**, so the GPU suite runs here and validates the new default before merge.

While in capabilities.go: QuerySysprobe used curl -s without --fail, so the /gpu/check endpoint's 503 "GPU eBPF probes are disabled" body came back as a successful response. TestGPUSysprobeEndpointIsResponding was therefore passing green with the probes disabled — it could not fail. Fixed for both the host and Kubernetes paths.

Describe how you validated your changes

• TestMetricNamesWithoutEBPFProbes — passes. Confirms process.core.usage is emitted with the probes on, absent with them off, and that no other metric disappears.
• Full pkg/collector/corechecks/gpu/nvidia package — passes, 27.3s.
• TestConfigurePRMCacheRequiresPRMEndpoint — passes with the new default, confirming an explicit enable_ebpf_probes: true still builds the eBPF collector. This is a default change, not a forced disable.
• Both run on linux with the nvml,test tags; the GPU e2e suite runs in this PR's pipeline.

Additional Notes

Known coverage gap. With the e2e suite pinned to probes-on, nothing at the e2e level exercises the shipped default — the unit test proves the metric set is right, but not that system-probe starts and stays healthy with the GPU module loaded probe-less. Closing that needs a second GPU suite variant and one more GPU runner slot. Deliberately deferred.

Cgroup permissions are unaffected. configure_cgroup_perms is a separate flag, and in cmd/system-probe/modules/gpu.go the cgroup call sits outside the EnableEBPFProbes block, so permission setup still runs with the probes off.

gpu.process.core.usage has consumers. Several dashboards query it. The upgrade release note points at gpu.process.sm_active as the closest NVML equivalent. Whether the out-of-the-box GPU integration dashboard uses it has not been checked — that asset lives outside this repo.

The deprecation is prose-only. Nothing in the code marks the flag or the probes as deprecated: no warning when a user explicitly opts back in, no removal target. Worth doing, but it belongs with the root-cause decision on the arm64 uprobe bug rather than here.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a0132ce105

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[datadog-official]

More details

The default change consistently disables the GPU eBPF path while preserving the explicitly enabled path, and the collector surface loses only gpu.process.core.usage as intended. The updated e2e configuration keeps probes-on coverage, while curl now correctly reports the disabled endpoint's HTTP failure instead of treating its error body as success.

Was this helpful? React 👍 or 👎

_{📊 Validated against 6 scenarios · Open Bits AI session}

_{🤖 Datadog Autotest · Commit a0132ce · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest}

[datadog-official]

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 52.21% (+0.14%)

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

[dd-octo-sts]

Files inventory check summary

File checks results against ancestor 9f1c7785:

Results for datadog-agent_7.83.0~devel.git.521.50c5c23.pipeline.128769532-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 9f1c778
📊 Static Quality Gates Dashboard
🔗 SQG Job

33 successful checks with minimal change (< 2 KiB)

	Quality gate	Current Size
✅	agent_deb_amd64	753.928 MiB
✅	agent_deb_amd64_fips	707.597 MiB
✅	agent_heroku_amd64	308.201 MiB
✅	agent_msi	639.260 MiB
✅	agent_rpm_amd64	753.912 MiB
✅	agent_rpm_amd64_fips	707.581 MiB
✅	agent_rpm_arm64	730.345 MiB
✅	agent_rpm_arm64_fips	687.281 MiB
✅	agent_suse_amd64	753.912 MiB
✅	agent_suse_amd64_fips	707.581 MiB
✅	agent_suse_arm64	730.345 MiB
✅	agent_suse_arm64_fips	687.281 MiB
✅	docker_agent_amd64	812.583 MiB
✅	docker_agent_arm64	814.079 MiB
✅	docker_agent_jmx_amd64	1003.481 MiB
✅	docker_agent_jmx_arm64	993.629 MiB
✅	docker_cluster_agent_amd64	209.994 MiB
✅	docker_cluster_agent_arm64	223.077 MiB
✅	docker_cws_instrumentation_amd64	7.439 MiB
✅	docker_cws_instrumentation_arm64	6.877 MiB
✅	docker_dogstatsd_amd64	39.304 MiB
✅	docker_dogstatsd_arm64	37.433 MiB
✅	docker_host_profiler_amd64	305.307 MiB
✅	docker_host_profiler_arm64	316.621 MiB
✅	dogstatsd_deb_amd64	30.045 MiB
✅	dogstatsd_deb_arm64	28.085 MiB
✅	dogstatsd_rpm_amd64	30.045 MiB
✅	dogstatsd_suse_amd64	30.045 MiB
✅	iot_agent_deb_amd64	46.274 MiB
✅	iot_agent_deb_arm64	42.957 MiB
✅	iot_agent_deb_armhf	43.722 MiB
✅	iot_agent_rpm_amd64	46.274 MiB
✅	iot_agent_suse_amd64	46.273 MiB

[cit-pr-commenter-54b7da]

Regression Detector

Regression Detector Results

Metrics dashboard
Target profiles
Run ID: 76dcfff7-9902-4800-a7c6-e8191a1357ff

Baseline: f93514b
Comparison: 1316bc4
Diff

Optimization Goals: ✅ No significant changes detected

Fine details of change detection per experiment

perf	experiment	goal	Δ mean %	Δ mean % CI	trials	links
➖	quality_gate_idle	memory utilization	+0.30	[+0.24, +0.35]	1	Logs bounds checks dashboard
➖	quality_gate_security_no_fs_load	memory utilization	+0.24	[+0.16, +0.32]	1	Logs bounds checks dashboard
➖	quality_gate_logs	% cpu utilization	+0.22	[-0.78, +1.22]	1	Logs bounds checks dashboard
➖	quality_gate_idle_all_features	memory utilization	+0.15	[+0.11, +0.18]	1	Logs bounds checks dashboard
➖	quality_gate_private_action_runner	memory utilization	+0.02	[-0.10, +0.15]	1	Logs bounds checks dashboard
➖	quality_gate_security_idle	memory utilization	-0.04	[-0.10, +0.02]	1	Logs bounds checks dashboard
➖	quality_gate_security_mean_fs_load	memory utilization	-0.11	[-0.15, -0.08]	1	Logs bounds checks dashboard
➖	quality_gate_metrics_logs	memory utilization	-0.58	[-0.83, -0.33]	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	3 ≤ 4	bounds checks dashboard
✅	quality_gate_idle	memory_usage	10/10	148.21MiB ≤ 154MiB	bounds checks dashboard
✅	quality_gate_idle	total_bytes_received	10/10	729.35KiB ≤ 819.20KiB	bounds checks dashboard
✅	quality_gate_idle_all_features	intake_connections	10/10	3 ≤ 4	bounds checks dashboard
✅	quality_gate_idle_all_features	memory_usage	10/10	496.33MiB ≤ 512MiB	bounds checks dashboard
✅	quality_gate_idle_all_features	total_bytes_received	10/10	1.12MiB ≤ 1.25MiB	bounds checks dashboard
✅	quality_gate_logs	intake_connections	10/10	4 ≤ 6	bounds checks dashboard
✅	quality_gate_logs	memory_usage	10/10	184.21MiB ≤ 195MiB	bounds checks dashboard
✅	quality_gate_logs	missed_bytes	10/10	0B = 0B	bounds checks dashboard
✅	quality_gate_logs	total_bytes_received	10/10	263.77MiB ≤ 292MiB	bounds checks dashboard
✅	quality_gate_metrics_logs	cpu_usage	10/10	356.23 ≤ 2000	bounds checks dashboard
✅	quality_gate_metrics_logs	intake_connections	10/10	3 ≤ 6	bounds checks dashboard
✅	quality_gate_metrics_logs	memory_usage	10/10	411.13MiB ≤ 430MiB	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	73.26MiB ≤ 75MiB	bounds checks dashboard
✅	quality_gate_security_idle	cpu_usage	10/10	28.98 ≤ 100	bounds checks dashboard
✅	quality_gate_security_idle	memory_usage	10/10	305.07MiB ≤ 330MiB	bounds checks dashboard
✅	quality_gate_security_mean_fs_load	cpu_usage	10/10	60.05 ≤ 200	bounds checks dashboard
✅	quality_gate_security_mean_fs_load	memory_usage	10/10	276.05MiB ≤ 310MiB	bounds checks dashboard
✅	quality_gate_security_no_fs_load	cpu_usage	10/10	22.45 ≤ 100	bounds checks dashboard
✅	quality_gate_security_no_fs_load	memory_usage	10/10	287.73MiB ≤ 320MiB	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".

Replicate Execution Details

We run multiple replicates for each experiment/variant. However, we allow replicates to be automatically retried if there are any failures, up to 8 times, at which point the replicate is marked dead and we are unable to run analysis for the entire experiment. We call each of these attempts at running replicates a replicate execution. This section lists all replicate executions that failed due to the target crashing or being oom killed.

Note: In the below tables we bucket failures by experiment, variant, and failure type. For each of these buckets we list out the replicate indexes that failed with an annotation signifying how many times said replicate failed with the given failure mode. In the below example the baseline variant of the experiment named experiment_with_failures had two replicates that failed by oom kills. Replicate 0, which failed 8 executions, and replicate 1 which failed 6 executions, all with the same failure mode.

Experiment	Variant	Replicates	Failure	Logs	Debug Dashboard
experiment_with_failures	baseline	0 (x8) 1 (x6)	Oom killed		Debug Dashboard

The debug dashboard links will take you to a debugging dashboard specifically designed to investigate replicate execution failures.

❌ Retried Profiling Replicate Execution Failures (ddprof)

Note: Profiling replicas may still be executing. See the debug dashboard for up to date status.

Experiment	Variant	Replicates	Failure	Debug Dashboard
quality_gate_logs	baseline	10	Oom killed	Debug Dashboard
quality_gate_metrics_logs	baseline	10	Oom killed	Debug Dashboard
quality_gate_metrics_logs	comparison	10	Oom killed	Debug Dashboard

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 intake_connections: 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_security_idle, 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_no_fs_load, bounds check memory_usage: 10/10 replicas passed. Gate passed.
• quality_gate_security_no_fs_load, bounds check cpu_usage: 10/10 replicas passed. Gate passed.
• quality_gate_idle, bounds check total_bytes_received: 10/10 replicas passed. Gate passed.
• quality_gate_idle, bounds check intake_connections: 10/10 replicas passed. Gate passed.
• quality_gate_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_metrics_logs, bounds check cpu_usage: 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 intake_connections: 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 missed_bytes: 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.

[mbertrone]

@gjulianm one thing I hit while flipping the default that I'd like your read on, since it sits outside what this PR touches.

Two gates next to enable_ebpf_probes are keyed on gpu_monitoring.enabled rather than on the probes flag, so the new default configuration still pays for the event monitor even though nothing consumes it:

• pkg/system-probe/config/config.go:147 — gpuEnabled || unconditionally adds EventMonitorModule to EnabledModules. Its NeedsEBPF (cmd/system-probe/modules/eventmonitor_linux.go:29-31) returns true by default, so ebpf.Setup runs and the event monitor loads its own eBPF programs.
• cmd/system-probe/modules/eventmonitor.go:136 — if gpucfg.Enabled { createGPUProcessEventConsumer(evm) } builds a process consumer subscribed to exec/exit events.

That consumer's only reader is cmd/system-probe/modules/gpu.go:75 (ProcessMonitor: processEventConsumer), which is inside the if c.EnableEBPFProbes block at line 72. With the probes off the probe is never created, so the consumer is never read.

This isn't new — it was already reachable for anyone who set the flag manually — but this PR makes it the shipped default, so every GPU host now loads the event monitor's eBPF machinery for nothing.

Two questions:

1. Is the event monitor needed for anything else in GPU monitoring that I'm missing? As far as I can trace it isn't: prmHandler goes through the device cache, and configureCgroupPermissions already runs outside the probes block.
2. If not — do you want both gates moved to EnableEBPFProbes here, or as a follow-up? They'd have to move together to stay consistent with the EnableEBPFProbes && processEventConsumer == nil guard at gpu.go:60.

[gjulianm]

Two questions:

1. Is the event monitor needed for anything else in GPU monitoring that I'm missing? As far as I can trace it isn't: prmHandler goes through the device cache, and configureCgroupPermissions already runs outside the probes block.
2. If not — do you want both gates moved to EnableEBPFProbes here, or as a follow-up? They'd have to move together to stay consistent with the EnableEBPFProbes && processEventConsumer == nil guard at gpu.go:60.

@mbertrone I think we can safely disable the event monitor if eBPF probes are disabled, yes, we can update the guards

[mbertrone]

Two questions:

1. Is the event monitor needed for anything else in GPU monitoring that I'm missing? As far as I can trace it isn't: prmHandler goes through the device cache, and configureCgroupPermissions already runs outside the probes block.
2. If not — do you want both gates moved to EnableEBPFProbes here, or as a follow-up? They'd have to move together to stay consistent with the EnableEBPFProbes && processEventConsumer == nil guard at gpu.go:60.

@mbertrone I think we can safely disable the event monitor if eBPF probes are disabled, yes, we can update the guards

@gjulianm great I'll address that in another PR

[temporal-github-worker-1]

Backport evaluation: View Slack thread

[dd-octo-sts]

⚠️ Automatic backport to 7.82.x failed.

This usually happens when the cherry-pick has merge conflicts and needs manual resolution.

To backport manually, run:

git fetch
git worktree add .worktrees/backport-7.82.x 7.82.x
cd .worktrees/backport-7.82.x
git switch --create backport-54291-to-7.82.x
git cherry-pick -x --mainline 1 1316bc4f3ee3e6de03431e9b504d2fcd24366a28
git push --set-upstream origin backport-54291-to-7.82.x

Workflow logs: https://github.com/DataDog/datadog-agent/actions/runs/31006163118