I'm implementing tracing feature with otel's official sdk tracing pacakge in Golang. The link for its repository is here.
While TracerProvider has all the configuraion such as Exporter, SpanProcessor, Sampler..., we can still choose different Tracers from the same TracerProvider:
tracerA := otel.GetTracerProvider().Tracer("TracerA")
tracerB := otel.GetTracerProvider().Tracer("TracerB")
Since they are from the same TracerProvider, tracerA and tracerB behave the same. And there's no other setting that makes difference. Example below will make one trace, not separated traces.
ctx, span := tracerA.Start(context.Background(), "First Span")
ctx, span = tracerB.start(ctx, "Second Span")
// above becomes
|----------------------| // First Span
|-------------| // Second Span
I wonder why otel provides those different Tracer instances. The result is the same no matter which Tracer is used. Is there a use-case for it?
Tracers are used to distinguish scope. A trace can indeed cross the boundaries of scope, but in order to show information flow within a system it is important to preserve the scope origin of a span.
For example, if you have one package that calls another and both packages are instrumented to record tracing telemetry, knowing what package a span comes from is critical if you want to track down a bug or performance question. For this reason, Tracers need to uniquely identify instrumentation code. In the case of OpenTelemetry Go, it is recommended that the Tracer name ...
is the Go package name of the library providing instrumentation (note: not the code being instrumented).
That Tracer should only be used within that instrumentation package and any other package that is a part of an application should have its own Tracer.
The fact that all of these Tracers originate from the same TracerProvider, and the TracerProvider is the object with all the export and processing configuration, means that all the telemetry these Tracers will produce for an application is all processed and exported the same.