Quartz 5

Lab: Monitor signals, logs, alerts, and Insights

Properties1
tagslab, az-104, monitor, kql, alerts, insights

3 min read

Lab: Monitor signals, logs, alerts, and Insights

Outcome

Route selected diagnostic categories to Log Analytics, interpret a metric chart, query known data with KQL, configure a short-lived alert/action group/processing rule, and investigate VM, Storage, and Network Insights.

Do

  1. Create a disposable workspace and VM plus a storage/network test resource. Configure each resource’s diagnostic setting to send only relevant categories to the workspace; record selected tables, destination, and retention. Generate a harmless activity such as a tag update, then wait for ingestion rather than treating configuration as data.
  2. In Metrics, chart one VM or storage metric with two time grains and aggregations. Record the time window, aggregation, threshold, and why a spike or average supports (or does not support) an operational conclusion.
  3. Query a populated table in Logs with a bounded KQL query, such as AzureActivity | where TimeGenerated > ago(1h) | take 20. Save the query and its expected columns. Query an intentionally wrong table/category, diagnose empty results from diagnostic selection, resource scope, ingestion delay, and time range, then correct it.
  4. Create an action group pointing to a training mailbox or safe webhook. Create a metric/log/activity alert with a deliberately reachable threshold, trigger it, inspect the alert and notification, then add an alert-processing rule that suppresses that scope during a short maintenance window. Verify suppression and remove the rule.
  5. Enable supported VM Insights and inspect performance/map data. Open the Storage and Network Insights views for the training resources; record the selected metric, time range, and a practical question each answers.

Verify

Capture diagnostic-setting categories/tables, metric chart interpretation, saved query/output, alert/action delivery, processing-rule state, and three Insights views. You should now understand: metrics are numeric time series, logs are queryable records, diagnostics choose what reaches a destination, and a processing rule changes alert handling rather than the signal.

Break and fix

  1. Remove a needed diagnostic category and query its table. Restore the category, wait for new data, and distinguish no data from a bad KQL filter.
  2. Set an alert threshold/time aggregation that never matches. Inspect evaluation details, correct the condition, and trigger it safely.
  3. Suppress an alert too broadly. Narrow its scope/time window, verify the intended alert resumes, then delete the rule.

Scenario practice

  1. Configure: Choose metric versus log signal, diagnostic categories/table, threshold/window, action group, and maintenance suppression for a workload.
  2. Diagnose: A dashboard shows no logs while the VM is running. Inspect resource scope, diagnostic setting, table, ingestion delay, KQL time range, and permissions.
  3. Distinguish: Contrast metrics, logs, Activity Log, Insights, alert rules, action groups, and alert-processing rules.

Clean up

Delete alerts, processing rules, action group, diagnostic settings, Insights agent/configuration if dedicated, workspace, test resources, and resource group. Do not retain notification endpoints or logs containing sensitive training data.

Sources and re-audit

Re-audit when Monitor data collection, alert processing, or Insights behavior changes.

azure-monitor · log-analytics · kql · metric-alert · action-group · All labs

Graph View

Backlinks