Opentelemetry-specification: Named Tracer question

Created on 13 Jan 2020  路  9Comments  路  Source: open-telemetry/opentelemetry-specification

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

Most helpful comment

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

All 9 comments

@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.

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.

ping @danielkhan for your opinion here

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".

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.

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.

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

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

@obecny :+1:ed to @dyladan resolution, closing the issue

Was this page helpful?
0 / 5 - 0 ratings