Skip to content

Add declarative configuration support#1226

Draft
zeitlinger wants to merge 5 commits intomainfrom
declarative-config-support
Draft

Add declarative configuration support#1226
zeitlinger wants to merge 5 commits intomainfrom
declarative-config-support

Conversation

@zeitlinger
Copy link
Copy Markdown
Member

@zeitlinger zeitlinger commented Mar 20, 2026

Summary

  • Register the distro's resource detector via DeclarativeConfigurationCustomizerProvider (model customizer) and ComponentProvider SPIs for DC mode
  • Add InstrumentationDefaults utility for DC-native default configuration — distro authors write defaults.getStructured("micrometer").setDefault("base_time_unit", "s") and the same instance serves both DC mode (model injection) and auto-config mode (otel.instrumentation.* translation)
  • ConfigPropertiesBackedConfigProvider (from open-telemetry/opentelemetry-java-instrumentation#15835) bridges ConfigProperties to DC paths automatically

Supersedes #1062.

Candidates for shared utils (otel-java-contrib)

These patterns will be needed by every distro adding DC support:

  • InstrumentationDefaults — DC-native API for defining instrumentation defaults, with applyToModel() and toConfigProperties() adapters
  • DistroComponentProvider boilerplate — registering a distro resource detector requires walking a null-check chain through ResourceModelExperimentalResourceDetectionModel → detectors list; a helper like ModelHelper.ensureResourceDetector(model, name) would simplify this

To be discussed in Java SIG before porting.

Test plan

  • ./gradlew :custom:test passes
  • InstrumentationDefaultsTest covers toConfigProperties(), applyToModel(), and does-not-override-existing semantics
  • Smoke test with DC YAML config once upstream ConfigPropertiesBackedConfigProvider lands

Copilot AI review requested due to automatic review settings March 20, 2026 15:45
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds support for OpenTelemetry Declarative Configuration (DC) mode in the Grafana Java agent distro by registering the distro resource detector through DC-related SPIs and aligning default instrumentation settings to DC notation.

Changes:

  • Register DC model customizer and ComponentProvider implementations via META-INF/services for DC mode.
  • Introduce DistroComponentProvider and GrafanaDeclarativeConfigurationCustomizerProvider to ensure the distro resource detector is present in the DC model.
  • Express default instrumentation settings in DC notation and translate them into otel.instrumentation.* properties for existing auto-configuration.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file
File Description
custom/src/main/resources/META-INF/services/io.opentelemetry.sdk.extension.incubator.fileconfig.DeclarativeConfigurationCustomizerProvider Registers the distro DC model customizer provider via ServiceLoader.
custom/src/main/resources/META-INF/services/io.opentelemetry.sdk.autoconfigure.spi.internal.ComponentProvider Registers the distro ComponentProvider for DC-based component creation.
custom/src/main/java/com/grafana/extensions/resources/internal/DistroComponentProvider.java Adds the distro resource detector into the DC model and provides the Resource instance.
custom/src/main/java/com/grafana/extensions/GrafanaDeclarativeConfigurationCustomizerProvider.java Hooks the model mutation into the DC customization SPI.
custom/src/main/java/com/grafana/extensions/GrafanaAutoConfigCustomizerProvider.java Moves default instrumentation settings to a DC-defaults map and translates to otel.instrumentation.*.
custom/build.gradle Adds incubator extension dependency needed for the new DC-related types.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

@zeitlinger
Copy link
Copy Markdown
Member Author

@jack-berg @jaydeluca @trask I've sketched out how distros can cater both to DC and non-DC.

The key addition (which I'd propose should go to contrib) is this:

class GrafanaDistributionConfig {

  static final InstrumentationDefaults DEFAULTS = new InstrumentationDefaults();

  static {
    DEFAULTS.getStructured("micrometer").setDefault("base_time_unit", "s");
    DEFAULTS.getStructured("log4j_appender").setDefault("experimental_log_attributes", "true");
    DEFAULTS.getStructured("logback_appender").setDefault("experimental_log_attributes", "true");
  }

  private GrafanaDistributionConfig() {}
}

Not sure it it should be static - but the main point is it's similarity to the DC API

Register the distro's resource detector via DeclarativeConfigurationCustomizerProvider
(model customizer) and ComponentProvider SPIs so it works in DC mode.

Express default instrumentation properties in DC notation as the source of truth,
translated to otel.instrumentation.* keys for auto-configuration.
ConfigPropertiesBackedConfigProvider bridges them to DC paths automatically.

Supersedes #1062.

Signed-off-by: Gregor Zeitlinger <gregor.zeitlinger@grafana.com>
Express defaults as Map<instrumentation, Map<property, value>> to mirror
the DC YAML structure instead of dotted paths.

Signed-off-by: Gregor Zeitlinger <gregor.zeitlinger@grafana.com>
The bridge already translates otel.instrumentation.* properties to DC
paths automatically — no need to maintain a separate DC representation.

Signed-off-by: Gregor Zeitlinger <gregor.zeitlinger@grafana.com>
Defines defaults using DC-style structured navigation:
  defaults.getStructured("micrometer").setDefault("base_time_unit", "s")

Same instance used by both code paths:
- DC mode: applyToModel() injects into the DC model
- Non-DC mode: toConfigProperties() translates to otel.instrumentation.* keys

TODO: Propose as shared utility in otel-java-contrib for distros.
Signed-off-by: Gregor Zeitlinger <gregor.zeitlinger@grafana.com>
Signed-off-by: Gregor Zeitlinger <gregor.zeitlinger@grafana.com>
@zeitlinger zeitlinger force-pushed the declarative-config-support branch from c4acad4 to 3ce1ec9 Compare March 31, 2026 15:34
zeitlinger added a commit to zeitlinger/opentelemetry-java-instrumentation that referenced this pull request Apr 10, 2026
Provides a utility for distributions to define instrumentation property
defaults once and have them work with both traditional property-based
configuration (otel.instrumentation.*) and declarative configuration
(YAML model under instrumentation/development.java).

Extracted from grafana/grafana-opentelemetry-java#1226.
Signed-off-by: Gregor Zeitlinger <gregor.zeitlinger@grafana.com>
zeitlinger added a commit to zeitlinger/opentelemetry-java-instrumentation that referenced this pull request Apr 10, 2026
Provides a utility for distributions to define instrumentation property
defaults once and have them work with both traditional property-based
configuration (otel.instrumentation.*) and declarative configuration
(YAML model under instrumentation/development.java).

Extracted from grafana/grafana-opentelemetry-java#1226.
Signed-off-by: Gregor Zeitlinger <gregor.zeitlinger@grafana.com>
@zeitlinger
Copy link
Copy Markdown
Member Author

zeitlinger commented Apr 18, 2026

Upstream PR open-telemetry/opentelemetry-java-instrumentation#17816 switched InstrumentationDefaults to a nested API:

Once #17816 lands, update GrafanaDistributionConfig:

DEFAULTS.getStructured("micrometer").setDefault("base_time_unit", "s");

becomes

DEFAULTS.get("micrometer").setDefault("base_time_unit", "s");

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants