-
Notifications
You must be signed in to change notification settings - Fork 858
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow adding span processors when building a tracer provider. #2223
Allow adding span processors when building a tracer provider. #2223
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2223 +/- ##
=============================================
+ Coverage 0 87.49% +87.49%
- Complexity 0 2431 +2431
=============================================
Files 0 269 +269
Lines 0 8380 +8380
Branches 0 889 +889
=============================================
+ Hits 0 7332 +7332
- Misses 0 723 +723
- Partials 0 325 +325
Continue to review full report at Codecov.
|
@@ -216,10 +216,6 @@ public OpenTelemetrySdk build() { | |||
MeterProvider meterProvider = buildMeterProvider(); | |||
TracerSdkProvider tracerProvider = buildTracerProvider(); | |||
|
|||
for (SpanProcessor spanProcessor : spanProcessors) { | |||
tracerProvider.addSpanProcessor(spanProcessor); | |||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the downside about removing this is that now we won't be adding span processors to a pre-configured SDK. Not sure if we're ok with that or not. I know we've chatted about removing the ability to provide the fully configured SDK altogether, which would make this (obviously) just fine.
sdk/all/src/main/java/io/opentelemetry/sdk/OpenTelemetrySdk.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the reason to add this is wrong, we should remove the capability from the OpenTelemetry.Builder and add only this one.
Can you explain why you say this? @iNikem has very much wanted this capability in the configuration of OpenTelemetrySdk itself. Providing the option in either place will let people either configure the whole public API, or just the tracing part of it, as they desire. |
Here are some reasons:
We need to remember that larger our API surface is, more things we need to maintain and be careful about. So limiting the API is always the best decision. The trade-off is 1 extra line on the configuration code so not worth it. |
In #2231, I removed all duplicate ways. You can see in the test that I can still set all the options, and with not that much extra code. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bogdandrutu I thought the PR description being simple would be easier to understand but guess not :)
The real motivation for this is to remove the mutating addSpanProcessor
- there's no use for it, unless we add removeSpanProcessor
to parallel logging libraries ability to configure handlers. If you have code that only calls add
once, it can happen when building the SDK itself no matter what.
After adding this method, I can refactor our tests, and then deprecate the mutator. This is orthogonal to #2231
sdk/all/src/main/java/io/opentelemetry/sdk/OpenTelemetrySdk.java
Outdated
Show resolved
Hide resolved
There is one problem with this approach "circular initialization dependencies". One of the reason "SpanProcessor" was not in the builder is because an implementation of a "SpanProcessor" (or an exporter that is needed to construct the SpanProcessor) may need/depend on a "[Tracer/Meter]Provider" to record metrics or some tracing. Now the problem is:
So how are you going to solve this initialization ordering issue? |
Hmm - it seems the problem already exists when trying to configure the global Have also gotten feedback from teammates that it's very mysterious having to do a mutation, not being able to configure the SDK in one go. So need to come up with something I think :) The issue seems to mostly be about details of tracing / monitoring (exporters, remote samplers, etc). So it would be good if we can push the complexity down from the end-user layer ( |
The problem is that then you make creating of other telemetry components more of a special case, if you don't care about that, then this may be a decent solution. A second option is to always rely on SPI to load the core parts of the sdk, then the current OtelSDK.Builder is not a builder, it just sets the configuration to the already loaded core part. From user perspective this happens in one shot, and it also allows telemetry components (except core part loaded with SPI) to access the global correctly. That means user does not need to set the global when using our SDK which is also fine I think. |
ok, I think we have a plan to go forward with this now.
I'm ok with having 1 happen in a separate PR from 2. @bogdandrutu Your thoughts on sequencing? |
… into tracer-sdk-builder-addspanprocessor
… into tracer-sdk-builder-addspanprocessor
Is this PR blocked on anything? Let me know if there're any changes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
@bogdandrutu is there anything left to block this, since we removed the options from the main sdk builder itself? |
Similar to how we added to
OpenTelemetrySdk.Builder
I think we should have it here for symmetry and for users that only interact with the tracer-sdk.