Open tl-eirik-albrigtsen opened 5 months ago
Working workaround with metricsRelabelings
(here using kube-prometheus-stack):
kube-state-metrics:
prometheus:
monitor:
enabled: true
metricRelabelings:
- action: drop
sourceLabels: [__name__]
# these metrics generates duplicates
# https://github.com/kubernetes/kube-state-metrics/issues/2405
regex: kube_horizontalpodautoscaler_status_target_metric|kube_horizontalpodautoscaler_spec_target_metric
Could be related to https://github.com/kubernetes/kube-state-metrics/issues/2408
/assign /triage accepted
Has anyone been able to find a work around other then dropping the label?
@dgrisonnet do you know if the fix for #2408 will fix this as well or if that was specific to the kube_endpoint_address metric?
What happened: Upgraded to prometheus 2.52 which now is more strict about duplicates: https://github.com/prometheus/prometheus/issues/14089 (similar to https://github.com/kubernetes/kube-state-metrics/issues/2390 )
Have an HPA that looks like this:
and this causes KSM to attempt to produce duplicate metrics because it expects the metric name to be unique across target metrics which is not true (the selectors does that).
debug logs from prometheus:
and this causes the standard mixin alert
PrometheusDuplicateTimestamps
to continuously trigger.What you expected to happen:
No duplicate metrics. I'm guessing the temporary solution is to
drop
action onkube_horizontalpodautoscaler_status_target_metric|kube_horizontalpodautoscaler_spec_target_metric
, but figured it might be worth raising an issue here for others.How to reproduce it (as minimally and precisely as possible):
An HPA like above, and some way to use external metrics in HPAs (prometheus-adapter or keda I guess) and I expectdefault kube-state-metrics scraping of hpa metrics.
Anything else we need to know?:
Environment: