Azure Architect AZ-303 Lab -Back Up and Restore VMs with Azure Backup

Back Up and Restore VMs with Azure Backup

 

Description

Azure Backup is a service for backing up your data in Azure. You can back up Linux and Windows VMs running in Azure with Azure Backup as well as on-premises servers. Azure Backup can be used for more than just backing up machines but this lab focuses on VM backups.

You will use Azure Backup to backup a Windows Server VM running IIS in this lab. You will configure a backup schedule and retention periods using a backup policy. You will finish by restoring the VM back to an earlier state by performing a restore operation. Along the way you will learn the key concepts of Azure Backup.

Learning Objectives

Upon completion of this lab you will be able to:

• Back up and restore virtual machines running in Azure
• Configure backup policies to schedule backups and define data retention periods
• Understand how snapshots are created using an Azure Backup VM extension
• Evaluate the different options available for restoring including in-place instant restores, restore to disks, and restore to new VMs
• Describe the default consistency level for Windows and Linux VMs in Azure Backup

Intended Audience

This lab is intended for:

• Azure administrators
• AZ-103 exam candidates
• Anyone responsible for backup and retention of virtual machines

Prerequisites

You should be familiar with:

• Azure VM and Storage Account basics

Creating an Azure Recovery Services Vault

Introduction

Recovery Services vaults are the core service for backing up and restoring several sources of data. These include Azure VMs (Windows and Linux), on-prem machines, Individual files, Azure Files file shares, and Azure SQL Databases. Having all your data backed up in a central location makes it easy to manage and organize. Recovery Services vaults also enable disaster recovery scenarios by replicating data to vaults in other Azure regions and storage used for the vault is geo-redundant by default. The cost of the service is based on the number of instances you back up/protect and the amount of storage used. You will use a Recovery Services vault to back up a Windows Azure VM in this Lab.

You will create a Recovery Services vault using the Azure Portal in this Lab Step.

 

Instructions

1. In the Azure Portal upper search bar, enter recovery services, and click Recovery Services vaults in the results drop-down under Services:

 

2. Click +Add to create a new Recovery Services vault:

 

3. In the Create Recovery Services vault blade, enter the following values leaving the default value for the rest:

• Project Details
  • Resource group: Select the one available
• Instance Details
  • Vault name: lab-vault-#### where you replace #### with random digits to ensure a unique name within the Azure subscription
  • Region: East US

  

4. Click Review + create.

 

5. Click Create:

 

6. Click Go to resource in the success notification that appears to navigate to the Recovery Services vault:

Take a moment to browse around the Recovery Services vault blade to see what you can do with it. You will be given specific instructions for what you need to do with your vault later in the lab.

 

Summary

In this lab step, you created an Azure Site Recovery vault that can be used to backup and restore data as well as replicate data across regions.

Connecting to the Virtual Machine (RDP)

Introduction

Remote Desktop Protocol (RDP) is a protocol developed by Microsoft that enables a remote connection to a Windows host. Remote Desktop uses a client/server model, whereby the initiating computer runs Remote Desktop client software to connect to the remote computer, which must run Remote Desktop server software. Remote Desktop server software is built into the Windows operating system. Windows also ships with a Remote Desktop client. Many free Remote Desktop clients exist for Linux and macOS, including those from Microsoft and Apple. The following instructions will detail how to connect using both:

• Remote Desktop on Microsoft Windows - installed by default.
• Remote Desktop for macOS - official Microsoft version available in the App Store.

Instructions will be similar for other Remote Desktop clients with different operating systems. Once your VM is in a running state, you can connect to it using a Remote Desktop client.

 

Instructions

1. Click the Azure Portal accordion menu  in the upper-left corner followed by Virtual machines:

 

2. Select the running ca-lab-vm VM from the list:

Note: If the VM is not listed, wait a minute and refresh the page.

 

3. From the Overview blade, click on the Connect > RDP command:

Note: The Overview blade displays helpful graphical information for your VM: CPU usage, disk input/output, and network traffic. Scroll up and down to view this information.

 

4. In the Connect to virtual machine blade that appears, click Download RDP File:

This generates and downloads a Remote Desktop file (.rdp extension) that serves as a shortcut to connect to your machine. The .rdp file is used by the Remote Desktop client to connect to the running VM.

Note: You may run into a permissions error when attempting to access the RDP file. This just means that your provisioning resources for this Lab, including the permissions that manage your user, aren't done deploying. Refresh the page every minute or so until you're able to continue.

 

The following instructions are divided based upon your operating system, either Windows or macOS.

Instructions for Windows

5.a. Open the downloaded .rdp file to connect to your VM.

You will see the following warning:

 

5.b. Click Connect.

You know where the .rdp file came from, so you can ignore the warning.

 

5.c. Enter the credentials for the VM:

• User name: student
• Password: 1Cloud_Academy_Labs!

Warning: If you receive a connection error instead of the credentials prompt, wait a minute and try again until the VM is ready to accept the connection. Additionally, if Mircosoft detects another account you may have to click more choices > use another account.

 

5.d. Click Ok.

You will be prompted with a warning about the certificate not being from a trusted certifying authority: 

 

5.e. Click Yes to bypass the warning.

This warning is expected and you can safely ignore it.

 

5.f. Proceed to instruction 6.

 

Instructions for macOS

5.a. Open the downloaded .rdp file to connect to your VM.

You will see Negotiating Credentials…

Warning: If you receive a connection error, wait a minute and try again until the VM is ready to accept the connection.

 

5.b. When presented with the Verify Certificate dialog, click Continue:

Although the certificate cannot be verified, it is safe to continue.

 

5.c. Enter the login credentials configured for the VM:

• User name: student
• Password: 1Cloud_Academy_Labs!

 

5.d. Click OK when ready. You will see "Connecting RDP..."

 

The following instructions are for all operating systems

6. Observe several Windows startup notifications in the Remote Desktop window.

After a few minutes, you will be able to interact with the Windows VM.

Important! The CPU and memory specifications for the VM in this lab are modest. For example, only two CPU cores. Therefore, connecting via RDP, which triggers several Windows initialization processes, causes an unresponsive user interface. In some instances, your screen may go black for 20 seconds, then transition to blue as the "Please wait for the Local Session Manager" Windows message is displayed. The entire Windows startup process typically takes a couple of minutes. After Windows is up and running, it is like any other Windows host. It is just a Windows host running in Azure.

Tip: See Troubleshoot Remote Desktop connections to a Windows-based Azure Virtual Machine if you experience lasting problems connecting to the VM.

 

7. Click No on the blue Network message that displays on the right side of the screen and close Server Manager by clicking the x in the top right corner of the window.

You will see the Windows Desktop:

 

8. Click on the search icon near the bottom left corner and enter cmd. Press enter to open a command prompt.

 

9. Enter the following command to view system information related to the virtual machine's operating system:

Copy code
systeminfo | findstr.exe OS

The OS Name is Microsoft Windows Server.

 

10. Close the command prompt window by clicking the x in the upper-right corner.

 

Summary

In this Lab Step, you used a Remote Desktop client to connect to an Azure VM running Windows.

Installing IIS on the Lab VM with PowerShell

Introduction

For this lab, you will use Microsoft Internet Information Services (IIS) as the application that you will customize to show the effects of backing up and restoring data. IIS is a web server that will allow you to easily verify the effects of the data changes using your web browser. You will install IIS on the Windows Server lab VM that is created by the Cloud Academy Lab environment using PowerShell in this lab step.

 

Instructions

1. Click the magnifying glass in the lower-left corner and enter powershell.

 

2. Click on Windows PowerShell:

 

3. Enter the following at the PowerShell prompt to install a basic IIS web server:

Copy code
Add-WindowsFeature Web-Common-Http

A progress bar is displayed until the installation is complete and the PowerShell prompt is returned to you:

You will confirm that the IIS webserver is up and running by using your web browser to navigate to the VM.

 

4. From the lab VM's Overview blade, copy the Public IP address of the VM:

The Network Security Group attached to the VM allows HTTP traffic so you can reach the VM's webserver with your browser using this IP address.

 

5. Open a new browser tab and navigate to the VM's public IP address:

This confirms you have installed IIS and it is working as expected.

 

Summary

In this lab step, you used PowerShell to install the IIS web server.

Backing Up the Lab VM with Azure Backup

Introduction

Azure Backup is a service for backing up data in Azure. The data is stored in a Recovery Services vault. You can back up Linux and Windows VMs running in Azure with Azure Backup as well as on-prem servers. Windows VM backups are application-consistent meaning that VM files, as well as memory and pending I/O operations, are included in the backup snapshot. Linux VM backups are file-consistent by default but with custom scripting, it is possible to create application-consistent backups for Linux. For a full treatment of the capabilities of Azure Backup, refer to the documentation.

You will use Azure Backup to backup the entire VM running IIS. You can create multiple backups for a VM and each backup is called a restore point. You have the ability to create restore points manually or via a schedule defined in a backup policy. You will see each method works in this lab step.

 

Instructions

1. From the ca-lab-vm blade in Azure Portal, click Backup in the left panel:

You can also configure VM backups from the Recovery Services vault blade in the Portal. It is particularly useful to use the vault blade when backing up more than one VM. However, for individual VMs it is convenient to manage the backup from the VM blade.

The Recovery Services vault you created earlier is automatically selected for storing the backup. A default backup policy (DefaultPolicy) is created when you created the vault, but you will configure your own next.

 

2. Click Create (or edit) a new policy.

 

3. In the Backup policy blade, enter LabBackupPolicy as the Policy name and configure the Backup schedule and retention fields freely (it will not impact the lab):

The backup policy defines when restore points are created as well as how long they are retained for. In practice, you can consider your organization's recovery point objective (RPO) and retention requirements to appropriately configure the backup policy. Daily backup restore points can be retained up to 9999 days (27 years) while weekly, monthly, and yearly ones can be retained for 99 years.

There are also Instant Restore points that can be retained for up to 5 days. Instant restore points allow you to perform in-place restores without the need to create a new VM or new disks. Instant restore points are stored outside of the vault for rapid recovery.

 

4. Click OK to create the backup policy.

 

5. Click Enable backup to start protecting the VM with Azure Backup.

After a minute the backup is enabled.

 

6. Return to the Backup blade and observe the view summarizing the backup state of the VM:

This will create the backup policy and start protecting the VM. A VM snapshot extension is automatically installed on the VM. However, the initial restore point will not be created until the time you specified in the backup policy schedule. You will manually create the first restore point next instead of waiting for the scheduled one.

 

7. Click Backup now in the command bar to kick off the initial backup.

 

8. In the Backup now blade, leave the default Retain Backup Till value and click OK.

After a few seconds a notification appears:

This tells you a backup job has started. It takes more time for the backup job to complete. You will monitor the job next.

 

9. Click View all Jobs to view the backup job operation table.

There will be a Completed job for configuring the backup and one In progress while the initial backup takes place:

The first backup has to backup the entire file system. Following backups are generally much faster because the restore point only needs to store the changes from the previous restore point. 

 

10. Click Backup to view details about the operation.

Focus on the Sub Tasks:

The Backup operation consists of taking a snapshot and transferring the snapshot data to the vault. The snapshot usually completes in under ten minutes while transferring to the vault can take up to 24 hours for the initial backup. However, you can use the snapshot to perform an instant restore even before the data is transferred to the vault.

 

11. Return to the ca-lab-vm Backup blade and observe the changes to the summary:

There is now an Application Consistent Snapshot restore point available to restore the VM to.

Note: If you don't yet see the Snapshot periodically refresh the view until the snapshot operation completes

 

Summary

In this lab step, you created a backup policy that configures the backup schedule and retention periods for Azure Backup. You manually initiated the initial backup. The initial backup operation can take several hours to complete, but you can perform instant restores with the snapshot data before it is stored in the vault.

Performing a Restore Operation on Lab VM with Azure Backup

Introduction

You can use Azure Backup restore points to completely restore VMs to the point in time of the snapshot or you can create disks from the restore point that you can use to retrieve files if that is all that is required. For use cases requiring only individual file backups you should consider installing the Azure Backup Microsoft Azure Recovery Services (MARS) agent on the VM. The MARS agent is built for individual file and folder recovery scenarios.

You will perform a complete restore of the VM in this Lab Step. You will perform an in-place instant restore which does not require creating a new VM nor new disks. The original disk data is overwritten in-place. This type of restore is said to be "instant" because it uses snapshots that are already outside of the Recovery Services vault so there is no need to wait for the data to be transferred out of the vault to a staging location. There is some delay involved while the VM disks are overwritten and the VM must be stopped to begin the restore operation.

 

Instructions

1. In your RDP session's PowerShell terminal, enter the following to customize the web page being served by IIS:

Copy code
Add-Content -Path C:\inetpub\wwwroot\Default.htm -Value $($env:computername)

You will essentially rollback this change by restoring the VM to an early point in time. In this illustrative example, only a single file is changed so a VM restore may be overkill. However, you would follow the same steps for more complex installations involving more than single-file changes.

 

2. Refresh the browser tab that navigated to the IIS website and confirm the default web page has changed to a new one that displays the VM name:

 

3. In the Portal, click Overview in the left navigation panel of the VM blade:

 

4. Click Stop followed by OK to stop the VM:

To restore the disks with the snapshots the VM must be stopped and deallocated. After a minute or two, the confirmation notification appears:

 

5. Click Backup in the left navigation panel.

 

6. Click Restore VM to kick off a restore operation:

 

7. In the Select Restore point blade, select the only available Snapshot and click OK.

 

8. In the Restore configuration blade, click Replace existing to perform an in-place restore and choose the only available storage account as the Staging Location:

The staging location is where disks are created from the snapshots before they replace the VMs current disks. The Create new configuration can create an entirely new VM or new disks from the restore point rather than an in-place restore.

 

9. Click OK followed by Restore

 

10. Click View all Jobs.

 

11. Click the Restore operation to view its details.

The restore operation should complete in ten minutes or less. The Transfer data from vault operation is completed "instantly" because you used an in-place restore using a snapshot already stored outside the vault. Once you see the following it is OK to proceed to the following instructions:

 

12. Return to the Overview blade and click Start to start the VM:

You will now confirm the VM has been restored to the point before you changed the web page served by IIS.

 

13. After waiting 30 seconds, click Refresh to reveal the new public IP address assigned to the VM:

 

14. Copy the Public IP address:

 

15. Navigate to the IP address in a new browser tab:

This confirms the VM has been restored to the early restore point!

 

Summary

In this lab step, you performed an Azure Backup restore operation. Specifically, you performed an in-place instant restore which can be completed more quickly than other restore operations because there is no delay for transferring data out of the vault to a staging location.

Azure Architect AZ-303 Lab - Monitoring Resources with Azure Monitor

 

Introduction

Metrics are an Azure Monitor tool capable of providing near-real-time numerical data about some aspect of your infrastructure. Metrics are collected at regular, defined intervals and help you act on data quickly, both by visualizing data and helping automate actions based on that data through alerts.

In this lab step, you'll configure a metric to track an Azure virtual machine (VM), and save that metric to an Azure dashboard.

 

Instructions

1. In the Azure Portal, type Monitor into the search bar at the top and click Monitor from the filtered drop-down list:

 

2. In the Overview blade of the Monitor dashboard, click Metrics:

Because you don't have any metrics saved, you'll be brought to the Select a scope blade to select a scope to track. In this case, your scope will be an Azure virtual machine.

 

3. In the search box, enter ca-lab-vm and select the virtual machine named ca-lab-vm:

 

4. Click Apply:

You'll be brought to the main Metrics blade with your new scope selected:

 

5. Select Percentage CPU as the Metric and Avg as the Aggregation:

The Metric drop-down allows you to select different metrics to track. The Aggregation drop-down allows you to specify different options for processing the the data points.

Once you've chosen those values, you'll see a chart with your desired data:

You can also use the New chart button to add multiple charts to the Metrics blade:

Next, you'll save this chart to a dashboard so that you can easily view it in the future.

 

6. At the top right of the chart, click Pin to dashboard > Pin to current dashboard:

 

7. To view your current dashboard, click the hamburger icon at the top left of the Azure Portal, then click Dashboard:

Notice the chart at the bottom of your dashboard:

Dashboards are a great way to customize and quickly view the data that is important to you, and Azure Monitor metrics will often provide mission-critical data.

 

Summary

In this lab step, you practiced creating an Azure Monitor metric to track the CPU usage for an Azure VM. You also saved that metric to your default dashboard for easy visibility.

Configuring Log Analytics Workspaces in Azure

Introduction

Log Analytics workspaces are unique environments used to collect and interact with several Azure Monitor data sources in Azure. Companies use Log Analytics workspaces in part because it allows them to import data from a variety of sources and query it using a robust query language that you'll cover in another lab step. You can also manage alerts, view the health of your resources and more from your workspace.

In this lab step, you'll practice creating a Log Analytics workspace and configuring it to receive log data from an Azure VM.

 

Instructions

1. In the search bar at the top of the Azure Portal, begin to type log analytics until you can click Log Analytics workspaces:

 

2. Click Add in the top left:

 

3. Fill in the following details, then click Review + Create:

• Subscription: Leave as the default option
• Resource Group: Select the only available one
• Name: ca-lab-workspaceXXXX, where XXXX is a random 4-digit number
• Region: (US) South Central US

 

4. On the validation blade, click Create.

Your deployment will start:

Within five minutes, your deployment will complete. Click Go to resource to go to your new Log Analytics workspace:

Congrats! You've created a Log Analytics workspace. Next, you'll need to import data from some source, to be able to view that data in your new workspace. An Azure virtual machine has been provisioned in this lab. You'll connect that VM to your workspace next, so that you can view its data.

 

5. In the workspace blade, click Virtual machines under Workspace Data Sources:

Workspace Data Sources allow you to import data from different sources, to be queried in your workspace.

 

6. Notice that on the Virtual machines blade, a virtual machine already exists. Depending on how quickly you arrived at this step, it might also be connecting to another workspace:

The virtual machine will eventually, automatically connect to a default workspace, which is why it may be connecting now. Once the virtual machine completes its connection, it'll look like this:

The virtual machine is connected to another workspace, meaning its logs and data will be sent to that workspace. However, you'll need it to connect to your new workspace in order to interact with its data.

Note: Again, depending on how quickly you reach this step, the VM may not have connected. If that's the case, skip to step 8.

 

7. Click the virtual machine and then click Disconnect, then Yes to confirm:

The virtual machine will disconnect in under five minutes:

 

8. Once the virtual machine is disconnected, connect it to your new workspace by clicking the virtual machine once again and then clicking Connect:

The virtual machine will begin to connect to your workspace. Click the name of your workspace at the top left to go back to the virtual machine blade:

Within between five and ten minutes, the virtual machine will connect to your workspace:

That's it! You've created a Log Analytics workspace and connected a VM to it.

 

Summary

In this lab step, you created a Log Analytics workspace and connected an Azure virtual machine to it. In another lab step, you'll interact with that VM's data using your new workspace.

 Querying Logs with the Azure Monitor Query Language

Introduction

A big reason companies use Log Analytics workspaces is their ability to use a powerful query language called Kusto Query Language (KQL) to query logs. KQL is a pipeline-driven, read-only query language that will look very familiar if you've ever worked with a structured query language (SQL).

In this lab step, you'll use KQL to query data about the virtual machine you connected to your Log Analytics workspace.

 

Instructions

1. In your workspace blade, click Logs on the left:

 

2. Exit out of the Queries pop up until you reach the Logs blade:

 

3. Notice that by default a new query tab is opened:

In the query tab is a window where you'll be able to write and execute KQL commands:

 

6. Input the Heartbeat command into the query window:

 

7. Click Run and watch as the bottom window populates with data:

The Heartbeat query checks virtual machines attached to a workspace at regular intervals. Depending on the amount of time that's transpired since you connected your machine, you'll see a different amount of results, or heartbeats, in the result window.

This command demonstrates the usefulness of KQL. Using a query consisting of one word, you're returned several data points containing useful information about your VM. Next, you'll use KQL to filter and display your results differently.

 

8. In the left menu of your query tab, click Filter:

The Filter tab will give you a list of available filters for your specified query, which in this case is Heartbeat. Notice some of the available filters. Each filter option pertains to a column, and each available value under the filter option represents an actual value that was returned by your query. For example, look at the first option, Category:

The (1) next to Category means that one unique value was returned among all heartbeats. The (34) next to Direct Agent means that 34 results contained a value of Direct Agent for their Category column. Note that because your lab will have been running for a different amount of time, it's likely you'll see a number different from 34.

 

9. Click the Category column then click Apply & Run, and watch it populate your query window:

If you've worked with SQL, this syntax will start to look a little more familiar. A new line has been added, prepended with a pipe, |, that contains a where clause to filter your data. In this case, you get the same amount of results, but in a situation where your workspace monitors multiple VMs, you can use KQL to filter down to the exact data needed. 

Next, you'll type a new filter rather than find it in the list.

 

10. Update your query to the following and click Run:

Copy code
1
2
Heartbeat
| where TimeGenerated > ago(5m) 

Recall that a pipe (|) on a new line initiates a new filter or action. The new line in your query filters your results to only show heartbeats within the last five minutes, by only grabbing rows that have a TimeGenerated value greater than five minutes ago, as shown by the ago function.

If you typed this command out instead of copying it, you probably noticed that as you typed the ago function, Azure gave you several other functions to autocomplete. Autocomplete is another powerful tool to use when working with KQL in Azure Monitor.

Finally, you'll save your query for easy access later.

 

11. Click Save at the top of the query tab:

 

12. In the form, use the following values and click Save:

• Name: My first query
• Save as: Query
• Category: exampleQueries

 

13. Note that now if you click Query explorer in the top-right:

You can navigate through saved queries, find a saved query category, and click your saved query to populate a new query tab:

 

14. Open a new query tab with the + button at the top of the tab:

 

15. Insert the following code into the query window and click Run:

Copy code
1
2
Heartbeat
| summarize count()

Notice the result is a single column containing the results of a count() function, which grabs the number of rows contained in the Heartbeat search. Summarize is a useful feature that allows you to aggregate the contents of a search using a number of filters and methods. In the previous query, you summarized the count of all heartbeats. Here are some other useful, commonly-used summarize uses:

Copy code
1
2
Heartbeat
| summarize by ComputerIP

This command summarizes heartbeats by the ComputerIP column. This command shows that you can also summarize by column names to get unique values for that column. You should get one result from this query, but in a real-world scenario, this query could could be fleshed out to grab all IPs that have been allocated at some point by a single VM:

Copy code
1
2
3
Heartbeat
| where SourceComputerId == 'Some Computer ID'
| summarize by ComputerIP

You can also use numerical aggregates with the summarize operator:

Copy code
1
2
Heartbeat
| summarize min(TimeGenerated)

This would grab the min value, or smallest value, of the TimeGenerated column, which would give you the oldest heartbeat. Check out the docs on the summarize operator to find out more about aggregating your queries.

 

Summary

In this lab step, you used KQL to view regularly-generated information about a virtual machine. You practiced finding objects and filters to query using a provided menu, as well as constructing queries and filters yourself. Finally, you saved a query for easy future use.

Working with Metric Alerts in Azure

Introduction

Metric alerts are an Azure Monitor tool used to alert you when some metric crosses a threshold, and even to act or remediate those crossed thresholds automatically by triggering functions and automated procedures. Metric alerts can be triggered by a wide range of both pre-defined and custom metrics, and can be used to do anything from send an email or text to triggering an Azure function.

In this lab step, you'll configure a metric alert to fire when an Azure VM has used more than a specified amount of CPU, on average, over a certain period.

 

Instructions

1. In your Lab Analytics workspace, click Alerts near the bottom-left:

 

2. Click New alert rule:

 

3. Under Scope, click Edit resource.

 

4. In the blade that opens on the right, change Filter by resource type to Virtual machines:

 

5. Select the ca-lab-vm virtual machine and click Done:

 

6. Under Condition, click Add condition:

 

7. In the blade that opens on the right, select Percentage CPU at the top. Insert the following values, leaving all others as default, then click Done:

• Threshold value: 0
• Aggregation granularity: 1 minute

This means that your alarm will trigger if its CPU usage average goes over 0, for a period of at least 1 minute. In a real-world scenario, you'd set a higher CPU limit, but for the purposes of this lab, the aim is to trigger the alert.

 

8. Set Percent CPU higher than 0 as the Alert rule name:

Note: While you won't work with severity in this lab, note that you can also set the severity of the alert, with 0 being the most severe and 4 being the least:

Severity allows you to communicate how quickly an alert should be acted on, and even allows you to further refine your automated actions, such as emails sent and remediations taken due to your alert.

 

9. Click Create alert rule.

Note: It can take up to ten minutes for alert rules to provision and show up on the alerts blade.

 

10. To view alert rules for your resource group, click the name of your resource group to the right of Selected subscriptions:

Note: Your resource group's name will be different, and will follow a cal-XXX-XX format.

 

11. Click Manage alert rules:

Notice that your alert rule is among those listed. Next, you'll give your alert time to provision and register that your VM's CPU usage is higher than 0%.

 

12. Click View Classic Alerts at the top left of the page to return to the alerts blade:

It can take up to ten minutes for a metric alert rule to become active. Once it has, you'll see your alert trigger in the alerts blade of your Log Analytics workspace:

Note that while it's outside of the scope of this lab, you can also set action groups to act on alerts like this one. Common actions include sending a text or email or even restarting the VM.

 

Summary

In this lab step, you configured a metric alert to listen for the CPU usage of an Azure VM, and to fire when that CPU usage went above a certain average number.