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.