Skip to content
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

Merged
merged 8 commits into from
Oct 22, 2019

Conversation

jkwatson
Copy link
Contributor

@jkwatson jkwatson commented Oct 1, 2019

This implements #573

/cc @bogdandrutu

Copy link
Member

@arminru arminru left a 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! 🙂

@jkwatson
Copy link
Contributor Author

jkwatson commented Oct 2, 2019

Updated with feedback from @arminru

@codecov-io
Copy link

codecov-io commented Oct 2, 2019

Codecov Report

Merging #584 into master will increase coverage by 0.16%.
The diff coverage is 89.13%.

Impacted file tree graph

@@             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
Impacted Files Coverage Δ Complexity Δ
...va/io/opentelemetry/opentracingshim/TraceShim.java 25% <0%> (-8.34%) 1 <0> (ø)
...ntelemetry/sdk/trace/TracerSdkFactoryProvider.java 100% <100%> (ø) 2 <2> (?)
...in/java/io/opentelemetry/sdk/OpenTelemetrySdk.java 100% <100%> (ø) 3 <1> (ø) ⬇️
...ntelemetry/trace/DefaultTracerFactoryProvider.java 100% <100%> (ø) 4 <4> (?)
...a/io/opentelemetry/trace/DefaultTracerFactory.java 80% <80%> (ø) 4 <4> (?)
...a/io/opentelemetry/sdk/trace/TracerSdkFactory.java 90% <90%> (ø) 3 <3> (?)
.../src/main/java/io/opentelemetry/OpenTelemetry.java 97.22% <95.45%> (+0.25%) 15 <7> (ø) ⬇️
... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a02b6d3...d8f4283. Read the comment docs.

Copy link
Member

@bogdandrutu bogdandrutu left a 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.

@jkwatson
Copy link
Contributor Author

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?

@bogdandrutu
Copy link
Member

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.

@jkwatson
Copy link
Contributor Author

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. :)

@bogdandrutu
Copy link
Member

Let's do that way for the moment and reevaluate in the next release when the Global instance otep will be addressed

@jkwatson
Copy link
Contributor Author

sure thing. I'll update it. Maybe I'll add a FactoryFactoryProviderImpl along side it. (just kidding!!!)

@jkwatson
Copy link
Contributor Author

updated with a TracerFactoryProvider

Copy link
Member

@bogdandrutu bogdandrutu left a comment

Choose a reason for hiding this comment

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

Overall LG

@jkwatson
Copy link
Contributor Author

If this is close enough to move forward with, I'll update the description and we can get it approved. Thoughts?

@arminru
Copy link
Member

arminru commented Oct 15, 2019

If this is close enough to move forward with, I'll update the description and we can get it approved. Thoughts?

Sounds good!

@jkwatson jkwatson changed the title A rough idea of how named tracers might look in the API. Add named tracers to the API Oct 15, 2019
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.
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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 and version arguments supplied to the TracerFactory must be used
to create a Resource instance which is stored on the created Tracer.
The readable representations of all Span instances created by a Tracer must
provide a getLibraryResource method that returns this Resource information
held by the Tracer.

In order to allow SpanProcessors 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.

Copy link
Contributor Author

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

jkwatson and others added 2 commits October 15, 2019 09:48
…ider.java

Co-Authored-By: Armin Ruech <armin.ruech@gmail.com>
Co-Authored-By: Armin Ruech <armin.ruech@gmail.com>
@bogdandrutu bogdandrutu merged commit 60ba3b7 into open-telemetry:master Oct 22, 2019
@jkwatson jkwatson deleted the named_tracer_ideas branch December 16, 2019 18:07
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.

4 participants