Skip to content
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

Add support for the "Value" metric type in addition to "AverageValue" #2030

Closed
amirschw opened this issue Aug 12, 2021 · 12 comments · Fixed by #2309
Closed

Add support for the "Value" metric type in addition to "AverageValue" #2030

amirschw opened this issue Aug 12, 2021 · 12 comments · Fixed by #2309
Labels
feature-request All issues for new features that have not been committed to needs-discussion stale-bot-ignore All issues that should not be automatically closed by our stale bot

Comments

@amirschw
Copy link
Contributor

amirschw commented Aug 12, 2021

Proposal

Except for the CPU and memory scalers, all scalers, including the external scaler, only support the averageValue metric type. The proposal is to allow for other metric types (specifically value).

Edit: Apparently, Utilization is not supported for external metrics, so the proposal is only to support the Value metric type in addition to AverageValue.

Use-Case

There are already a few related issues with some use cases:

Our use case is the following. We currently use the Azure Service Bus scaler for scaling one of our workloads. We would like to add another trigger (with an external scaler) that will scale the deployment based on the latency of the queue workers or the average dequeue delta. For this we need the absolute metric value in milliseconds and not the average value across all pods (e.g. we want to scale out when average latency is greater than 500ms).

Anything else?

The CPU and memory scalers already support different metric types by setting a required type in the scaled object metadata:

if val, ok := config.TriggerMetadata["type"]; ok && val != "" {
meta.Type = v2beta2.MetricTargetType(val)
} else {
return nil, fmt.Errorf("no type given")
}
var value string
var ok bool
if value, ok = config.TriggerMetadata["value"]; !ok || value == "" {
return nil, fmt.Errorf("no value given")
}
switch meta.Type {
case v2beta2.ValueMetricType:
valueQuantity := resource.MustParse(value)
meta.Value = &valueQuantity
case v2beta2.AverageValueMetricType:
averageValueQuantity := resource.MustParse(value)
meta.AverageValue = &averageValueQuantity
case v2beta2.UtilizationMetricType:
valueNum, err := strconv.ParseInt(value, 10, 32)
if err != nil {
return nil, err
}
utilizationNum := int32(valueNum)
meta.AverageUtilization = &utilizationNum
default:
return nil, fmt.Errorf("unsupport type")

If we want to make this more generic, another approach can be to add the metric type to the trigger spec. Something like the below for example. The default metric type can be averageValue for maintaining backward compatibility.

triggers:
  - type: external
    metricType: value
    metadata:
      scalerAddress: external-scaler-service:8080
      ... # more metadata

After we discuss and agree on the approach we will be happy to contribute this.

@amirschw amirschw added feature-request All issues for new features that have not been committed to needs-discussion labels Aug 12, 2021
@zroubalik
Copy link
Member

zroubalik commented Aug 18, 2021

Thanks for raising this issue 🎉

This is generally useful feature, I have a few remarks:

  • we need to be sure that mixing different types of metricType in one ScaledObject works correctly - ie. define multiple triggers with different metricType. I am not sure how HPA handles that, we should investigate, most probably it won't be a problem
  • we need to be sure that this works correctly with ScaledJob, as it is not using MetricServer and HPA for scaling, related: ScaledJob: introduce MultipleScalersCalculation #2016
  • this should come with a solid documentation, we should explain different metricTypes with examples and consequencies on scaling
  • I concur we should make it more generic, ie. adding this to triggers spec is probably the right place

Do you think that you can join our community call and discuss this feature there? Details: https://keda.sh/community/

@amirschw
Copy link
Contributor Author

Thank you @zroubalik for responding and for the good remarks! I will be happy to join the next community call to discuss this. Should I just hop on the call or sign myself up somewhere?

@zroubalik
Copy link
Member

Great, no need to sign anywhere. The call is open for everyone :)

@sqerison
Copy link

sqerison commented Sep 6, 2021

Hey guys. I am also looking forward to seeing this feature released. So +1

@fbalicchia
Copy link
Contributor

fbalicchia commented Sep 6, 2021

Hi @amirschw , I don't know if you start to implements feature. In the meantime I've written POC for my case
extending Scaler interface proving an enum, adding a utils to set default check and sanitize input.
this is little bit different approach to add a spec
https://github.com/fbalicchia/keda/commit/d20b88615610bc1158d47a463c1f796fbbfa3f88

Tell me how do you want go head, when you finish I will happy to test it
Thanks

@amirschw
Copy link
Contributor Author

Hey @fbalicchia, thanks for sharing your POC and apologies for the delay, I just got back from a long vacation (Jewish holidays... 😄). I should hopefully have time to get back to this soon.

@amirschw
Copy link
Contributor Author

Just got back to this issue now. I hope to have at least a draft PR by tomorrow.

@amirschw
Copy link
Contributor Author

@zroubalik, @sqerison, @fbalicchia, here's the PR: #2309.

@amirschw amirschw changed the title Support for different metric types Add support for the "Value" metric type in addition to "AverageValue" Nov 21, 2021
@stale
Copy link

stale bot commented Jan 20, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale All issues that are marked as stale due to inactivity label Jan 20, 2022
@stale
Copy link

stale bot commented Jan 27, 2022

This issue has been automatically closed due to inactivity.

@stale stale bot closed this as completed Jan 27, 2022
@zroubalik zroubalik added the stale-bot-ignore All issues that should not be automatically closed by our stale bot label Jan 27, 2022
@zroubalik zroubalik reopened this Jan 27, 2022
@stale stale bot removed the stale All issues that are marked as stale due to inactivity label Jan 27, 2022
@Punkoivan
Copy link

Hello folks!
Took a look at related PR. Once you make it, I'll be happy to test it :)

Currently searching for a way to use value instead of averageValue for Prometheus trigger.
Hope I'm looking into correct issue.

Thanks a lot for your work, you folks definitely make our lives easier.

@denzhel
Copy link

denzhel commented Mar 11, 2022

Hello folks! Took a look at related PR. Once you make it, I'll be happy to test it :)

Currently searching for a way to use value instead of averageValue for Prometheus trigger. Hope I'm looking into correct issue.

Thanks a lot for your work, you folks definitely make our lives easier.

Same here, would be happy to test it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request All issues for new features that have not been committed to needs-discussion stale-bot-ignore All issues that should not be automatically closed by our stale bot
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

6 participants