See what your cloud is doing, in KQL.

Every Azure resource emits telemetry, but scattered across a hundred blades it is noise. Observability is the discipline of pooling that telemetry in one place and being able to ask it questions — which is what a Log Analytics workspace and its query language, KQL, are for. This lab uses a data source you already generate for free: the subscription Activity log, the audit trail of every management operation you run. You will pipe it into a workspace, query it, and then turn a query into an alert — the exact shape of production monitoring, where a KQL expression that returns rows is what wakes someone up.

By the end you will have a workspace collecting real data, a KQL query that reads back your own operations, and a scheduled-query alert rule with an action group behind it — a loop you can point at any workload later.

Monitoring is a question you have written down in advance.

Create a resource group and a Log Analytics workspace. The workspace is the pool everything queryable lands in.

# Windows/Git Bash: stop it mangling /subscriptions/... arguments (harmless on macOS/Linux)
export MSYS_NO_PATHCONV=1

RG="campux-lab-obs-rg"
az group create -n "$RG" -l eastus

az monitor log-analytics workspace create -g "$RG" -n campux-logs

WS_ID=$(az monitor log-analytics workspace show -g "$RG" -n campux-logs --query id -o tsv)
WS_GUID=$(az monitor log-analytics workspace show -g "$RG" -n campux-logs --query customerId -o tsv)
echo "workspace resource id: $WS_ID"

A diagnostic setting at the subscription level routes the Activity log into your workspace. From now on, every management operation you run is recorded there.

SUB_ID=$(az account show --query id -o tsv)

az monitor diagnostic-settings subscription create \
  --name campux-activity-to-logs \
  --location eastus \
  --subscription "$SUB_ID" \
  --workspace "$WS_ID" \
  --logs '[{"category":"Administrative","enabled":true},{"category":"Alert","enabled":true}]'

Now generate a little activity to be sure there is something to find — create and delete a throwaway resource group:

az group create -n campux-obs-ping -l eastus && az group delete -n campux-obs-ping --yes

Query the AzureActivity table straight from the CLI. Read this KQL as a pipeline: take the table, keep the last hour, summarise a count per operation, sort by the busiest.

az monitor log-analytics query -w "$WS_GUID" --analytics-query '
AzureActivity
| where TimeGenerated > ago(1h)
| summarize count() by OperationNameValue, ActivityStatusValue
| sort by count_ desc
' -o table

An alert is a KQL query Azure runs on a schedule, firing when it returns too many rows. First an action group — who gets told — then the rule itself, watching for failed operations.

# who to notify (put your own email in)
az monitor action-group create -g "$RG" -n campux-oncall \
  --short-name cxoncall \
  --action email me [email protected]

AG_ID=$(az monitor action-group show -g "$RG" -n campux-oncall --query id -o tsv)

# fire if any Activity-log operation failed in the last 5 minutes
az monitor scheduled-query create -g "$RG" -n campux-failed-ops \
  --scopes "$WS_ID" \
  --condition "count 'placeholder' > 0" \
  --condition-query placeholder='AzureActivity | where ActivityStatusValue == "Failure"' \
  --evaluation-frequency 5m --window-size 5m \
  --severity 2 --action-groups "$AG_ID" \
  --description "A management operation failed"

az monitor scheduled-query show -g "$RG" -n campux-failed-ops \
  --query "{name:name, enabled:enabled, freq:evaluationFrequency}" -o table

Delete the resource group, and remove the subscription-level diagnostic setting separately — it lives on the subscription, not in the group.

az monitor diagnostic-settings subscription delete \
  --name campux-activity-to-logs --subscription "$SUB_ID" --yes
az group delete -n campux-lab-obs-rg --yes
az group exists -n campux-lab-obs-rg      # -> false

You created a Log Analytics workspace, routed real telemetry into it, queried that telemetry in KQL, and built a scheduled-query alert wired to an action group. That is "observability with Azure Monitor, Log Analytics, and thoughtful alerting" — a line lifted almost word-for-word from the job descriptions — done rather than described. KQL in particular is a transferable superpower: the same language queries Application Insights, Microsoft Sentinel, and Azure Resource Graph, so the query muscle you just built pays off far beyond this one workspace.