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

Named Tracer question #407

Closed
obecny opened this issue Jan 13, 2020 · 9 comments
Closed

Named Tracer question #407

obecny opened this issue Jan 13, 2020 · 9 comments

Comments

@obecny
Copy link
Member

obecny commented Jan 13, 2020

With regards to
https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/api-tracing.md#obtaining-a-tracer

Lets have such example

const webTracerRegistry = new WebTracerRegistry({});
webTracerRegistry.addSpanProcessor(new SimpleSpanProcessor(new ConsoleSpanExporter()));

###Case A

const tracerA = webTracerRegistry.getTracer('foo');

###Case B

const tracerB = webTracerRegistry.getTracer();

Please clarify what should happen when the name is invalid or empty - Case B.

  1. tracerB should be created, it should be a "WebTracer" class and "ConsoleSpanExporter" should be showing the spans in console - exactly the same as for tracerA

  2. tracerB should be created, it should be a no-op tracer - so the "ConsoleSpanExporter" will not show any span in console - completely opposite as tracerA

  3. The point 1 is correct by default but we should create a "Provider" which will allow an application owners to change this behaviour so they can overwrite default behaviour by providing its own implementation of Tracer when name is not provided and then they can create a case when point 2 can be true.

  4. opposite to point 3 (point 2 is correct, add provider so application owner can create point 1)

  5. something else ?

P.S. We don't have yet the Provider so please take it also into consideration

thx in advance for clarification

@dyladan
Copy link
Member

dyladan commented Jan 13, 2020

@obecny recommend removing the web specific parts of this and just making it called TracerProvider since the difference between web and node does not matter for this question and is likely to confuse people outside of the JS SIG.

3 and 4 are definitely not in the current spec so I would just remove them so we also don't confuse people.

@dyladan
Copy link
Member

dyladan commented Jan 13, 2020

As I see it, the root of this question is "what should happen when getTracer is called with a missing name?" (invalid usage because name is a required parameter). I would say a no-op tracer should be returned.

@dyladan
Copy link
Member

dyladan commented Jan 13, 2020

ping @danielkhan for your opinion here

@Oberon00
Copy link
Member

Oberon00 commented Jan 14, 2020

The spec says "a working default implementation" should be returned, so I'd log an error and return a tracer with a fallback instrumentation library name like "MISSING LIBRARY".

@obecny
Copy link
Member Author

obecny commented Jan 14, 2020

We had some discussion with ruby too and one thing which was brought that having just a no-op tracer would be like fail silently and is a bad pattern instead of using the same tracer but with a name what @Oberon00 proposed and just adding some warning message that the name is missing and default name has been set. This way tracing will be working but it will be easy to indicate what went wrong instead of seeing nothing and trying to figure out what and where is the problem.

@dyladan
Copy link
Member

dyladan commented Jan 14, 2020

Yes on the spec call today I think we agreed to give a tracer anyways and just assign "NAME MISSING" or something like that as the name.

@mwear
Copy link
Member

mwear commented Jan 14, 2020

FWIW, Ruby will provide a working implementation where the name defaults to an empty string.

@dyladan
Copy link
Member

dyladan commented Jan 21, 2020

@obecny I think we can close this with resolution: "should return a regular working tracer with some default name"

@arminru
Copy link
Member

arminru commented Feb 21, 2020

@obecny 👍ed to @dyladan resolution, closing the issue

@arminru arminru closed this as completed Feb 21, 2020
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

No branches or pull requests

5 participants