feat(api): Add delegating no-op meter provider #4858
Conversation
hectorhdzg
changed the title
|
Hey Hector, you marked this as "Breaking change", would you mind providing more info on that? |
|
@maryliag sure thing, this is a breaking change because the behavior of metrics.getMeterProvider would be different now, it will return a ProxyMeterProvider instead of the actual registered meter provider, same as current behavior for tracerProvider |
| createGauge(_name: string, _options?: MetricOptions): Gauge { | ||
| return this._getMeter().createGauge(_name, _options); | ||
| } |
There was a problem hiding this comment.
There's a certain difficulty in the case of the metrics API vs the trace/logs APIs - there's another layer that needs to be taken into account, which is the instruments.
In Traces, the (no-op) span is an object which is only kept for the time that the span is active. So one span being no-op is not too problematic. For logs, the record is passed straight to the logger so it's also not a problem there. In metrics however, an instrument is instantiated early and is kept over the lifetime of the app. That means that when a user gets a Meter, they usually also create the Instruments already. A later-updated ProxyMeter would therefore be of very limited help as the instruments would also need to be proxies in order to give a smooth experience.
There was a problem hiding this comment.
Thanks for taking a look @pichlermarc, I wanted to fix #4112, so this is still relevant for us, I understand this change may need a major version update in the api package, maybe this is something I can move to a different branch and start experimenting with Instruments proxies or similar concept, what do you think?
There was a problem hiding this comment.
I don't think the major bump is necessary for this (just as with logs and traces). The types we export from the API are what we guarantee will be there. If there's extra properties on the registered SDK and those are available on the API too in plain JavaScript, then that was never guaranteed to also be there when returned by the API.
We can merge this to a separate branch to experiment with delegating instruments, but I think that could also be done here on this branch, as the PR won't really address the whole problem (instruments created before SDK registration being no-op) as it stands right now.
| export { ProxyMeter, MeterDelegator } from './metrics/ProxyMeter'; | ||
| export { ProxyMeterProvider } from './metrics/ProxyMeterProvider'; |
There was a problem hiding this comment.
Hmm, would it be required to export this? 🤔 It seems to me that it'd perfectly fine to keep this internal in case we want to change something about it in the future.
| public readonly name: string, | ||
| public readonly version?: string, | ||
| public readonly options?: MeterOptions |
There was a problem hiding this comment.
I think all of these could be private, right? 🤔
Fixes #3622
Short description of the changes
Adding ProxyMeterProvider and ProxyMeter
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist: