You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Feedback from etcd-io/etcd#12919 (comment). Globals are nice for simpler examples, but it is often better for larger projects to avoid them so libraries are isolated from each other.
My suggestion would be to leave the examples in opentelemetry-go as-is, since I would categorize them as "simple", but change the more complex examples in contrib (e.g. the grpc or http examples) to plumb tracerprovider and propagation through. It would also be a better demonstration of those instrumentation libraries' capabilities, as it would show some of the common arguments that could be passed. That may be more confusing if examples differ in their approaches, and i'm open to other ideas on how to make it easier for new users to understand when they should, or shouldn't use global variables.
The text was updated successfully, but these errors were encountered:
I was looking into helping on this issue. The examples have changed quite a bit since this issue was raised. @dashpole can you please confirm this is still an improvement that needs to be made?
From my findings I see that the namedtracer example is the only one that uses a global variable. I think this fits with the suggestion as it is a "simple" example where the other examples are using the NewTracerProvider() to create a instance.
@MrAlias I think that means this issue can be closed?
pellared
transferred this issue from open-telemetry/opentelemetry-go
Dec 1, 2024
Feedback from etcd-io/etcd#12919 (comment). Globals are nice for simpler examples, but it is often better for larger projects to avoid them so libraries are isolated from each other.
My suggestion would be to leave the examples in opentelemetry-go as-is, since I would categorize them as "simple", but change the more complex examples in contrib (e.g. the grpc or http examples) to plumb tracerprovider and propagation through. It would also be a better demonstration of those instrumentation libraries' capabilities, as it would show some of the common arguments that could be passed. That may be more confusing if examples differ in their approaches, and i'm open to other ideas on how to make it easier for new users to understand when they should, or shouldn't use global variables.
The text was updated successfully, but these errors were encountered: