Service Bus Queue Request retrieving 0 messages when queque have messages

[Xavgra]

Describe the bug
Using the adapter to scale a service in AKS to scale a service in the basis of the total number queque's messages.
I've found that in some cases the Azure API is returning a 0 instead of the right number of messages. The API returns the right value and a 0 alternatively.

To Reproduce
After creating a queque and having added some messages, deploy the external metric image in AKS and check the results on the pod's log.

After requesting the Azure API, the error happens when you make a request to the API in the very few seconds of minute apparently.

Got a wrong result (minute 32)

A few minutes after we get the right value (minute 32)

Expected behavior
The api should return the real number of messages in the queque

Kubernetes version (kubectl version):
Running on AKS

Logs (kubectl logs <metric adapter pod id>)
externalmetrics.log

Additional context

[rmyourself]

We have the same issue. Can any body helps?

[eugen-nw]

This behavior is quite lame as it does confuse scale-out solutions that are based on the count of messages in the queue. Could someone please fix this?

[jinzishanshan]

We have the same issue.Recent days, this issue happened frequently and make the hpa somewhat abnormal. Anyone can help this?

[jsturtevant]

This is related to the fact we are using the Azure Monitor API to get the results and we are dependent on what they return from the API. There are other issues with latency in regards to using Azure Monitor API as well.

We started to add direct connections the services in #59 but work has been redirect to Keda as it has support for many more types of scalers including directly connection to Service Bus and has been moved into the CNCF.

Please checkout KEDA which should resolve this issue. The core concepts are the same.

[eugen-nw]

Regretfully, switching to KEDA is not an option for us at the moment as there is no budget to invest in this work. As such it would be much appreciated if the metric would be able to switch to monitoring the Message Queue directly, just as Service Bus Explorer does. The actual results will be also retrieved much quicker than they are now.