Is there a metric that I can look at to see the number of hosts running concurrently in Azure Functions? The functions are running in the Consumption plan.
If you have integrated Application Insights with Azure Functions, then you can see the number of (serverless) instances in the Live Metrics of Application Insights. Below is an example where you see two (serverless) instances - 1st and 3rd the ones that you see in the below image.
Integrate Azure Functions with App Insights, try to create some load and then go to Application Insights's Live Metric blade where you can view the servers running for your Azure Functions.
Update:
You can also view the instances in the "Diagnose & Solve Problems --> Availability & Performance --> Overview section..
Related
in my Azure architecture I would like to scale down a couple of web app services.
I would like to use the D1 tear, which has a limited consumption time of 240 min/daily (as you can see in the picture below).
My question is: how can I use the Azure Monitor Metrics tool to get the average compute time for the last 30 days?
Maybe the CPU Time?
I'm asking that because I don't know if those web services work less then 4 hours a day.
Thanks for reading
Thanks for asking question! You may want to know that Azure App Service provides built-in monitoring functionality for web apps in the Azure portal from the Azure portal, you can review quotas and metrics for an app and App Service plan, and set up alerts and autoscaling rules based metrics.
If the app is hosted in D1 that is Shared plan, the limits on the resources that the app can use are defined by quotas.
Check Understand quotas and Monitoring quotas and metrics in the Azure portal
Let us know if further query.
When hosting an Azure Function in an App Service Plan, are there any significant differences compared with using an App Service (EDIT: for a restful API) associated with the same App Service Plan? I assume the only difference is that the Function offers additional out of the box triggers. Any differences I'm missing that would lead to preferring one over the other?
I'd also like to confirm that hosting Azure Functions in an App Service Plan can actually limit scalability if scaling is not configured on the App Service Plan. As I understand it, Functions automatically scale as needed when using Consumption or Premium hosting without additional configuration.
When hosting an Azure Function in an App Service Plan, are there any significant differences compared with using an App Service associated with the same App Service Plan? I assume the only difference is that the Function offers additional out of the box triggers. Any differences I'm missing that would lead to preferring one over the other?
Well, an Azure Function is a different beast than an App Service. An Azure function is triggered by an external event or a timer. It then executes the code of the function. When hosted on a consumption plan this execution is allowed to run for 5 or 10 minutes max. When you need a longer execution time you need to run it on an App Service Plan.
An App Service can host any app you've created. Like a website (that runs continuously and doesn't need to be triggered before it starts doing something) or an api for example.
I'd also like to confirm that hosting Azure Functions in an App Service Plan can actually limit scalability if scaling is not configured on the App Service Plan. As I understand it, Functions automatically scale as needed when using Consumption or Premium hosting without additional configuration.
Correct, when hosting Azure Functions in an App Service Plan you are responsible for making sure the app service is scaled to allow the function to perform well under load. Thats why the consumption plan is designed to handle this so the developer can focus on the functionality and does not need to worry about the infrastructure.
So, for integration scenario's azure functions are a very natural fit. For web sites an App Service might be the best solution.
To address your comment:
I should have mentioned that this question was in the context of hosting a restful API and not a UI application. In this scenario, I'm not seeing much difference between a Function and App Service, but please correct me if I'm missing something
A couple of things: For one, there is a certain sweet spot. If traffic is heavy enough a consumption plan based azure function might be more costly than having a dedicated app service plan. That depends of course on a lot of factors (CPU usage, request duration etc.). Also, you won't be able to use things like Asp.Net Core Middleware out of the box.
Finally, I'd argue that if your api is becoming large enough managing a single asp.net core solution may be easier than having to manage a lot of azure functions with small functions or one azure function project with lots and lots of functions, but hey, that's just my opinion (haven't actually dealt with it to be honest)
Some resources to consider:
https://www.taztopia.com/single-post/2019/07/28/azure-function-vs-web-app-aka-serverless-vs-paas
https://dasith.me/2018/01/20/using-azure-functions-httptrigger-as-web-api/
The main difference is in how you pay for it:
Azure Functions Consumption plan you pay per execution
Azure Functions in an App Service (dedicated plan) you pay for the allocated hardware per minute.
You also have control of which VNET your functions run in when you use an app service plan. You may have security requirements that make this important.
You are correct that if you run it in an app service that is not configured to scale, then throughput will be limited by the allocated hardware.
For details see: https://learn.microsoft.com/en-us/azure/azure-functions/functions-scale
If you are having limited and predictable workload then deploy az function in AppService plan with supports VNET integration for private compute otherwise go for Premium plan which will provide autoscaling capability of your compute environment.
I am using Azure App Service which hosts application that reads data from Event hub using EventProcessorHost. I have allocated 6 instances(Manual Scaling) to run. I checked the Metrics(CPU Time) in App Service and found only 5 instances are running.
I am getting different instances count for different metrics.
Data In metrics shows 6 instances while CPU Time metrics shows 5 instances. I am confused. Please suggest.
Regards,
Amit Agrawal
the AlwaysOn feature is used to keep your app loaded, particularly when it's not receiving any traffic.
However, I am aware of numerous instances of AppServices, across a number of Azure Regions, where the metrics were showing the instance count different to the number of instances deployed. This was since yesterday. I believe there have been underlying Azure issues.
In the Azure Portal, under the menu for your WebApp, you should be able to see the recent health of your WebApp within the 'Resource Health' section.
I would advise that you raise a ticket with Microsoft, just to be sure.
#azurefamily
I am using Azure App Service which hosts application that reads data from Event hub using EventProcessorHost. I have allocated 6 instances(Manual Scaling) to run. I checked the Metrics(CPU Time) in App Service and found only 5 instances are running.
I am getting different instances count for different metrics.
Data In metrics shows 6 instances while CPU Time metrics shows 5 instances. I am confused. Please suggest.
Regards,
Amit Agrawal
the AlwaysOn feature is used to keep your app loaded, particularly when it's not receiving any traffic.
However, I am aware of numerous instances of AppServices, across a number of Azure Regions, where the metrics were showing the instance count different to the number of instances deployed. This was since yesterday. I believe there have been underlying Azure issues.
In the Azure Portal, under the menu for your WebApp, you should be able to see the recent health of your WebApp within the 'Resource Health' section.
I would advise that you raise a ticket with Microsoft, just to be sure.
#azurefamily
We are designing an application which will be hosted on AKS(Azure kubernetes service). The application will consist of a set of services written in asp .net core running in docker containers. I want to monitor the services as well as the containers/nodes and have the observability across the cluster. Azure monitor for containers seems to be a good solution for monitoring containers, nodes and the cluster as a whole however I want the advanced monitoring capabilities of the application insights for the asp .net core services for example application maps, live metrics streams, transaction tracing and such features. Moreover, I don't want to have overlapping solutions. Is the Azure monitor for containers able to provide all or most of these application insights features or do I have to have both solutions in order to get proper cluster monitoring and also the advanced application monitoring?
Azure Monitor for containers provide infrastructure level monitoring and basic application logs with stdout and stderr, Kubernetes events captured out of the box.
It does not provide instrumentation for your apps or distributed tracing capabilities today, which is possible with Application Insights.
If you are looking for application map & instrumentation for events metrics and logs for your app, you can use both together and it's possible to correlate data from both and create dashboards and views.
The long term road map has Azure Monitor for containers & Application insights combined offering
In this (https://learn.microsoft.com/en-us/azure/azure-monitor/insights/container-insights-overview) guide, you can find all the features of AKS monitoring. If these covers all your use cases then you don't need to install any other tool. If not, then you cover only those features which are missing.