The introduction of "named tracers" brought up an interesting question around shared configuration objects (e.g. SpanProcessors).
Currently, the specification states that SpanProcessors must be registered on Tracer instances (https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/sdk-tracing.md#span-processor). With the introduction of named tracers, the logical counterpart for registering those would be the TracerFactory.
This however, brings up interesting questions:
Tracer instances created by the same TracerFactory share the same configuration objects? If e.g. these configuration objects change during the creation of 2 Tracers, should only the latter "see" this changes or should the former one receive those as well?Tracer expose operations to manipulate those objects (e.g. add another SpanProcessor)?TracerFactory and all other Tracers created by it?This is the current suggestion that whould go into the SDK specification:
Tracer instances created by a TracerFactory share the same configuration. Changes to this configuration data (e.g. adding an Exporter) reflect in all Tracer instances. Technically this could mean that Tracers have a reference to their TracerFactory and access those configuration objects through it.TracerFactory instances. This means methods like addSpanProcessor should move from Tracer to TracerFactory.This issue was resolved by PR #313, right?
No, I don't think so: https://github.com/open-telemetry/opentelemetry-specification/pull/313#issuecomment-543015376
I will look into Sampling and Propagators separately to have more focused PRs.
I think that by default all configs should be at Factory level and shared with all Tracers, and if needed we can allow special configs to be overwritten at Tracer level.
Closing it, as it seems this was solved. Please re-open if this isn't the case.
Most helpful comment
This is the current suggestion that whould go into the SDK specification:
Tracerinstances created by aTracerFactoryshare the same configuration. Changes to this configuration data (e.g. adding anExporter) reflect in allTracerinstances. Technically this could mean thatTracershave a reference to theirTracerFactoryand access those configuration objects through it.TracerFactoryinstances. This means methods likeaddSpanProcessorshould move fromTracertoTracerFactory.