This chapter covers Azure Connection Monitor v2, the next-generation network performance monitoring service in Azure that provides end-to-end connectivity and latency measurements between Azure resources and hybrid networks. For the AZ-104 exam, understanding Connection Monitor v2 is critical because it appears in questions about monitoring hybrid connectivity, VPN performance, and ExpressRoute health—typically 2-3% of exam questions. You will need to know its architecture, configuration steps, how it differs from Connection Monitor v1 and Network Performance Monitor, and how to interpret its data for troubleshooting.
Jump to a section
Imagine you are a network administrator for a large enterprise with multiple branch offices connected via a private MPLS network. You need to know not just whether each link is up, but the actual performance—latency, jitter, packet loss—from each branch to critical applications in your data center. Traditional SNMP polling gives you interface statistics but cannot measure end-to-end path health or isolate which hop is causing degradation. Azure Connection Monitor v2 is like installing a radar system that continuously pings every branch-to-datacenter path, records round-trip time and loss, and can even trace the exact route taken. The radar sends out probes (like ICMP or TCP SYN packets) at configurable intervals (default 60 seconds) from agents in each branch (NIC-based endpoints) to the destination. It measures the time each probe takes and whether any are lost. Over time, it builds a baseline of normal performance. When latency exceeds a threshold (e.g., 20% above baseline), it triggers an alert. If a probe fails entirely, it can run a traceroute to identify which hop dropped the packet. The radar's data is stored in a Log Analytics workspace, where you can query historical trends, create dashboards, and set alerts. Without this radar, you would only know a link is down when users complain—with it, you see degradation before it becomes an outage and can pinpoint the faulty hop, whether it is your ISP, a router in your own network, or the destination server itself.
What is Azure Connection Monitor v2 and Why Does It Exist?
Azure Connection Monitor v2 (CMv2) is a cloud-based network monitoring service that provides end-to-end connectivity and performance telemetry between Azure virtual machines (VMs), on-premises machines, and other endpoints. It replaces the original Connection Monitor (v1) and the legacy Network Performance Monitor (NPM) solution. CMv2 is built on top of Azure Monitor’s foundational capabilities, using Log Analytics workspaces for data storage and Azure Monitor alerts for notifications.
CMv2 exists because traditional network monitoring tools often lack visibility into the Azure network fabric. When you deploy workloads in Azure, the path between resources may traverse multiple virtual networks, load balancers, VPN gateways, and the Microsoft backbone. Simple ping tests from a VM can be unreliable because ICMP is often blocked by NSGs or firewalls. CMv2 uses lightweight agents (Azure Monitor Agent or Legacy Agent) to send synthetic probes—TCP SYN packets, ICMP echo requests, or custom port checks—and measures latency, packet loss, jitter, and path changes. It also supports traceroute to identify the hop-by-hop path.
How Connection Monitor v2 Works Internally
CMv2 operates through a set of components:
Monitor: A logical container that defines the scope of monitoring. Each monitor is associated with a Log Analytics workspace and contains one or more test groups.
Test Group: A collection of source and destination endpoints. Sources are typically Azure VMs or on-premises machines with the monitoring agent installed. Destinations can be URLs, FQDNs, IP addresses, or Azure resources (e.g., another VM, a SQL database).
Test: A specific measurement configuration within a test group, defining the protocol (TCP, ICMP), port number, probe frequency (default 60 seconds), and thresholds for failure (e.g., 5 consecutive failures).
Endpoint: A source or destination. Sources must have the Azure Monitor Agent (AMA) or Legacy Microsoft Monitoring Agent (MMA) installed and the Network Watcher extension enabled. Destinations can be any reachable IP or URL.
When a test runs, the agent on the source endpoint sends probes to the destination at the configured frequency. Each probe is a TCP SYN packet (if TCP is used) or an ICMP echo request. The agent records:
Round-trip time (RTT): The time from sending the probe to receiving the response.
Packet loss: The percentage of probes that do not receive a response within the timeout period (default 3 seconds).
Jitter: The variation in RTT between consecutive probes.
Path: If traceroute is enabled, the agent sends packets with incrementing TTL values to discover each hop along the path.
The collected data is sent to the Log Analytics workspace in the NWConnectionMonitorTestResult and NWConnectionMonitorPathResult tables. You can query these tables with KQL (Kusto Query Language) to analyze trends, create dashboards, and set alerts.
Key Components, Values, Defaults, and Timers
Probe frequency: Default 60 seconds. Configurable from 10 seconds to 300 seconds. Lower frequency provides faster detection but increases data volume and cost.
Failure threshold: The number of consecutive failed probes before the test is marked as failed. Default is 5. For example, with a 60-second frequency, 5 failures means the endpoint is considered unreachable after 5 minutes.
Timeout: 3 seconds per probe. If no response within 3 seconds, the probe is counted as lost.
Protocols: TCP (preferred), ICMP, or HTTP (for URL endpoints). TCP is recommended because it is more reliable and less likely to be blocked.
Port: For TCP tests, you must specify a port number. Common choices are 80, 443, or a custom application port. ICMP tests do not use a port.
Traceroute: Enabled by default for TCP and ICMP tests. It sends up to 30 hops. The path is updated every time a probe is sent (i.e., every 60 seconds by default).
Data retention: Probes data is stored in Log Analytics for 30 days by default (configurable up to 730 days with workspace retention settings).
Configuration and Verification Commands
To create a Connection Monitor v2 via the Azure portal, you navigate to Network Watcher > Connection Monitor > Create. You specify:
A name and Log Analytics workspace.
Source endpoints (select VMs with agent installed).
Destination endpoints (IP, FQDN, or Azure resource).
Test configuration (protocol, port, frequency, failure threshold).
Using Azure CLI, you can create a monitor with the az network watcher connection-monitor create command. For example:
az network watcher connection-monitor create \
--name MyMonitor \
--location eastus \
--source-resource /subscriptions/.../virtualMachines/VM1 \
--dest-address 10.0.0.4 \
--protocol TCP \
--dest-port 80 \
--interval 60 \
--traceroute-enabled trueTo view test results:
az network watcher connection-monitor query \
--name MyMonitor \
--location eastusIn Log Analytics, you can query:
NWConnectionMonitorTestResult
| where TimeGenerated > ago(1h)
| summarize avg(RoundTripTimeMs) by TestGroupName, TestConfigurationNameHow It Interacts with Related Technologies
Network Watcher: Connection Monitor v2 is a feature of Network Watcher. You must enable Network Watcher in the region of the source VMs.
Azure Monitor Agent: Required on source machines. It replaces the legacy MMA. The agent must have the Network Watcher extension installed.
Log Analytics: All data is stored in a Log Analytics workspace. You can create alerts based on KQL queries.
Azure Monitor Alerts: You can set up metric alerts for RTT, loss, or failure count. For example, alert when average RTT exceeds 200 ms for 5 minutes.
ExpressRoute and VPN: CMv2 can monitor connectivity over ExpressRoute and VPN gateways by setting the destination to an on-premises IP or the gateway IP. It measures performance across the hybrid connection.
Azure Private Link: CMv2 can monitor connectivity to Private Link endpoints, though the path may not include all hops if the endpoint is within the same virtual network.
Performance and Scale Considerations
Each source VM can monitor up to 20 destinations per test group. A single monitor can have up to 50 test groups.
The total number of probes per second per source VM is limited to 10. If you configure many destinations with a low probe frequency, you may hit this limit.
Data ingestion costs apply: each probe result is a log entry. At default 60-second frequency for 1 source to 5 destinations, you generate ~7,200 logs per day. At $2.30 per GB ingested (typical Log Analytics cost), this is negligible. However, if you monitor hundreds of destinations with 10-second intervals, costs can rise significantly.
Troubleshooting Common Issues
No data in Log Analytics: Check that the Azure Monitor Agent is installed and the Network Watcher extension is enabled. Verify the agent can reach the Log Analytics workspace (outbound HTTPS to *.ods.opinsights.azure.com).
Probes failing: Check NSG rules on source and destination. For TCP tests, the destination must allow inbound SYN packets on the test port. For ICMP, allow ICMP Echo Request.
High latency: Use the traceroute data to identify which hop adds delay. The path data shows RTT per hop.
Monitor status shows 'Not running': Ensure the source VM is running. CMv2 cannot monitor from stopped VMs.
Enable Network Watcher and Log Analytics
Before creating a Connection Monitor v2, you must ensure Network Watcher is enabled in the Azure region(s) where your source VMs are located. Network Watcher is enabled by default per region, but if you have disabled it, you need to re-enable it via the portal or CLI: `az network watcher configure --resource-group NetworkWatcherRG --locations eastus --enabled true`. Also, create or select a Log Analytics workspace to store monitoring data. The workspace must be in the same region as the Network Watcher for optimal performance. Verify the workspace by checking its resource ID: you will need it later.
Install and configure Azure Monitor Agent on source VMs
On each Azure VM that will act as a source endpoint, install the Azure Monitor Agent (AMA). This can be done via the portal (Extensions + Applications > Add > Azure Monitor Agent) or using Azure Policy for bulk deployment. After installation, enable the Network Watcher extension for AMA: `az vm extension set --resource-group MyRG --vm-name MyVM --name NetworkWatcherAgentLinux --publisher Microsoft.Azure.NetworkWatcher --version 1.4` (use NetworkWatcherAgentWindows for Windows VMs). Verify installation by checking that the extension status is 'Provisioning Succeeded'. The agent must have outbound connectivity to the Log Analytics workspace and to the destination endpoints.
Create the Connection Monitor v2 resource
In the Azure portal, navigate to Network Watcher > Connection Monitor and click 'Create'. Provide a name (e.g., 'Prod-Monitor') and select the Log Analytics workspace. Under 'Source endpoints', add your source VMs by selecting them from the list (they must have the agent installed). Under 'Destination endpoints', you can specify IP addresses, FQDNs, or Azure resources. For example, to monitor a web server, add its private IP and port 443. Configure test settings: protocol TCP, port 443, probe frequency 60 seconds, failure threshold 5. Enable traceroute. Review and create the monitor. The creation takes a few minutes as the monitor initializes.
Configure alerts and dashboards in Log Analytics
Once the monitor is running and data flows into Log Analytics, create alerts for critical conditions. For example, to alert when packet loss exceeds 5% over 10 minutes, use the KQL query: `NWConnectionMonitorTestResult | where TimeGenerated > ago(10m) | summarize LossPercent = avg(PacketsLossInPercent) by SourceEndpoint, DestinationEndpoint | where LossPercent > 5`. Create an Azure Monitor alert rule that runs this query every 5 minutes. Also, build a dashboard in Azure Monitor Workbooks using the `NWConnectionMonitorTestResult` and `NWConnectionMonitorPathResult` tables to visualize RTT trends and path changes over time.
Monitor and troubleshoot using traceroute data
Regularly review the path data to ensure traffic is taking the expected route. For example, if you have a VPN connection to on-premises, the path should show the VPN gateway as a hop. If you see unexpected hops (e.g., an internet egress point), there may be a routing issue. Use the `NWConnectionMonitorPathResult` table: `NWConnectionMonitorPathResult | where TimeGenerated > ago(1h) | project SourceEndpoint, DestinationEndpoint, HopAddresses, HopRtts`. If a hop shows high RTT or packet loss, investigate that network device. You can also run a manual traceroute from the source VM to compare with CMv2 data.
Scenario 1: Monitoring Hybrid Connectivity over VPN A financial services company has a hub-and-spoke topology in Azure with a VPN gateway connected to their on-premises data center. They use Connection Monitor v2 to monitor latency and packet loss from a source VM in Azure (spoke) to an on-premises server IP. The monitor is configured with TCP probes on port 443 (the application port) every 30 seconds. The test group includes three destinations: the primary on-premises server, a backup server, and the VPN gateway itself. The operations team has set up an alert in Log Analytics that triggers when RTT exceeds 150 ms for 5 consecutive probes. This allows them to detect ISP issues or VPN tunnel degradation before users notice. In production, they found that the traceroute data often shows an extra hop when traffic is asymmetrically routed—this helped them identify a misconfigured route in Azure Route Server.
Scenario 2: Performance Baseline for ExpressRoute
A retail company uses ExpressRoute for all critical traffic between Azure and their headquarters. They deploy Connection Monitor v2 with sources in multiple Azure regions and destinations at their HQ IPs. They set up a baseline over one week using the NWConnectionMonitorTestResult table to compute average RTT and jitter. They then configure dynamic thresholds in Azure Monitor alerts that trigger when RTT deviates more than 20% from the baseline. This proactive approach caught a BGP route advertisement issue that caused traffic to be routed through a secondary ExpressRoute circuit with higher latency. Without CMv2, they would not have noticed until application timeouts occurred.
Scenario 3: Multi-tier Application Monitoring A SaaS company runs a three-tier application on Azure VMs: web servers, application servers, and database servers. They create a Connection Monitor v2 with sources on web servers and destinations on app servers (port 8080) and from app servers to database servers (port 1433). Each test group monitors the critical path. They discovered that during peak hours, the latency between app and database servers spiked due to a noisy neighbor on the same physical host. By correlating CMv2 data with VM metrics, they moved the database VM to a dedicated host. Common misconfigurations include forgetting to open the destination port in the NSG (which causes 100% packet loss) or using ICMP when the destination firewall blocks it—always use TCP for reliability.
What AZ-104 Tests on Connection Monitor v2 The AZ-104 exam objective 4.5 (Monitor and troubleshoot virtual networking) includes Connection Monitor v2 as a key tool. Specifically, you should know:
How to create and configure a Connection Monitor (portal, CLI, PowerShell).
The difference between Connection Monitor v1 and v2 (v2 uses Log Analytics, no longer requires NPM solution; v2 supports traceroute and more flexible endpoints).
The required agents: Azure Monitor Agent (preferred) or Legacy Microsoft Monitoring Agent with Network Watcher extension.
How to interpret test results: RTT, loss, jitter, path hops.
How to set up alerts based on CMv2 data.
Integration with Network Watcher and Log Analytics.
Common Wrong Answers and Why Candidates Choose Them 1. Connection Monitor v2 requires the Network Performance Monitor (NPM) solution: This is false. CMv2 replaces NPM. Candidates confuse the old NPM solution (which was a separate solution in Log Analytics) with the new built-in CMv2. The exam expects you to know that NPM is legacy and should not be used for new deployments. 2. You must use ICMP for all probes: Many candidates assume ICMP is the default because of ping. CMv2 defaults to TCP, and TCP is recommended because ICMP is often blocked. The exam may present a scenario where ICMP fails but TCP works—choose TCP. 3. Connection Monitor v2 can monitor any endpoint without an agent: Sources require an agent. Destinations do not need an agent (they can be any reachable IP or URL). Candidates often think both ends need agents, but only the source needs one. 4. Traceroute is not available in CMv2: It is enabled by default. The exam may test that you can see the path per hop.
Specific Numbers and Terms That Appear on the Exam
- Default probe frequency: 60 seconds (configurable 10-300).
- Default failure threshold: 5 consecutive probes.
- Default timeout: 3 seconds.
- Maximum hops in traceroute: 30.
- Source VM limit: up to 20 destinations per test group.
- Required extension: Network Watcher extension for Azure Monitor Agent.
- Data tables: NWConnectionMonitorTestResult and NWConnectionMonitorPathResult.
Edge Cases and Exceptions - If the source VM is in a different region than the Network Watcher, you must create the monitor in the source region. CMv2 can monitor cross-region destinations. - If the destination is a private IP in another VNet, ensure peering or VPN is configured and NSGs allow the probe traffic. - CMv2 does not support monitoring from Azure VM Scale Sets directly—you must use individual VM instances. - You cannot monitor from a VM that is stopped or deallocated.
How to Eliminate Wrong Answers
- If a question mentions 'on-premises agent', look for 'Azure Monitor Agent' or 'Legacy MMA'—not 'System Center Operations Manager'.
- If the question asks about 'path visualization', the answer should involve traceroute/hop-by-hop data from NWConnectionMonitorPathResult.
- For alerting, remember that CMv2 data goes to Log Analytics, so alerts are based on log queries (not metric alerts directly, though you can create metric alerts from logs).
Connection Monitor v2 replaces Connection Monitor v1 and Network Performance Monitor; it is the current monitoring solution for network performance in Azure.
Only source endpoints require the Azure Monitor Agent (or Legacy MMA) with the Network Watcher extension; destinations can be any reachable IP or URL.
Default probe frequency is 60 seconds, configurable from 10 to 300 seconds; default failure threshold is 5 consecutive probes.
TCP is the recommended probe protocol because ICMP is often blocked; specify a port for TCP tests.
Traceroute is enabled by default and provides hop-by-hop path data stored in NWConnectionMonitorPathResult.
Data is stored in Log Analytics tables NWConnectionMonitorTestResult and NWConnectionMonitorPathResult; retention defaults to 30 days.
Alerts are created using log queries in Azure Monitor; you can alert on RTT, packet loss, or failure count.
Source VMs can monitor up to 20 destinations per test group; total probes per second per VM is limited to 10.
CMv2 can monitor hybrid connectivity over VPN and ExpressRoute by setting destinations to on-premises IPs.
Common exam numbers: probe frequency 60s, timeout 3s, max hops 30, failure threshold 5.
These come up on the exam all the time. Here's how to tell them apart.
Connection Monitor v2
Uses Log Analytics workspace for data storage; no separate NPM solution needed.
Supports TCP, ICMP, and HTTP probes; traceroute enabled by default.
Sources require Azure Monitor Agent (AMA) or Legacy MMA with Network Watcher extension.
Data stored in NWConnectionMonitorTestResult and NWConnectionMonitorPathResult tables.
Configurable via portal, CLI, PowerShell, and ARM templates.
Connection Monitor v1
Required the Network Performance Monitor (NPM) solution in Log Analytics, which is now deprecated.
Only supported ICMP probes; traceroute was not available.
Required the Legacy Microsoft Monitoring Agent (MMA) with Network Watcher extension.
Data stored in NPM-specific tables (e.g., NetworkMonitoring).
No longer recommended for new deployments; existing monitors can be migrated to v2.
Mistake
Connection Monitor v2 requires the Network Performance Monitor solution to be installed in Log Analytics.
Correct
CMv2 is a standalone feature of Network Watcher and does not require the NPM solution. NPM is legacy and should not be used. CMv2 stores data directly in Log Analytics tables.
Mistake
Both source and destination endpoints must have the Azure Monitor Agent installed.
Correct
Only source endpoints need the agent. Destinations can be any IP address, FQDN, or Azure resource that is reachable from the source. The destination does not need to run any agent.
Mistake
ICMP is the only protocol supported for probes.
Correct
CMv2 supports TCP, ICMP, and HTTP. TCP is the default and recommended because ICMP is often blocked by firewalls and NSGs.
Mistake
Connection Monitor v2 can monitor connectivity from any Azure resource, including Azure SQL Database and Azure Storage, without agents.
Correct
Sources must be Azure VMs or on-premises machines with the agent. Destinations can be Azure SQL, Storage, or any endpoint, but the source must be an agent-enabled machine.
Mistake
The default probe frequency is 10 seconds.
Correct
The default probe frequency is 60 seconds. It can be configured to as low as 10 seconds, but this increases cost and data volume.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Connection Monitor v2 is the latest version that replaces v1 and the Network Performance Monitor (NPM) solution. Key differences: v2 uses Log Analytics tables (NWConnectionMonitorTestResult, NWConnectionMonitorPathResult) instead of NPM-specific tables; supports TCP, ICMP, and HTTP probes (v1 only ICMP); includes built-in traceroute; and uses Azure Monitor Agent (preferred) or Legacy MMA. v1 is deprecated and should not be used for new deployments. For the exam, know that v2 is the recommended solution.
Create an alert rule in Azure Monitor based on a log query. For example, to alert when average RTT exceeds 200 ms over 5 minutes, use: `NWConnectionMonitorTestResult | where TimeGenerated > ago(5m) | summarize avg(RoundTripTimeMs) by SourceEndpoint, DestinationEndpoint | where avg_RoundTripTimeMs > 200`. Set the query frequency to 5 minutes and action group to notify you. Alternatively, you can use metric alerts for Connection Monitor metrics if you prefer, but log alerts are more flexible.
Yes, but only as source endpoints. You must install the Azure Monitor Agent (or Legacy MMA) on the on-premises machine and ensure it can reach the Log Analytics workspace and the destination endpoints. The on-premises machine must also have the Network Watcher extension. As destinations, on-premises machines do not need an agent—you can use their IP address or FQDN.
Common reasons: (1) The source VM is stopped or deallocated. (2) The Azure Monitor Agent or Network Watcher extension is not installed or is unhealthy. (3) NSG or firewall rules on the source or destination are blocking the probe traffic. For TCP probes, ensure the destination port is open. For ICMP, ensure ICMP is allowed. (4) The destination is not reachable due to routing issues, VPN tunnel down, or DNS resolution failure. Check the traceroute data to identify where packets are dropped.
Connection Monitor v2 itself does not have a separate charge; you pay for the underlying Azure Monitor Log Analytics ingestion and retention. Each probe result is a log entry. At default 60-second frequency for 1 source to 5 destinations, you generate ~7,200 logs per day (~0.2 GB per month). At typical Log Analytics rates ($2.30/GB), this is about $0.46 per month. However, if you use lower probe intervals or monitor many endpoints, costs increase. Alerts and dashboards may also incur additional costs.
A source VM can monitor up to 20 destinations per test group. A single Connection Monitor can have up to 50 test groups. If you need to monitor more than 20 destinations from one source, create additional test groups. However, be aware of the probe rate limit of 10 probes per second per source VM—if you configure many destinations with low probe intervals, you may hit this limit and experience degraded performance.
Azure provides a migration tool in the portal under Network Watcher > Connection Monitor. You can select your v1 monitors and click 'Migrate to v2'. The tool will create equivalent v2 monitors and disable the v1 monitors. Ensure your source VMs have the Azure Monitor Agent installed before migration. After migration, verify that data is flowing to the new tables. Note that v1 monitors will be deprecated, so migration is recommended.
You've just covered Azure Connection Monitor v2 — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?