Best practices for instrumenting

[craigpastro]

👋 I recall reading somewhere that for instrumenting an app of some sort the best way would be to have a tracer per package by defining a package variable:

var tracer = otel.Tracer(<pkg-name>)

Alternative, you could define a tracer on init and pass it to where you need it.

Another alternative is to just otel.Tracer(name) wherever you need it, but is not the best as it is behind a mutex.

Anyway, what I wanted to ask is, is there any place the best way of doing this is documented? https://opentelemetry.io/docs/instrumentation/go/getting-started/ uses option 3 above, which is the worst of the alternatives, isn't it?

Thanks!

[pellared]

I think that var tracer = otel.Tracer(<pkg-name>) is good enough for most applications (unless e.g. you need to unit test the instrumentation of your application).

I will take your feedback into consideration when working on #4531. I will also consider updating https://opentelemetry.io/docs/instrumentation/go/manual/#traces.

[craigpastro]

Thanks @pellared ! I was trying to convince someone to use var tracer = otel.Tracer(<pkg-name>) but I couldn't find any official documentation and I am not very convincing on my own. There are also some nice projects using it in this way so I suppose that also works.

[pellared]

You can take a look at #4539

[craigpastro]

Thank you! That is very clear and will be a good place to point people to for sure.

[dmathieu]

An alternative way, which we use in the -contrib instrumentations, is to store the tracer within a struct so it can dynamically be set to something else (for testing) while avoiding to rely on global state.

See the net/http transport for example: https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/instrumentation/net/http/otelhttp/transport.go#L35

[craigpastro]

Hi @dmathieu! Ah, yes, I have seen this pattern quite a bit too. Thank you! So

it can dynamically be set to something else (for testing) while avoiding to rely on global state.

are the main advantages of this approach?

[dmathieu]

Yes. It's more flexible, as it doesn't rely on the global state.

[craigpastro]

I see. Thanks @dmathieu! That's good to know.