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
Currently from #1887, the ProxyMeter will defer to a global MeterProvider once it is set in the API. However, this needs to go all the way down to the instrument level, or users will end up with no-op instruments even after configuring an SDK.
The text was updated successfully, but these errors were encountered:
I think this would be consistent with the general proxy approach, but it would be inconsistent with the current approach that we have implemented in Tracing, for example:
TracerProvider produces Tracers -> MeterProvider produces Meters
Tracer produce Spans -> Meter produce Instruments
I see how this approach is problematic as well, users may end up with no-op spans even after configuring an SDK.
I have the feeling that we should allow Tracer/MeterProviders to be changed (again) until we have a more well defined plan, because this seems like will conflict with the upcoming work that should introduce configuration and/or distros.
I see how this approach is problematic as well, users may end up with no-op spans even after configuring an SDK.
It isn't quite the same, as spans are generally short lived while instruments are part of the initial application set-up. With this approach, the user will still lose measurements made before the SDK is configured, just how they would lose spans. I think it's OK to lose a little bit of telemetry in this edge case where a user creates tracers/instruments before setting up the SDK.
Currently from #1887, the
ProxyMeter
will defer to a global MeterProvider once it is set in the API. However, this needs to go all the way down to the instrument level, or users will end up with no-op instruments even after configuring an SDK.The text was updated successfully, but these errors were encountered: