How to resolve 503.0 error in IIS container - iis

I just started using IIS in a container on Azure App Service.
I get 503.0 errors on a windows container (IIS):
HTTP Error 503.0 - Service Unavailable
The service is unavailable.
Most likely causes:
- An invalid identity in the application pool could cause this error.
- The application pool is no longer running because of configuration or reaching application failure limits.
- The concurrent application request limit was reached.
Even after an App Service restart, the problem persists.
So I deleted and then recreated the service app.
I see these errors only on an environment with more load but not on a test env.
Do you have any idea to help me avoid these 503.0 errors?
Is it possible to stop one container among others in App Service?

My problem was ultimately due to out of memory. I increased the memory limit used by each container in the App Service (parameter: WEBSITE_MEMORY_LIMIT_MB).
I did not understand at the beginning why I was receiving the out-of-memory error despite the app service graphs showing use of 40%. This is because the node which hosts the Windows containers already consumes around 50% of the physical memory, but I think it lacks visibility on memory usage with Windows containers.
Support says:
On Azure App Service Windows container we do not have memory analysis detector in Diagnose and solve problems blade.

Related

Azure Container Instance - restarting once in a while for no apparent reason

I have a few different containerized web apps running on Azure Container Instance (ACI). I recently noticed that some of these containers just restart with no apparent reason once in a month or so. Since the restarts are on different apps/containers each time, I have no reason to suspect that the apps are crashing.
The restart policy on all of them are set to "Always".
Is it normal or expected for the containers to restart even when there is no app crash? Perhaps when Azure does maintenance on the host machines or maybe a noisy neighbor on the same host causing a pod movement to another host?
(I am in the process of adding a log analytics workspace so that I can view the logs before the restart. Since the restarts are so infrequent, I wouldn't have any logs to look at for quite some time.)
Same here
I've contacted MS support and got the response that per design ACI maintenance can restart the hosts so it can't be expected to run ACI for weeks uninterrupted
Recommendation is to
adapt your app to be resilient (so you don't care about restarts)
use AKS to gain full control over lifecycle
use VM as host for your app with appropriate policies (no updates / restarts...)
For me this was a deal-breaker since I couldn't find this info anywhere. I've ended up with VM.

How to diagnose AspNetCore application not starting on Azure App Service?

We have multiple AspNetCore applications hosted on an Azure Web App as OutOfProcess and deployed as virtual applications with separate paths.
We have the same setup in different environments, all infrastructure and applications are deployed automatically through our pipeline but it's only breaking in one environment and we can't find out why.
We have tried turning on stdoutLogEnabled to true. This reveals an invalid runtime.config.json error, I have read this can be caused by multiple issues but we can't identify any reason for it. We also intermittently see a 502.5 ANCM startup failure when navigating to the swagger URL for each application.
If we look in the application event logs in the Azure portal we are seeing this error failed to start process with command line 'dotnet .\<DLL>' with multiple retries. Failed to bind to port <PortNumber>
We can start the applications locally with Kudu by navigating to the location of the DLL and running dotnet <DLL>. The application starts successfully so it seems to be a problem on the web app. We've tried restarting and stopping and starting the web app, even tried scaling the app service to attempt getting a clean start but nothing has succeeded.
I'm not sure what other steps we can take to diagnose this issue or what we might have done wrong as the same applications are working fine in other environments.

My application successfully deployed in Azure but I can't hit the URL

Deployment succesful in Azure but when I click on my URL I get an a 503 error?
This is a Linux OS Web app (App is Node/React) I think it might have something to do with the low CPU resources as I am on the free plan in Azure?
When you browse to the app, it returns a HTTP "502 Bad Gateway" error or a HTTP "503 Service Unavailable" error.
This problem is often caused by application level issues, such as:
requests taking a long time
application using high memory/CPU
application crashing due to an exception.
Troubleshooting steps to solve "502 bad gateway" and "503 service unavailable" errors
Troubleshooting can be divided into three distinct tasks, in sequential order:
Observe and monitor application behavior
Collect data
Mitigate the issue
I would suggest you to go through these troubleshooting steps, it will help finding the right error.

Azure web app is 503 Service Unavailable. How do I get it back running?

Our website has been hosted on Azure for a few years. Tonight it is throwing 503 Service unavailable errors. I cannot even load a url to a .jpg file. I have restarted the app and still nothing loads from the website. I cannot buy Azure support because I have bought and cancelled Azure support in the past. We are a 3 person business and depend on our small website and it is down and I don't know what to do. None of the trace logs make any sense to me.
I think 503 could mean that you reached a quota and Azure now respond with a 503 for requests. So I would check the Quotas section within your App Service Plan.
Also check:
Troubleshoot HTTP errors of "502 bad gateway" and "503 service unavailable" in Azure App Service
There are several things you can do to help remedy the situation.
Restart the application (please indicate what it is that will help
us)
Restart the instance that the application is running on.
Restore from a previous working backup of the site.
You should also add more information to your post so we can help, like what application you are using e.g. Apache, Nginx ect.
I've also had a similar problem. I had two deployment slots and in the first slot (production) which I had the latest code and in the second slot, I've missed deploying the latest code and configured traffic as 60-40 which gave me hard time finding it.
Once I've set 100% to the production slot it started working.
Just thought to share this in case it could be useful if you come across the same stuff in the future.
For me it was "Path mappings" in "Configuration".
As soon as i added a new Azure Storage Mount, the application broke.
Setting my Storage account -> Networking, to "Enabled from all networks" fixed the issue.
For us it was a result of the remote debugger. Disabling remote debugger and restarting the app service fixed the 503 error. I think one dev was remote-debugging while another was deploying the app and that seems to have caused an issue under the hood of the app service that broke port binding (we were seeing a stack track in logs about failing to bind to port).

HTTP 502 from one instance of an Azure Web App

We suddenly began experiencing HTTP 502 errors (The specified CGI application encountered an error and the server terminated the process) from one of the instances of our web app. I was able to determine this using Kudu's "Support" tab whereby you can drill down to metrics per instance.
After restarting w3wp for the instance everything continued successfully as normal. There were no problems with resource usage (CPU/RAM) and the odd thing is that the 502s were returning instantly. So, requests weren't timing out for the client.
What are the possible steps to investigate why this happened?
Our application logs wouldn't have anything and our web server logs only have the record of these 502 but with no further details.
In our case it seems to have come down to port exhaustion on the app service plan. Read here for more details on the limitations for each of the plans available.

Resources