I have a P1v2 type appservice plan instance.
It runs 3-4 nodejs application services in a containerized environment.
These application services have been completely error free for a whole year, the metrics don't show anything that would overload them, there are no application side errors either.
The appservice plan metrics are also fine.
But lately, once or twice a week I get flooded with alerts because the appservice plan restarts, so all 3-4 appservices too.
And the container startup time is around 3-4 minutes.
And in the meantime the CPU usage increases, plus there are other alerts.
Anyone have any idea what could be the reason for the restarts?
In service health , you will be get notified if there are any planned maintenance or any infrastructure update activities .
To know more information about the app service plan restart i would suggest to open discussion over Microsoft Q&A or to file a support ticket wherein technical support team would help you in troubleshooting the issue from platform end.
You refer the below blog where you can see the sample toasted email notification from Microsoft for a planned maintenance activity.
Related
Is it possible to put app to sleep during night time anymore?
I have the app service setting NOT on "Always On", but this setting is not respected.
The bills used to be twice as much as they are now, because in past they app set itself to sleep. How do I know this? The service hours are now around 730 (that's a full month). Is Azure no more "Pay-As -You-Go?"
Thanks.
#Joonas, There was never an option to put the app to sleep in Azure Web Apps. The only way to ensure that you are not getting billed is to Scale down the corresponding App Service Plan of the web app to FREE tier.
You can configure scale settings based on a specific schedule so that the app service plan can be scaled up.
Always On is a setting used to keep your app up and running at all times. Assume that you have 10 web apps hosted on a server, out of which 8 are your dev or least used sites, while the other 2 are busy sites accessed throughout the day. In such a scenario you don't want the dev sites to be running at all times as they will hold system resources. The Always On feature is handy in such scenarios. You can set Always On to true for the 2 busy sites and false for the other 8 sites.
Check the number of App Service Plans in your subscription and
also their pricing tier. This will help you understand the costs. In
Azure App Service, you get billed for the App Service Plan and not
the Web App.
This image should help you understand App Service Plan
You can get the answer from this official FAQ:
Am I charged for apps while they are in stopped state?
Yes. Rates listed apply to apps in stopped state. Please delete apps that are not in use or update tier to Free to avoid charges.
I am running a .NET Core web application on an Azure App Service (App Service plan is configured to use S1). It is stable.
However, I recently ran an automated test against production and it caused 100s of errors in a few minutes. After this, the App Service became unavailable for a long time.
I know that App Service basically uses IIS and I know that there is a setting in IIS that will shut down an App Service on too many errors in a short time. I am assuming that this is the setting that came into effect for my app.
My question is: How do I prevent Azure from shutting down my App Service, even if many errors happen in a short time?
Investigate the "Always On" setting that can be changed in the Azure Portal under Application settings, General Settings. This value is configured per App.
The UI control will be disabled if your price tier does not support always on. Typically these lower priced levels in the pricing tiers are not used for a production site.
I recently ran an automated test against production and it caused 100s of errors in a few minutes. After this, the App Service became unavailable for a long time.
Firstly, you can enable diagnostic functionality for App Service web app to log information from both the web server and the web application, which will help you troubleshoot the issue.
Secondly, you can try to increase the number of instances that run your app and check if it can mitigate the issue.
Besides, if possible, you can set up staging environment and do automated test on staging environment instead of production environment, which will not cause your production shutting down for long time when you do automated test on staging.
I am not sure whether this problem was correctly diagnosed back in 2017 when I was using a .NET Core WebApp. Maybe it was or maybe it wasn't.
However, I have today in late 2019 on Azure Functions V2 and .NET Core 2.2 recreated the same scenario and provoked 5000 unhandled exceptions in one minute and the Function did not go down because of that.
So anyone finding this question can pretty much rest assured, if they are on Azure Functions V2 or newer - it does not crash just because of the quantity of exceptions like it was the case with default settings in IIS in the past.
I was wondering if someone can shed some lights on the application monitoring and alerting solution that's being used to specifically monitor the Azure app service. We have multiple API apps running on App service service and we would like to monitor certain metrics (ex: Availability, response time, number of request received, etc). I enabled the application insight on each of these apps and the result is quite promising, it fulfills all my requirement, but there's one small issue: I need to scroll through each app to see their performance. I can't aggregate them all in one space. I would like to create a centralized dashboard for all aforementioned metrics and have them displayed. I tried using OMS but it seems to be lacking a lot of functionality.
Any pointer would be very appreciated.
I wrote recently about it on our blog: http://predica.pl/blog/azure-monitoring-and-auditing/ - you will find link to MS documentation also there.
If you are using App Insights already you should be able to pick things from App Insights and put it on the Azure portal dashboard. Other than that probably getting data into Power Bi application insight is your best shot - https://powerbi.microsoft.com/en-us/documentation/powerbi-content-pack-application-insights/
I have a deployment slot on Azure. During debug of my debug slot it suddenly stopped working. I therefore stopped and started it again. Now I am not able to access it on the azure portal:
If I tried to navigate to the service from VS I get:
Starting and stopping is not working. And I cannot find anybody with this issue. I can't even delete it to recreate it, since the deployment slots has completely disappeared :/
Anybody have an idea of how to tackle this, e.g. through azure command prompt or powershell?
Error Message in Azure
When I try to publish I get the following:
Web deployment task failed. (Could not connect to the remote computer ("AppServie-development.scm.azurewebsites.net") using the specified process ("Web Management Service") because the server did not respond. Make sure that the process ("Web Management Service") is started on the remote computer. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_COULD_NOT_CONNECT_TO_REMOTESVC.) AppService C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Microsoft.Web.Publishing.targets 4283
happened to all our services including DB connections just a short moment ago. Now waiting for resolution from their side....
https://azure.microsoft.com/en-us/status/
it only mentioned global DNS issue, but I guess that means all services?... anyway, I'm sitting duck here waiting my boss to shout at me
14:03
All our services are back online
we are not paying the support subscription so unofficially we are their second class customers...?
but anyway problem solved, a typical 1 hour experience as we have with Microsoft in most technical issues.... (personal opinion - not bad overall when running in a cloud)
All our services went down as well due to connection issues with DBs
I am also following on Twitter on "#azure". Seems to be a problem that hits a lot of people right now. Also many of the bigger websites in North Europe seems to be super slow / down.
Seems to be only in North/West Europe.
News from : https://azure.microsoft.com/en-us/status/
DNS - Multi-Region
Last updated 5 minutes ago
Starting at 11:48 UTC 15 Sep, 2016 a subset of customers using DNS in multiple regions may experience difficulties connecting to their resources hosted in this region. This issue is also having knock-on impact on impact on multiple Azure services, including SQL Database, Virtual Machines, Visual Studio Team Services, and App Service \ Web Apps. Engineers are aware of this issue and are actively investigating. The next update will be provided in 60 minutes, or as events warrant.
I have a web role in azure that is using syncfusion docToPdf to convert word documents to pdf.
If I publish this role using a full deployment, converting a doc is fast, <500ms.
But after a update deployment, it's unusable slow, >5s every time.
If I reimage the instance it will be fast again, until I do a new deployment update.
If I reboot the slow instance it has no effect.
For all other functionality in the role there is no performance difference between full deployment and upgrade deployment.
I do not understand why this is happening or where to start to fix it...
It turns out that this happened because of Application Insights, for some reasons it made word to pdf 10 times slower.
When we modified applicationinsights.config and replaced [All Namespaces] with only our own namespaces syncfusion started running smoothly again
Windows Azure cloud service take some amount of time to initiate the service while accessing it first time, immediately after update deployment. This is due to the cloud service stops from the server when the service is idle for a certain amount of time, while updating the cloud service. Whereas the service remains running immediately after full deployment, hence it doesn’t require to restart service. Please refer the below blog for further details
http://wp.sjkp.dk/windows-azure-websites-and-cloud-services-slow-on-first-request