Veelgestelde vragen over de oplossing Netwerkprestatiemeter

Network Performance Monitor symbol

Belangrijk

Vanaf 1 juli 2021 kunt u geen nieuwe tests toevoegen in een bestaande werkruimte of een nieuwe werkruimte inschakelen in Network Performance Monitor. U kunt de tests die vóór 1 juli 2021 zijn gemaakt, blijven gebruiken. Migreer uw tests van Network Performance Monitor naar de nieuwe Verbindingsmonitor in Azure Network Watcher vóór 29 februari 2024 om serviceonderbreking voor uw huidige workloads te minimaliseren.

In dit artikel worden de veelgestelde vragen (Veelgestelde vragen) over Network Performance Monitor (NPM) in Azure vastgelegd

Netwerkprestatiemeter is een cloudgebaseerde hybride netwerkbewakingsoplossing waarmee u de netwerkprestaties tussen verschillende punten in uw netwerkinfrastructuur kunt bewaken. Het helpt u ook bij het bewaken van de netwerkverbinding met service- en toepassingseindpunten en het bewaken van de prestaties van Azure ExpressRoute.

Netwerkprestatiemeter detecteert netwerkproblemen zoals verkeer blackholing, routeringsfouten en problemen die conventionele netwerkbewakingsmethoden niet kunnen detecteren. De oplossing genereert waarschuwingen en waarschuwt u als een drempelwaarde voor een netwerkverbinding wordt overschreden. Bovendien worden problemen met de netwerkprestaties tijdig gedetecteerd en wordt de oorzaak van het probleem op een bepaald netwerksegment of apparaat opgespoord.

Meer informatie over de verschillende mogelijkheden die worden ondersteund door Network Performance Monitor , is online beschikbaar.

Agents instellen en configureren

Wat zijn de platformvereisten voor de knooppunten die moeten worden gebruikt voor bewaking door NPM?

Hieronder vindt u de platformvereisten voor de verschillende mogelijkheden van NPM:

  • De mogelijkheden van PERFORMANCE Monitor en Service Connectivity Monitor van NPM ondersteunen zowel Windows server als Windows desktops/clientbesturingssystemen. Windows ondersteunde versies van serverbesturingssystemen zijn 2008 SP1 of hoger. Windows ondersteunde bureaubladen/clientversies zijn Windows 10, Windows 8.1, Windows 8 en Windows 7.
  • De ExpressRoute Monitor-functie van NPM ondersteunt alleen Windows server (2008 SP1 of hoger) besturingssysteem.

Kan ik machines gebruiken als bewakingsknooppunten in NPM?

De mogelijkheid om netwerken te bewaken met behulp van Linux-knooppunten is nu algemeen beschikbaar. Open hier de agent.

Wat zijn de groottevereisten van de knooppunten die moeten worden gebruikt voor bewaking door NPM?

Voor het uitvoeren van de NPM-oplossing op knooppunt-VM's om netwerken te bewaken, moeten de knooppunten ten minste 500 MB geheugen en één kern hebben. U hoeft geen afzonderlijke knooppunten te gebruiken voor het uitvoeren van NPM. De oplossing kan worden uitgevoerd op knooppunten waarop andere workloads worden uitgevoerd. De oplossing heeft de mogelijkheid om het bewakingsproces te stoppen als er meer dan 5% CPU wordt gebruikt.

Als ik NPM wilt gebruiken, moet ik mijn knooppunten verbinden als directe agent of via System Center Operations Manager?

Zowel de prestatiemeter als de mogelijkheden van serviceconnectiviteitsmonitor ondersteunen knooppunten die zijn verbonden als directe agents en verbonden via Operations Manager.

Voor de Mogelijkheid van ExpressRoute Monitor moeten de Azure-knooppunten alleen als directe agents worden verbonden. Azure-knooppunten, die zijn verbonden via Operations Manager, worden niet ondersteund. Voor on-premises knooppunten worden de knooppunten die zijn verbonden als directe agents en operations manager ondersteund voor het bewaken van een ExpressRoute-circuit.

Welk protocol tussen TCP en ICMP moet worden gekozen voor bewaking?

Als u uw netwerk bewaakt met behulp van Windows serverknooppunten, raden we u aan TCP te gebruiken als het bewakingsprotocol, omdat dit een betere nauwkeurigheid biedt.

ICMP wordt aanbevolen voor Windows desktops/clientbesturingssystemen op basis van knooppunten. Dit platform staat niet toe dat TCP-gegevens worden verzonden via onbewerkte sockets, die NPM gebruikt om netwerktopologie te detecteren.

Hier vindt u meer informatie over de relatieve voordelen van elk protocol.

Hoe kan ik een knooppunt configureren ter ondersteuning van bewaking met behulp van het TCP-protocol?

Voor het knooppunt ter ondersteuning van bewaking met behulp van TCP-protocol:

  • Zorg ervoor dat het knooppuntplatform is Windows Server (2008 SP1 of hoger).
  • Voer EnableRules.ps1 PowerShell-script uit op het knooppunt. Zie de instructies voor meer informatie.

Hoe kan ik de TCP-poort wijzigen die door NPM wordt gebruikt voor bewaking?

U kunt de TCP-poort die door NPM wordt gebruikt voor bewaking wijzigen door het scriptEnableRules.ps1 uit te voeren. U moet het poortnummer invoeren dat u wilt gebruiken als parameter. Als u bijvoorbeeld TCP wilt inschakelen op poort 8060, voert u uit EnableRules.ps1 8060. Zorg ervoor dat u dezelfde TCP-poort gebruikt op alle knooppunten die worden gebruikt voor bewaking.

Het script configureert alleen Windows Firewall lokaal. Als u regels voor netwerkfirewall of netwerkbeveiligingsgroep (NSG) hebt, moet u ervoor zorgen dat het verkeer dat is bestemd voor de TCP-poort die door NPM wordt gebruikt, is toegestaan.

Hoeveel agents moet ik gebruiken?

U moet ten minste één agent gebruiken voor elk subnet dat u wilt bewaken.

Wat is het maximum aantal agents dat ik kan gebruiken of ik zie de fout '.... Hebt u de configuratielimiet bereikt"?

NPM beperkt het aantal IP-adressen tot 5000 IP-adressen per werkruimte. Als een knooppunt zowel IPv4- als IPv6-adressen heeft, telt dit als 2 IP-adressen voor dat knooppunt. Daarom bepaalt deze limiet van 5000 IP-adressen de bovengrens voor het aantal agents. U kunt de inactieve agents verwijderen van het tabblad Knooppunten in NPM >> Configureren. NPM onderhoudt ook de geschiedenis van alle IP-adressen die ooit zijn toegewezen aan de VM die als host fungeert voor de agent en elk wordt geteld als afzonderlijke IP-adressen die bijdragen aan die bovengrens van 5000 IP-adressen. Als u IP-adressen voor uw werkruimte wilt vrijmaken, kunt u de pagina Knooppunten gebruiken om de IP-adressen te verwijderen die niet in gebruik zijn.

Bewaking

Hoe worden verlies en latentie berekend

Bronagents verzenden TCP SYN-aanvragen (als TCP is gekozen als het protocol voor bewaking) of ICMP-ECHO-aanvragen (als ICMP is gekozen als het protocol voor bewaking) naar doel-IP met regelmatige tussenpozen om ervoor te zorgen dat alle paden tussen de combinatie van brondoel-IP worden gedekt. Het percentage ontvangen pakketten en retourtijd van pakketten wordt gemeten om het verlies en de latentie van elk pad te berekenen. Deze gegevens worden geaggregeerd via het polling-interval en over alle paden om de geaggregeerde waarden van verlies en latentie voor de IP-combinatie voor het specifieke polling-interval op te halen.

Met welke frequentie verzendt de bronagent pakketten naar de bestemming voor bewaking?

Voor de mogelijkheden van Performance Monitor en ExpressRoute Monitor verzendt de bron elke 5 seconden pakketten en registreert de netwerkmetingen. Deze gegevens worden geaggregeerd over een polling-interval van 3 minuten om de gemiddelde en piekwaarden van verlies en latentie te berekenen. Voor serviceconnectiviteitsmonitor wordt de frequentie van het verzenden van de pakketten voor netwerkmeting bepaald door de frequentie die de gebruiker heeft ingevoerd voor de specifieke test tijdens het configureren van de test.

Hoeveel pakketten worden er verzonden voor bewaking?

Het aantal pakketten dat door de bronagent naar de bestemming in een polling wordt verzonden, is adaptief en wordt bepaald door ons eigen algoritme, dat kan verschillen voor verschillende netwerktopologieën. Meer het aantal netwerkpaden tussen de combinatie van bron-doel-IP, meer is het aantal pakketten dat wordt verzonden. Het systeem zorgt ervoor dat alle paden tussen de combinatie van bron-doel-IP worden gedekt.

Hoe detecteert NPM netwerktopologie tussen bron en doel?

NPM maakt gebruik van een eigen algoritme op basis van Traceroute om alle paden en hops tussen de bron en bestemming te detecteren.

Biedt NPM routerings- en schakelniveaugegevens

Hoewel NPM alle mogelijke routes tussen de bronagent en de bestemming kan detecteren, biedt deze geen inzicht in welke route is genomen door de pakketten die door uw specifieke workloads zijn verzonden. De oplossing kan u helpen bij het identificeren van de paden en onderliggende netwerkhops, die meer latentie toevoegen dan verwacht.

Waarom zijn sommige paden beschadigd?

Er kunnen verschillende netwerkpaden bestaan tussen de bron- en doel-IP-adressen en elk pad kan een andere waarde van verlies en latentie hebben. NPM markeert deze paden als beschadigd (aangeduid met rode kleur) waarvoor de waarden van verlies en/of latentie groter zijn dan de respectieve drempelwaarde die is ingesteld in de bewakingsconfiguratie.

Wat geeft een hop in rode kleur aan in de netwerktopologiekaart?

Als een hop rood is, wordt hiermee aangegeven dat deze deel uitmaakt van ten minste één beschadigd pad. NPM markeert alleen de paden als beschadigd. De status van elk pad wordt niet gescheiden. Als u de lastige hops wilt identificeren, kunt u de latentie hop-by-hop bekijken en de hop-by-hop-latentie scheiden en de hop-by-hop scheiden die meer dan verwachte latentie toevoegen.

Hoe werkt foutlokalisatie in Prestatiemeter?

NPM maakt gebruik van een probabilistisch mechanisme om foutkansen toe te wijzen aan elk netwerkpad, netwerksegment en de samenstellende netwerkhops op basis van het aantal beschadigde paden waarvan ze deel uitmaken. Naarmate de netwerksegmenten en hops deel uitmaken van meer beschadigde paden, neemt de foutkans die eraan is gekoppeld toe. Dit algoritme werkt het beste wanneer u veel knooppunten hebt met NPM-agent die met elkaar zijn verbonden, omdat dit de gegevenspunten verhoogt voor het berekenen van de foutkansen.

Wat zijn de standaard Log Analytics-query's voor waarschuwingen?

Query prestatiemeter

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

Query voor serviceconnectiviteitsmonitor

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

ExpressRoute-monitorquery's: Circuits-query

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

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

Algemene query

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

Kan NPM routers en servers bewaken als afzonderlijke apparaten?

NPM identificeert alleen de IP- en hostnaam van onderliggende netwerkhops (switches, routers, servers, enzovoort) tussen de bron- en doel-IP-adressen. Het identificeert ook de latentie tussen deze geïdentificeerde hops. Deze onderliggende hops worden niet afzonderlijk bewaakt.

Kan NPM worden gebruikt om de netwerkverbinding tussen Azure en AWS te bewaken?

Ja. Raadpleeg het artikel Azure-, AWS- en on-premises netwerken bewaken met BEHULP van NPM voor meer informatie.

Is het bandbreedtegebruik van ExpressRoute binnenkomend of uitgaand?

Bandbreedtegebruik is het totaal van binnenkomende en uitgaande bandbreedte. Deze wordt uitgedrukt in bits/sec.

Kunnen we informatie over binnenkomende en uitgaande bandbreedte voor de ExpressRoute ophalen?

Binnenkomende en uitgaande waarden voor zowel primaire als secundaire bandbreedte kunnen worden vastgelegd.

Gebruik voor informatie op MS-peeringniveau de onderstaande query in Zoeken in logboeken

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

Gebruik de onderstaande query in Zoeken in logboeken voor informatie op niveau van persoonlijke peering

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

Voor informatie op circuitniveau gebruikt u de onderstaande query in Zoeken in logboeken

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

Welke regio's worden ondersteund voor de prestatiemeter van NPM?

NPM kan connectiviteit tussen netwerken in elk deel van de wereld bewaken, vanuit een werkruimte die wordt gehost in een van de ondersteunde regio's

Welke regio's worden ondersteund voor de serviceconnectiviteitsmonitor van NPM?

NPM kan connectiviteit met services in elk deel van de wereld bewaken vanuit een werkruimte die wordt gehost in een van de ondersteunde regio's

Welke regio's worden ondersteund voor ExpressRoute Monitor van NPM?

NPM kan uw ExpressRoute-circuits in elke Azure-regio bewaken. Als u wilt onboarden naar NPM, hebt u een Log Analytics-werkruimte nodig die moet worden gehost in een van de ondersteunde regio's

Problemen oplossen

Waarom worden sommige hops gemarkeerd als niet-geïdentificeerd in de netwerktopologieweergave?

NPM maakt gebruik van een gewijzigde versie van traceroute om de topologie van de bronagent naar de bestemming te detecteren. Een niet-geïdentificeerde hop geeft aan dat de netwerkhop niet heeft gereageerd op de traceroute-aanvraag van de bronagent. Als drie opeenvolgende netwerkhops niet reageren op de traceroute van de agent, markeert de oplossing de niet-reagerende hops als niet-geïdentificeerd en probeert niet meer hops te detecteren.

Een hop reageert mogelijk niet op een traceroute in een of meer van de onderstaande scenario's:

  • De routers zijn geconfigureerd om hun identiteit niet te onthullen.
  • De netwerkapparaten staan ICMP_TTL_EXCEEDED verkeer niet toe.
  • Een firewall blokkeert het ICMP_TTL_EXCEEDED-antwoord van het netwerkapparaat.

Wanneer een van de eindpunten zich in Azure bevindt, wordt traceroute niet-geïdentificeerde hops weergegeven, omdat azure-infrastructuur de identiteit voor traceringsroute niet onthult.

Ik krijg waarschuwingen voor beschadigde tests, maar ik zie de hoge waarden in de grafiek verlies en latentie van NPM niet. Hoe kan ik controleren wat niet in orde is?

NPM genereert een waarschuwing als de end-to-endlatentie tussen de bron en bestemming de drempelwaarde overschrijdt voor elk pad ertussen. Sommige netwerken hebben meerdere paden die verbinding maken met dezelfde bron en bestemming. NPM genereert een waarschuwing als een pad beschadigd is. Het verlies en de latentie in de grafieken is de gemiddelde waarde voor alle paden, waardoor de exacte waarde van één pad mogelijk niet wordt weergegeven. Als u wilt weten waar de drempelwaarde is overschreden, zoekt u de kolom 'SubType' in de waarschuwing. Als het probleem wordt veroorzaakt door een pad, is de waarde van het subtype NetworkPath (voor prestatiemetertests), EndpointPath (voor tests van serviceconnectiviteitsmonitor) en ExpressRoutePath (voor ExpressRotue Monitor-tests).

Voorbeeldquery om te vinden is dat het pad niet in orde is:

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

Waarom geeft mijn test een slechte status aan, maar de topologie niet

NPM bewaakt end-to-end verlies, latentie en topologie met verschillende intervallen. Verlies en latentie worden elke 5 seconden gemeten en elke drie minuten geaggregeerd (voor Performance Monitor en Express Route Monitor) terwijl de topologie eenmaal per 10 minuten wordt berekend met behulp van traceroute. Tussen 3:44 en 4:04 kan de topologie bijvoorbeeld drie keer worden bijgewerkt (3:44, 3:54, 4:04), maar verlies en latentie worden ongeveer zeven keer bijgewerkt (3:44, 3:47, 3:50, 3:53, 3:56, 3:59, 4:02). De topologie die om 3:54 wordt gegenereerd, wordt weergegeven voor het verlies en de latentie die wordt berekend op 3:56, 3:59 en 4:02. Stel dat u een waarschuwing krijgt dat uw ER-circuit beschadigd was om 3:59 uur. U meldt u aan bij NPM en probeert de topologietijd in te stellen op 3:59. NPM geeft de topologie weer die is gegenereerd om 3:54. Als u de laatst bekende topologie van uw netwerk wilt begrijpen, vergelijkt u de velden TimeProcessed (tijdstip waarop verlies en latentie is berekend) en TracerouteCompletedTime (tijdstip waarop topologie is berekend).

Wat is het verschil tussen de velden E2EMedianLatency en AvgHopLatencyList in de tabel NetworkMonitoring

E2EMedianLatency is de latentie elke drie minuten na het aggregeren van de resultaten van tcp ping-tests, terwijl AvgHopLatencyList elke 10 minuten wordt bijgewerkt op basis van traceroute. Gebruik het veld TimeProcessed om de exacte tijd te begrijpen waarop E2EMedianLatency is berekend. Gebruik het veld TracerouteCompletedTime om de exacte tijd te begrijpen waarop traceroute is voltooid en bijgewerkt AvgHopLatencyList

Waarom verschillen hop-by-hop latentienummers van HopLatencyValues

HopLatencyValues zijn bron-naar-eindpunt. Bijvoorbeeld: Hops - A,B,C. AvgHopLatency - 10,15,20. Dit betekent dat bron naar A-latentie = 10, bron naar B-latentie = 15 en bron naar C-latentie 20 is. In de gebruikersinterface wordt de latentie van A-B-hop berekend als 5 in de topologie

De oplossing toont 100% verlies, maar er is verbinding tussen de bron en bestemming

Dit kan gebeuren als de hostfirewall of de tussenliggende firewall (netwerkfirewall of Azure NSG) de communicatie tussen de bronagent en de bestemming blokkeert via de poort die wordt gebruikt voor bewaking door NPM (standaard is de poort 8084, tenzij de klant dit heeft gewijzigd).

  • Als u wilt controleren of de hostfirewall de communicatie op de vereiste poort niet blokkeert, bekijkt u de status van de bron- en doelknooppunten in de volgende weergave: Netwerkprestatiemeter -> Configuratie -> Knooppunten. Als ze beschadigd zijn, bekijkt u de instructies en neemt u corrigerende maatregelen. Als de knooppunten in orde zijn, gaat u naar de onderstaande stap b.
  • Gebruik de onderstaande instructies om te controleren of een tussenliggende netwerkfirewall of Azure NSG de communicatie op de vereiste poort niet blokkeert:
    • psping utility is hier beschikbaar voor download
    • Voer de volgende opdracht uit vanaf het bronknooppunt.
      • psping -n 15 <doelknooppunt IPAddress>:p ortNumber Standaard gebruikt NPM 8084-poort. Als u dit expliciet hebt gewijzigd met behulp van het script EnableRules.ps1, voert u het aangepaste poortnummer in dat u gebruikt). Dit is een ping van azure-machine naar on-premises
  • Controleer of de pings zijn geslaagd. Zo niet, dan wordt aangegeven dat een tussenliggende netwerkfirewall of Azure NSG het verkeer op deze poort blokkeert.
  • Voer nu de opdracht uit van het doelknooppunt naar het IP-adres van het bronknooppunt.

Er is verlies van knooppunt A naar B, maar niet van knooppunt B naar A. Waarom?

Aangezien de netwerkpaden tussen A en B kunnen verschillen van de netwerkpaden tussen B en A, kunnen verschillende waarden voor verlies en latentie worden waargenomen.

Waarom worden al mijn ExpressRoute-circuits en peeringverbindingen niet gedetecteerd?

NPM detecteert nu ExpressRoute-circuits en peeringverbindingen in alle abonnementen waartoe de gebruiker toegang heeft. Kies alle abonnementen waaraan uw Express Route-resources zijn gekoppeld en schakel bewaking in voor elke gedetecteerde resource. NPM zoekt naar verbindingsobjecten bij het detecteren van een privépeering. Controleer daarom of een VNET is gekoppeld aan uw peering. NPM detecteert geen circuits en peering die zich in een andere tenant bevinden dan de Log Analytics-werkruimte.

De FUNCTIE ER Monitor heeft een diagnostisch bericht 'Verkeer wordt niet doorgegeven via een circuit'. Wat betekent dat?

Er kan een scenario zijn waarin er een goede verbinding is tussen de on-premises en Azure-knooppunten, maar het verkeer wordt niet uitgevoerd via het ExpressRoute-circuit dat is geconfigureerd om te worden bewaakt door NPM.

Dit kan gebeuren als:

  • Het ER-circuit is niet beschikbaar.
  • De routefilters worden zodanig geconfigureerd dat ze prioriteit geven aan andere routes (zoals een VPN-verbinding of een ander ExpressRoute-circuit) via het beoogde ExpressRoute-circuit.
  • De on-premises en Azure-knooppunten die zijn gekozen voor het bewaken van het ExpressRoute-circuit in de bewakingsconfiguratie, hebben geen verbinding met elkaar via het beoogde ExpressRoute-circuit. Zorg ervoor dat u de juiste knooppunten hebt gekozen die verbinding met elkaar hebben via het ExpressRoute-circuit dat u wilt bewaken.

Waarom rapporteert ExpressRoute Monitor mijn circuit/peering als beschadigd wanneer deze beschikbaar is en gegevens doorgeeft.

ExpressRoute Monitor vergelijkt de netwerkprestatiewaarden (verlies, latentie en bandbreedtegebruik) die door de agents/service worden gerapporteerd met de drempelwaarden die tijdens de configuratie zijn ingesteld. Als voor een circuit het gerapporteerde bandbreedtegebruik groter is dan de drempelwaarde die is ingesteld in Configuratie, wordt het circuit gemarkeerd als beschadigd. Als voor peerings het gerapporteerde verlies, latentie of bandbreedtegebruik groter is dan de drempelwaarde die is ingesteld in de configuratie, wordt de peering gemarkeerd als beschadigd. NPM maakt geen gebruik van metrische gegevens of een andere vorm van gegevens om de status te bepalen.

Waarom rapporteert het bandbreedtegebruik van ExpressRoute Monitor een andere waarde dan metrische bits in/uit

Voor ExpressRoute Monitor is het bandbreedtegebruik het gemiddelde van binnenkomende en uitgaande bandbreedte in de afgelopen 20 minuten. Dit wordt uitgedrukt in bits/sec. Voor metrische gegevens van Express Route zijn bit-in-/uit-gegevenspunten per minuut. Intern is de gegevensset die voor beide wordt gebruikt, hetzelfde, maar de aggregatie varieert tussen NPM- en ER-metrische gegevens. Voor gedetailleerde, minuut per minuut bewaking en snelle waarschuwingen raden we u aan om waarschuwingen rechtstreeks in te stellen op metrische ER-gegevens

Tijdens het configureren van de bewaking van mijn ExpressRoute-circuit worden de Azure-knooppunten niet gedetecteerd.

Dit kan gebeuren als de Azure-knooppunten zijn verbonden via Operations Manager. De ExpressRoute Monitor-mogelijkheid ondersteunt alleen azure-knooppunten die zijn verbonden als directe agents.

Ik kan niet detecteren door ExpressRoute-circuits in de OMS-portal

Hoewel NPM zowel vanuit de Azure Portal als de OMS-portal kan worden gebruikt, werkt de circuitdetectie in de ExpressRoute Monitor-functie alleen via de Azure Portal. Zodra de circuits zijn gedetecteerd via de Azure Portal, kunt u de mogelijkheid in een van de twee portals gebruiken.

In de serviceconnectiviteitsmonitorfunctie worden de reactietijd van de service, netwerkverlies en latentie weergegeven als NA

Dit kan gebeuren als een of meer waar is:

  • De service is niet beschikbaar.
  • Het knooppunt dat wordt gebruikt om de netwerkverbinding met de service te controleren, is niet beschikbaar.
  • Het doel dat is ingevoerd in de testconfiguratie, is onjuist.
  • Het knooppunt heeft geen netwerkverbinding.

In de serviceconnectiviteitsmonitor wordt een geldige reactietijd van de service weergegeven, maar netwerkverlies en latentie worden weergegeven als NA

Dit kan gebeuren als een of meer waar is:

  • Als het knooppunt dat wordt gebruikt voor het controleren van de netwerkverbinding met de service een Windows clientcomputer is, blokkeert de doelservice ICMP-aanvragen of blokkeert een netwerkfirewall ICMP-aanvragen die afkomstig zijn van het knooppunt.
  • Het selectievakje Netwerkmetingen uitvoeren is leeg in de testconfiguratie.

In de serviceconnectiviteitsmonitorfunctie is de reactietijd van de service NA, maar netwerkverlies en latentie geldig

Dit kan gebeuren als de doelservice geen webtoepassing is, maar de test is geconfigureerd als een webtest. Bewerk de testconfiguratie en kies het testtype als Netwerk in plaats van Web.

Diversen

Is er een invloed op de prestaties op het knooppunt dat wordt gebruikt voor bewaking?

NPM-proces is geconfigureerd om te stoppen als het meer dan 5% van de CPU-resources van de host gebruikt. Dit is om ervoor te zorgen dat u de knooppunten voor hun gebruikelijke workloads kunt blijven gebruiken zonder dat dit van invloed is op de prestaties.

Bewerkt NPM firewallregels voor bewaking?

NPM maakt alleen een lokale Windows Firewall-regel op de knooppunten waarop het EnableRules.ps1 PowerShell-script wordt uitgevoerd, zodat de agents TCP-verbindingen met elkaar kunnen maken op de opgegeven poort. De oplossing wijzigt geen netwerkfirewall- of netwerkbeveiligingsgroepregels (NSG).

Hoe kan ik de status controleren van de knooppunten die worden gebruikt voor bewaking?

U kunt de status bekijken van de knooppunten die worden gebruikt voor bewaking vanuit de volgende weergave: Netwerkprestatiemeter -> Configuratie -> Knooppunten. Als een knooppunt beschadigd is, kunt u de foutdetails bekijken en de voorgestelde actie uitvoeren.

Kunnen NPM-latentienummers in microseconden rapporteren?

NPM rondt de latentienummers in de gebruikersinterface af en in milliseconden. Dezelfde gegevens worden opgeslagen op een hogere granulariteit (soms maximaal vier decimalen).

Ondersteunt NPM multi-homed knooppunten?

Nee. Voor elk NPM-knooppunt is een toegewezen Log Analytics-werkruimte vereist.

Welke aanvullende vereisten heeft de NPM voor Linux?

De OMS-agent voor Linux vereist ook het gebruik van GLIBC 2.14 of hoger.

Volgende stappen