Migrieren vom Netzwerkleistungsmonitor zum Verbindungsmonitor

In diesem Artikel erfahren Sie, wie Sie Ihre vorhandenen Tests von der Netzwerkleistungsüberwachung zum neuen Verbindungsmonitor ohne Ausfallzeiten migrieren. Weitere Informationen finden Sie unter Übersicht über den Verbindungsmonitor.

Hauptvorteile des neuen Verbindungsmonitors

Nachfolgend sind die wichtigsten Vorteile des neuen Verbindungsmonitors aufgeführt:

• Einheitliche Konnektivitätsüberwachung für Azure-Endpunkte und Hybridendpunkte

  • ARC-Server mit Azure Monitor-Agent-Unterstützung als Quell- und Zielendpunkte.

  • Unterstützung für abonnement-, arbeitsbereichs- und regionsübergreifende Überwachung.

  • Unterstützung von virtuellen Computern (VMs) und Skalierungsgruppen als Quell- und Zielendpunkte.

• Einfache Erfahrung mit vereinfachter Agent-Unterstützung

  • Einfache Azure Network Watcher-Erweiterung, die mit ARC-Endpunkten kompatibel ist.

  • Unterstützung für die Azure Monitor-Agent-Erweiterung mit aktivierten lokalen ARC-Endpunkten.

  • Automatisches Upgrade von Agents mit automatisierter Agent-Aktivierungsunterstützung.

• Visualisierung und Messung der End-to-End-Netzwerkpfadleistung mit der neuen Topologie (Vorschau)

  • Tiefe Einblicke in die Netzwerkleistungsmetriken mit synthetischer Überwachung über TCP-, ICMP- und HTTP-Protokolle.

  • Verbesserte Sichtbarkeit von End-to-End-Netzwerkpfaden und Verbindungen mit Wartezeit pro Hop und Pfadverlusten über Pfadkomponenten hinweg, Hervorhebung von Verbindungen mit hoher Wartezeit oder Paketverlusten.

  • Geometadaten und ASN-Daten, die über Internet-Hops hinweg verfügbar sind.

  • Heben Sie die Latenz der letzten Meile, der mittleren Meile und der letzten Meile mit Microsoft Edge Discovery hervor.

• Verbesserte Problembehandlung mit klaren, umsetzbaren Erkenntnissen

  • Schnelle Erkennung von Problemen mit der Netzwerkkonnektivität mit Warnmeldungen in Echtzeit.

  • Intelligente Einblicke in Änderungen über Netzwerkpfadkomponenten hinweg, um die zugrunde liegende Ursache für Konnektivitätsfehler hervorzuheben.

  • Identifizierung von Blockierungsregeln und Ressourcen, die für Konnektivitätsfehler an Endpunkten verantwortlich sind.

Netzwerkleistungsmonitor im Vergleich zum neuen Verbindungsmonitor

In der folgenden Tabelle werden der Netzwerkleistungsmonitor und der neue Verbindungsmonitor verglichen:

Wichtige Hinweise

Durch die Migration können die folgenden Ergebnisse erzielt werden:

• Die Funktion lokaler Agents und die Firewalleinstellungen bleiben unverändert erhalten. Es sind keine Änderungen erforderlich. Log Analytics-Agents, die auf Azure-VMs installiert sind, müssen durch die Network Watcher-Erweiterung ersetzt werden.
• Vorhandene Test werden „Verbindungsmonitor“ > „Testgruppe“ > „Testformat“ zugeordnet. Wählen Sie Bearbeiten aus, um die Eigenschaften des neuen Verbindungsmonitors anzuzeigen und zu ändern. Laden Sie eine Vorlage herunter, um Änderungen vorzunehmen, und übermitteln Sie sie mit Azure Resource Manager.
• Agents senden Daten sowohl an den Log Analytics-Arbeitsbereich als auch an Metriken.
• Datenüberwachung:
  • Daten in Log Analytics: Vor der Migration verbleiben die Daten im Arbeitsbereich, in dem der Netzwerkleistungsmonitor in der Tabelle „NetworkMonitoring“ konfiguriert ist. Nach der Migration werden die Daten in den Tabellen „NetworkMonitoring“, „NWConnectionMonitorTestResult“ und „NWConnectionMonitorPathResult“ im selben Arbeitsbereich gespeichert. Nach dem Deaktivieren der Tests im Netzwerkleistungsmonitor werden die Daten nur in den Tabellen „NWConnectionMonitorTestResult“ und „NWConnectionMonitorPathResult“ gespeichert.
  • Protokollbasierte Warnungen, Dashboards und Integrationen: Sie müssen die Abfragen anhand der neuen Tabellen „NWConnectionMonitorTestResult“ und „NWConnectionMonitorPathResult“ manuell bearbeiten. Informationen zum erneuten Erstellen der Warnungen in den Metriken finden Sie unter Metriken in Azure Monitor.
• Für ExpressRoute-Überwachung:
  • Vollständige Verluste und Latenzen: Dies ist im Verbindungsmonitor einfacher als im Netzwerkleistungsmonitor, da Sie nicht konfigurieren müssen, welche Verbindungen und Peerings überwacht werden sollen. Verbindungen im Pfad werden automatisch ermittelt, und Daten werden als Metriken zur Verfügung gestellt (schneller als bei Log Analytics, wo der Netzwerkleistungsmonitor die Ergebnisse gespeichert hat).
  • Bandbreitenmessungen: Mit der Einführung von Metriken bezüglich der Bandbreite hat sich der auf Log Analytics basierende Ansatz des Netzwerkleistungsmonitors bei der Bandbreitenüberwachung für ExpressRoute-Kunden als ineffizient erwiesen. Diese Funktion ist jetzt im Verbindungsmonitor nicht verfügbar.

Voraussetzungen

• Stellen Sie sicher, dass Network Watcher im Abonnement und in der Region des Log Analytics-Arbeitsbereichs aktiviert ist. Andernfalls wird die folgende Fehlermeldung angezeigt: „Bevor Sie die Migration starten, aktivieren Sie die Network Watcher-Erweiterung im Abonnement und am Standort des ausgewählten Log Analytics-Arbeitsbereichs.“
• Falls Sie eine Azure-VM verwenden, die einer anderen Region/einem anderen Abonnement angehört als die/dem, die/das der Log Analytics-Arbeitsbereich als Endpunkt verwendet, stellen Sie sicher, dass Network Watcher für dieses Abonnement und diese Region aktiviert ist.
• Virtuelle Azure-Computer, auf denen Log Analytics-Agents installiert sind, müssen mit der Network Watcher-Erweiterung aktiviert werden.

Migrieren der Tests

Führen Sie die folgenden Schritte aus, um vom Netzwerkleistungsmonitor zum Verbindungsmonitor zu migrieren:

1. Wählen Sie in Network Watcher die Option Verbindungsmonitor und anschließend die Registerkarte Tests aus dem NPM importieren aus.

   

2. Wählen Sie in den Dropdownlisten Ihr Abonnement und den Arbeitsbereich und dann das Netzwerkleistungsmonitor-Feature aus, das Sie migrieren möchten.

3. Wählen Sie zum Migrieren der Tests Importieren aus.

   • Wenn der Netzwerkleistungsmonitor für den Arbeitsbereich nicht aktiviert ist, wird die Fehlermeldung „Keine gültige Netzwerkleistungsmonitor-Konfiguration gefunden“ angezeigt.
   • Wenn in der Funktion, die Sie in Schritt 2 ausgewählt haben, keine Tests vorhanden sind, wird ein Fehler mit dem Hinweis angezeigt, dass <Funktion> im ausgewählten Arbeitsbereich nicht konfiguriert ist.
   • Wenn keine gültigen Tests verfügbar sind, wird ein Fehler mit dem Hinweis angezeigt, dass der ausgewählte Arbeitsbereich keine gültigen Tests enthält.
   • Ihre Tests können Agents enthalten, die nicht mehr aktiv sind, aber in der Vergangenheit aktiv waren. Es wird ein Fehler mit dem Hinweis angezeigt, dass nur einige Tests Agents enthalten, die nicht mehr aktiv sind. Diese Agents wurden möglicherweise in der Vergangenheit ausgeführt, sind aber jetzt heruntergefahren bzw. werden nicht mehr ausgeführt. Aktivieren Sie Agents, und migrieren Sie zum Verbindungsmonitor. Wählen Sie „Fortsetzen“ aus, um die Tests zu migrieren, die keine inaktiven Agents enthalten.

Nach dem Beginn der Migration werden die folgenden Änderungen durchgeführt:

• Es wird eine neue Verbindungsmonitorressource erstellt.
  • Pro Region und Abonnement wird ein Verbindungsmonitor erstellt. Bei Tests mit lokalen Agents weist der Name des neuen Verbindungsmonitors das Format <workspaceName>_<workspace_region_name> auf. Bei Tests mit Azure-Agents weist der Name des neuen Verbindungsmonitors das Format <workspaceName>_<Azure_region_name> auf.
  • Die Überwachungsdaten werden jetzt in dem Log Analytics-Arbeitsbereich, in dem der Netzwerkleistungsmonitor aktiviert ist, in neuen Tabellen namens „NWConnectionMonitorTestResult“ und „NWConnectionMonitorPathResult“ gespeichert.
  • Der Testname wird als Name der Testgruppe übernommen. Die Testbeschreibung wird nicht migriert.
  • Quell- und Zielendpunkte werden in der neuen Testgruppe erstellt und verwendet. Für lokale Agents werden die Endpunkte als <workspaceName>_<FQDN of on-premises machine> formatiert. Die Agent-Beschreibung wird nicht migriert.
  • Der Zielport und das Testintervall werden in eine Testkonfiguration namens TC_<protocol>_<port> und TC_<protocol>_<port>_AppThresholds verschoben. Das Protokoll wird anhand der Portwerte festgelegt. Für ICMP werden die Testkonfigurationen mit TC_<protocol> und TC_<protocol>_AppThresholds benannt. Falls Erfolgsschwellenwerte und andere optionale Eigenschaften festgelegt sind, werden sie migriert, andernfalls bleiben sie leer.
  • Wenn die Migrationstests Agents enthalten, die nicht ausgeführt werden, müssen Sie diese aktivieren und die Migration wiederholen.
• Der Netzwerkleistungsmonitor wird nicht deaktiviert, daher können die migrierten Tests weiterhin Daten an die Tabellen „NetworkMonitoring“, „NWConnectionMonitorTestResult“ und „NWConnectionMonitorPathResult“ senden. Dadurch wird sichergestellt, dass vorhandene protokollbasierte Warnungen und Integrationen nicht beeinträchtigt werden.
• Der neu erstellte Verbindungsmonitor wird unter „Verbindungsmonitor“ angezeigt.

Achten Sie nach der Migration auf Folgendes:

• Deaktivieren Sie die Tests im Netzwerkleistungsmonitor manuell. Bis dies geschehen ist, werden Ihnen diese weiterhin in Rechnung gestellt.
• Wenn Sie den Netzwerkleistungsmonitor deaktivieren, erstellen Sie Ihre Warnungen für die Tabellen „NWConnectionMonitorTestResult“ und „NWConnectionMonitorPathResult“ neu, oder verwenden Sie Metriken.
• Migrieren Sie externe Integrationen zu den Tabellen „NWConnectionMonitorTestResult“ und „NWConnectionMonitorPathResult“. Beispiele für externe Integrationen sind Dashboards in Power BI und Grafana sowie Integrationen mit SIEM-Systemen (Security Information and Event Management).

Mögliche allgemeine Fehler

Die folgende Tabelle enthält allgemeine Fehler, die während der Migration auftreten können:

Zugehöriger Inhalt

• Migrieren von Verbindungsmonitor (klassisch) zu Verbindungsmonitor
• Erstellen eines Verbindungsmonitors mithilfe des Azure-Portals