-
Notifications
You must be signed in to change notification settings - Fork 821
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
feat: bind controller with wrapped meter provider #1333
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1333 +/- ##
==========================================
+ Coverage 94.11% 94.17% +0.05%
==========================================
Files 145 144 -1
Lines 4335 4308 -27
Branches 883 875 -8
==========================================
- Hits 4080 4057 -23
+ Misses 255 251 -4
|
Maybe this is a silly question, but what is membraned? |
@dyladan No, its a fairly good question. I was also wondering if it's required to expose the interface MetricsCollector {
collect(): Promise<MetricRecord[]>;
} The metrics collector interface that the controller have access to, doesn't expose the internal state of meter providers. And the controller is receiving a thin object that delegates the collect method to the meter providers private |
@@ -54,3 +48,9 @@ export const DEFAULT_METRIC_OPTIONS = { | |||
unit: '1', | |||
valueType: api.ValueType.DOUBLE, | |||
}; | |||
|
|||
/** Represents an metrics collection interface. */ | |||
export interface MetricsCollector { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there some reason you decided to make this its own collector interface instead of just adding it to the existing meter provider?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The collect
method is not required by the spec. So I've tried not to expose the method on meter provider publicly but with restricted access from controllers.
*/ | ||
addController(controller: Controller) { | ||
controller.registerMetricsCollector({ | ||
collect: () => this._collect(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can avoid the extra function call and associated overhead if you make the collect
method public and do this.
controller.registerMetricsCollector(this);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or you could just inline the collect function implementation since it is only called in one place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed by inlining them.
unrefTimer(this._timer); | ||
} | ||
|
||
shutdown() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this also shut down the associated exporter? If I create a system like this:
const provider = new MeterProvider(new Controller(new Exporter()));
I would typically expect calling provider.shutdown()
, the provider would shut down the controller, and the controller would shut down the exporter. This is just my gut feeling though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed, it's true that controller shall shutdown exporters too.
@dyladan PR updated with the nodejs sdk. PTAL :D |
This PR does a lot of changes on the API of the metric SDK. However, it is recommended to follow the metric SDK specification so that there will not be significant changes regarding the API while the metric SDK spec is been drafted. So this PR will be blocked until there is a resolution on the metric SDK specification regarding the controllers and accumulators. |
#1528 Need updates according to the latest spec. |
Which problem is this PR solving?
One controller now binds with a membraned MeterProvider and can collect all metrics registered with the MeterProvider and its subsidiary Meters. Also, it is possible to create a pulling controller to properly control proactive metrics collections.
Short description of the changes
MeterProvider.addController
to register a controller.This PR superseded controller part changes of #1017.
Illustration of usage: