9.4 VM, Storage, and Network Insights

Why insights matter

Azure Monitor insights are built-in monitoring experiences for specific resource types. They combine metrics, logs, workbooks, and configuration guidance so administrators can start troubleshooting without building every query from scratch. VM insights, Storage insights, and Network insights are especially relevant to AZ-104 because they map directly to the monitoring objective and overlap with compute, storage, and networking skills.

Insights do not replace fundamentals. If data is missing, you still need to know whether metrics are automatic, whether diagnostic logs are enabled, whether the Azure Monitor Agent is installed, and whether a data collection rule sends guest data to the workspace. If a network view shows failed connectivity, you still need to inspect NSGs, routes, DNS, firewalls, and private endpoint configuration.

VM insights

VM insights monitors Azure VMs and supported hybrid machines. It can collect guest performance data and dependency information through Azure Monitor Agent and data collection rules. The portal path is Azure portal > Monitor > Insights > Virtual Machines or Azure portal > Virtual machine > Monitoring > Insights.

A VM insights rollout has these steps:

1. Select or create a Log Analytics workspace.
2. Enable VM insights for the VM, scale set, or policy-driven scope.
3. Install or validate Azure Monitor Agent.
4. Associate the VM with a data collection rule.
5. Confirm heartbeat, performance, and dependency data appear.
6. Build alerts or workbooks based on confirmed data.

Use VM insights when the question asks for guest-level performance trends, process and dependency views, or fleet health across multiple VMs. Use platform metrics alone when the question asks only for basic host-level CPU or disk metrics. Use boot diagnostics or serial console when the VM fails before the guest agent can report useful data.

Example heartbeat query:

Heartbeat
| where TimeGenerated > ago(1h)
| summarize LastSeen=max(TimeGenerated) by Computer, _ResourceId
| extend MissingMinutes = datetime_diff("minute", now(), LastSeen)
| order by MissingMinutes desc

If VM insights has no data, check the agent extension state, data collection rule association, workspace permissions, outbound connectivity to Azure Monitor endpoints, and OS support. If one VM is missing while others report, compare extensions and DCR association first. If every VM is missing after a network lockdown, suspect outbound firewall, proxy, or private link monitoring configuration.

Storage insights

Storage insights provides views across storage accounts for availability, latency, transactions, capacity, and errors. It helps identify whether a problem is account-wide, service-specific, API-specific, or client-specific. The portal path is Azure portal > Monitor > Insights > Storage Accounts or the monitoring area of a storage account.

Metrics answer fast questions: Is availability dropping? Are transactions spiking? Is latency rising? Are capacity trends approaching limits? Logs answer record questions: Which caller IP receives 403? Which operation returns 409? Did a SAS token fail after rotation? To answer those record questions, enable diagnostic settings for blob, file, queue, or table service logs and route them to Log Analytics.

A practical storage troubleshooting table:

Example storage failure query:

StorageBlobLogs
| where TimeGenerated > ago(2h)
| where StatusCode >= 400
| summarize Errors=count() by StatusCode, OperationName, AuthenticationType, CallerIpAddress
| order by Errors desc

Network insights and Network Watcher

Network troubleshooting in Azure is often a path problem. The packet must leave a source, match the intended route, pass NSG evaluation, resolve DNS, traverse firewalls or load balancers, and reach a healthy destination. Network Watcher provides tools for this path: IP flow verify, next hop, effective security rules, packet capture, VPN troubleshoot, topology, NSG diagnostics, flow logs, and Connection Monitor.

Use IP flow verify when the question asks whether an NSG allows or denies traffic to a VM. Provide source IP, destination IP, port, protocol, and direction. Use next hop when a route table, forced tunneling, virtual appliance, or peering route might send traffic the wrong way. Use effective security rules when multiple NSGs and rules apply. Use packet capture when you need evidence from traffic at the VM NIC. Use Connection Monitor when you need continuous reachability and latency monitoring between endpoints.

Network Watcher CLI examples:

az network watcher test-ip-flow \
  --resource-group rg-net \
  --vm vm-web01 \
  --direction Inbound \
  --protocol TCP \
  --local 10.10.1.4:443 \
  --remote 10.20.1.5:50000

az network watcher show-next-hop \
  --resource-group rg-net \
  --vm vm-web01 \
  --source-ip 10.10.1.4 \
  --dest-ip 10.30.1.10

Connection Monitor scenario

Suppose an app VM in spoke-a intermittently fails to reach a database private endpoint in spoke-b. A one-time ping is not enough, and ICMP may not be allowed. Create Connection Monitor tests from the app VM or subnet source to the database FQDN or private IP on the required TCP port. Monitor reachability, latency, and failures over time. If failures align with route updates, firewall changes, or DNS resolution changes, you have an evidence trail.

A troubleshooting order for private endpoint access:

1. Resolve the FQDN from the source VM and confirm it returns a private IP.
2. Use next hop to confirm the route goes through the expected path.
3. Use IP flow verify or effective security rules to check NSG behavior.
4. Check firewall or NVA logs if traffic is forced through inspection.
5. Confirm the destination service private endpoint connection is approved.
6. Use Connection Monitor to validate the path over time.

Exam traps

Do not use VM insights as the answer for NSG rule simulation. Use Network Watcher IP flow verify or effective security rules. Do not use Network Watcher to restore deleted files; use backup or snapshots. Do not assume storage metrics show caller identity; you need resource logs. Do not assume a VM is healthy because platform CPU metrics exist; guest and application health may require agent data, logs, or application monitoring.

If an insight workbook is blank, do not immediately redesign the workload. Verify collection. For VM insights, inspect agent and DCR. For storage insights, inspect diagnostic settings when record-level logs are needed. For network insights, confirm Network Watcher is enabled in the region and that you have permissions to read the resources and run diagnostics.