-
Notifications
You must be signed in to change notification settings - Fork 649
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
Move "config" out from Meter into MeterProvider #751
Conversation
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.
Had a quick question on stateful
. This PR doesn't change this because stateful
was passed into the Meter before, but why isn't the stateful
bool scoped to the individual metrics? I could see a case where you might want to create stateful and stateless metrics.
# Stateful determines whether how metrics are collected: if true, metrics | ||
# accumulate over the process lifetime. If false, metrics are reset at the | ||
# beginning of each collection interval. | ||
metrics.set_meter_provider(MeterProvider(batcher_mode == "stateful")) |
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.
Looks like this check happens on line 46. Right now this script crashes without any arguments
metrics.set_meter_provider(MeterProvider(batcher_mode == "stateful")) | |
metrics.set_meter_provider(MeterProvider(stateful)) |
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.
This is a good question. The current design is such that the responsibility for "statefulness" belongs to the batcher, and in turn, the meter. This means that all metrics that created and recorded with this meter will have the same statefulness. This "batcher" concept was created previously when the metrics api was not as well defined (and we still don't really have a well defined SDK spec), in which we needed a way to determine whether we are calculating actual values or deltas. I think some of the optional refinements for metric instruments is trying to address these cases, in which if they become actual api elements, we will have to change our design to decouple statefulness from the batcher and make them a metric level control.
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 spirit of the change LGTM, but when can we remove stateful
altogether?
@c24t EDIT: Can we get a stamp on 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.
LGTM, but ideally we get all these args out of MeterProvider
and into shared config.
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.
great, thanks!
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.
Change looks good, just a minor nit on the changelog entry to call out resource as well.
Co-authored-by: alrex <[email protected]>
* chore: 0.4.0 release proposal * use api instead of types
Part of [#750]
Similar to how
Tracer
has a reference toTracerProvider
and configuration are done through theTracerProvider
and passed along to eachTracer
created for it. Apply similar logic forstateful
forMeterProvider
andMeter
.The purpose of this in terms of SDK design is to move a lot of the configuration to one central place (MeterProvider), instead of giving responsibility to other components. The next logical step would be to move PushController as part of the MeterProvider and have MeterProvider control the config Dot Net is doing something like this). Another option is introduce a new "Pipeline" concept, in which we register each component to a
Pipeline
and that will be the path of logic that metrics will take. Go is doing something like this. Any suggestions not related to this PR please discuss in [#750].