Repository navigation
Create a separate registry for work-queue metrics #2670
Description
Hi all!
We are using custom controllers to manage our custom resources, and wish to export the workqueue metrics to Prometheus.
This is done by using the workqueue.SetProvider() provided by kubernetes.io/client-go.
When we try to register our metrics using this function in our init(), this doesn't take effect, as the init() function being used in the metrics package of this repo seems to making the call to SetProvider() first.
We can make use of this registry that you provide. It however comes with a whole lot of other metrics which we do not wish to export, such as - leader election, latency, request size, response size and other client metrics. And since they're internal we aren't able to unregister them.
Wonder if we can either:
- [The best option in my opinion] Create a separate registry for just workqueue metrics in this repo and not add the other metrics to it, so that we can use it in our project. We can then combine all those metrics along with the non-workqueue related ones in a separate registry, thus unaffecting the previous behaviour.
- Not have the
init()function altogether in themetrics.gofile. Instead provide those functionalities as a separate function, so that we users can call it in ourinit(). This way, if we choose to, we can create our own metrics and callSetProvider()ourselves. - Any other option which might not have been covered above...
- Or is there a way we can tackle this on our side without having to make any changes here?
I'm up for working on this issue.
Activity
troy0820 commentedon Feb 1, 2024
/kind support feature
I think this is a reasonable request. Do you mean that the defined metrics can then be registered to this "new" registry and pick the metrics you want to export rather than having all in one? Such as workqueue, etc?
And allow the user to register the metrics they want to expose?
sonamkshenoy commentedon Feb 1, 2024
Yep!
Something like: #2671
k8s-triage-robot commentedon May 1, 2024
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/staleis appliedlifecycle/stalewas applied,lifecycle/rottenis appliedlifecycle/rottenwas applied, the issue is closedYou can:
/remove-lifecycle stale/closePlease send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
k8s-triage-robot commentedon May 31, 2024
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/staleis appliedlifecycle/stalewas applied,lifecycle/rottenis appliedlifecycle/rottenwas applied, the issue is closedYou can:
/remove-lifecycle rotten/closePlease send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
k8s-triage-robot commentedon Jun 30, 2024
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/staleis appliedlifecycle/stalewas applied,lifecycle/rottenis appliedlifecycle/rottenwas applied, the issue is closedYou can:
/reopen/remove-lifecycle rottenPlease send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
k8s-ci-robot commentedon Jun 30, 2024
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
Details
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
alvaroaleman commentedon Jul 1, 2024
This issue is effectively a duplicate of #2238, except that it assumes a solution. Lets keep the discussion for this in the other issue.