Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[api] Implement a delegating no-op MeterProvider #3622

Open
pichlermarc opened this issue Feb 20, 2023 · 4 comments · May be fixed by #4858
Open

[api] Implement a delegating no-op MeterProvider #3622

pichlermarc opened this issue Feb 20, 2023 · 4 comments · May be fixed by #4858
Labels
api:metrics Issues and PRs related to the Metrics API feature-request never-stale

Comments

@pichlermarc
Copy link
Member

pichlermarc commented Feb 20, 2023

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

@pichlermarc pichlermarc added feature-request api:metrics Issues and PRs related to the Metrics API labels Feb 20, 2023
@pichlermarc pichlermarc changed the title Create a delegating noop MeterProvider Implement a delegating no-op MeterProvider Feb 20, 2023
@legendecas
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

dyladan commented Mar 2, 2023

We can also ask in the maintainer meeting

@github-actions
Copy link

github-actions bot commented May 8, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api:metrics Issues and PRs related to the Metrics API feature-request never-stale
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants