[api] Implement a delegating no-op MeterProvider

[pichlermarc]

Is your feature request related to a problem? Please describe.

Currently when a MeterProvider is registered via metrics.setMeterProvider() after acquiring a metrics.getMeterProivder() elsewhere, the previously acquired MeterProvider will stay no-op forever unless replaced manually. This causes instrumentations that are registered before the creation of an SDK MeterProvider to never provide any metrics.

Describe the solution you'd like

Implementing the same delegating-noop similar to the one in the trace API, where a ProxyTracerProvider and ProxyTracer delegate calls to either the registered SDK instance or a NoopTracerProvider or NoopTracer.

Describe alternatives you've considered

• providing a hook in the API for instrumentations to update their MeterProvider, Meter, or Instrument instances, once a new MeterProvider is registered. However, this may require significant implementation overhead for anyone who wants to take care of such a case.

Additional context

Related

• Version 0.35.1 of @opentelemetry/sdk-node broke http instrumentation #3609
• Global MeterProvider Get/Set API is under-defined opentelemetry-specification#3068

[legendecas]

I don't have concrete figures right now, but I'm wondering if creating delegation for every Instrument instance may increase performance implications. #3267 introduces a hook for instrumentation to update their Instrument instances when their meter provider is being updated.

What about exposing an event in the API when the registered global meter/tracer provider is being updated?

[pichlermarc]

I don't have concrete figures right now, but I'm wondering if creating delegation for every Instrument instance may increase performance implications. #3267 introduces a hook for instrumentation to update their Instrument instances when their meter provider is being updated.

What about exposing an event in the API when the registered global meter/tracer provider is being updated?

I was also wondering about that. Also, looking closer into it, keeping track of the batch observable callbacks could be rather tricky with this approach. I wanted to refrain from exposing the event in the API to keep the API surface small, but it may be the only way to do it.

I'll look into how Python handles the delegating no-op, maybe I'm missing something here. 🤔

[dyladan]

We can also ask in the maintainer meeting

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.