Best practices for instrumenting #4532
Replies: 2 comments 6 replies
-
I think that I will take your feedback into consideration when working on #4531. I will also consider updating https://opentelemetry.io/docs/instrumentation/go/manual/#traces. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
👋 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:
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!
Beta Was this translation helpful? Give feedback.
All reactions