I have an application gateway running with a web application in a App service plan. The application gateway listens and passes requests to the backend, which is the web app. There is a health probe implemented that works fine.
The web app was reachable fine until I scaled up the Service plan. Suddenly the health probe timed out reaching the backend and I got a 502 bad gateway error in the browser trying to reach the web application. After hours the website suddenly was back and the backend was healthy again. I was under the impression that you could scale up and down the App plan without any noticeable effect on the website, but it seems the gateway was not playing along.
Did I configure something wrong or should this work like I assumed?
I tried to reproduce the same in environment create app service running with application gateway and got a 502 error.
The number of TCP connections allowed by the plan standard while is an older it contains the double make sure while scaling up and down in app service try to remain in same tier so that inbound IP will wait for sometimes and then scale back.
Try to update your default setting in configuration ->General setting-> ARR Affinity Off. Either your application isn't stateful, or the session state is kept on a distant service like a cache or database. And try to Run your application with a minimum of 2-3 instances to prevent from failure.
You can make use of app service diagnostics gives you the right information to more easily
For Reference:
Get started with autoscale in Azure - Azure Monitor| Microsoft
Guide to Running Healthy Apps - Azure App Service
And I got the same error in application gateway as well to avoid the issue
In your virtual network -> service endpoint -> Add endpoint Microsoft.web in default subnet
.
Related
I have an Azure App Gateway connected to 3 different App Service apps all running as part of the same App Service Plan (3 different back-end pools). In the Backend Health section of the AG, one of the app/pool is constantly flipping between Healthy and Unknown states. I have checked the entire network configuration according to this article and everything seems to be configured properly.
I have configured ip restrictions on the app services according to this article specifying the subnet the AG resides in as allowed. I have also temporarily allowed my ip address and every time the health for the 1 app goes to "unknown", I am still able to access the app service using its native .azurewebsites.net url locally on my machine.
Any ideas how I can troubleshoot this?
Please check if below points help to work around the issue.
As a workaround initially,try to restart the application gateway after the backend is deployed .
Also check this discussion on github issue
Sometimes Appgateway will cache the response indefinitely and the fix
maybe "Dynamic DNS" which ensures that the "no existing domain" is not
cached on the Appgw.Also check for the fix using v16.
Also check this > similar issue which says to use custom domain names as the request looks for some domain.
We have an Azure Front Door resource configured with a single backend pool and a health probe to the backend. The backend is a web API running in App Service. The App Service resource is configured with a custom domain. The Front Door health metrics show drastically different results when configuring the backend with the custom domain vs. the one provided by App Service.
We originally configured the backend with the hostname provided by App Service (xxx.azurewebsites.net). The metrics in Front Door showed a very low, very inconsistent success rate for backend health. Then, we tried configuring the backend using the custom hostname we use in the App Service resource, and all of a sudden the health metrics are at 100%.
In the following image, you can see the point where we configured the backend with the custom hostname. The average health shoots up to 100%.
I would expect the Front Door health metrics to be the same (at or near 100%) regardless of the hostname used to configure the backend.
I have 1 Webapp running under same App service plan. As I am using a premium Azure app service plan with 15 instances, We are consuming only 10 percent of CPU. So to increase more availability and responsiveness of our app, I was planning to deploy one more instance of same app with a different name under same App service plan.
So now I am running my-app and my-app01 under 1 app service plan. Now I want to distibute the incoming traffic between this 2 apps.
As this app's are running under on app service, they are running on same location. So Azure Traffic manager doesn't allow the endpoints from same location. To by pass this I have used Traffic manager nested nedpoint to list my both app endpoints under one traffic manager.
then I have added my custom domain name to traffic manager as a CNAME record mapping.
myapp.abhisqs.com -> abhisq.trafficmanager.net -> (my-app.azurewebsites.net , my-app01.azurewebsites.net)
After doing this I am not able to open my app by hitting https://myapp.abhisqs.com/pages/default.aspx from Url, it was throwing 403 error. So I added a hostname(myapp.abhisqs.com) and SSL binding for my-app. Then I was able to open my app by using the https://myapp.abhisqs.com/pages/default.aspx.
So Now my other app instance my-app01 doesn't have a Hostname and SSL binding, So if my primary app (my-app) is off, then I am not able to open the app UI ( fails with error 403). Also from Azure portal I am not able to add host name and SSL binding to my second app which is running under same app service plan. It throws error "the host name 'myapp.abhisqs.com' is alredy configured for my-app so first remove that then configure with this."
So my question is what is best way to have multiple apps under same service plan, load balanced under one single custom domain name.
I am trying to setup IP Based SSL instead of SNI SSL on an azure Web App.
The App Service Plan is Standard S1, but unfortunately I am getting the following error message:
There are no IP addresses in the App Service Environment that are available to be assigned to your app.
What are the possible options?
I believe moving the current Web App to a different App Service Plan in a different resource group would solve this issue. I Have already tried moving the App service plan to a different resource group but failed.
Note: Clicking the scale up button doesn't work and shows a JavaScript error in the console
JavaScript Error found in Chrome console
Byron is correct that this is a bug in the UX.
A fix has been made and should be live later today.
Your app is being hosted in an App Service Environment.
Looks like the scale up bottom is not working and that is probably a bug in the UX.
As a workaround you should be able to go directly to the App Service Environment that is hosting your app and perform the scale operation there.
once the scale operation in the App Service environment is done and the new IP Address is added, then you should be able to come back to the SSL binging UX in the app and try this again.
If I deploy a web app (formerly known as an Azure WebSite) to an App Hosting Plan in Azure with a couple of instances (scale = 2) will the load balancer in front of the instances care if any of the instances is unhealthy?
I'm troubleshooting an issue that sometimes causes my site to return an http 503 ~50% of the time. My thinking here is that one of two of my instances has failed but the load balancer hasn't noticed.
If the load balancer does care, what does it look for? I can't find anyway to specify a ping url, for instance.
Note: this question has nothing to do with Traffic Manager.
Yes, Azure Web Apps monitors the health of the workers by making internal requests to it and verifying that they're healthy.
However, we don't check status codes that the web app returns to user requests (like 500, etc) since that could easily be an app specific issue rather than a problem with the machine.
So the answer you're looking for is: We continuously test whether or not the instances (VMs) are healthy and take them down if they're not. However, those tests do not rely on error codes the customer's site returns