[feature request] Support Dynamic Control (META)

[stevejgordon]

Component

This is a new component

Is your feature request related to a problem?

Currently, the SDK and instrumentations are configured once at startup and configuration cannot be adjusted at runtime without deploying an updated configuration and restarting the instrumented application. In some situations it can be useful to dynamically control the configuration at runtime, without requiring a restart. In large enterprises it can be complex and time consuming to deploy configuration changes to a many distributed services. This can include changing logging levels, sampling rates and potentially disabling exporting of signals. This may be for general operational needs, or to prevent a flood of signal data due to unexpected load or external misuse.

What is the expected behavior?

My colleague has been working on an initial version of dynamic control (via telemetry policies) for the Java SDK (contrib).

I plan to create a .NET version of this same concept to support remote, dynamic configuration of the SDK and its components. The core design will follow that of the Java version and the OTEP for telemetry policies with .NET idioms and alignment with the work I'm doing in the SDK for declarative config.

Initially, I propose that I work in one new project for this POC with a longer term plan to potentially refactor into several projects. The reasoning is that telemetry policies can be applied from files, HTTP, OpAMP and custom providers. Some consumers may want the file-based telemetry policies, and likely won't want OpAMP dependencies etc. Eventually I could see the need for a core/abstractions project, with implementations for each provider in their own projects. Until a working POC is in place and a design is settled, it's probably easier to maintain this as a single project. This is the same plan that exists for the Java implementation.

I'm introducing this issue to capture discussions around the initial design and implementation. This issue is the meta issue so that the overall outline and progress are clearer. Note this not a generic reconfiguring of arbitrary agent features/config/capability, this is very specific to control maybe a dozen capabilities in some dynamically adjustable way

Task breakdown

• Phase 1: Package, tests, solution, CI, and packaging infrastructure (Add dynamic control projects and infrastructure #4744)
• Phase 2: Internal policy model and validation ([Dynamic Control] Phase 2: Add ITelemetryPolicy and TraceSamplingRatePolicy #4950)
• Phase 3: Source identity, immutable snapshots, and atomic policy store ([Dynamic Control] Phase 3a: Add PolicyKey, SourceRegistrationId, and PolicySourceMetadata #5011)
• Phase 4: Ordered and coalesced policy-store subscriptions (requires Phase 3)
• Phase 5: Source contracts, configuration model, and initial shorthand parser (requires Phase 2)
• Phase 6: Policy aggregation, provider priority, and merge rules (requires Phase 3)
• Phase 7: Provider coordination, sequencing, status, and lifecycle (requires Phases 4–6)
• Phase 8: Trace-sampling implementer and sampler integration (requires Phase 7 and an agreed SDK integration seam)
• Phase 9: Experimental OpAMP provider (requires Phase 7)
• Phase 10: Experimental file provider (requires Phase 7)
• Phase 11: End-to-end integration, experimental public API, diagnostics, and documentation (requires Phase 8 and at least one provider)
• Phase 12: Declarative component-factory integration (requires Phase 8 and an agreed declarative factory seam; does not block Phases 3–11)

Phases 3 and 5 can proceed concurrently. After Phase 3, Phases 4 and 6 can proceed concurrently; after Phase 7, Phases 8–10 can proceed concurrently.

Future Tasks

These are intentionally not assigned to committed phases yet:

• SDK/agent self-diagnostic log-level policy.
• Additional trace-policy shapes beyond the sampling-rate proof of concept.
• Policies for other SDK components or signals.
• Provider capability negotiation or local policy guardrails.
• Extracting OpAMP or file providers into separate packages.

Which alternative solutions or features have you considered?

Proprietary vendor solutions such as EDOT .NET OpAMP integration.

Additional context

I'm planning to implement this as a contrib package. It's likely that some pre-req work will need to be completed in the SDK to support some of the dynamic configuration features.

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[stevejgordon]

@martincostello Could you please assign me. I've opened the initial PR and will start work on this alongside declarative config.