[usm] add module name to debugger #31003

guyarb · 2024-11-12T16:27:45Z

What does this PR do?

Adds module name to the debugger utilities of USM to allow filtering and distinguishing between usm entries to other modules.

Motivation

Allow other modules to easily implement their own debugging endpoints.

Filter out irrelevant entries in the blocked and traced programs output.

Describe how to test/QA your changes

UTs + manual query the debugging endpoints.

Possible Drawbacks / Trade-offs

Additional Notes

The module name will allow us to distinguish between different modules using attachers, and will allow us to provide only relevant information for the usm debugging endpoints

agent-platform-auto-pr · 2024-11-12T17:50:39Z

Test changes on VM

Use this command from test-infra-definitions to manually test this PR changes on a VM:

inv create-vm --pipeline-id=48885538 --os-family=ubuntu

Note: This applies to commit 264a038

cit-pr-commenter · 2024-11-12T18:17:58Z

Regression Detector

Regression Detector Results

Metrics dashboard
Target profiles
Run ID: f6a0f9e8-2ad2-46ff-95fb-f2fec0105434

Baseline: 0b38b96
Comparison: 264a038
Diff

Optimization Goals: ✅ No significant changes detected

Fine details of change detection per experiment

perf	experiment	goal	Δ mean %	Δ mean % CI	trials	links
➖	pycheck_lots_of_tags	% cpu utilization	+2.97	[-0.52, +6.46]	1	Logs
➖	basic_py_check	% cpu utilization	+2.20	[-1.70, +6.09]	1	Logs
➖	otel_to_otel_logs	ingress throughput	+0.85	[+0.19, +1.51]	1	Logs
➖	tcp_syslog_to_blackhole	ingress throughput	+0.36	[+0.30, +0.41]	1	Logs
➖	file_to_blackhole_500ms_latency	egress throughput	+0.14	[-0.10, +0.38]	1	Logs
➖	file_to_blackhole_300ms_latency	egress throughput	+0.11	[-0.09, +0.30]	1	Logs
➖	quality_gate_idle	memory utilization	+0.07	[+0.03, +0.12]	1	Logs bounds checks dashboard
➖	quality_gate_idle_all_features	memory utilization	+0.06	[-0.03, +0.16]	1	Logs bounds checks dashboard
➖	file_to_blackhole_100ms_latency	egress throughput	+0.03	[-0.30, +0.36]	1	Logs
➖	file_to_blackhole_0ms_latency	egress throughput	+0.01	[-0.43, +0.46]	1	Logs
➖	tcp_dd_logs_filter_exclude	ingress throughput	-0.00	[-0.01, +0.01]	1	Logs
➖	uds_dogstatsd_to_api	ingress throughput	-0.01	[-0.10, +0.08]	1	Logs
➖	file_to_blackhole_1000ms_latency	egress throughput	-0.16	[-0.64, +0.32]	1	Logs
➖	file_to_blackhole_1000ms_latency_linear_load	egress throughput	-0.44	[-0.93, +0.04]	1	Logs
➖	file_tree	memory utilization	-0.61	[-0.74, -0.48]	1	Logs
➖	uds_dogstatsd_to_api_cpu	% cpu utilization	-1.63	[-2.36, -0.90]	1	Logs

Bounds Checks: ❌ Failed

perf	experiment	bounds_check_name	replicates_passed	links
❌	file_to_blackhole_100ms_latency	lost_bytes	6/10
❌	quality_gate_idle	memory_usage	6/10	bounds checks dashboard
❌	quality_gate_idle_all_features	memory_usage	9/10	bounds checks dashboard
✅	file_to_blackhole_0ms_latency	lost_bytes	10/10
✅	file_to_blackhole_0ms_latency	memory_usage	10/10
✅	file_to_blackhole_1000ms_latency	memory_usage	10/10
✅	file_to_blackhole_1000ms_latency_linear_load	memory_usage	10/10
✅	file_to_blackhole_100ms_latency	memory_usage	10/10
✅	file_to_blackhole_300ms_latency	memory_usage	10/10
✅	file_to_blackhole_500ms_latency	memory_usage	10/10

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:

Its estimated |Δ mean %| ≥ 5.00%, indicating the change is big enough to merit a closer look.
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.
Its configuration does not mark it "erratic".

amitslavin · 2024-11-13T08:29:04Z

pkg/network/usm/utils/debugger.go

-	registries []*FileRegistry
-	attachers  map[string]Attacher
+	registries map[string][]*FileRegistry
+	attachers  map[string]map[string]Attacher


What do you think about flattening the nested map? I feel that the current attachers struct is quite complex. Maybe we should consider adding a struct to improve the current map structure?

added a syntactic sugar and documentation to make it easier

amitslavin · 2024-11-13T08:30:08Z

pkg/network/usm/utils/debugger.go

 }

-func (d *tlsDebugger) GetTracedPrograms() []TracedProgram {
+func (d *tlsDebugger) GetTracedPrograms(moduleName string) []TracedProgram {


Can you please add documentation to this function?

amitslavin · 2024-11-13T08:32:13Z

pkg/network/usm/utils/debugger_testutils.go

@@ -78,24 +79,24 @@ func WaitForProgramsToBeTraced(t *testing.T, programType string, pid int, traceM
 	t.Logf("process %v is not traced by %v, trying to attach manually", pid, programType)

 	// Get attacher for the program type


update the documentation to contain your change

amitslavin · 2024-11-13T08:34:26Z

pkg/network/usm/utils/debugger.go

+	if !ok {
+		d.mux.Unlock()
+		w.WriteHeader(http.StatusBadRequest)
+		fmt.Fprintf(w, "module %q is unrecognized", moduleName)


Maybe we can add unit tests to validate this flow, just to ensure that when we use a module that doesn't exist, everything behaves as expected.

gjulianm

LGTM for ebpf-platform files other than a minor comment. Thanks for this!

gjulianm · 2024-11-13T09:50:24Z

pkg/gpu/probe.go

@@ -139,7 +139,7 @@ func NewProbe(cfg *config.Config, deps ProbeDependencies) (*Probe, error) {
 		}
 	}

-	p.attacher, err = uprobes.NewUprobeAttacher(gpuAttacherName, attachCfg, p.m, nil, &uprobes.NativeBinaryInspector{}, deps.ProcessMonitor)
+	p.attacher, err = uprobes.NewUprobeAttacher("gpu", gpuAttacherName, attachCfg, p.m, nil, &uprobes.NativeBinaryInspector{}, deps.ProcessMonitor)


Can we have a constant gpuAttacherModuleName similar to gpuAttacherName?

cit-pr-commenter · 2024-11-13T10:53:03Z

Go Package Import Differences

Baseline: 0b38b96
Comparison: 264a038

binary	os	arch	change
system-probe	linux	amd64	+1, -0 +github.com/DataDog/datadog-agent/pkg/network/usm/consts
system-probe	linux	arm64	+1, -0 +github.com/DataDog/datadog-agent/pkg/network/usm/consts

val06 · 2024-11-13T12:35:24Z

pkg/gpu/probe.go

@@ -32,6 +32,7 @@ import (

 const (
 	gpuAttacherName = "gpu"
+	gpuModuleName   = gpuAttacherName


i think it would be better to use config.GPUMonitoringModule

(actually i can change all "magic string" references in probe.go in a separate PR)

unfortunately, no, as it will cause cyclic import
we need to move config.GPUMonitoringModule to be in pkg/

github-actions bot added component/system-probe long review PR is complex, plan time to review it labels Nov 12, 2024

guyarb added changelog/no-changelog team/usm The USM team qa/done Skip QA week as QA was done before merge and regressions are covered by tests labels Nov 12, 2024

guyarb added 2 commits November 12, 2024 19:23

usm: debugger: Add module name identifier

6a10902

The module name will allow us to distinguish between different modules using attachers, and will allow us to provide only relevant information for the usm debugging endpoints

usm: debugger: tests: Fixed tests to provide moduleName

7f67340

guyarb force-pushed the guy.arbitman/add-module-name-to-debugger branch from 93570a4 to 7f67340 Compare November 12, 2024 17:24

guyarb marked this pull request as ready for review November 12, 2024 17:24

guyarb requested review from a team as code owners November 12, 2024 17:24

guyarb requested a review from Jakobovski November 12, 2024 17:24

guyarb changed the title ~~Guy.arbitman/add module name to debugger~~ [usm] add module name to debugger Nov 12, 2024

hmahmood approved these changes Nov 12, 2024

View reviewed changes

usm: debugger: Added windows stubs

1dbad71

amitslavin requested changes Nov 13, 2024

View reviewed changes

gjulianm approved these changes Nov 13, 2024

View reviewed changes

guyarb added 5 commits November 13, 2024 12:25

gpu: Added a constant for gpu module name

9471355

tests: Use a constant for test module name

a186699

tests: Use a constant for test module name

12e1ae5

gpu: Added a constant for gpu module name in tests

c1a0f2e

usm: Use a constant for the module name

264a038

val06 reviewed Nov 13, 2024

View reviewed changes

Jakobovski approved these changes Nov 13, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[usm] add module name to debugger #31003

[usm] add module name to debugger #31003

guyarb commented Nov 12, 2024 •

edited

Loading

agent-platform-auto-pr bot commented Nov 12, 2024 •

edited

Loading

cit-pr-commenter bot commented Nov 12, 2024 •

edited

Loading

Fine details of change detection per experiment

Explanation

amitslavin Nov 13, 2024

guyarb Nov 13, 2024

amitslavin Nov 13, 2024

amitslavin Nov 13, 2024

amitslavin Nov 13, 2024

gjulianm left a comment

gjulianm Nov 13, 2024

cit-pr-commenter bot commented Nov 13, 2024

val06 Nov 13, 2024

guyarb Nov 13, 2024

		@@ -78,24 +79,24 @@ func WaitForProgramsToBeTraced(t *testing.T, programType string, pid int, traceM
		t.Logf("process %v is not traced by %v, trying to attach manually", pid, programType)

		// Get attacher for the program type

[usm] add module name to debugger #31003

Are you sure you want to change the base?

[usm] add module name to debugger #31003

Conversation

guyarb commented Nov 12, 2024 • edited Loading

What does this PR do?

Motivation

Describe how to test/QA your changes

Possible Drawbacks / Trade-offs

Additional Notes

agent-platform-auto-pr bot commented Nov 12, 2024 • edited Loading

Test changes on VM

cit-pr-commenter bot commented Nov 12, 2024 • edited Loading

Regression Detector

Regression Detector Results

Optimization Goals: ✅ No significant changes detected

Fine details of change detection per experiment

Bounds Checks: ❌ Failed

Explanation

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gjulianm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cit-pr-commenter bot commented Nov 13, 2024

Go Package Import Differences

Choose a reason for hiding this comment

Choose a reason for hiding this comment

guyarb commented Nov 12, 2024 •

edited

Loading

agent-platform-auto-pr bot commented Nov 12, 2024 •

edited

Loading

cit-pr-commenter bot commented Nov 12, 2024 •

edited

Loading