feat(metrics-api): add zeroOnMissingEndpoints option for aggregated endpoint scaling

[proudier]

When aggregateFromKubeServiceEndpoints is true and the target Service has no ready endpoints, the scaler currently returns an error. With zeroOnMissingEndpoints: "true", the scaler returns a metric value of 0 instead, allowing the ScaledObject to evaluate normally. This option is only valid when aggregateFromKubeServiceEndpoints is true; setting it without that flag is rejected at parse time.

See issue #7651 for details.

Checklist

• When introducing a new scaler, I agree with the scaling governance policy
• I have verified that my change is according to the deprecations & breaking changes policy
• Tests have been added (if applicable)
• Ensure make generate-scalers-schema has been run to update any outdated generated files
• Changelog has been updated and is aligned with our changelog requirements, only when the change impacts end users
• A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
• A PR is opened to update the documentation on (repo) (if applicable)
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

Relates to #7651

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[github-actions]

Thank you for your contribution! 🙏

Please understand that we will do our best to review your PR and give you feedback as soon as possible, but please bear with us if it takes a little longer as expected.

While you are waiting, make sure to:

• Add an entry in our changelog in alphabetical order and link related issue
• Update the documentation, if needed
• Add unit & e2e tests for your changes
• GitHub checks are passing
• Is the DCO check failing? Here is how you can fix DCO issues

Once the initial tests are successful, a KEDA member will ensure that the e2e tests are run. Once the e2e tests have been successfully completed, the PR may be merged at a later date. Please be patient.

Learn more about our contribution guide.

[rickbrouwer]

We currently see the so-called IgnoreNullValues ​​on a number of scalers.
Personally, I am in favor of keeping things consistent in terms of naming conventions, because that helps with interpretation.

I see that you only accept this value when using aggregateFromKubeServiceEndpoints. I am wondering aloud to myself whether this needs to be specific to this value, or if it could also be applied generally to this scaler to potentially cover other use cases as well. Do you happen to know why it is better to do this specifically on that field and not?

[proudier]

We currently see the so-called IgnoreNullValues ​​on a number of scalers. Personally, I am in favor of keeping things consistent in terms of naming conventions, because that helps with interpretation.

I studied the Prometheus scaler before implementing this and looked at ignoreNullValues (I agree, consistency is important). I suggest a different setting because it captures a different failure mode:

• ignoreNullValues: true is for when the data returned is invalid or metric is missing (data-level errors). An error will still be emitted if the scaler can't connect to the PromQL endpoints.
• zeroOnMissingEndpoints: true is for when no endpoints are available ("network-level" errors). An error will still be emitted if the endpoints return malformed data or the value is missing.

What do you think? Should we favor reusing the same names even if the semantic is different?

I see that you only accept this value when using aggregateFromKubeServiceEndpoints. I am wondering aloud to myself whether this needs to be specific to this value, or if it could also be applied generally to this scaler to potentially cover other use cases as well. Do you happen to know why it is better to do this specifically on that field and not?

The aggregateFromKubeServiceEndpoints setting gates the code path where zeroOnMissingEndpoints is evaluated. I added the check in NewMetricsAPIScaler so the user is alerted early the current configuration will probably not yield the expected behavior.

But taking a step back, I think you're bringing a good point: I could capture some error cases down the getMetricValueFromURL code path that match the definition of zeroOnMissingEndpoints we'd agree on above.

[rickbrouwer]

WDYT @kedacore/keda-core-contributors @kedacore/keda-core-maintainers