I have a Web site deployed on Azure Web App. My web site gets very slow at times. This behavior is random.
On checking IIS Logs during the period of slowness, I found few requests coming in where the Client IP Address is blank (It shows "-").
The response time of these requests runs into minutes and finally they result into HTTP 500 error. This happens only for the requests where c-ip is blank.
All other requests that have a Client-IP address are processed successfully. But because of the bad requests my application becomes very slow. I have to restart my Web App to resolve this issue.
What could be the possible reason behind these requests having a blank Client IP Address ? Could this be a malicious attack on the web site ?
Difficult to say. Could you add Application Insights service to your project? It allows you to see what is going on before and after 5 minutes of "this" request. The second reason can be the mode of your Azure Web App - is it free or shared or standard?
After AI added, you could share some more insights, because it is important to know what is that request about, not just the fact that it was processed.
https://azure.microsoft.com/en-us/documentation/articles/app-insights-start-monitoring-app-health-usage/
Related
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.
I have ASP.NET Core Web API deployed as App Service on Azure. App Service is set up to require Client Certificate. Also AlwaysOn for App Service is set to True.
Issue is that first request with small payload sent to Web API takes approximately 2-3 seconds, and with large payload timed out. But after first small successful request, next one with large payload executes in less than a second. After some period of inactivity the issue occurs again, and first request to Web API again either takes time or timed out.
When Require Incoming Certificate is disabled, no issues with first request execution time, it executes quite fast always.
Web apps are unloaded if they are idle for a set period of time.
Quoted from official docs:
The downside is that the response to the first request after the web app is unloaded is longer, to allow the web app to load and start serving responses.
If you're using a Basic and Standard service plan, you can turn on the Always On setting to keep the app always loaded:
In the Azure portal, go to your web app.
Select Application settings.
For Always On, select On.
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.
Is there a way to know when/if the whole website was down? And even better, the reason that it was down. I don't have access to the servers, only have access to Kentico admin with global admin privileges. Thanks!
Down as in the user trying to visit the site is getting a 503 Error?
If it goes down because of an error in Kentico, you would be able to check the event log, but if it is a server error you would need to check the server event logs.
There are a bunch of services online that will notify you when your site isn't responding like Uptimer Robot
One of the options is integrate your Kentico App with Azure Application Insights.
You can configure
.Net Performance monitoring via usage analytics (server
resources like http response time)
Status monitor to diagnose IIS
issues on live running web sites (without re-deploying)
Usage
analytics for pages of the website (client side like Google
Analytics)
Automated stress testing System availability and health
monitoring (think uptime / downtime tracking)
Crash reporting for
apps and devices
http://www.mcbeev.com/Blog/April-2016/Application-Insights-for-Kentico
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