Over the past few months a few of you have noticed this message in your inbox ("Could not automatically scale xxx because monitoring data was not found"). I would like to provide some additional details about exactly what is happening here.
As you know Autoscale requires monitoring data to be collected from your VM/role instances in order to scale. However, there can be times when there is not any monitoring data available. Two common causes of this are a problem inside the role instance that prevents it from writing out data (e.g. it is recycling), or, throttling or a network issue on the storage accounts that contain your monitoring data. If either of these happen then autoscale will (temporality) be unable to calculate how many instances you should have. As soon as the roles or storage accounts are healthy again, autoscale will automatically resume as it was before. There is not explicit action that you or support can take to bring autoscale back.
However, when we initially designed Autoscale for Azure, we were aware that occasionally metrics would be unavailable, so we have built safeguards in place to keep your service up in this scenario. These safeguards are based on the "default" instance count, which you may have seen in our API contract. The default instance count is the number of instances that you had before you turned on autoscale. In case autoscale cannot find data to scale by, we will automatically scale you up to your default count. As a result, you should never have to arbitrarily adjust the minimum instance count to deal with a metric outage.
If you currently have more instances than the default, and metrics are unavailable, then we will not scale you down, as your service actually needed those additional instances when metrics went off.
These behaviors ensure that even if there is no data available, Autoscale will never cause your service to perform worse than it did before you turned on autoscale.
The primary scenarios that is problematic when metrics are not being reported is you may see an atypical spike in usage that you never were prepared for before. At this point, you'll need to observe your service and manually increase instance count, since autoscale cannot do it on your behalf. This is why we send the email you're seeing, so that you can be aware of the issue, and if your load does spike, you can be ready to manually adjust instance count.
In summary, it should be extremely rare that you every see this issue, but if there is a storage outage (as there was this week), then you'll see this show up in your inbox. I hope the above details help you to understand what is going on.