-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Issues in kube-state-metrics dev-setup #8951
Comments
@chrischdi It's low priority, but maybe you can take a look when you have some time. |
/triage accepted |
Just verified:
This is fixed in v2.9.2
This is fixed in v2.9.2
This one is questionable :-) We have this issue currently only for CRDs, where would otherwise define an empty So they do not really provide any information other than that labels. The above labels are also available at every other metric which exists for these CRDs. Other observation with v2.9.2: Kube-state-metrics logs the following for lots of our defined metrics (once per affected metric, when loading the configuration):
|
Would the general convention be that every info metrics needs an _info prefix? So not only our one "main" info metric per CRD but also something like annotation_paused? |
Hm makes sense to some degree. But I think in cases where you don't have additional useful labels it makes still sense to have one "main" info metric without additional labels. Vs just using some other metric (with potentially many other dimensions) as a info metric. |
From current perspective: also the xref: OpenMetrics specification / suffixes. We use the
|
Ah makes sense. Would be good to adjust them. |
So what we actually would want is:
The configuration does currently not allow us to define a gauge type with a fixed value of 1. Maybe that would be the best. |
Ah, got it Probably worth discussing with kube-state-metrics folks |
/priority important-longterm |
I saw a few (potential) issues with kube-state-metrics when running our dev-setup. Not sure if they are upstream issues or if they are related to our configuration.
For example:
Not sure if they are expected. I think this would become very noisy with a few hundreds of clusters.
The text was updated successfully, but these errors were encountered: