You will route VM metrics and logs into a Log Analytics workspace, query them with KQL, and create an alert that notifies you on a threshold. By the end you will detect problems before users do.

Learning Objectives

  • Connect resources to a Log Analytics workspace.
  • Query telemetry with KQL.
  • Create a metric/log alert with an action group.
  • Time: ~3 hours · Difficulty: Intermediate · Prereqs: a running Azure VM.

Architecture Overview

Environment Setup

You will need: a VM, a Log Analytics workspace, and the Azure CLI.

Before you begin: enable diagnostic settings so data actually flows to the workspace.

Step-by-Step Execution

01
Create a workspace and connect the VM
az monitor log-analytics workspace create -g tyf-rg -n tyf-law
02
Query telemetry with KQL
$ az monitor log-analytics query -w $WID --analytics-query "Heartbeat | summarize count() by Computer"
Computer count_ web01 120
03
Create an alert with an action group
az monitor metrics alert create -g tyf-rg -n cpu-high --scopes $VMID --condition "avg Percentage CPU > 80" --action $AG_ID

Progress So Far

Testing & Validation

az monitor metrics alert show -g tyf-rg -n cpu-high --query "enabled" -o tsv

The alert should report true. Generate load on the VM and confirm the action group notifies you, proving end-to-end observability.

Troubleshooting
  • No data in workspace: enable diagnostic settings / install the Azure Monitor Agent.
  • KQL returns nothing: widen the time range; data ingestion has a short delay.
  • Alert never fires: verify the condition aggregation window and the action group target.

Extension Ideas

  • Build dashboards or workbooks over the same KQL.
  • Forward security signals into Microsoft Sentinel.
  • Compare with self-hosted logging in Log Management.

Key Results

  • Centralized VM telemetry in a Log Analytics workspace.
  • Queried metrics and heartbeats with KQL.
  • Created a CPU alert wired to a notification action group.
  • Achieved proactive detection ahead of user impact.