-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
feat: Add new hpa metrics to prevent prometheus timeseries duplication #2614
base: main
Are you sure you want to change the base?
Conversation
…MetricSource and add tests
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: CountryTk The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Welcome @CountryTk! |
/triage accepted |
Hey, could this please be reviewed @CatherineF-dev @rexagod |
Ok! In reviewing |
targetMetricLabels = []string{"metric_name", "metric_target_type"} | ||
targetMetricLabels = []string{"metric_name", "metric_target_type"} | ||
containerMetricLabels = []string{"metric_name", "metric_target_type", "container"} | ||
objectMetricLabels = []string{"metric_name", "metric_target_type", "full_target_name"} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: full_target_name -> target_name, container -> container_name
) | ||
} | ||
|
||
func createHPASpecTargetMetric() generator.FamilyGenerator { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Unify createHPASpecTargetMetric and createHPASpecTargetObjectMetric. These two functions have some similar codes.
For example
- createHPASpecTargetMetric(CollectContainerResourceMetricSourceType=false)
- createHPASpecTargetMetric(CollectContainerResourceMetricSourceType=true)
Overall LGTM. Two small comments. |
Thanks for the review, I've implemented your suggestions @CatherineF-dev |
createHPASpecTargetContainerMetric(), | ||
createHPAStatusTargetContainerMetric(), | ||
createHPAStatusTargetObjectMetric(), | ||
createHPASpecTargetMetric(true), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit:
createHPASpecTargetObjectMetric()
createHPASpecTargetMetric()
func createHPASpecTargetObjectMetric() {
createHPASpecTarget([]{autoscaling.ObjectMetricSourceType})
}
func createHPASpecTargetMetric() {
createHPASpecTarget([]{autoscaling.PodsMetricSourceType, autoscaling.ResourceMetricSourceType, ...})
}
func createHPASpecTarget(autoscalingTypes) {
if m.Type not in autoscalingTypes {
return
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made some adjustments according to how I understood this comment, not 100% sure if I did it as you wish though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, @CatherineF-dev could you take a look if the changes requested are what you desired? Thank you
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM. Left a small comment on some metrics are removed.
Thank you for the patch. I believe this identifies a resource-agnostic pitfall where we loop over certain nested fields without including a primary key in the overall generated metrics' label-sets. I'll take a closer look tomorrow but so far this lgtm. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question, wouldn't the earlier kube_horizontalpodautoscaler_spec_target_metric
still be there after this is in, and cause the error to still show up?
Could you help enable I want to make a small change. Or could you apply these small changes? 96d948a |
![]() For me it shows maintainer edit access is enabled. Anyway, I've added your suggested changes in the latest commit.
Nope because
|
kube_horizontalpodautoscaler_spec_target_metric{horizontalpodautoscaler="hpa1",metric_name="events",metric_target_type="average",namespace="ns1"} 30 | ||
kube_horizontalpodautoscaler_spec_target_metric{horizontalpodautoscaler="hpa1",metric_name="hits",metric_target_type="average",namespace="ns1"} 12 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These metrics are deleted. Could you double check?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
metric name "hits" and some others are now under their respective metric
hits
is now under kube_horizontalpodautoscaler_spec_target_object_metric
instead of kube_horizontalpodautoscaler_spec_target_metric
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems a breaking change. Could we keep kube_horizontalpodautoscaler_spec_target_metric not changed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it is a breaking change but I was under the impression that it's fine since these metrics are experimental.
#2403 (comment)
I like the second option since the metric is still experimental so we can make changes to it. It will surely break some users but we didn't provide guarantees for this metrics. So as long as we make a smooth transition it should be fine.
The benefit of this approach is that the metrics will be specialized to the metric type they are targeting, so the labels will make sense for it and we won't run in scenarios where we have labels that are not used by some types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
kube_horizontalpodautoscaler_spec_target_object_metric{target_name="",horizontalpodautoscaler="hpa1",metric_name="hits",metric_target_type="average",namespace="ns1"} 12
@dgrisonnet I'm not sure if this is what you meant, can you PTAL?
What this PR does / why we need it:
Added 4 new hpa metrics to prevent duplicated timeseries events like described in this issue: #2403
Added new metrics are:
How does this change affect the cardinality of KSM: (increases, decreases or does not change cardinality)
Cardinality is increased because of new metrics
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes # #2403
FYI: I've also tested this change in our prelive cluster and for us it fixed the issue