We expose metrics and recording rules (in the following text, when metrics are mentioned, recording rules are implicitly included) to users for various uses or intend to do so (alerts, dashboards, ad-hoc queries, HPA).
A change in a metric will break user artifacts, e.g. when a metric name changes, or the label set changes. This can happen on upgrades of components (we introduce changes from upstream) or due to actively introduced changes, e.g. dropping ingestion of some metrics for a reduced footprint.

It would be helpful to have a defined support level for the metrics we expose.

• Users can make informed decisions before they depend on metrics.
• We can create automated checks against our own support statement and raise awareness when changes are introduced.

Automation is key, since the metric set we expose is large.

Support levels

This requires further discussion, consider this list a first attempt/

Fully supported

We will ensure this metric will be consistent in the next version. However in that next version the support level could change (in order to allow us to react to upstream changes).

Supported

This metric will stay consistent in the current version.

Best effort

The default level. The metric can change at any time.

Deprecated

The metric will change or vanish in a future release.

DoD

TBD
Lets discuss first if this is feasible and yields benefits.