Add ability to customize some aspects of the otel sdk creation by breedx-splk · Pull Request #1586 · open-telemetry/opentelemetry-android

breedx-splk · 2026-02-12T21:37:26Z

Related to #1577

This adds some additional customization capabilities to the initialization DSL. We've had users ask for similar things quite a few times now...and rather than always having to resort to using the OpenTelemetryRumBuilder I figured we could try and find some middle ground -- something that allows users to get the benefits of the initializer while still being able to do niche/bespoke customizations when needed.

This does change the api by adding functionality, but is backwards compatible and thus non-breaking.

breedx-splk · 2026-02-12T21:40:02Z

+fun interface TracerProviderCustomizer {
+    fun customize(builder: SdkTracerProviderBuilder): SdkTracerProviderBuilder
+}
+
+fun interface LoggerProviderCustomizer {
+    fun customize(builder: SdkLoggerProviderBuilder): SdkLoggerProviderBuilder
+}
+
+fun interface MeterProviderCustomizer {
+    fun customize(builder: SdkMeterProviderBuilder): SdkMeterProviderBuilder
+}


So these types aren't completely necessary -- but I thought that it read a bit cleaner than using the underlying functional methods from the SDK. If we're worried about the increase in surface area, then we could probably just remove them and refer to the functions...but it's a bit verbose.

What do you think?

What's the use case you have in mind for these customizers in the initializer? They seem to be providing a huge hammer to me. If I'm not mistaken, they would allow users to override our processors and our exporters, so they might get into trouble by doing so and then seeing that sessions, disk buffering, and export parameters don't work as configured via the DSL options.

typealias might be an option here if you want a degree of separation but without creating an extra interface

typealias might be an option here if you want a degree of separation but without creating an extra interface

Yes! Thank you. I think the typealias is considerably cleaner here.

What's the use case you have in mind for these customizers in the initializer?

Good question. The ones that I've heard, and what was discussed in #1577, is the ability to add custom SpanProcessors into the sdk. Without some help from the initializer, the developer would need to use the OpenTelemetryRumBuilder directly, missing out on the benefits/convenience of the Initializer.

Another use case that has been brought up more than once is the ability to expire/swap HTTP exporter headers/tokens...so basically customizing the exporters. That's not covered here, but I think we will need to address it before too long.

They seem to be providing a huge hammer to me. If I'm not mistaken, they would allow users to override our processors and our exporters, so they might get into trouble by doing so and then seeing that sessions, disk buffering, and export parameters don't work as configured via the DSL options.

You're completely correct -- this is a big hammer! You're also right, that I think this allows users to break things that the agent tries to help with. I think this is already true of the upstream autoconfigure as well -- it's possible to ab/use the autoconfigure callbacks to undo some of the defaults (like breaking the BSP which is responsible for exporting, for example).

Got it, thanks for the details.

The ones that I've heard, and what was discussed in #1577, is the ability to add custom SpanProcessors into the sdk.

This is fair enough. I believe we should be more specific with the api surface additions to make its evolution more iterative, though. I see the benefits of adding a big hammer like this one in terms of making it future-proof, but I'm afraid it can cause strange and difficult to address isssues down the line. Based on that, why don't we provide an API to add processors specifically instead?

Another use case that has been brought up more than once is the ability to expire/swap HTTP exporter headers/tokens...so basically customizing the exporters.

This should probably be a separate API that would allow to customize the exporters that we create in the agent. Not only to avoid providing a big hammer, but also because of how the Java SDK works. By adding a [Signal]ProviderCustomizer as proposed in this PR, I don't think that would help users to customize our exporters, as they can't access those via the Java SDK builders. So a specific exporter customizer seems to be the only feasible approach.

You're completely correct -- this is a big hammer! You're also right, that I think this allows users to break things that the agent tries to help with. I think this is already true of the upstream autoconfigure as well -- it's possible to ab/use the autoconfigure callbacks to undo some of the defaults (like breaking the BSP which is responsible for exporting, for example).

Don't get me wrong, I do not to like the idea of having to be some sort of police for our users and to tell them what they should and shouldn't do with their code. The thing is that experienced users can already do whatever they want to by using the rum builder, while being conscious that they might break things, which is why I believe that whoever decides to use the agent is expecting not only simplicity but also reliability, and it will become difficult to guarantee the reliability if we make it too flexible. Because of that, and to being able to provide better support for agent users when they run into trouble, I think it's best to increase the API surface to support concrete use cases in mind, such as allowing for custom processors in this case, and thus prevent other accidental changes.

fractalwrench · 2026-02-13T10:24:21Z

+fun interface TracerProviderCustomizer {
+    fun customize(builder: SdkTracerProviderBuilder): SdkTracerProviderBuilder
+}
+
+fun interface LoggerProviderCustomizer {
+    fun customize(builder: SdkLoggerProviderBuilder): SdkLoggerProviderBuilder
+}
+
+fun interface MeterProviderCustomizer {
+    fun customize(builder: SdkMeterProviderBuilder): SdkMeterProviderBuilder
+}


typealias might be an option here if you want a degree of separation but without creating an extra interface

fractalwrench · 2026-02-13T10:26:25Z

+import io.opentelemetry.sdk.trace.SdkTracerProviderBuilder
+
+@OpenTelemetryDslMarker
+class OtelSdkCustomizationsSpec internal constructor() {


Is it worth considering marking these new APIs as 'experimental' or 'incubating'? I suppose this is a more general question on what stability guarantees we want to provide for new APIs in modules that are otherwise stable?

My personal opinion is that marking a new API as experimental for a couple of versions is fairly normal on Android. Would be curious to hear others thoughts.

Seems like a reasonably good idea to me. Open to ideas on how to actually do this in practice.

The Incubating annotation in android-agent is one way of achieving this. It's probably worth chatting about this at the SIG as it's a broader discussion of how we approach adding new APIs to otherwise stable modules

fractalwrench · 2026-02-13T10:28:47Z

+}
+
+fun interface TracerProviderCustomizer {
+    fun customize(builder: SdkTracerProviderBuilder): SdkTracerProviderBuilder


One potential downside is that this does tie our API further to symbols declared in opentelemetry-java's SDK module. If we ever do decide to use opentelemetry-kotlin then this takes us further from that goal - but perhaps that's ok for now?

Right, this did occur to me as I was hacking on this, and I respect that you're especially sensitive to this (with KSP compat being an end goal). I'm not sure how to do things like this without some amount of dependency on java core for now....

I think the benefits outweigh the downside here tbh.

fractalwrench · 2026-02-13T10:31:16Z

+     * You can use this to customize additional nonstandard aspects of the OpenTelemetry SDK.
+     * Most users should not need to provide any customizations here.
+     */
+    fun otelSdkCustomizations(action: OtelSdkCustomizationsSpec.() -> Unit) {


I think we should add some sort of guarantee about configuration order here. For example, this could be the final action after all the other configuration (such as OTLP exporters) has been setup on the builder object.

I agree this is important to consider. I think right now that the implementation does these last, but I'm not sure how to bake that into this contract.

fractalwrench · 2026-02-13T10:33:01Z

I agree with the goal of allowing users to configure the underlying OpenTelemetry instance more. I think this changeset opens up some interesting questions about the tradeoffs of how best to achieve that.

codecov · 2026-02-13T17:27:53Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 66.36%. Comparing base (61aa085) to head (6d1fa6e).
⚠️ Report is 65 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1586      +/-   ##
==========================================
+ Coverage   65.86%   66.36%   +0.50%     
==========================================
  Files         157      158       +1     
  Lines        3132     3146      +14     
  Branches      318      319       +1     
==========================================
+ Hits         2063     2088      +25     
+ Misses        972      966       -6     
+ Partials       97       92       -5

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

breedx-splk · 2026-02-17T17:34:52Z

Thanks for a good discussion, everyone. After the SIG meeting today, I think we concluded that the specific use case of adding geo attributes would be better handled by an existing API which we overlooked previously -- namely the globalAttributes(supplier) which leverages the internal GlobalAttributesSpanAppender.

With that, I'm going to convert o draft for now, in case we want to continue discussing the tradeoffs...but I definitely agree that the approach provided in this PR is pretty broad and opens up some specific problems (big footgun, sdk in api footprint).

breedx-splk added 2 commits February 12, 2026 13:34

add ability to customize some aspects of sdk creation

d019c02

fix copypasta

fe9fbc0

breedx-splk requested a review from a team as a code owner February 12, 2026 21:37

breedx-splk commented Feb 12, 2026

View reviewed changes

redump because I guess positioning is also important

86f61ca

$fractalwrench$

fractalwrench reviewed Feb 13, 2026

View reviewed changes

use typealias instead of explicit interface

6d1fa6e

breedx-splk marked this pull request as draft February 17, 2026 17:34

breedx-splk mentioned this pull request Feb 20, 2026

Expose more customization for metrics #1544

Open

Conversation

breedx-splk commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fractalwrench commented Feb 13, 2026

Uh oh!

codecov Bot commented Feb 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

breedx-splk commented Feb 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

breedx-splk commented Feb 12, 2026 •

edited

Loading

codecov Bot commented Feb 13, 2026 •

edited

Loading