Netzwerkleistungsmonitor-Lösung: häufig gestellte Fragen

Network Performance Monitor symbol

Wichtig

Ab dem 1. Juli 2021 ist es nicht mehr möglich, neue Tests in einem vorhandenen Arbeitsbereich hinzufügen oder einen neuen Arbeitsbereich im Netzwerkleistungsmonitor zu aktivieren. Sie können weiterhin die Tests verwenden, die vor dem 1. Juli 2021 erstellt wurden. Migrieren Sie Ihre Tests vor dem 29. Februar 2024 aus dem Netzwerkleistungsmonitor zum neuen Verbindungsmonitor in Azure Network Watcher, um die Dienstunterbrechungen im Zusammenhang mit Ihren aktuellen Workloads zu minimieren.

Dieser Artikel umfasst die häufig gestellten Fragen (FAQs) zum Netzwerkleistungsmonitor (NPM) in Azure.

Der Netzwerkleistungsmonitor ist eine cloudbasierte hybride Netzwerküberwachungslösung, mit der Sie die Netzwerkleistung zwischen verschiedenen Punkten in Ihrer Netzwerkinfrastruktur überwachen können. Zudem können Sie die Netzwerkkonnektivität mit Dienst- und Anwendungsendpunkten und die Leistung von Azure ExpressRoute überwachen.

Der Netzwerkleistungsmonitor erkennt Netzwerkprobleme wie ins Nichts führenden Datenverkehr (Blackholing), Routingfehler und Probleme, die mit herkömmlichen Netzwerküberwachungsmethoden nicht erkannt werden können. Die Lösung generiert Warnungen und benachrichtigt Sie, sobald ein Schwellenwert für eine Netzwerkverbindung überschritten wird. Sie gewährleistet außerdem das rechtzeitige Erkennen von Leistungsproblemen im Netzwerk und ordnet die Ursache des Problems einem bestimmten Netzwerksegment oder Gerät zu.

Weitere Informationen zu den verschiedenen vom Netzwerkleistungsmonitor unterstützten Funktionen sind online verfügbar.

Einrichten und Konfigurieren von Agents

Welche Plattformanforderungen gelten für die vom Netzwerkleistungsmonitor zur Überwachung verwendeten Knoten?

Nachfolgend sind die Plattformanforderungen für die verschiedenen Funktionen des Netzwerkleistungsmonitors aufgeführt:

  • Die Funktionen „Systemmonitor“ und „Dienstkonnektivitätsmonitor“ des Netzwerkleistungsmonitors unterstützen Windows Server sowie Windows-Desktop- und Windows-Clientbetriebssysteme. Windows Server-Betriebssystemversionen werden ab 2008 SP1 unterstützt. Die unterstützten Desktop- und Clientversionen von Windows sind Windows 10, Windows 8.1, Windows 8 und Windows 7.
  • Die Funktion „ExpressRoute-Monitor“ des Netzwerkleistungsmonitors unterstützt nur das Windows Server-Betriebssystem (2008 SP1 oder höher).

Kann ich Computer als Überwachungsknoten im Netzwerkleistungsmonitor verwenden?

Die Funktion zum Überwachen von Netzwerken mithilfe von Linux-basierten Knoten ist jetzt allgemein verfügbar. Greifen Sie hier auf den Agent zu.

Welche Größenanforderungen gelten für die vom Netzwerkleistungsmonitor zur Überwachung verwendeten Knoten?

Zur Ausführung der Netzwerkleistungsmonitor-Lösung auf virtuellen Knotencomputern zum Überwachen von Netzwerken müssen die Knoten mindestens einen Speicher von 500 MB und einen Kern aufweisen. Zum Ausführen des Netzwerkleistungsmonitors müssen Sie keine separaten Knoten verwenden. Die Lösung kann auf Knoten ausgeführt werden, auf denen andere Workloads ausgeführt werden. Die Lösung bietet die Möglichkeit, den Überwachungsprozess zu beenden, falls er mehr als 5% der CPU-Ressourcen nutzt.

Soll ich zur Verwendung des Netzwerkleistungsmonitors die Knoten als Direkt-Agent oder über System Center Operations Manager verbinden?

Die beiden Funktionen „Systemmonitor“ und „Dienstkonnektivitätsmonitor“ unterstützen Knoten, die als Direkt-Agent sowie über Operations Manager verbunden werden.

Für die Funktion „ExpressRoute-Monitor“ sollten die Azure-Knoten nur als Direkt-Agents verbunden werden. Azure-Knoten, die über Operations Manager verbunden werden, werden nicht unterstützt. Lokale Knoten werden zur Überwachung einer ExpressRoute-Leitung unterstützt, wenn sie als Direkt-Agents und über Operations Manager verbunden sind.

Welches Protokoll, TCP oder ICMP, sollte für die Überwachung ausgewählt werden?

Wenn Sie Ihr Netzwerk mithilfe Windows Server-basierter Knoten überwachen, sollten Sie TCP als Überwachungsprotokoll verwenden, da es eine höhere Genauigkeit bietet.

ICMP wird für Windows-Knoten mit Desktop-/Clientbetriebssystemen empfohlen. Auf dieser Plattform können keine TCP-Daten über RAW-Sockets gesendet werden, die NPM zum Ermitteln der Netzwerktopologie verwendet.

Weitere Informationen zu den jeweiligen Vorteilen der einzelnen Protokolle finden Sie hier.

Wie kann ich einen Knoten zur Unterstützung der Überwachung mithilfe des TCP-Protokolls konfigurieren?

Damit der Knoten die Überwachung mithilfe des TCP-Protokolls unterstützt, ist Folgendes zu beachten:

  • Stellen Sie sicher, dass als Plattform für den Knoten Windows Server (2008 SP1 oder höher) verwendet wird.
  • Führen Sie das PowerShell-Skript EnableRules.ps1 auf dem Knoten aus. Weitere Informationen finden Sie in diesen Anweisungen.

Wie kann ich den vom Netzwerkleistungsmonitor zur Überwachung verwendeten TCP-Port ändern?

Sie können den vom Netzwerkleistungsmonitor zur Überwachung verwendeten TCP-Port ändern, indem Sie das Skript EnableRules.ps1 ausführen. Sie müssen die Nummer des zu verwendenden Ports als Parameter eingeben. Um TCP beispielsweise an Port 8060 zu aktivieren, führen Sie EnableRules.ps1 8060 aus. Stellen Sie sicher, dass Sie den gleichen TCP-Port auf allen zur Überwachung verwendeten Knoten verwenden.

Das Skript konfiguriert nur die lokale Windows-Firewall. Wenn Sie Netzwerkfirewall- oder Netzwerksicherheitsgruppen-Regeln (NSG) definiert haben, achten Sie darauf, dass sie den Datenverkehr für den vom Netzwerkleistungsmonitor verwendeten TCP-Port zulassen.

Wie viele Agents sollte ich verwenden?

Sie sollten mindestens einen Agent für jedes Subnetz verwenden, das Sie überwachen möchten.

Was ist die maximale Anzahl von Agents, die ich verwenden kann, bevor der Fehler „...Sie haben Ihr Konfigurationslimit erreicht“ angezeigt wird?

NPM beschränkt die Anzahl von IPs auf 5.000 IPs pro Arbeitsbereich. Wenn ein Knoten sowohl IPv4- als auch IPv6-Adressen besitzt, wird dies als 2 IPs für diesen Knoten gezählt. Daher würde dieser Grenzwert von 5.000 IPs die Obergrenze für die Anzahl der Agents bestimmen. Sie können die inaktiven Agenten von der Registerkarte "Knoten" in NPM >> Konfigurieren löschen. NPM pflegt außerdem einen Verlauf aller IPs, die jemals der VM zugwiesen wurden, die den Agent hostet, und diese werden auch als separate IPs gezählt, die zu dieser Obergrenze von 5.000 IPs beitragen. Um IPs für Ihren Arbeitsbereich freizugeben, können Sie die Seite „Knoten“ verwenden, um die IPs zu löschen, die nicht verwendet werden.

Überwachung

Wie werden Verlust und Latenz berechnet?

Quell-Agents senden TCP SYN-Anforderungen (wenn TCP als Protokoll zur Überwachung ausgewählt ist) oder ICMP ECHO-Anforderungen (wenn ICMP als Protokoll zur Überwachung ausgewählt ist) in regelmäßigen Abständen an die Ziel-IP-Adresse, um sicherzustellen, dass alle Pfade zwischen der Kombination aus Quell- und Ziel-IP-Adresse abgedeckt sind. Der Prozentsatz der empfangenen Pakete und die Roundtripzeit der Pakete werden gemessen, um Verlust und Latenz der einzelnen Pfade zu berechnen. Diese Daten werden für das Abrufintervall und für alle Pfade aggregiert, um die aggregierten Werte von Verlust und Latenz für die IP-Kombination für das bestimmte Abrufintervall zu erhalten.

Mit welcher Häufigkeit sendet der Quell-Agent Pakete zur Überwachung an das Ziel?

Für die Funktionen Systemmonitor und ExpressRoute-Monitor sendet die Quelle alle 5 Sekunden Pakete und erfasst die Netzwerkmessungen. Diese Daten werden über ein Abrufintervall von 3 Minuten aggregiert, um die Durchschnitts- und Spitzenwerte von Verlust und Latenz zu berechnen. Für die Funktion Dienstkonnektivitätsmonitor ergibt sich die Häufigkeit des Sendens der Pakete zur Netzwerkmessung durch die Häufigkeit, die der Benutzer beim Konfigurieren des Tests für den jeweiligen Test eingibt.

Wie viele Pakete werden zur Überwachung gesendet?

Die Anzahl der Pakete, die in einem Abruf vom Quell-Agent an das Ziel gesendet werden, ist anpassbar und wird durch den proprietären Algorithmus festgelegt, der sich bei verschiedenen Netzwerktopologien unterscheiden kann. Je höher die Anzahl der Netzwerkpfade zwischen der Kombination aus Quell- und Ziel-ID, desto höher die Anzahl der gesendeten Pakete. Das System stellt sicher, dass alle Pfade zwischen der Kombination aus Quell- und Ziel-ID abgedeckt sind.

Wie ermittelt der Netzwerkleistungsmonitor die Netzwerktopologie zwischen der Quelle und dem Ziel?

Der Netzwerkleistungsmonitor verwendet einen proprietären Algorithmus basierend auf Traceroute, um alle Pfade und Hops zwischen der Quelle und dem Ziel zu ermitteln.

Bietet der Netzwerkleistungsmonitor Informationen auf Routing- und Switchingebene?

Obwohl der Netzwerkleistungsmonitor alle möglichen Routen zwischen dem Quell-Agent und dem Ziel erkennen kann, sind die jeweiligen Routen der Pakete, die von den spezifischen Workloads gesendet wurden, nicht zu entnehmen. Mit der Lösung können Sie die Pfade und die zugrunde liegenden Netzwerkhops ermitteln, die zu einer höheren Latenz als erwartet führen.

Warum sind einige Pfade fehlerhaft?

Zwischen der Quell- und der Ziel-ID können verschiedene Netzwerkpfade vorhanden sein, und die einzelnen Pfade können unterschiedliche Werte für Verlust und Latenz aufweisen. Der Netzwerkleistungsmonitor markiert die Pfade als fehlerhaft (rot gekennzeichnet), deren Werte für Verlust und/oder Latenz größer sind als der entsprechende in der Überwachungskonfiguration festgelegte Schwellenwert.

Was bedeutet ein rot gekennzeichneter Hop in der Netzwerktopologiekarte?

Wenn ein Hop rot gekennzeichnet ist, heißt das, dass er Teil mindestens eines fehlerhaften Pfads ist. Der Netzwerkleistungsmonitor markiert die Pfade nur als fehlerhaft, der Integritätsstatus der einzelnen Pfade wird jedoch nicht gesondert angegeben. Die problematischen Hops können Sie ermitteln, indem Sie die Latenz der einzelnen Hops anzeigen und die Hops isolieren, deren Latenz höher als erwartet ausfällt.

Wie funktioniert die Fehlerlokalisierung im Systemmonitor?

Der Netzwerkleistungsmonitor verwendet eine Wahrscheinlichkeitsmethode, um den einzelnen Netzwerkpfaden, Netzwerksegmenten und den zugehörigen Netzwerkhops basierend auf der Anzahl der fehlerhaften Pfade, zu denen sie gehören, Fehlerwahrscheinlichkeiten zuzuweisen. Wenn die Netzwerksegmente und Netzwerkhops zu einer höheren Anzahl von fehlerhaften Pfaden gehören, steigt auch die zugewiesene Fehlerwahrscheinlichkeit. Dieser Algorithmus lässt sich am besten bei vielen Knoten anwenden, die über einen NPM-Agent miteinander verbunden sind, da sich dadurch die Datenpunkte zur Berechnung der Fehlerwahrscheinlichkeiten erhöhen.

Welche Log Analytics-Standardabfragen für Warnungen gibt es?

Abfrage des Systemmonitors

NetworkMonitoring
 | where (SubType == "SubNetwork" or SubType == "NetworkPath") 
 | where (LossHealthState == "Unhealthy" or LatencyHealthState == "Unhealthy") and RuleName == "<<your rule name>>"

Abfrage des Dienstkonnektivitätsmonitors

NetworkMonitoring
 | where (SubType == "EndpointHealth" or SubType == "EndpointPath")
 | where (LossHealthState == "Unhealthy" or LatencyHealthState == "Unhealthy" or ServiceResponseHealthState == "Unhealthy" or LatencyHealthState == "Unhealthy") and TestName == "<<your test name>>"

Abfragen des ExpressRoute-Monitors: Verbindungsabfrage

NetworkMonitoring
 | where (SubType == "ERCircuitTotalUtilization") and (UtilizationHealthState == "Unhealthy") and CircuitResourceId == "<<your circuit resource ID>>"

Privates Peering

NetworkMonitoring
 | where (SubType == "ExpressRoutePeering" or SubType == "ERVNetConnectionUtilization" or SubType == "ExpressRoutePath")   
 | where (LossHealthState == "Unhealthy" or LatencyHealthState == "Unhealthy" or UtilizationHealthState == "Unhealthy") and CircuitName == "<<your circuit name>>" and VirtualNetwork == "<<vnet name>>"

Microsoft-Peering

NetworkMonitoring
 | where (SubType == "ExpressRoutePeering" or SubType == "ERMSPeeringUtilization" or SubType == "ExpressRoutePath")
 | where (LossHealthState == "Unhealthy" or LatencyHealthState == "Unhealthy" or UtilizationHealthState == "Unhealthy") and CircuitName == ""<<your circuit name>>" and PeeringType == "MicrosoftPeering"

Allgemeine Abfrage

NetworkMonitoring
 | where (SubType == "ExpressRoutePeering" or SubType == "ERVNetConnectionUtilization" or SubType == "ERMSPeeringUtilization" or SubType == "ExpressRoutePath")
 | where (LossHealthState == "Unhealthy" or LatencyHealthState == "Unhealthy" or UtilizationHealthState == "Unhealthy")

Kann der Netzwerkleistungsmonitor Router und Server als einzelne Geräte überwachen?

Der Netzwerkleistungsmonitor ermittelt nur die IP-Adresse und den Hostnamen der zugrunde liegenden Netzwerkhops (Switches, Router, Server usw.) zwischen der Quell- und der Ziel-IP-Adresse. Zudem wird die Latenz zwischen diesen identifizierten Hops ermittelt. Diese zugrunde liegenden Hops werden nicht einzeln überwacht.

Kann mit dem Netzwerkleistungsmonitor die Netzwerkkonnektivität zwischen Azure und AWS überwacht werden?

Ja. Weitere Informationen finden Sie im Artikel Monitor Azure, AWS, and on-premises networks using NPM (Überwachen von Azure, AWS und lokalen Netzwerken mit dem Netzwerkleistungsmonitor).

Gibt die ExpressRoute-Bandbreitennutzung die eingehende oder die ausgehende Bandbreite an?

Die Bandbreitennutzung ist die Summe der eingehenden und ausgehenden Bandbreite. Sie wird in Bit/s angegeben.

Können Informationen zur eingehenden und ausgehenden Bandbreite für ExpressRoute erfasst werden?

Eingehende und ausgehende Werte können für die primäre und die sekundäre Bandbreite erfasst werden.

Verwenden Sie die folgende Abfrage in der Protokollsuche, um Informationen auf Ebene des Microsoft-Peerings abzurufen.

NetworkMonitoring
 | where SubType == "ERMSPeeringUtilization"
 | project CircuitName,PeeringName,BitsInPerSecond,BitsOutPerSecond 

Verwenden Sie die folgende Abfrage in der Protokollsuche, um Informationen auf Ebene des privaten Peerings abzurufen.

NetworkMonitoring
 | where SubType == "ERVNetConnectionUtilization"
 | project CircuitName,PeeringName,BitsInPerSecond,BitsOutPerSecond

Verwenden Sie die folgende Abfrage in der Protokollsuche, um Informationen auf Verbindungsebene abzurufen.

NetworkMonitoring
 | where SubType == "ERCircuitTotalUtilization"
 | project CircuitName, BitsInPerSecond, BitsOutPerSecond

Welche Regionen werden für den Systemmonitor des Netzwerkleistungsmonitors unterstützt?

Der Netzwerkleistungsmonitor kann die Konnektivität zwischen Netzwerken in jedem Teil der Welt von einem Arbeitsbereich aus überwachen, der in einer der unterstützten Regionen gehostet wird.

Welche Regionen werden für den Dienstkonnektivitätsmonitor des Netzwerkleistungsmonitors unterstützt?

Der Netzwerkleistungsmonitor kann die Konnektivität mit Diensten in jedem Teil der Welt von einem Arbeitsbereich aus überwachen, der in einer der unterstützten Regionen gehostet wird.

Welche Regionen werden für den ExpressRoute-Monitor des Netzwerkleistungsmonitors unterstützt?

Der Netzwerkleistungsmonitor kann die ExpressRoute-Leitungen in jeder Azure-Region überwachen. Zur Integration in den Netzwerkleistungsmonitor benötigen Sie einen Log Analytics-Arbeitsbereich, der in einer der unterstützten Regionen gehostet werden muss.

Problembehandlung

Warum sind einige Hops in der Netzwerktopologieansicht als unbekannt markiert?

Der Netzwerkleistungsmonitor verwendet eine geänderte Version von Traceroute, um die Topologie zwischen dem Quell-Agent und dem Ziel zu ermitteln. Ein unbekannter Hop gibt an, dass der Netzwerkhop nicht auf die Traceroute-Anforderung des Quell-Agents reagiert hat. Wenn drei aufeinanderfolgende Netzwerkhops nicht auf die Traceroute-Anforderung des Agents reagieren, markiert die Lösung die nicht reagierenden Hops als unbekannt und versucht nicht, weitere Hops zu ermitteln.

Ein Hop reagiert in einem der folgenden Szenarien möglicherweise nicht auf eine Traceroute-Anforderung:

  • Die Router wurden so konfiguriert, dass ihre Identität nicht angezeigt wird.
  • Die Netzwerkgeräte lassen keinen ICMP_TTL_EXCEEDED-Datenverkehr zu.
  • Die ICMP_TTL_EXCEEDED-Antwort vom Netzwerkgerät wird durch eine Firewall blockiert.

Wenn einer der Endpunkte in Azure liegt, zeigt Traceroute nicht identifizierte Hops an, da die Azure-Infrastruktur keine Identität für Traceroute offenlegt.

Ich erhalte Warnungen für fehlerhafte Tests, aber die hohen Werte werden im NPM-Diagramm zu Verlust und Latenz nicht angezeigt. Wie prüfe ich, was fehlerhaft ist?

NPM löst eine Warnung aus, wenn die End-to-End-Latenz zwischen Quelle und Ziel den Schwellenwert für einen beliebigen Pfad dazwischen überschreitet. Einige Netzwerke verfügen über mehrere Pfade, die dieselbe Quelle und dasselbe Ziel verbinden. NPM löst eine Warnung aus, wenn ein beliebiger Pfad fehlerhaft ist. Die in den Diagrammen gezeigte Darstellung von Verlust und Latenz ist der Durchschnittswert für alle Pfade und gibt daher möglicherweise nicht den genauen Wert eines einzelnen Pfads an. Suchen Sie in der Warnung nach der Spalte „SubType“, um zu verstehen, wo der Schwellenwert überschritten wurde. Wenn das Problem durch einen Pfad verursacht wird, lautet der SubType-Wert „NetworkPath“ (für Systemmonitortests), „EndpointPath“ (für Dienstkonnektivitätsmonitor-Tests) und „ExpressRoutePath“ (für ExpressRoute-Monitortests).

Beispielabfrage zur Feststellung, ob der Pfad fehlerhaft ist:

NetworkMonitoring
 | where ( SubType == "ExpressRoutePath")
 | where (LossHealthState == "Unhealthy" or LatencyHealthState == "Unhealthy" or UtilizationHealthState == "Unhealthy") and CircuitResourceID =="<your ER circuit ID>" and ConnectionResourceId == "<your ER connection resource id>"
 | project SubType, LossHealthState, LatencyHealthState, MedianLatency

Warum wird mein Test als fehlerhaft angezeigt, aber die Topologie nicht?

NPM überwacht End-to-End-Verlust, Latenz und Topologie mit unterschiedlichen Intervallen. Verlust und Latenz werden einmal alle 5 Sekunden gemessen und alle drei Minuten aggregiert (für Systemmonitor und ExpressRoute-Monitor), während die Topologie alle 10 Minuten mit Traceroute berechnet wird. Die Topologie wird z.B. zwischen 3:44 Uhr und 4:04 Uhr drei Mal aktualisiert (3:44 Uhr, 3:54 Uhr, 4:04 Uhr), aber Verlust und Latenz sieben Mal (3:44 Uhr, 3:47 Uhr, 3:50 Uhr, 3:53 Uhr, 3:56 Uhr, 3:59 Uhr, 4:02 Uhr). Die um 3:54 Uhr generierte Topologie wird für Verlust und Latenz gerendert, die um 3:56 Uhr, 3:59 Uhr und 4:02 Uhr berechnet wird. Nehmen wir an, Sie erhalten eine Warnung, dass Ihre Expressroute-Verbindung um 3:59 Uhr fehlerhaft war. Sie melden sich beim NPM an und versuchen, die Topologiezeit auf 3:59 Uhr festzulegen. NPM rendert die um 3:54 Uhr generierte Topologie. Um die letzte bekannte Topologie Ihres Netzwerks zu verstehen, vergleichen Sie die Felder TimeProcessed (Zeit, zu der Verlust und Latenz berechnet wurden) und TracerouteCompletedTime (Zeit, zu der die Topologie berechnet wurde).

Was ist der Unterschied zwischen den Feldern E2EMedianLatency und AvgHopLatencyList in der Tabelle NetworkMonitoring?

E2EMedianLatency ist die Latenz, die alle drei Minuten nach Aggregieren der Ergebnisse der TCP-Ping-Tests aktualisiert wird, während AvgHopLatencyList alle 10 Minuten auf Basis von Traceroute aktualisiert wird. Um die genaue Zeit zu kennen, zu der E2EMedianLatency berechnet wurde, verwenden Sie das Feld TimeProcessed. Um die genaue Zeit zu kennen, zu der Traceroute AvgHopLatencyList abgeschlossen und aktualisiert hat, verwenden Sie das Feld TracerouteCompletedTime.

Warum unterscheiden sich Hop-by-Hop-Latenzzahlen von HopLatencyValues?

HopLatencyValues sind die Quelle für den Endpunkt. Beispiel: Hops – A, B, C. AvgHopLatency – 10, 15, 20. Dies bedeutet, dass die Latenz von Quelle zu A = 10, Latenz von Quelle zu B = 15 und die Latenz von Quelle zu C 20 beträgt. Die Benutzeroberfläche berechnet die A-B-Hop-Latenz in der Topologie als 5.

Die Lösung zeigt einen Verlust von 100 % an, obwohl eine Verbindung zwischen der Quelle und dem Ziel besteht.

Das kann der Fall sein, wenn die Hostfirewall oder die zwischengeschaltete Firewall (Netzwerkfirewall oder Azure-NSG) die Kommunikation zwischen dem Quell-Agent und dem Ziel über den Port blockiert, der vom Netzwerkleistungsmonitor zur Überwachung verwendet wird (standardmäßig handelt es sich um Port 8084, es sei denn, der Kunde hat dies geändert).

  • Um zu überprüfen, ob die Host-Firewall die Kommunikation auf dem erforderlichen Port nicht blockiert, zeigen Sie den Integritätsstatus der Quell- und Zielknoten in der folgenden Ansicht an: Netzwerkleistungsmonitor -> Konfiguration -> Knoten. Wenn sie fehlerhaft sind, sehen Sie sich die Anweisungen an, und nehmen Sie Korrekturmaßnahmen vor. Wenn die Knoten fehlerfrei sind, fahren Sie mit dem nächsten Schritt fort.
  • Um sicherzustellen, dass keine zwischengeschaltete Netzwerkfirewall oder Azure-NSG die Kommunikation am entsprechenden Port blockiert, verwenden Sie wie folgt das Drittanbieterhilfsprogramm PsPing:
    • Das Hilfsprogramm PsPing ist hier als Download verfügbar.
    • Führen Sie im Quellknoten den folgenden Befehl aus.
      • psping -n 15 <IP-Adresse des Zielknotens>:. Standardmäßig verwendet der Netzwerkleistungsmonitor Port 8084. Wenn Sie den Port explizit über das Skript „EnableRules.ps1“ geändert haben, geben Sie die verwendete benutzerdefinierte Portnummer ein. Dies ist ein Ping vom Azure-Computer an den lokalen Computer.
  • Überprüfen Sie, ob die Pings erfolgreich ausgeführt werden. Wenn dies nicht der Fall ist, bedeutet das, dass eine zwischengeschaltete Netzwerkfirewall oder Azure-NSG den Datenverkehr an diesem Port blockiert.
  • Führen Sie nun den Befehl von der Zielknoten-ID zur Quellknoten-ID aus.

Es ist Verlust von Knoten A zu Knoten B zu verzeichnen, jedoch nicht von Knoten B zu Knoten A. Warum?

Da sich die Netzwerkpfade von A zu B von den Netzwerkpfaden von B zu A unterscheiden können, können sich unterschiedliche Werte für Verlust und Latenz ergeben.

Warum werden nicht alle meine ExpressRoute-Leitungen und -Peeringverbindungen ermittelt?

NPM erkennt jetzt ExpressRoute-Leitungen und -Peeringverbindungen in allen Abonnements, auf die der Benutzer Zugriff hat. Wählen Sie alle Abonnements aus, in denen Ihre Express Route-Ressourcen verknüpft sind, und aktivieren Sie die Überwachung für jede ermittelte Ressource. NPM sucht nach Verbindungsobjekten, wenn privates Peering ermittelt wird. Überprüfen Sie daher, ob ein VNET mit Ihrem Peering verbunden ist. NPM erkennt keine Leitungen und Peerings, die sich in einem anderen Mandanten befinden als der Log Analytics-Arbeitsbereich.

In der Funktion ExpressRoute-Monitor wird die Diagnosemeldung „Traffic is not passing through ANY circuit“ (Der Datenverkehr wird über KEINE Verbindung geleitet) angezeigt. Was bedeutet das?

In einem möglichen Szenario besteht eine fehlerfreie Verbindung zwischen den lokalen und Azure-Knoten, der Datenverkehr wird jedoch nicht über die ExpressRoute-Leitung geleitet, die zur Überwachung durch den Netzwerkleistungsmonitor konfiguriert ist.

Möglich sind folgende Ursachen:

  • Die ExpressRoute-Leitung ist nicht verfügbar.
  • Die Routenfilter sind so konfiguriert, dass andere Routen (z.B. eine VPN-Verbindung oder eine andere ExpressRoute-Leitung) Priorität vor der vorgesehenen ExpressRoute-Leitung haben.
  • Die zur Überwachung der ExpressRoute-Leitung in der Überwachungskonfiguration ausgewählten lokalen und Azure-Knoten sind über die vorgesehene ExpressRoute-Leitung nicht miteinander verbunden. Vergewissern Sie sich, dass Sie die richtigen Knoten ausgewählt haben, die über die zu überwachende ExpressRoute-Leitung miteinander verbunden sind.

Warum meldet der ExpressRoute-Monitor meine Leitung bzw. Peeringverbindung als fehlerhaft, obwohl diese verfügbar ist und Daten übergibt?

Der ExpressRoute-Monitor vergleicht die vom Agent bzw. Dienst gemeldeten Netzwerkleistungswerte (Verlust, Latenz und Bandbreitenauslastung) mit den bei der Konfiguration festgelegten Schwellenwerten. Wenn die gemeldete Bandbreitenauslastung einer Leitung größer ist als der in der Konfiguration festgelegte Schwellenwert, wird die Leitung als fehlerhaft gekennzeichnet. Wenn die gemeldeten Werte für Verlust, Latenz oder Bandbreitenauslastung eines Peerings größer sind als die in der Konfiguration festgelegten Schwellenwerte, wird das Peering als fehlerhaft gekennzeichnet. NPM verwendet keine Metriken oder andere Arten von Daten, um Entscheidungen über den Integritätszustand zu treffen.

Warum meldet der ExpressRoute-Monitor bei der Bandbreitenauslastung einen Wert, der sich von der Metrik für ein- und ausgehende Bits unterscheidet?

Im ExpressRoute-Monitor ist die Bandbreitenauslastung der Durchschnitt der ein- und ausgehenden Bandbreite in den letzten 20 Minuten. Dieser Wert wird in Bits/s ausgedrückt. Bei ExpressRoute-Metriken sind ein- und ausgehende Bits minutenbasierte Datenpunkte. Intern wird für beide Angaben dasselbe Dataset verwendet, aber die Aggregation erfolgt in NPM und ExpressRoute-Metriken unterschiedlich. Um eine differenzierte, minutengenaue Überwachung und schnelle Warnungen zu erhalten, empfiehlt es sich, Warnungen direkt für die ExpressRoute-Metriken festzulegen.

Beim Konfigurieren der Überwachung der ExpressRoute-Leitung werden die Azure-Knoten nicht erkannt

Dies kann der Fall sein, wenn die Azure-Knoten über Operations Manager verbunden werden. Mit der Funktion „ExpressRoute-Monitor“ werden nur die Azure-Knoten unterstützt, die als Direkt-Agents verbunden werden.

Ich kann keine ExpressRoute-Leitungen im OMS-Portal ermitteln

Obwohl der Netzwerkleistungsmonitor über das Azure-Portal und über das OMS-Portal verwendet werden kann, wird die Ermittlung von Leitungen in der Funktion ExpressRoute-Monitor nur über das Azure-Portal ausgeführt. Wenn die Leitungen über das Azure-Portal ermittelt wurden, kann die Funktion in beiden Portalen verwendet werden.

In der Funktion Dienstkonnektivitätsmonitor werden Dienstantwortzeit, Netzwerkverlust und Latenz als nicht verfügbar angezeigt

Dies ist in folgenden Fällen möglich:

  • Der Dienst ist nicht verfügbar.
  • Der Knoten, der zum Überprüfen der Netzwerkkonnektivität mit dem Dienst verwendet wird, ist nicht verfügbar.
  • In die Testkonfiguration wurde ein falsches Ziel eingegeben.
  • Der Knoten verfügt nicht über Netzwerkkonnektivität.

In der Funktion Dienstkonnektivitätsmonitor wird eine gültige Dienstantwortzeit angezeigt, Netzwerkverlust und Latenz werden jedoch als nicht verfügbar angezeigt

Dies ist in folgenden Fällen möglich:

  • Wenn es sich bei dem Knoten, der zum Überprüfen der Netzwerkkonnektivität mit dem Dienst verwendet wird, um einen Windows-Clientcomputer handelt, blockiert der Zieldienst möglicherweise ICMP-Anforderungen, oder eine Netzwerkfirewall blockiert ICMP-Anforderungen des Knotens.
  • Das Kontrollkästchen „Netzwerkmessungen durchführen“ ist in der Testkonfiguration deaktiviert.

In der Funktion Dienstkonnektivitätsmonitor wird die Dienstantwortzeit als nicht verfügbar angezeigt, es sind jedoch gültige Angaben zu Netzwerkverlust und Latenz verfügbar

Dies kann der Fall sein, wenn der Zieldienst keine Webanwendung ist, der Test aber als Webtest konfiguriert ist. Bearbeiten Sie die Testkonfiguration, und wählen Sie für den Testtyp „Netzwerk“ anstelle von „Web“ aus.

Sonstiges

Ist die Leistung auf dem zur Überwachung verwendeten Knoten beeinträchtigt?

Der Prozess des Netzwerkleistungsmonitors ist so konfiguriert, dass er beendet wird, wenn mehr als 5 % der CPU-Ressourcen des Hosts genutzt werden. Dadurch wird sichergestellt, dass die Knoten weiterhin für die üblichen Workloads verwendet werden können, ohne dass die Leistung beeinträchtigt wird.

Bearbeitet der Netzwerkleistungsmonitor die Firewallregeln für die Überwachung?

Der Netzwerkleistungsmonitor erstellt nur eine lokale Windows-Firewallregel auf den Knoten, auf denen das PowerShell-Skript „EnableRules.ps1“ ausgeführt wird, sodass die Agents TCP-Verbindungen untereinander am angegebenen Port erstellen können. Die Lösung ändert keine Netzwerkfirewall- oder Netzwerksicherheitsgruppen-Regeln (NSG).

Wie kann ich die Integrität der Knoten überprüfen, die zur Überwachung verwendet werden?

Sie können den Integritätsstatus der für die Überwachung verwendeten Knoten in der folgenden Ansicht anzeigen: Netzwerkleistungsmonitor -> Konfiguration -> Knoten. Wenn ein Knoten fehlerhaft ist, können Sie die Fehlerdetails anzeigen und die empfohlene Aktion ausführen.

Kann der Netzwerkleistungsmonitor Latenzzeiten in Mikrosekunden melden?

Der Netzwerkleistungsmonitor rundet die Latenzzeiten in der Benutzeroberfläche und in Millisekunden. Die gleichen Daten werden mit einer höheren Granularität (manchmal mit bis zu vier Dezimalstellen) gespeichert.

Unterstützt der Netzwerkleistungsmonitor mehrfach vernetzte Knoten?

Nein. Für jeden NPM-Knoten ist ein dedizierter Log Analytics-Arbeitsbereich erforderlich.

Besitzt der Netzwerkleistungsmonitor zusätzliche Anforderungen für Linux?

Der OMS-Agent für Linux erfordert auch die Verwendung von GLIBC 2.14 oder höher.

Nächste Schritte