feat(remoteconfig): add Dynamic Instrumentation system probe module with per-node Remote Config support#3200
Conversation
|
grantseltzer
force-pushed
the
grantseltzer/di-remote-enable-signal
branch
from
cde1f24 to
e4dd37e
Compare
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cde1f24292
ℹ️ 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".
| }, | ||
| Config: &v2alpha1.DatadogAgentSpec{ | ||
| Features: &v2alpha1.DatadogFeatures{ | ||
| DynamicInstrumentation: &v2alpha1.DynamicInstrumentationFeatureConfig{ |
There was a problem hiding this comment.
When a node-scoped Remote Config payload arrives, this builds a DatadogAgentProfile whose config sets features.dynamicInstrumentation. The DatadogAgent profile reconciliation path validates every profile before applying it (agentprofile.ValidateProfileAndReturnRequirements -> v1alpha1.ValidateDatadogAgentProfileSpec), and api/datadoghq/v1alpha1/datadogagentprofile_validation.go still allowlists only gpu and apm, so these generated profiles are marked invalid/skipped and the per-node RC enablement never reaches matching nodes. Add dynamicInstrumentation to the DatadogAgentProfile feature allowlist (and its test allowlist) or avoid creating profiles with unsupported feature config.
Useful? React with 👍 / 👎.
Add a DynamicInstrumentationFeatureConfig type with an Enabled flag and wire it into DatadogFeatures as the dynamicInstrumentation field. Because DatadogFeatures is embedded in DatadogAgentSpec, this field is also exposed on the DatadogAgentInternal and DatadogAgentProfile CRDs, which lets a profile enable the module on a node subset. Regenerated deepcopy, openapi, CRD manifests, and docs via make generate and make manifests.
Add a dyninst feature that enables the Dynamic Instrumentation system probe module on the node agent. The handler follows the USM pattern: it requires the core agent and system-probe containers, sets HostPID, the AppArmor annotation, system-probe capabilities, and the procdir/cgroups/debugfs/socket volumes, and sets DD_DYNAMIC_INSTRUMENTATION_ENABLED, DD_SYSTEM_PROBE_ENABLED, and DD_SYSPROBE_SOCKET on the core agent and system-probe containers. The env var name matches the agent binding dynamic_instrumentation.enabled. Configure reads features.dynamicInstrumentation.enabled from the spec and merges the cluster-wide remote config status into the spec, so the same handler serves both the cluster-wide and node-scoped (DatadogAgentProfile) enablement paths. Registered the new DynamicInstrumentationIDType and the blank import in both the datadogagent and datadogagentinternal controllers.
Wire the agent_config remote config product to enable the Dynamic Instrumentation system probe module on a node subset. Add a dynamic_instrumentation field to SystemProbeFeaturesConfig and a node_selector field to DatadogAgentRemoteConfig, and merge the new field into the cluster-wide status path alongside CWS/USM/CSPM. Because parseReceivedUpdates merges every config into a single struct, a node selector carried there would collapse multiple node-scoped payloads into one; to avoid that, parseReceivedUpdates now partitions configs, returning the merged cluster-wide config plus the list of node-scoped configs untouched. Each node-scoped config that enables the module is reconciled into a DatadogAgentProfile named by a stable hash of its node selector, with config.features.dynamicInstrumentation.enabled set so the feature handler turns the module on only for matching nodes. Every callback reconciles the full set of managed profiles and deletes any whose config was removed or disabled, so teardown happens without leaking profiles. Verified with go build, go vet, and the existing remoteconfig and feature tests.
grantseltzer
force-pushed
the
grantseltzer/di-remote-enable-signal
branch
from
e4dd37e to
39cabd4
Compare
2 participants
What does this PR do?
Adds the Dynamic Instrumentation system probe module to the operator, plus the operator-side plumbing to enable it through Remote Config.
features.dynamicInstrumentationfield. Setting it on a DatadogAgent (or a DatadogAgentProfile) now turns the module on.Motivation
This is the operator side of letting users enable the module from the Datadog UI. The backend product and UI that send the Remote Config payload come in follow-up changes, so the full UI flow isn't wired up yet.
Additional Notes
Nothing in the Remote Config path does anything until a payload arrives, so this is safe to merge before the backend and UI land. The config field itself works today.
Minimum Agent Versions
Agent team)
Describe your test plan
Build, vet, lint, and existing tests pass. Two ways to exercise it:
features.dynamicInstrumentation.enabled: trueon a DatadogAgent and confirm the node agents pick up the module.Checklist
enhancementqa/skip-qalabel[1]: https://docs.github.com/en/authentication/man Jump to bottom (ctrl+End) ↓ cation/signing-commits