You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When debugging whether a controller is congested or not, we can measure how long our own reconcilers take to proccess an event using something like #[instrument] on the reconciler fn, but we have do not have access to how long an event spends in scheduling before it hits our reconciler, nor do we have information about how deep the queue is.
Having these numbers would be useful because it lets us more accurately tune controller parallelism and, as a result, vertically scale appropriately.
If it's something that can be exposed, then maybe two synchronised numbers is sufficient, but that might be quite difficult to actually thread through from Controller -> scheduler...
Describe alternatives you've considered
A feature-flagged metrics module using prometheus_client. This is the official rust prometheus client and it seems relatively light, but it should be fine behind an optional feature flag if we want to go down this route. Should try to do kube-rs/controller-rs#55 first if this is desirable.
..there is another that is well used and very optimized (prometheus) - but that also is lacking too many features and hasn't been released in a year so hard to recommend that these days
Documentation, Adoption, Migration Strategy
docs on scaling + metrics on kube.rs
release notes
imagine this will be purely additive
Target crate for feature
kube-runtime
The text was updated successfully, but these errors were encountered:
Would you like to work on this feature?
Maybe
What problem are you trying to solve?
When debugging whether a controller is congested or not, we can measure how long our own reconcilers take to proccess an event using something like
#[instrument]
on the reconciler fn, but we have do not have access to how long an event spends in scheduling before it hits our reconciler, nor do we have information about how deep the queue is.Having these numbers would be useful because it lets us more accurately tune controller parallelism and, as a result, vertically scale appropriately.
Ref: good article on common metrics for queues
Describe the solution you'd like
If it's something that can be exposed, then maybe two synchronised numbers is sufficient, but that might be quite difficult to actually thread through from
Controller
->scheduler
...Describe alternatives you've considered
A feature-flagged metrics module using prometheus_client. This is the official rust prometheus client and it seems relatively light, but it should be fine behind an optional feature flag if we want to go down this route. Should try to do kube-rs/controller-rs#55 first if this is desirable.
..there is another that is well used and very optimized (prometheus) - but that also is lacking too many features and hasn't been released in a year so hard to recommend that these days
Documentation, Adoption, Migration Strategy
imagine this will be purely additive
Target crate for feature
kube-runtime
The text was updated successfully, but these errors were encountered: