Azure Architect AZ-303 Lab -Deploying And Monitoring Azure App Service Web Apps

 

Creating an Azure App Service Plan

Introduction

Azure App Service is a platform-as-a-service (PaaS) offering that allows you to quickly build, deploy, and scale Web, API, Mobile, and Function apps. The App Service platform supports both Windows and Linux for running applications in a variety of languages and frameworks, such as .NET, .NET Core, Java, Ruby, Node.js, PHP, Python, and Docker containers.

App Service plans are containers for the apps that you deploy in App Service. App Service plans are offered in different tiers, with more functionality provided by higher, more expensive tiers. The following list highlights some of the distinctions between the available tiers:

• Free (Windows only): Run a small number of apps for free
• Shared (Windows only): Run more apps and provides support for custom domains
• Basic: Run unlimited apps and scale up to three instances with built-in load balancing
• Standard: The first tier recommended for production workloads. It scales up to ten (10) instances with Autoscaling support and VNet integration to access resources in your Azure virtual networks without exposing them to the internet
• Premium: Scale up to 20 instances and additional storage over the standard tier
• Isolated: Scale up to 100 instances, runs inside of an Azure Virtual Network isolated from other customers, and supports private access use cases

The most up-to-date information for the features included with each tier is available here and in the Azure Portal as you will see in this Lab Step where you create an App Service plan.

 

Instructions

1. In the search bar at the top of the Azure Portal, enter app service plans. Click App Service plans under Services:

 

2. Click + New to create a new App Service plan.

 

3. In the New App Service Plan form, enter the following values and accept the defaults for the rest:

• Resource Group: Select Use existing, then select the Lab's resource group from the drop-down menu (it will resemble cal-123).
• App Service plan: ca-lab-plan (The name must be unique per subscription, but not globally)
• Operating System: Windows
• Location: South Central US

 

 

4. Click on Change size under Pricing tier and in the blade that appears click See additional options to reveal the different tiers and their respective features:

Read through the tier details. Notice that within a tier there are different choices for the underlying virtual machine sizes running the App Service. For example, in the image above there are different sizes visible for the premium tier: P1v2 (Premium 1 version 2), P2v2, and P3v2. Depending on your workload, you can consider which tier and size will meet your requirements.

 

5. Select the S1 tier and click Apply.

 

6. Click Review and Create and then Create to create the App Service plan.

It takes approximately ten (10) seconds for the App Service plan to be created. You will receive a notification when it completes:

 

7. Click Go to resource.

The Overview blade of the app service plan appears:

The Overview shows how many App(s) / Slots are currently in use. Deployment Slots allow you to have multiple instances of an app running. Every app uses at least one slot for the production app, but additional slots are useful for testing before releasing to production and having a slot to rollback to with no downtime if an issue is found in production. The Overview also displays metrics for CPU, Memory, Data In, and Data Out. You can use these metrics to determine when it might be time to Scale up or Scale out your plan, both of which are available in the blade menu on the left under SETTINGS. To be notified when metrics have exceeded set thresholds, you can configure Alerts. You should also be aware of the Networking settings, which allow you to configure access to resources in an Azure VNet or on-prem, and the File system storage settings, which show you how much storage you have left in your plan.

 

Summary

In this Lab Step, you created an App Service plan. You learned about the different pricing tier features and saw how to monitor an App Service plan.

It is worth pointing out that App Service plans can be automatically created when you create different types of apps. This Lab has separated the creation of the App Service plan to highlight:

• The App Service architecture where multiple apps go inside a single App Service plan
• Different tiers available for App Service plans

Creating a Web App in Azure

Introduction

Azure App Service Web Apps, or simply Web Apps, are the instances of your websites and web applications hosted in Azure App Service. For most scenarios, Web Apps is the best choice for hosting websites and web applications in Azure. Each Web App is deployed into an App Service plan. Web Apps are DevOps-ready, and can be deployed using a variety of continuous deployment tools.

In this Lab Step, you will create a Windows-based Web App and learn about the other options available.

 

Instructions

1. In the search bar at the top of the Azure Portal, enter app services. Click App Services under SERVICES:

 

2. Click + Add to create a new App Service:

 

5. In the Web App form, enter the following values and accept the defaults for the rest:

• Resource Group: Select Use existing, then select the Lab's resource group from the drop-down menu (it will resemble cal-123)
• Name: ca-lab-app-#### where you replace #### with random digits. (The name must be globally unique because it is part of the DNS name for the app.)
• Runtime stack: .NET Core 2.x (LTS) (where x is the latest minor version number available)
• OS: Windows
• Region: South Central US
• App Service plan/Windows Plan: ca-lab-plan

You can temporarily select the other options for the OS to see how what additional settings are required for Linux or Docker apps. It's worth noting that the App Service plan pricing for Windows includes a small premium over the cost of a Linux plan. Docker apps also run in a Linux App Service plan. If you are using cross-platform languages, you can reduce your costs by using Linux App Service plans. Linux plans aren't at feature parity with Windows plans, so you should check if a Linux plan will meet your requirements before opting to save costs.

 

6. Move on Monitoring section and enter the following values:

• Application Insights: No (this can be enabled after creation)

 

6. Click Review + create and then Create again.

 

7. Once the Web App is created, click on the notification bell icon in the upper-right toolbar, and choose Go to resource to view its Overview blade:

 

8. Close the Notifications pane if it stayed open.

 

9. Observe the information available in the Overview blade:

There are commands to Stop and Restart the application. The underlying virtual machines are not stopped or restarted, so other apps in the same App Service plan are not impacted by these commands. There are also commands to Get and Reset the publish profile, which is used when deploying applications directly from Microsoft's Visual Studio integrated development environment (IDE). The table below the command bar also includes FTP information that can be used to deploy Web Apps and access logs for the application. Below that are shortcuts to other menu items in the App Service blade, including App Service Advisor that can make recommendations based on your application's CPU, memory, and connections history. Lastly, there are a handful of charts for monitoring key metrics. There is usually a few minutes of delay before metrics are displayed in the charts.

 

10. Click Browse in the upper command bar to navigate to the URL of the app in a new tab:

This is the default App Service app that is deployed when creating a new Web App.

 

11. Refresh the page a few times to generate additional metric data.

 

Summary

In this Lab Step, you created a Windows-based App Service Web App using the Azure Portal. The process of creating and managing Web Apps is DevOps-ready and can be automated using the Azure CLI, PowerShell, or the Azure REST API.

Creating a Staging Deployment Slot

Introduction

Deployment slots allow you to have separate instances of your application that have their own hostnames. This is useful for several reasons:

• You can organize your workflow by having dedicated testing and staging slots in addition to the default production slot.
• Once you have vetted a new release in the staging slot, you can swap it into production to avoid having to warm up the production application.
• By swapping releases into production, the previous release remains in a slot where it can easily be swapped back into production if an issue is found in the new release.

Each deployment slot maintains its own configuration and application settings. Deployment slots are available with the standard and premium App Service plans.

You will create one deployment slot to stage releases in this Lab Step.

 

Instructions

1. In the App Service blade, click Deployment slots under the Deployment section:

The production deployment slot is available by default:

 

2. Click + Add Slot.

 

3. Enter the following values in the Add a slot form:

• Name: staging (This name identifies the slot, and is part of the URL used for accessing the slot's application.)
• Clone settings from: Do not clone settings (You can potentially save time by cloning another slot's configuration.)

 

4. Click Add to create the slot.

After a few seconds, the new deployment slot appears in the deployment slots table:

 

5. Click on the staging slot.

You are presented with a blade that looks exactly like the Web App blade for the production slot:

Additional deployment slots are like the production slot with a few exceptions, that you will see later.

 

6. Click on Browse in the command bar to open the default application deployed in the staging slot:

Notice that the URL subdomain is the web app name appended with - and the slot name, -staging in this case. The production slot is special in that there is no slot name appended.

 

Summary

In this Lab Step, you created a deployment slot for the Web App to use for staging releases to the production slot.

Deploying a Web App Using Deployment Slots

Introduction

Key benefits of deployment slots are the ability to swap pre-warmed websites into production, and to easily roll back to the previous version, by repeating the last swap. It is a best practice to use deployment slots when deploying a Web App. There are different types of swaps that you can use depending on the level of confidence you have in a release:

• Auto Swap: As soon as an application is deployed to a slot it automatically swaps into a target slot. This is not the same as deploying directly to the target because the application gets a warm start, and the previous release of the target slot is preserved if a rollback is required.
• Swap: The most basic swap type that requires you to manually trigger the swap operation.
• Swap with preview: This type is similar to a regular swap, but allows you to preview the swap before completing it. Because each slot maintains its own configuration and application settings, the web app may not behave exactly as it did in the originating slot, and that is a good thing. 

Some settings such as SSL certificates, custom domain names, and scale settings do not swap when you swap deployment slots. Other settings do swap, such as monitoring and diagnostic settings, framework versions, app settings, and connection strings. However, app settings and connection strings can be configured to be sticky and stay with a slot. For example, if you have separate test and production databases, you can configure the database connection string to stick to each slot. 

In this Lab, you will deploy a new release to staging and swap into production. You will use a pre-built ASP.NET Core 2 app bundled in a Zip file that is ready to deploy for simplicity. It is better to use a source-controlled deployment method in production. App Services supports deployments via GitHub, BitBucket, Visual Studio Team Services (VSTS), DropBox, and more. You will also see how app settings can be configured to stick to a slot.

 

Instructions

1. Download the pre-built application CALabApp.zip file that you will deploy to the staging slot.

 

2. From the staging slot's Web App blade, enter advanced tools in the search bar and select Advanced Tools under DEVELOPMENT TOOLS:

 

3. In the blade that appears, click Go to open the advanced tools interface:

The Advanced Tools are what App Service deployments are built on top of. The advanced tools engine is called Kudu. With Kudu you can get command-line access to instances hosting your Web Apps, view running processes, install site extension, and much more. You will only need to use the Zip file deploy functionality provided by Kudu in this Lab Step. Other deployment options do not require using Kudu and can be configured in the Portal, but require setting up an external repository.

 

4. From the Kudu toolbar, click Tools > Zip Push Deploy:

In the view that appears, you can see the files that are currently being hosted for the Web App:

The default Web App is only a single .html file.

 

5. Drag and drop the CALabApp.zip file onto the directory contents table to kick off a Zip deploy:

A small progress bar appears in the upper-right corner to display the progress:

Deployment output is also displayed below the directory contents. It takes approximately ten (10) seconds to deploy the small application. It is complete when you see Deployment successful in the output:

 

6. Close the Kudu browser tab.

 

7. Click Browse on the staging slot's Overview blade to navigate to the Web App:

The Web App is now warmed up from your initial request. The test-setting message at the top of the page echoes the value of the app setting named test-setting. Currently, it is undefined because you have not configured the test-setting value. You will use this message to verify how app settings behave across swaps.

 

8. Open the staging slot's Configuration blade:

The Application Settings are divided into different sections. The Application settings and Connection strings are always swapped by default since the Web App depends on specific framework versions and platform to work correctly.

 

9. Under the Application settings section, click + New application setting and enter the following values before clicking OK:

• Name: test-setting
• Value: blue
• Deployment Slot Setting: Checked (By default the app setting will swap to the target slot. Checking Slot Setting makes it stick to the source slot.)

The new setting appears in the table:

 

10. Click Save at the top of the blade followed by Continue to save the app setting.

 

11. Refresh the staging slot Web App's homepage to see the change reflected:

 

12. From the Overview blade, click Swap in the command bar.

 

13. In the Swap form, enter the following values:

• Source: ca-lab-app-###(staging)
• Destination: ca-lab-app-###
• Perform swap with preview: checked

The preview will be generated by applying the settings from the Target slot to the source slot temporarily. By using swap with preview you have the opportunity to cancel the swap if the preview is not what you expected.

 

14. Click on Start swap for starting the swap operation.

The production slot settings are now applied on staging for preview. Because the production slot does not define any value for test-setting, refreshing the staging slot now shows undefined:

For this lab we will accept this preview.

 

15. Click Complete swap to finish the swap after approving the preview.

 

15. Close the staging blade and Browse to the production slot's Web App to confirm the swap completed:

You can optionally also confirm that the staging slot's Web App is now the default application, which could be rolled back to by repeating the swap.

 

Summary

In this Lab Step, you deployed a Web App to production using Zip file deployment and a staging slot. It is a best practice to use deployment slot swaps to release Web Apps to production with zero downtime and pre-warming. You also saw how slot settings can be used to configure the behavior of Web Apps based on the slot that they occupy.

Monitoring Azure Web Apps

Introduction

There are several facets to monitoring Web Apps in Azure. You should be familiar with what is available for monitoring, so that you can use the best tool for the task at hand. The following list summarizes the most commonly used monitoring tools available to you:

• Metrics: Metrics are collected for Web Apps and measured by server-level information, such as the number of failed requests, average response time, and data in/out. You have seen metrics at work in the charts visible on Web Apps overview blades. Metrics is a global service that is part of Azure Monitor. It measures data for a wide-variety of Azure resources, not only Web Apps. Metrics have different retention periods based on their time resolution:
  • Per minute metrics are retained for 30 hours
  • Per hour metrics are retained for 30 days
  • Per day metrics are retained for 30 days
• Diagnostic Logs: Collect logs from your application and/or from the web server hosting your application. The level of detail of the logs can be configured. You may need to configure higher levels of details when actively debugging issues, and return to a lower level of detail to reduce the amount of storage space used, and associated costs, for logs. By default, diagnostic logs are all disabled.
• Resource health: Monitors your App Services for Azure service issues that may be impacting your Web Apps. For example, service outages or smaller-scale hardware issues impacting the hardware serving your Web App. Resource health is useful for checking if any SLAs have been violated, entitling you to a refund. Resource health is a global service that can monitor multiple resource types, not only Web Apps.
• Service health: Service health is a general service that reports broad service outages, and not individual resource health. If a complete App Service outage is being experienced, Service health will report the outage, but because the outage affects the individual health of individual resources, Resource health will also notify you. Therefore, for monitoring a specific Web App, you can just check Resource health.

Another useful tool for monitoring Web Apps in Azure is Application Insights. Application Insights is a separate service and will be covered in a separate Lab Step.

In this Lab Step, you will see how to use metrics, diagnostic logs, and Resource health to monitor your Web App.

 

Instructions

1. On the Overview blade of the production Web App, click on one of the charts to open a Metrics blade:

The above image shows the Requests metric for the Web App at a per minute resolution for the Past hour. Above the graph are several drop-down menus that allow you to see metrics for resources in different Resource groups and Subscriptions. Recall that Metrics is a global service and not specific to Web Apps. The Overview charts are simply configured to select the current Web App in the Metrics interfaces. You plot metrics for multiple resources on the same chart. All of the Available metrics are listed for the Web App and shown in the column on the left.

 

2. Unselect the metric that is currently plotted, and select Connections, HTTP 2xx, HTTP Server Errors, and Thread Count to demonstrate multi-metric charting:

As long as metrics share the same units, they can be plotted on the same chart. The selected metrics are simply numbers without units and can be plotted together. You can adjust the title, subtitle, Chart type, and Time range to your metric charts, and click Pin to dashboard to save them and make them easily accessible on the Portal dashboard. You can also add an alert based on the metrics.

In the plot above, you can see that the Web App was de-allocated because there were no requests for several minutes. The next request would require the Web App to be loaded into memory again and cause additional delay. If you want to avoid such delays, you can enable Always On in the Web App's application settings.

 

3. Close the Metrics blade.

 

4. Scroll down the sidebar menu and select MONITORING > App Service Logs.

The App Service logs blade has settings to enable different types of logging: 

Mouse over each information bubble to learn the distinction between each type of logging. There are also FTP and FTPS connection URLs at the bottom to download log files stored on the file system.

 

5. Click on the Click here to install the ASP.NET Core site extension to enable Application Logging banner to have Kudu install the extension to enable application logging.

The progress notification disappears after the extension is installed. Depending on the language or framework of your Web App, you may or may not have to install an extension.

 

6. Set the following values:

• Application Logging (Filesystem): On
  • Level: Verbose
• Web server logging: File System (Using Storage is more suitable in production because you can store more data, and it does not use up the limited file system resources in your App Service plan)
  • Quota (MB): 35
  • Retention Period (Days): 0 (Zero means indefinitely)

 

7. Click Save.

 

8. Click MONITORING > Log stream in the sidebar to view the application and web server logs in near real-time from the Portal:

 

9. Refresh the production Web App browser tab to generate some logging activity.

 

10. Wait up to a minute for the verbose application logs to appear in the streaming log console:

Application logs are useful when you have added logging messages in your application. In the image above, only server request logs are displayed. You may also see AspNetCore logs that are automatically transmitted by ASP.NET Core applications. The logs are written in batches so you will see several messages appear at once rather than in true real-time. If you need to retrieve application logs from the web server using Kudu or FTP, the logs are located in D:\home\LogFiles\Application.

 

11. Click Web server logs in the Log stream blade to switch to view web server logs.

 

12. Refresh the production Web App browser tab, and wait up to a minute for the verbose application logs to appear in the streaming log console:

The web server logs are retained on the server's file system in D:\home\LogFiles\http\RawLogs. You can access them using Kudu or FTP when necessary.

 

13. Scroll down to the SUPPORT + TROUBLESHOOTING section of the sidebar menu, and click Resource health:

If Azure detects that everything is OK with your App Service resource, you should see a report similar to the following:

The Health history tracks the resource health over the past two weeks. Because the Web App has not existed that long, the previous day's resource health shows up with a question mark (?) icon. If there were any detected issues, you would see error or warning icons in the history.

 

Summary

In this Lab Step, you learned how to use metrics, diagnostic logging, and Resource health to monitor Azure Web Apps. Metrics record many useful data points related to serving a Web App, in general. Diagnostic logs can record general web server logs or application-specific logs that you output from your Web App. Resource health lets you know if Azure has detected any issues that can impact the performance and availabilityy of your Web App.

Monitoring Application Performance With Application Insights

Introduction

Application Insights is an application performance management (APM) service. Some of the features of Application Insights include the ability to:

• Find and diagnose performance issues
• Find and diagnose runtime exceptions
• Monitor and alert on application health
• Analyze customer usage
• Create custom key performance indicator (KPI) dashboards

Application Insights can collect data from applications in Azure, running on-prem, or on other clouds. The integration with Azure Web Apps makes it exceptionally easy to use in Azure. Application Insights support for the following languages is provided officially by Microsoft: .NET, Java, and JavaScript (client-side and server-side with Node.js). The developer community provides support for other languages and platforms including Python and Ruby. If a library is not available for your language or framework of choice, any language can be supported by integrating with the Application Insights API.

This Lab Step walks you through enabling and using Application Insights to monitor a Web App.

 

Instructions

1. In the production Web App blade's sidebar menu, click Settings > Application Insights:

 

2. Click Turn on Application Insights and in the Application Insights form, enter the following values:

• Link to an Application Insights resource: Create new resource
  • New resource name: ca-lab-app-...
  • Location: South Central US

 

3. Click Apply, and click Yes.

Enabling Application Insights when the Web App is created can avoid having to restart. It takes a minute to complete.

 

4. Click on the View Application Insights Data link:

The Application Insights Overview blade for the Web App appears:

 

The Overview displays a few charts that are similar to what is displayed on the Web App's overview. But there is much more to Application Insight's monitoring capabilities.

 

5. Refresh the production Web App's browser tab, and click on a few of the different links in the header to generate some request data.

The refresh will take longer than usual because the Web App was unloaded when Application Insights forced a restart. Application Insights is only aware of requests that happen after you linked your Web App to Application Insights.

 

6. Click on Search in the command bar.

The search functionality lets you quickly search through traces, requests logs, page views, exceptions, and other types of data stored by Application Insights.

 

7. Enter home in the search bar:

Scan through the results to see what kind of information can easily be searched through. You can click on any result to see a detailed view for it.

Note: You may need to wait a minute before the recent requests are available for searching. Click Refresh every ten seconds until some results display.

 

8. Click on Logs in the menu bar.

Log Analytics allows you to run SQL-like queries over the information tracked by Application Insights.

 

9. Click on Get Started, close the example query welcome page and then Double-click pageViews to generate a query for all page views:

 

10. Click RUN to execute the query:

The results are shown in a table in the lower half of the page:

You are not only limited to table views for displaying results.

 

11. Click CHART to see a chart view of results.

The default configuration of the chart is not the most useful, but you can configure it.

 

12. Make the following changes in the drop-down menus above the chart to display a chart that shows the total page views for each page:

• Change the x-axis from Timestamp to Name
• Change the y-axis from Duration to Item Count
• Change the split by from Id to URL

The chart can be configured as part of the query itself, but that is outside of the scope of this Lab. The Analytics Home Page tab has a few common queries that you can try to get an idea of other queries.

 

13. Close the Logs blade.

  

14. In the sidebar menu, click INVESTIGATE > Performance to see performance monitoring data:

 

From this view, you can dive into the time distributions for any request served by the Web App. The Overall operation is selected by default, but you can click on any request in the lower table to narrow in on a specific request. You can also drag the time window boundaries to zoom in on a specific time range.

15. Close the Application Insights blade.

Summary

In this Lab Step, you used Application Insights to monitor an Azure Web App. Application Insights is a comprehensive application performance management service that can provide fine-grained monitoring data to help ensure your Web Apps are operating at their best.