Expose prometheus metrics at ScaledJob like ScaledObject

[yoongon]

Provide a description of what has been changed
Expose prometheus metrics at ScaledJob like ScaledObject
Refer to : #4798

Checklist

• I have verified that my change is according to the deprecations & breaking changes policy
• Changelog has been updated and is aligned with our changelog requirements
• A PR is opened to update the documentation on (repo) (if applicable)
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

Fixes #
#4798

Relates to #

[github-actions]

Thank you for your contribution! 🙏 We will review your PR as soon as possible.

🏖️ Over the summer, the response time will be longer than usual due to maintainers taking time off so please bear with us.

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

Learn more about:

• Our contribution guide

[JorTurFer]

Thanks for the contribution!

As the goal is adding new metrics, we should create new counters here for them and update those counters instead of reusing already existing counters for ScaledObjects. Otherwise, It could be confusing

[yoongon]

Thanks for the feedback. I will update the code again.

[yoongon]

Thanks for the contribution!

As the goal is adding new metrics, we should create new counters here for them and update those counters instead of reusing already existing counters for ScaledObjects. Otherwise, It could be confusing

@JorTurFer
=> I updated the code with new counters for ScaledJob. Could you check again? Thanks.

[JorTurFer]

We can't rename the already existing metrics because that's a breaking change and our deprecation policy requires 2 version between deprecation and removal.
I'm thinking in 2 different option for this:

• Use a new label to inform if it's ScaledObject or ScaledJobs on metrics where the name isn't clear, such as 'keda_scaler_active' or keda_scaler_metrics_value, and duplicating the metrics with clear name, for example keda_scaled_object_errors with keda_scaled_job_errors
• Duplicate all the metrics for the ScaledJobs

In both cases, we should maintain current metrics, but I'm not sure about which is the best approach for new metrics, I don't have any strong opinion but personally I prefer the labels option. WDYT @kedacore/keda-core-contributors ?

In any case, we have to add e2e test coverage to these metrics: https://github.com/kedacore/keda/blob/main/tests/sequential/prometheus_metrics/prometheus_metrics_test.go

[JorTurFer]

This metrics isn't needed. The ScaledJob doesn't generate an HPA

[yoongon]

We can't rename the already existing metrics because that's a breaking change and our deprecation policy requires 2 version between deprecation and removal. I'm thinking in 2 different option for this:

• Use a new label to inform if it's ScaledObject or ScaledJobs on metrics where the name isn't clear, such as 'keda_scaler_active' or keda_scaler_metrics_value, and duplicating the metrics with clear name, for example keda_scaled_object_errors with keda_scaled_job_errors
• Duplicate all the metrics for the ScaledJobs

In both cases, we should maintain current metrics, but I'm not sure about which is the best approach for new metrics, I don't have any strong opinion but personally I prefer the labels option. WDYT @kedacore/keda-core-contributors ?

In any case, we have to add e2e test coverage to these metrics: https://github.com/kedacore/keda/blob/main/tests/sequential/prometheus_metrics/prometheus_metrics_test.go

You are right. I should have taken a look, because It conflicts with document(https://keda.sh/docs/2.11/operate/prometheus/).
.Thanks for the catch. I will take a look at better solution.

[yoongon]

• Use a new label to inform if it's ScaledObject or ScaledJobs on metrics where the name isn't clear, such as 'keda_scaler_active' or keda_scaler_metrics_value, and duplicating the metrics with clear name, for example keda_scaled_object_errors with keda_scaled_job_errors

@JorTurFer
I have a question for the above comment. Are you suggesting these steps?

1. Preserve existing metrics such as **keda_scaler_metrics_value** for ScaledObject
2. Creating new metrics like **keda_scaler_scaled_object_metrics_value**  and **keda_scaler_scaled_jobe_metrics_value**
3. Deprecate **keda_scaler_metrics_value**  in the future.

Do I understand right?

[JorTurFer]

I have a question for the above comment. Are you suggesting these steps?

1. Preserve existing metrics such as **keda_scaler_metrics_value** for ScaledObject
2. Creating new metrics like **keda_scaler_scaled_object_metrics_value**  and **keda_scaler_scaled_jobe_metrics_value**
3. Deprecate **keda_scaler_metrics_value**  in the future.

Do I understand right?

Sorry for the slow response (the summer break xD)

No, I meant that metrics like keda_scaler_metrics_value (which doesn't say anything related with ScaledObject) can be extended using labels for adding the extra information about if it's from ScaledObject or ScaledJob, duplicate them it's not necessary.

For labels whose have scaledobject in the naming such us keda_scaled_object_errors, we can duplicate the for scaledjobs , for example keda_scaled_object_errors and keda_scaled_job_errors. Or maybe unifying both in something like keda_scalable_object_errors, using labels to clarify if the metric is for so or sj.

For example, this metric is the same for both, splitting them based on type a label: https://github.com/kedacore/keda/blob/main/pkg/prommetrics/prommetrics.go#L124-L132

[yoongon]

@JorTurFer
Thanks for the feedback. It becomes much clear for me.
I updated. PLTAL.
Thanks!

[semgrep-app]

Semgrep found 8 third-party-action-not-pinned-to-commit-sha findings:

• .github/workflows/pr-e2e.yml: L209, L191, L118, L75
• .github/workflows/pr-e2e-creator.yml: L26, L17
• .github/workflows/pr-e2e-checker.yml: L26, L17

An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.

_{Ignore this finding from third-party-action-not-pinned-to-commit-sha.}

[yoongon]

Using GitHub sync break the changes.
I close this one and will file a new PR.

[yoongon]

I opened a new PR here.
#4913