Azure App Service instances can be unloaded after 20min of inactivity, but does anyone know how this is impacted by health checks? In particular, does enabling health check to prevent the application of being unloaded? If so, does that lead to increased costs?
Enabling Health Check will keep the application alive as they continuously ping the health check endpoint in a specific time.
However a better way to keep the application alive is by using the setting AlwaysOn within Azure App Service settings.
Regarding the cost, the App Service are always billed even if they are inactive. Once provisioned, the meter will keep ticking and active/inactive web app will not have any impact on costs whatsoever.
Related
Health Check can restart an instance. Auto-Heal also can restart an instance.
So, when should I use Health Check and when should I use Auto-Heal. Should I use them both together?
The Health Check feature is pretty basic compared to Auto-Heal. Basically it makes a request to a predefined url and if it does not get a succesful response it will take that instance out of the load balancer pool. If it remain unhealthy it will be replaces with a new instance. It works only if scale-out is applied to the web app.
Auto-Heal is much more sophisticated: instead of pinging a url it can be configured to restart an instance when a certain memory or cpu usage limit is reached, or when the response time is degraded during a certain period.
We have a problem with an application hosted on Azure App Service Plan version P3V2. Depending on the traffic in our system, the App Service Plan is scaled up to 5 instances. During heavy traffic, one of the application instances stops responding to requests and after a few minutes it is restarted by the Auto Heal functions. We use Application Insights to monitor the application, unfortunately no logs are saved when there is a problem with the operation of this one instance, also in Event Log we do not see any logs that can help us.
Below I am sending a screen from last week showing all the situations when one of the instances stopped responding to requests.
We did not notice any jumps in the memory used in the application as well as the increased processor time.
I would be grateful for any suggestions or tips.
State of the application:
A single virtual machine which runs an apache server.
Application exposed via the virtual machine's public IP (not behind a loadbalancer)
I have an healthprobe endpoint running that needs probed every few seconds to see if the app is up, and trigger an alert in case it is not.
What are my options? I want to get the healthprobe up and running first, before I move to a virtual machine scale set and a load balancer.
You need something like a watchdog that calls the health endpoint at a given interval. In Azure you can use an availability test. You can then create alerts based on this availability and optionally create dashboards that show the status over a given period.
As a bonus you might integrate the application insights resource in your web app to get detailed monitoring. See the docs
Under Support+troubleshooting -> Resource health of your virtual machine portal panel, you can set up a health alert.
You can then select under which conditions the alert should be triggered. In your case, Current resource status: Unavailable should work just fine. You can also implement a custom notification (E-Mail) under Actions or implement a logic that triggers an Azure Function or Logic App that performs an action when the VM is unavailable.
To detect if your application in Apache server is working correctly you can use a monitoring solution that checks the Apache error logs.
If I have one instance of app service is it still recommended to have enabled Health Check (e.g. for monitoring purpose)?
If yes then what about functionality Always On? Doesn't it double requests which at the end do the same thing? I mean to keep application running without idle and check if there are server http errors.
Azure WebApp Always On and Health Check features are used for different use-cases.
Always On setting is used to keep the app always loaded. This eliminates longer load times after the app is idle. With the Always On feature, the front end loadbalancer sends a request to the application root.
Health check setting allows you to monitor the health of your site using Azure Monitor where you can see the site's historical health status and create a new alert rule.
You can disable Always On and just use Health Checks, that will cover both use-cases:
keep application running without idle
monitor the health of your site
Is it possible to use the cloud role (classic) LoadBalancerProbe with HTTPS Health probe to automatically restart a failed role instance?
I understand that this situation should be investigated, but if there's some spontaneous issue and all it needs is a reboot, and nobody is immediately aware of the issue (i.e. after hours or in a crisis), then it could resolve the situation.
Or at worst, can we tell it to move the existing connection to a health instance? Or will that happen when the user hits refresh on their browser?
Service Healing feature should help in this case. It is already provided service in Azure. For both web and worker roles, Azure injects a guest agent into the VM to monitor your role. This guest agent also performs a health check every 15 seconds of the role instance in the virtual machine. Again, if a predefined number of consecutive health check failures or a signal from the load balancer causes a role to become unhealthy and a recovery action to be initiated which is to restart the role instance.
Ref : https://azure.microsoft.com/en-us/blog/service-healing-auto-recovery-of-virtual-machines/