[WP] Autogenerate config doc

[theop-dd]

What does this PR do?

This PR adds the capability to generate automatically the documentation for the workload protection agent settings.

Motivation

Previously, the documentation needed to be updated manually, leading to a gap between the doc and the real capabilities of the agent (that were not explained and presented).

Describe how you validated your changes

Manually test that the documentation is properly generated

[datadog-datadog-prod-us1]

🎯 Code Coverage (details)
• Patch Coverage: 0.00%
• Overall Coverage: 52.39% (+0.02%)

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

[joepeeples]

Added some editorial suggestions for the content portions. Also opened DOCS-15130 to further assess this new method of updating the docs.

[dd-octo-sts]

Files inventory check summary

File checks results against ancestor e7322df9:

Results for datadog-agent_7.84.0~devel.git.225.4cd6ae0.pipeline.131269496-1_amd64.deb:

No change detected

Results for datadog-iot-agent_7.84.0~devel.git.225.4cd6ae0.pipeline.131269496-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 e7322df
📊 Static Quality Gates Dashboard
🔗 SQG Job

33 successful checks with minimal change (< 2 KiB)

	Quality gate	Current Size
✅	agent_deb_amd64	760.215 MiB
✅	agent_deb_amd64_fips	713.076 MiB
✅	agent_heroku_amd64	312.555 MiB
✅	agent_msi	644.198 MiB
✅	agent_rpm_amd64	760.199 MiB
✅	agent_rpm_amd64_fips	713.060 MiB
✅	agent_rpm_arm64	735.964 MiB
✅	agent_rpm_arm64_fips	692.151 MiB
✅	agent_suse_amd64	760.199 MiB
✅	agent_suse_amd64_fips	713.060 MiB
✅	agent_suse_arm64	735.964 MiB
✅	agent_suse_arm64_fips	692.151 MiB
✅	docker_agent_amd64	818.831 MiB
✅	docker_agent_arm64	819.640 MiB
✅	docker_agent_jmx_amd64	1009.729 MiB
✅	docker_agent_jmx_arm64	999.190 MiB
✅	docker_cluster_agent_amd64	210.475 MiB
✅	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
✅	iot_agent_deb_amd64	46.475 MiB
✅	iot_agent_deb_arm64	43.127 MiB
✅	iot_agent_deb_armhf	43.910 MiB
✅	iot_agent_rpm_amd64	46.476 MiB
✅	iot_agent_suse_amd64	46.475 MiB

[theop-dd]

Added some editorial suggestions for the content portions. Also opened DOCS-15130 to further assess this new method of updating the docs.

@joepeeples

Thanks for all the suggestion, I have added them. WDYM by opening DOCS-15130, did you open another PR? I am currently working on the PR to make this update on the documentation repo.

[joepeeples]

WDYM by opening DOCS-15130, did you open another PR? I am currently working on the PR to make this update on the documentation repo.

Hi @theop-dd, I opened a Jira ticket for the Docs team, so we can take a closer look because it's a new mechanism for automatically updating documentation. Someone will be following up on this soon.

[theop-dd]

WDYM by opening DOCS-15130, did you open another PR? I am currently working on the PR to make this update on the documentation repo.

Hi @theop-dd, I opened a Jira ticket for the Docs team, so we can take a closer look because it's a new mechanism for automatically updating documentation. Someone will be following up on this soon.

@joepeeples
Okay great.
FYI: this mechanism is very similar to what we do for our SECL documentation if you want to have a look.

[aiuto]

I'm curious about how (if?) this gets consumed.
We obviously run it from here.

datadog-agent/tasks/security_agent.py

Line 494 in 946b1ac

def generate_cws_documentation(ctx):

Does it need to be a distinct callable task?
Could we fold the line bazel(ctx, "run", "//docs/cloud-workload-security:cws_docs")
into

datadog-agent/tasks/security_agent.py

Line 540 in 946b1ac

generate_cws_documentation(ctx)

and cut the task?
I ask because we will soon completely eliminate most of the code in cws_go_generate() and replace with a single bazel target that can bundle all the generated files directly into the distribution.
I'm trying to separate what is needed for local developer testing vs. what is needed for build/test/release.

[theop-dd]

The cws_go_generate command is quite long, so when we're only modifying the documentation, we prefer to run generate_cws_documentation since it's more convenient and faster. Having both task is useful for us but only from a local developer perspective. For build/test/release we only need the cws_go_generate indeed.

[cit-pr-commenter-54b7da]

Regression Detector

Regression Detector Results

Metrics dashboard
Target profiles
Job ID: 6918e3c2-d37f-4fc1-b6b0-fb2edd6b392c

Baseline: e7322df
Comparison: 4cd6ae0
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	+1.17	[+0.30, +2.05]	1	Logs bounds checks dashboard
➖	quality_gate_private_action_runner	memory utilization	+0.56	[+0.44, +0.68]	1	Logs bounds checks dashboard
➖	quality_gate_metrics_logs	memory utilization	+0.36	[+0.11, +0.61]	1	Logs bounds checks dashboard
➖	quality_gate_security_mean_fs_load	memory utilization	+0.17	[+0.09, +0.24]	1	Logs bounds checks dashboard
➖	quality_gate_security_idle	memory utilization	+0.14	[+0.02, +0.26]	1	Logs bounds checks dashboard
➖	quality_gate_idle_all_features	memory utilization	-0.12	[-0.17, -0.08]	1	Logs bounds checks dashboard
➖	quality_gate_security_no_fs_load	memory utilization	-0.16	[-0.31, -0.01]	1	Logs bounds checks dashboard
➖	quality_gate_idle	memory utilization	-0.18	[-0.30, -0.06]	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	172.81MiB ≤ 178MiB	bounds checks dashboard
✅	quality_gate_idle	total_bytes_received	10/10	743.00KiB ≤ 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	521.02MiB ≤ 538MiB	bounds checks dashboard
✅	quality_gate_idle_all_features	total_bytes_received	10/10	1.13MiB ≤ 1.25MiB	bounds checks dashboard
✅	quality_gate_logs	intake_connections	10/10	16 ≤ 40	bounds checks dashboard
✅	quality_gate_logs	memory_usage	10/10	203.14MiB ≤ 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.18MiB ≤ 292MiB	bounds checks dashboard
✅	quality_gate_metrics_logs	cpu_usage	10/10	364.52 ≤ 2000	bounds checks dashboard
✅	quality_gate_metrics_logs	intake_connections	10/10	19 ≤ 40	bounds checks dashboard
✅	quality_gate_metrics_logs	memory_usage	10/10	410.94MiB ≤ 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	71.80MiB ≤ 76MiB	bounds checks dashboard
✅	quality_gate_security_idle	cpu_usage	10/10	26.52 ≤ 100	bounds checks dashboard
✅	quality_gate_security_idle	memory_usage	10/10	332.64MiB ≤ 335MiB	bounds checks dashboard
✅	quality_gate_security_mean_fs_load	cpu_usage	10/10	58.47 ≤ 200	bounds checks dashboard
✅	quality_gate_security_mean_fs_load	memory_usage	10/10	305.37MiB ≤ 314MiB	bounds checks dashboard
✅	quality_gate_security_no_fs_load	cpu_usage	10/10	20.82 ≤ 100	bounds checks dashboard
✅	quality_gate_security_no_fs_load	memory_usage	10/10	308.62MiB ≤ 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_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_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_private_action_runner, 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_security_no_fs_load, 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_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 total_bytes_received: 10/10 replicas passed. Gate passed.
• quality_gate_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 intake_connections: 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 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_mean_fs_load, bounds check cpu_usage: 10/10 replicas passed. Gate passed.

[dd-octo-sts]

This pull request has been automatically marked as stale because it has not had activity in the past 15 days.

It will be closed in 30 days if no further activity occurs. If this pull request is still relevant, adding a comment or pushing new commits will keep it open. Also, you can always reopen the pull request if you missed the window.

Thank you for your contributions!