-
Notifications
You must be signed in to change notification settings - Fork 848
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
Add named tracers to the API #584
Add named tracers to the API #584
Conversation
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 for taking it on right away! 🙂
api/src/main/java/io/opentelemetry/trace/spi/TracerFactory.java
Outdated
Show resolved
Hide resolved
Updated with feedback from @arminru |
Codecov Report
@@ Coverage Diff @@
## master #584 +/- ##
============================================
+ Coverage 78.1% 78.27% +0.16%
- Complexity 691 702 +11
============================================
Files 86 89 +3
Lines 2453 2476 +23
Branches 232 233 +1
============================================
+ Hits 1916 1938 +22
- Misses 448 449 +1
Partials 89 89
Continue to review full report at Codecov.
|
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.
In my mind I thought that we will still have a TracerFactoryProvider (for the spi part) then the OpenTelemetry will return a TracerFactory (constructed using di) then from there you get Tracers.
I feel that the current PR changes the TracerProvider -> TracerFactory which is not what I expect.
Yeah, I went back and forth on which was the right way to go. I guess the decision is: do we want to control the caching of tracers at the API layer, or do we want to have that be an SDK responsibility. My gut tells me that it belongs in the SDK, but I don't feel extremely strongly about that. Thoughts? |
So everything is an interface TracerFactory/Tracer so the TracerFactoryProvider will provide it's own implementation for the factory so the SDK will control the caching or anything they want. |
Ah, I see what you're saying. Does that extra layer of indirection buy us much? SDK implementors now have to both implement a factory, and a factory factory (the provider implementation). It starts to sound like a parody of Java code. :) |
Let's do that way for the moment and reevaluate in the next release when the Global instance otep will be addressed |
sure thing. I'll update it. Maybe I'll add a FactoryFactoryProviderImpl along side it. (just kidding!!!) |
34a3aec
to
5d7feaf
Compare
updated with a |
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.
Overall LG
5d7feaf
to
b959240
Compare
If this is close enough to move forward with, I'll update the description and we can get it approved. Thoughts? |
Sounds good! |
api/src/main/java/io/opentelemetry/trace/spi/TracerFactoryProvider.java
Outdated
Show resolved
Hide resolved
String key = instrumentationName + "/" + instrumentationVersion; | ||
Tracer tracer = tracersByKey.get(key); | ||
if (tracer == null) { | ||
// todo: pass in the name & version here to the implementation to be used for purposes. |
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.
Please create an issue for tracking this TODO.
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 wasn't able to find a specification on what the SDK should do with these values. There is mention of creation of a Resource
that represents this data in the SDK, but nothing concrete. Did I miss it somewhere?
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.
Regarding named tracers, the SDK spec says:
The
name
andversion
arguments supplied to theTracerFactory
must be used
to create aResource
instance which is stored on the createdTracer
.
The readable representations of allSpan
instances created by aTracer
must
provide agetLibraryResource
method that returns thisResource
information
held by theTracer
.
In order to allow SpanProcessor
s to access the tracer's name and version when processing spans, ReadableSpan
will have to be extended by adding a method Resource getLibraryResource()
, which returns a Resource
describing the named tracer.
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.
aha! great. I saw mention of this in the OTEP, but hadn't tracked it down in the actual spec. Thanks! Issue added: #617
…ider.java Co-Authored-By: Armin Ruech <armin.ruech@gmail.com>
Co-Authored-By: Armin Ruech <armin.ruech@gmail.com>
This implements #573
/cc @bogdandrutu