Migrate to Connection monitor from Network performance monitor

In this article, you learn how to migrate your existing tests from Network performance monitor to the new Connection monitor with zero downtime. For more information, see Connection monitor overview.

Key benefits of the new Connection monitor

The following are key benefits of the new Connection monitor:

• Unified connectivity monitoring experience for Azure and Hybrid endpoints

  • Azure Monitor agent enabled ARC servers as source and destination endpoints.

  • Cross subscription, cross workspace and cross region monitoring support.

  • Virtual machines (VMs) and scale sets support as source and destination endpoints.

• Ease of experience with simplified agent support

  • Lightweight Azure Network Watcher extension compatible with ARC endpoints.

  • Support for Azure Monitor agent extension with ARC enabled on-premises endpoints.

  • Auto upgrade of agents with automated agent enablement support.

• Visualize & measure end-to-end network path performance with the new Topology (preview)

  • Deep insights into network performance metrics with synthetic monitoring across TCP, ICMP, and HTTP protocols.

  • Enhanced visibility into end-to-end network path and connections with per hop latency and path loss across path components, highlighting links with high latency or packet loss.

  • Geo meta data and ASN data available across internet hops.

  • Highlight last mile, middle mile, and last mile latency with Microsoft edge discovery.

• Enhanced troubleshooting with clear actionable insights

  • Fast detection with real-time alerting network connectivity issues.

  • Smart insights into changes across networking path components to highlight the underlying cause for connectivity errors.

  • Identification of blocking rules, resources responsible for causing endpoint connectivity failures.

Network performance monitor vs new Connection monitor

The following table compares Network performance monitor and the new Connection monitor:

Key points to note

The migration helps produce the following results:

• On-premises agents and firewall settings work as is. No changes are required. Log Analytics agents that are installed on Azure virtual machines need to be replaced with the Network Watcher extension.
• Existing tests are mapped to Connection monitor > Test group > Test format. By selecting Edit, you can view and modify the properties of the new Connection monitor, download a template to make changes to it, and submit the template via Azure Resource Manager.
• Agents send data to both the Log Analytics workspace and the metrics.
• Data monitoring:
  • Data in Log Analytics: Before migration, the data remains in the workspace in which Network performance monitor is configured in the NetworkMonitoring table. After the migration, the data goes to the NetworkMonitoring table, NWConnectionMonitorTestResult table and NWConnectionMonitorPathResult table in the same workspace. After the tests are disabled in Network performance monitor, the data is stored only in the NWConnectionMonitorTestResult table and NWConnectionMonitorPathResult table.
  • Log-based alerts, dashboards, and integrations: You must manually edit the queries based on the new NWConnectionMonitorTestResult table and NWConnectionMonitorPathResult table. To re-create the alerts in metrics, see Metrics in Azure Monitor.
• For ExpressRoute monitoring:
  • End to end loss and latency: This is easier in Connection monitor than in Network performance monitor, as you don't need to configure which circuits and peerings to monitor. Circuits in the path are automatically discovered, data is available in metrics (faster than LA, which was where Network performance monitor stored the results).
  • Bandwidth measurements: With the launch of bandwidth related metrics, Network performance monitor's log analytics based approach wasn't effective in bandwidth monitoring for ExpressRoute customers. This capability is now not available in Connection monitor.

Prerequisites

• Ensure that Network Watcher is enabled in the subscription and region of the Log Analytics workspace. If not done, you see an error stating "Before you attempt to migrate, enable Network watcher extension in subscription and location of LA workspace selected."
• In case Azure virtual machine (VM) is in a different region/subscription than Log Analytics workspace that's used as an endpoint, make sure Network Watcher is enabled for that subscription and region.
• Azure virtual machines with Log Analytics agents installed must be enabled with the Network Watcher extension.

Migrate the tests

To migrate the tests from Network performance monitor to Connection monitor, follow these steps:

1. In Network Watcher, select Connection monitor, and then select the Import tests from NPM tab.

   

2. In the drop-down lists, select your subscription and workspace, and then select the Network performance monitor feature you want to migrate.

3. Select Import to migrate the tests.

   • If Network performance monitor isn't enabled on the workspace, you see an error stating "No valid NPM config found".
   • If no tests exist in the feature you chose in step 2, you see an error stating "Workspace selected doesn't have <feature> config".
   • If there are no valid tests, you see an error stating "Workspace selected does not have valid tests"
   • Your tests might contain agents that are no longer active, but have been active in the past. You'll see an error stating "Few tests contain agents that are no longer active. These agents might be running in the past but are shut down/not running anymore. Enable agents and migrate to Connection monitor. Select continue to migrate the tests that do not contain agents that are not active."

After the migration begins, the following changes take place:

• A new connection monitor resource is created.
  • One connection monitor per region and subscription is created. For tests with on-premises agents, the new connection monitor name is formatted as <workspaceName>_<workspace_region_name>. For tests with Azure agents, the new connection monitor name is formatted as <workspaceName>_<Azure_region_name>.
  • Monitoring data is now stored in the same Log Analytics workspace in which Network performance monitor is enabled, in new tables called NWConnectionMonitorTestResult table and NWConnectionMonitorPathResult table.
  • The test name is carried forward as the test group name. The test description isn't migrated.
  • Source and destination endpoints are created and used in the new test group. For on-premises agents, the endpoints are formatted as <workspaceName>_<FQDN of on-premises machine>. The Agent description isn't migrated.
  • Destination port and probing interval are moved to a test configuration called TC_<protocol>_<port> and TC_<protocol>_<port>_AppThresholds. The protocol is set based on the port values. For ICMP, the test configurations are named as TC_<protocol> and TC_<protocol>_AppThresholds. Success thresholds and other optional properties if set, are migrated, otherwise are left blank.
  • If the migrating tests contain agents that aren't running, you need to enable the agents and migrate again.
• Network performance monitor isn't disabled, so the migrated tests can continue to send data to the NetworkMonitoring table, NWConnectionMonitorTestResult table and NWConnectionMonitorPathResult table. This approach ensures that existing log-based alerts and integrations are unaffected.
• The newly created connection monitor is visible in Connection monitor.

After the migration, be sure to:

• Manually disable the tests in Network performance monitor. Until you do so, you continue to be charged for them.
• While you're disabling Network performance monitor, re-create your alerts on the NWConnectionMonitorTestResult and NWConnectionMonitorPathResult tables or use metrics.
• Migrate any external integrations to the NWConnectionMonitorTestResult and NWConnectionMonitorPathResult tables. Examples of external integrations are dashboards in Power BI and Grafana, and integrations with Security Information and Event Management (SIEM) systems.

Common errors encountered

The following table list common errors that you might encounter during the migration:

Related content

• Migrate from Connection monitor (classic) to Connection monitor.
• Create a connection monitor using the Azure portal.