Azure App Services

Azure App Services is a fully managed Platform as a Service (PaaS), and it is used for hosting Web Applications and REST APIs. In this article, I present the Monitoring, Logging and Autoscaling features of an App Service with a .NET 7 WEB API project.

What is an App Service

image source: http://code.benco.io/

As mentioned previously, an App Service is a PaaS, that can be used for hosting Web Applications and REST APIs. With an App Service, you can host your application without needing to worry about the infrastructure that runs your app. Azure App Service supports different languages such as .NET, Java, Ruby, Node.js, PHP, Python and Ruby.

In an App Service, you pay only for the resources that the App Service uses, and it is determined by the App Service Plan on which you run your app. In order to have an App Service, it’s necessary to have an App Service Plan (to which the App Service will be related).

This service also offers DevOps capabilities, such as Continous Deployment from Azure DevOps, GitHub, BitBucket and other sources. If you want to check how to deploy an application to an Azure App Service, from an Azure DevOps Repository using Azure Pipelines, check the article on which I present how to deploy a .NET Web API and a SQL Database with Azure Pipelines, by clicking here.

Creating an App Service

To create an App Service, login into Azure Portal, and search for “App Services”:

Then click on the “Create” button:

On the next page, select the Resource Group (or create a new one), inform the App Service name, select the Runtime stack, the Operating System you prefer, the Region, and the Pricing Plan and click on “Next: Deployment” to configure the other options if you need, or “Review + Create” to skip the others config:

A few remarks about this configuration:

• In order to have full log capabilities, it’s necessary to choose Windows OS. If you only need Application Logging and/or Deployment Logging, you can choose Linux. If you want to check more details about the supported logs in both OS, check the Microsoft page Enable diagnostics logging for apps in Azure App Service.
• In order to enable auto-scaling, it’s necessary to choose the plan “Standard” or higher.
• It’s also possible to enable Application Insights for the App Service (on the Monitoring page):

On the next page, review the configuration and click on “Create”:

Once the deployment succeeds, a notification will be displayed, and you can open it and click to go to the resource:

On the App Service page, we can get the app URL:

And we can see that the web app is running:

Deploying a .NET Web API from Visual Studio

For demonstration purposes, I created a new .NET 7 Web API project using Visual Studio and will use this project to deploy to the App Service. This project contains the weather forecast endpoint that is generated by the template:

I only removed the if statement in Program.cs, to enable Swagger, this way we can access the API with Swagger. This is the Program.cs:

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.

builder.Services.AddControllers();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

app.UseSwagger();
app.UseSwaggerUI();

app.UseHttpsRedirection();

app.UseAuthorization();

app.MapControllers();

app.Run();

To deploy the project manually, right-click on the solution and click on “Publish”:

Then select “Azure” and click on “Next”:

Select “Azure App Service (Windows)”, if you are using Windows, otherwise select “Azure App Service (Linux):

Authenticate with your Azure account and select the app service you would like to deploy, and select the Subscription and the App Service:

In the next step you can configure API Management (if you need it), otherwise check the “Skip this step” and click on “Finish”:

Then a publish profile will be created, and you can click on Close:

Back to the Publish option, in Visual Studio, click on the “Publish” button:

Once deployed, you should see this option” to open the website:

We can now access the Web API (remember to include the /swagger in the URL, and execute a request:

Monitoring

After accessing the API and making some requests, let’s check the Monitoring charts in Azure Portal. Open the App Service and go to Overview, you should see some graphs:

On the Overview page, you can see the five charts that provide information related to the App Service. These metrics can be useful for monitoring the network usage of your app, and allows you to identify any potential bottlenecks or performance issues. They are:

• Http 5xx: presents a graph related to server issues. It tracks the HTTP 5xx status codes returned by your app. These status codes indicate server-side errors, such as a server-side exception or some failure to complete the request.
• Data In: presents the amount of data that is received by your app over a period of time (the incoming data to the Web App).
• Data Out: presents the amount of data that is sent by your app over a period of time (the outgoing data from the Web App).
• Requests: present the number of requests received by your app over a period of time.
• Response Time: presents how much time it takes for your app to respond to incoming requests, over a period of time.

If you want to do some tests on that, you can hit your app sometimes, and wait on the overview page for a while and you will see that the graphs will show traffic details:

Logs

In Azure Portal, in the App Service, you can find the section “Monitoring” where you can see the “App Service logs” option:

On this option you can find the following logging options:

This service also provides different types of logs for Web Apps, such as:

• Application Logging: these are log messages generated by the application. It can be assigned to one of the following categories: Critical, Error, Warning, Info, Debug or Trace.
• Web Server Logging: all the RAW HTTP request data.
• Detailed Error Messages: copies of the .html error pages.
• Failed Request Tracing: detailed tracing information about failed requests (which includes a trace of the IIS components).
• Deployment Logging: logs related to content that is published to an app.

You can access the logs via OneDrive, DropBox, External source (such as Git or Mercurial repo) or via FTP using some FTP tool.

For demonstration purposes, I enabled only the Application logging option:

Now let’s make a test, access the Log Stream:

And you should see this page:

Now let’s make a new request to our API, and after that, we should see the following information:

Autoscaling — out and in

Azure App Service provides the possibility to manually scale the app, or automatically scale based on metrics such as CPU utilization, memory usage, etc. The App Service provides manual scaling (for any App Service Plan) and autoscaling (for Standard or higher App Service Plans).

Note: In order to enable autoscale you need to have App Service Plan Standard or higher, otherwise it will only be possible to use Manual Scale.

If you want to use Manual Scale, you just need to inform the number of instances that you want to have and click on Save:

For autoscaling, when you add a scale out rule, it’s important to always add a scale in rule too. Here is the difference between them:

• Scale out will add more instances of your app
• Scale in will reduce the number of instances of your app

Always when you have a scale out rule, make sure you also have a scale in rule configured, otherwise your app will never decrease the number of instances.

Before enabling autoscaling, let’s check how many instances of our app we have. To check it, go to “App Service Plan”, then in the “Settings” menu select “Properties”:

This information is also available on the “App Services”, in “Scale out” page:

Let’s now enable autoscaling configuration. In the App Service page, in the Settings menu, go to Scale out (App Service plan):

A small note about the difference between the Scale up and Scale out operations:

• Scale up: refers to increasing the resources allocated to your App Service instance, such as CPU, memory and Storage.
• Scale out: means that more instances of your app will be added to handle increased demand.

By default, the option Manual Scale will be selected, so check the option Custom autoscale, to enable autoscaling, and in the Rules option, click on “Add a rule”:

On this page, you can create the rules for autoscaling, and if you click on “Run history”, you can also see the history of scaling of your app.

Autoscaling can be configured to scale based on:

• Metric: it can scale based on the number of HTTP requests awaiting processing, CPU percentage usage, length of the disk queue, and others.
• Scheduled time: it can be configured to scale to a specific instance count according to a schedule. For example, you can scale at a particular time of the day, or on a specific date or day of the week, and you can also specify an end date to the app scale back at this time.

Configure autoscale with a Metric

This is how I configured the scale out rule:

• On the Metric name, I selected as a metric the “Memory Percentage”
• On Operator, I added a configuration for when the value is “Greate than”
• On the Metric threshold, I added a configuration for when the memory percentage goes above 50%
• On Operator, I selected the option “Increase count by”
• On Instance count, I added the value 1
• On Cool down, I added the number 5
• The other options I left as default (Duration: 10 minutes, Aggregation: Average)

This configuration means that when the Memory Percentage goes above 50% for the duration of 10 minutes, then it will increase the instance count by 1, over a cool down period of 5 minutes (this means that it will not execute this scale action again for 5 minutes — “the cool down” period).

Note: I’m using these values to easily scale the app for demonstration purposes only. Please choose carefully the values in order to avoid conflicts of metrics (you can read more about it on this Microsoft’s documentation page).

Let’s create a scale outrule and click on “Add”:

Now you can see the scale out rule that we just added. Let’s add a new rule for the scale in (click on “Add a rule”):

You can also set a name for the autoscaling configuration (check the “Default” option in the configuration overview):

Here is the scale in rule:

As we used the “Memory Percentage” for the scale out rule, we should have the same for the scale in rule. So in Metric name I added as a metric the “Memory Percentage”.

This configuration means that when the memory percentage is less than or equal to 5, which means when it goes less than 5% for the duration of 5 minutes, then it will decrease the instance count by 1, over a cool down period of 5 minutes.

Make sure also to configure the Instance limits, by defining a Minimum, Maximum and Default value for the app instances, and click on “Save”:

And now go to the “App Service Plan”, and select “Properties” (or check in the App Service on the Scale out page), and you can see that the “Instances Count” is now increased:

Configure autoscale based on a Schedule

You can also configure autoscaling to scale your app based on a schedule (you can define a Start and End date, or even select the days and times you want to scale).

With this configuration, you can then set autoscaling for your app to scale during specific days and hours, for example, during the weekends, or some other specific schedule as you need. For that, on the “Scale out” page click on “Add a scale condition” and select “Scale to a specific instance count”, and let’s create a scale configuration to scale the app by 3 instances, on Saturdays and Sundays from 12:00 up to 23:00:

Conclusion

Azure App Service support a range of programming languages and allows you to easily deploy Web Apps, offering great features such as Monitoring with graphs which allow you to monitor the status of your app, Logging features, which allows you to always be aware of what is happening in your app, Manual Scaling and Autoscaling, providing High Availability to your app, in combination with Security and Integration with other Azure Services (such as databases, storages, etc).

Thanks for reading!

References

App Service overview — Microsoft Docs

Enable diagnostics logging for apps in Azure App Service — Microsoft Docs

Get started with autoscale in Azure — Microsoft Docs