Netzwerkleistungsmonitor-Lösung: häufig gestellte Fragen

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).

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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")

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.

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).

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

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

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.

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.

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.

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.

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

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).

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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

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

Nächste Schritte

• Weitere Informationen zum Netzwerkleistungsmonitor finden Sie unter Netzwerkleistungsmonitor-Lösung in Azure.