CRD metrics are extremely brittle

[logicalhan]

What happened:

CRD metrics are currently extremely brittle due to the way it is implemented. The name of the CRD is interpolated into the name of the metric which makes it impossible to aggregate a CRD across different versions (or at least very very annoying to do so).

What you expected to happen:

The name, version, group of the CRD should be a value in a metric label.

How to reproduce it (as minimally and precisely as possible):

https://github.com/kubernetes/kube-state-metrics/blob/master/docs/customresourcestate-metrics.md

[dgrisonnet]

I agree with that sentiment, prefixing the metrics by the GVK means that it is impossible today to build any kind of alerts or dashboards that would work across multiple versions of the CRD. It is very tedious and risky to have to update all the things that depend on the metrics when an API is updated. A UX improvement could also be to make it so that users don't necessarily have to update their ksm config after every API update by always matching all the versions available for a certain API if none is specified.

Today, we have a way to override the prefix of the metric: https://github.com/kubernetes/kube-state-metrics/blob/master/docs/customresourcestate-metrics.md#naming but as far as I know, this would still not add the gvk labels which would make it impossible to differentiate metrics from different versions of the API.
In terms of usability, I also don't think that defaulting to a gvk prefix is the right choice, for the reason mentioned in this issue so I would be in favor of changing the existing implementation as suggested above.

[rexagod]

/assign