We have an Azure subscription through a Cloud Service Provider (CSP), which causes some limitations on what we can get and see in Azure. Nevertheless, we can see CPU and Memory usage per App Service Plan.
How can we see the same for specific App Services under the plan?
If I see abnormal CPU/memory utilization for the plan, how can I tell which App Service is causing it?
You can check this under any Site -> scroll down to the "Metrics (App Service Plan)" option. There you will be able to see the metrics across all sites which are in the plan and filter the data the way you want:
Update 2018-12-04
Check other answers for more updated information, since the experience evolve and change over time. And stop down voting just because you came 2 years later.
I will not include the current solution/screenshots here, because it will be unfair to the other contributors. And I cannot delete this answer as it is accepted one (because it was correct by the time asked and answered).
Go to any site (app) that's part of the App Service Plan
Click on 'Diagnose and Solve Problems'
In the screen that opens, click 'Metrics (App Service Plan)'.
For an App Service it's currently under:
Go to any site (app) that's part of the App Service Plan
Click on "Diagnose and Solve Problems"
Click on Performance Counters (on the right side of the screen)
Check e.g. the "Average Memory Working Set" checkbox
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 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 am looking into web Apps Monitoring in Microsoft Azure and I can see a variety of options in the portal. I have some questions in those which I will put forward one by one. The question length may be a bit long so apologies in advance :-)
Process Explorer
Here we can find process details per instance which are running for my Web App.In case of scale out we will also see multiple instances. I want to know why we are seeing 2 processes per instance and what is the significance of each process.
2.Metrics Per Instance (Apps)
While looking at this report, I can see 2 different tabs (see image), I am unable to map it to the instances I am having in my web apps.
2.A) Is it true that If I have multiple deployment slots/ scaled out instances I will see that many tabs in the report?
2.B) Is there a way by which I can map these to my Web App instances in the Process Explorer
3.Metrics Per Instance App Service Plan
Here Again we have to different indicators same as in Apps. Can some please help me how to decipher these.
Can you guys please help me out with the reports as it seems to be quite confusing and I am unable to map it with my Instances, Deployment Slots in relation to the app service Plan.
Once again apologies for a long question.
Thanks in Advance,
Mayank
Looks like no one answered this in a long time. Let me see if I can explain this better.
This blade that you are talking about is accessible under "Diagnose and solve problems" options of an App Service Web App. Lot of changes has been made in the last few months to this feature. Read more about it here: App Lens - Azure App Service
1. Why we are seeing 2 processes per instance and what is the significance of each process.
In Azure App Service. For every web app there is another web app provisioned. This site is known as KUDU. So one w3wp.exe corresponds to the process hosting your code and the second w3wp.exe corresponds to the process hosting the KUDU. This process will have a SCM tag appended against it. You can read more about it here: Project Kudu - Github
2.Is it true that If I have multiple deployment slots/ scaled out instances I will see that many tabs in the report? Is there a way by which I can map these to my Web App instances in the Process Explorer
To answer the first part, YES, the tabs corresponds to the number of instances the app service plan is scaled out to. So if your web app is scaled out to 7 instances, then you will see 7 tabs in the report.
There is no straight approach to correlate the instance names to process explorer. There is an alternate way. I have a blog post using which you can connect to the KUDU site of a web app on a specific instance. See this: Connect to Kudu site of a specific instance
3. Metrics Per Instance App Service Plan Here Again we have to different indicators same as in Apps. Can some please help me how to decipher these.
as the name says, Metrics per instance (App Service Plan) displays data for the entire VM, while Metrics per Instance (Apps) displays data for a specific web app or process (w3wp.exe). In Azure App Service, you can provision several web apps inside a VM. So, this view provides a holistic view of the overall usage of the VM. This will help you in determining whether you need to scale out or scale up.
I hope this answers this question.
I'm testing different Azure web app pricing tiers. In the portal I clicked "Scale up (App Service plan)" and chose the B1 Basic pricing tier to test how the performance compared with F1 Free and D1 Shared. When I try to scale down from Basic to Free or Shared, it says "Successfully updated App Service plan", but it doesn't work. I've tried this over a week or so and it just doesn't work. I was able to switch between Free and Shared with no problems before this. Surely this is some sort of error? We must be able to downgrade?
You must turn off the "Always On" feature of the Web App from the Azure portal "Application Settings" before changing (downgrading) the App Service Plan.
So the new portal has a few bugs. I tried to do this operation with the old portal and got a helpful error message:
Cannot update the site 'test' because it uses x64 worker process which is not allowed in the target compute mode.
If you choose a setting not available in a downgrade, for example 64-bit or "Always On" (confirmed), and then try to downgrade, it will say it succeeded when actually it failed.
And they won't let us use the old portal soon. Great.
"Always On" can be found here now:
I had the same issue; it was not possible to change the tier even after I changed the app service configuration to 32-bit. The problem was the other app services in the app service plan. After changing all the app services of the service plan into 32-bit, it was possible to change it to Free tier.
I have a MVC 5 web app hosted on Azure using Application Insights. App Insights was installed via a NugGet package in VS 2015 and the Key is set correctly. I have included the JS portion in the bottom of my page template. I am receiving ALL App Insight data EXCEPT the "Servers" section, which displays lower level perfmon data (Process CPU, Avail, Memory, Process IO Rate, etc).
The ApplicationInsights.config file appears to contain the necessary module:
<Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.PerformanceCollectorModule, Microsoft.AI.PerfCounterCollector">
Here is a screenshot from the Portal:
I am running this on the B1 App Service Plan level. I cannot find any information that could indicate this information is not available at this tier.
In the Performance Counters section of the "Install Application Insights Status Monitor to monitor website performance" article they sneak in a "Not for Azure web apps" comment.
I believe they are making a distinction between Performance Telemetry, which you can get for web apps, and Server Performance Counters, which you cannot.
Take a look here. This is a custom solution, not from AI team, but it does the right thing - the account of the application pool on the box should have access to Performance Monitor to be able to read Performance Counter values and report them to AI.