英文:
What is a use-case for multiple Tracers?
问题
我正在使用Golang中的otel官方sdk跟踪包实现跟踪功能。其存储库的链接在这里。
虽然TracerProvider具有诸如Exporter、SpanProcessor、Sampler等的所有配置，但我们仍然可以从同一个TracerProvider中选择不同的Tracer：
tracerA := otel.GetTracerProvider().Tracer("TracerA")
tracerB := otel.GetTracerProvider().Tracer("TracerB")
由于它们来自同一个TracerProvider，tracerA和tracerB的行为是相同的。没有其他设置会产生差异。下面的示例将生成一个跟踪，而不是分离的跟踪。
ctx, span := tracerA.Start(context.Background(), "First Span")
ctx, span = tracerB.start(ctx, "Second Span")
// 上述代码等同于
|----------------------| // First Span
|-------------| // Second Span
我想知道为什么otel提供这些不同的Tracer实例。无论使用哪个Tracer，结果都是相同的。这是否有特定的用例？
英文:
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?
答案1
得分: 5
Tracer用于区分作用域。追踪确实可以跨越作用域的边界，但为了展示系统内的信息流动，保留跨度的作用域起源非常重要。
例如，如果你有一个调用另一个包的包，并且这两个包都被仪表化以记录跟踪遥测数据，那么如果你想追踪错误或性能问题，知道一个跨度来自哪个包是至关重要的。因此，Tracer需要唯一标识仪表化代码。在OpenTelemetry Go的情况下，建议Tracer的名称是...
仪表化库的Go包名称（注意：不是被仪表化的代码）。
该Tracer应仅在该仪表化包内使用，并且任何作为应用程序一部分的其他包都应该有自己的Tracer。
所有这些Tracer都源自同一个TracerProvider，而TracerProvider是具有所有导出和处理配置的对象，这意味着这些Tracer为应用程序生成的所有遥测数据都会被相同地处理和导出。
英文:
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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论