You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@MrsDaehin and I are working on #4411 but we have noticed that there isn't any metric
(in the operator) that we can use for measuring how KEDA is performing in terms of response time.
As the majority of the work (during the normal operation) is done here:
I think that we can add a metric with the difference between the calculated time for next execution (now + pollingInterval) and the real execution time. If the time is close to 0 it means that we are fine, but if the new loop starting is too much later than the expected, we aren't executing the control loop on the expected time, which probably is because the CPU is overloaded
Use-Case
This metric can give as a measure about how the load is impacting in the scalable object processing loop measuing the time between loops
Is this a feature you are interested in implementing yourself?
Yes
Anything else?
No response
The text was updated successfully, but these errors were encountered:
JorTurFer
changed the title
Add a Promethean metric for measuring the scalable object loop processing deviation
Add a Prometheus metric for measuring the scalable object loop processing deviation
Jun 16, 2023
Proposal
@MrsDaehin and I are working on #4411 but we have noticed that there isn't any metric
(in the operator) that we can use for measuring how KEDA is performing in terms of response time.
As the majority of the work (during the normal operation) is done here:
keda/pkg/scaling/scale_handler.go
Lines 164 to 181 in bce3375
I think that we can add a metric with the difference between the calculated time for next execution (now + pollingInterval) and the real execution time. If the time is close to 0 it means that we are fine, but if the new loop starting is too much later than the expected, we aren't executing the control loop on the expected time, which probably is because the CPU is overloaded
Use-Case
This metric can give as a measure about how the load is impacting in the scalable object processing loop measuing the time between loops
Is this a feature you are interested in implementing yourself?
Yes
Anything else?
No response
The text was updated successfully, but these errors were encountered: