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.
Related
I have a long running console application, using while(true)... structure
It implemented by using Net Core
What type of Azure App Service I should create to host that application ?
Decision tree for Azure compute services
Azure offers a number of ways to host your application code. The term compute refers to the hosting model for the computing resources that your application runs on. The following flowchart will help you to choose a compute service for your application. The flowchart guides you through a set of key decision criteria to reach a recommendation.
Treat this flowchart as a starting point. Every application has unique requirements, so use the recommendation as a starting point. Then perform a more detailed evaluation, looking at aspects such as:
Feature set
Service limits
Cost
SLA
Regional availability
Developer ecosystem and team skills
Compute comparison tables
I recommend reading this guide afterwards
Criteria for choosing an Azure compute service
Another great entry point for developers concerned with a similar question
.NET application architecture
You have to use "Azure App Service as a WebJob"
To deploy the .NET Core console application to an Azure App Service Web App Web Job access the Azure portal and navigate to the Azure App Service where you will host the WebJob.
Clicking on the Add button renders the blade
Once the WebJob is successfuly uploaded, it will render in the WebJob blade. Click on it and you will see the Run button. As this WebJob is a manually triggered job, you must click on the Run button in order for the job logic within the .NET Core console application to run.
After starting the .NET Core WebJob, click on the Logs link and a new browser tab is opened and you can see the most current state of the WebJob
I am trying to implement SignalR hubs on my REST service (ASP.NET Web Api) hosted on azure. I've been reading some common stuff related to SignalR and I came to this one that it is server bound. You can check here. Which means that in order to be able to scale it on multiple server instancs I have to do some additional stuff. So, then, I started to ask myself "How many instances do I currently have running of my REST service on Azure? How do I know that?"
So, what I did was - I navigated to azure portal and opened my service > Process explorer
Does that mean than my web app scales automatically and I currently have 2 instances of my web api runing? I think it clearly says that there's currently only one instaces of it running 2 processes but how do I know if it will scale some time in the future?
No, your photo shows your app process and Kudu, which is a management interface you can access at https://yourappname.scm.azurewebsites.net.
You can see the instance count in your app's App Service Plan. If it is on Free or Shared, there can only be one. If it is Basic/Standard/Premium, it is one by default. If you haven't setup auto-scale, it won't scale to more than 1 instance unless you tell it to.
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 at possibly running some of our business on Azure.
I am trying to pick the services that would work best for my company, but I am getting mixed signals.
Because I am starting a new system, I want to pick the offerings that are not "legacy" (aka "current"). But there seems to be no way straight forward way to know that.
For example, this page of the Microsoft Documentation says
Cloud Services is similar to Service Fabric in degree of control versus ease of use, but it’s now a legacy service and Service Fabric is recommended for new development.
This page clearly states that Cloud Services is "legacy". However, you would never know this by going to the Cloud Services overview page. It has great marketing material that sells Cloud Services as a great option. But if I picked it, then I would be starting out on a platform that is in a legacy status.
Now I know that about Cloud Services vs Service Fabric. But there are tons offerings on Azure. I am trying to research them one by one to find out which ones are the most recent incarnation, but I feel like I am wasting my time.
Another example is storage. Lucky for me an Azure MVP answered my question on this one. Apparently, there is "older storage account" based disks and "managed" disks. Turns out managed disks are the new, easy way to do things. The storage account is harder. Still available, but not really what a new user should be picking. But again, this is very hard to find out unless someone who has been working with this stuff for a long time tells you.
I was about to start in on App Services and Web Apps, but I thought I would ask first to see if I am doing research that is already done and posted out there.
Is there somewhere that shows the current list of Azure services that you should look at if you are starting a new project?
I asked the similar question almost a year ago, and I even spoke with Azure Support Team after that. At that time, Microsoft did not officially state Cloud Service is legacy.
Does Azure App Service/Web App replace Azure Cloud Service?
We have been hosting our enterprise applications in Cloud Service since 2013, and a couple of them are in App Service. Here is my thought -
4 years ago we only have Cloud Service - Web Role and Worker Role,and App Service (formally named as Web App) is not fully ready for enterprise applications yet. Since App Service came up, Microsoft heavily promote App Service compare to Cloud Service. In addition, what I notice is Cloud Service did not get new features like App Service.
Service Fabric is quite new, and it doesn't have all the belts and whistles like App Service, so we might have to wait a bit for enterprise applications.
Only advantage of Cloud Service is you can remote desktop to a role instance, after the application is deployed.
If I host a new application in Azure today, I'll definitely use App Service.
Microsoft has published a list of Azure reference architectures. It was last updated in November 2016. You can browse it here, and there is some guidance given. But for example, you mentioned using Service Fabric (which is a great way to go for a robust app that really needs to scale), but Service Fabric isn't mentioned in the aforementioned resource.
I spend a lot of time running down Azure resources in relation to web applications (not to be confused with App Service Web Apps), and I have not found a definitive source of the type of info you're looking for personally.
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