Często zadawane pytania dotyczące rozwiązania monitor wydajności sieci

Network Performance Monitor symbol

Ważne

Od 1 lipca 2021 r. nie będzie można dodawać nowych testów w istniejącym obszarze roboczym ani włączać nowego obszaru roboczego w obszarze Network monitor wydajności. Możesz nadal używać testów utworzonych przed 1 lipca 2021 r. Aby zminimalizować zakłócenia usługi w bieżących obciążeniach, przeprowadź migrację testów z usługi Network monitor wydajności do nowej Monitor połączenia na platformie Azure Network Watcher przed 29 lutego 2024 r.

Ten artykuł zawiera często zadawane pytania dotyczące usługi Network monitor wydajności (NPM) na platformie Azure

Monitor wydajności sieci to oparte na chmurze rozwiązanie do monitorowania sieci hybrydowej, które ułatwia monitorowanie wydajności sieci między różnymi punktami w infrastrukturze sieciowej. Pomaga również monitorować łączność sieciową z punktami końcowymi usługi i aplikacji oraz monitorować wydajność usługi Azure ExpressRoute.

Monitor wydajności sieci wykrywa problemy z siecią, takie jak blackholing ruchu, błędy routingu i problemy, których konwencjonalne metody monitorowania sieci nie są w stanie wykryć. Rozwiązanie generuje alerty i powiadamia użytkownika, gdy nastąpi naruszenie progu związanego z połączeniem sieciowym. Ponadto gwarantuje ono szybkie wykrywanie problemów z wydajnością sieci i lokalizuje źródło problemu w określonym segmencie lub urządzeniu w sieci.

Więcej informacji na temat różnych możliwości obsługiwanych przez usługę Network monitor wydajności jest dostępnych w trybie online.

Konfigurowanie i konfigurowanie agentów

Jakie są wymagania dotyczące platformy dla węzłów, które mają być używane do monitorowania przez narzędzie NPM?

Poniżej przedstawiono wymagania dotyczące platformy dla różnych możliwości narzędzia NPM:

  • Funkcje monitora łączności monitor wydajności i usługi NPM obsługują zarówno serwer Windows, jak i komputery stacjonarne/systemy operacyjne klienta Windows. Windows obsługiwane wersje systemu operacyjnego serwera to 2008 z dodatkiem SP1 lub nowszym. Obsługiwane wersje komputerów stacjonarnych/klienckich Windows są Windows 10, Windows 8.1, Windows 8 i Windows 7.
  • Funkcja monitora usługi ExpressRoute usługi NPM obsługuje tylko system operacyjny Windows (2008 SP1 lub nowszy).

Czy mogę używać maszyn jako węzłów monitorowania w usłudze NPM?

Możliwość monitorowania sieci przy użyciu węzłów opartych na systemie Linux jest teraz ogólnie dostępna. Uzyskaj dostęp do agenta tutaj.

Jakie są wymagania dotyczące rozmiaru węzłów, które mają być używane do monitorowania przez narzędzie NPM?

Aby można było uruchomić rozwiązanie NPM na maszynach wirtualnych węzłów do monitorowania sieci, węzły powinny mieć co najmniej 500 MB pamięci i jeden rdzeń. Do uruchamiania narzędzia NPM nie trzeba używać oddzielnych węzłów. Rozwiązanie może działać w węzłach, w których są uruchomione inne obciążenia. Rozwiązanie ma możliwość zatrzymania procesu monitorowania, jeśli używa więcej niż 5% procesora CPU.

Czy do używania menedżera NPM należy połączyć węzły jako agent bezpośredni lub za pośrednictwem programu System Center Operations Manager?

Zarówno monitor wydajności, jak i funkcje monitora łączności usług obsługują węzły połączone jako agenci bezpośredni i połączone za pośrednictwem programu Operations Manager.

W przypadku możliwości monitorowania usługi ExpressRoute węzły platformy Azure powinny być połączone tylko jako agenci bezpośredni. Węzły platformy Azure połączone za pośrednictwem programu Operations Manager nie są obsługiwane. W przypadku węzłów lokalnych węzły połączone jako agenci bezpośredni i za pośrednictwem programu Operations Manager są obsługiwane do monitorowania obwodu usługi ExpressRoute.

Który protokół między protokołami TCP i ICMP należy wybrać do monitorowania?

Jeśli monitorujesz sieć przy użyciu Windows węzłów opartych na serwerze, zalecamy użycie protokołu TCP jako protokołu monitorowania, ponieważ zapewnia lepszą dokładność.

W przypadku Windows komputerów stacjonarnych/klienckich węzłów opartych na systemie operacyjnym zaleca się użycie protokołu ICMP. Ta platforma nie zezwala na wysyłanie danych TCP za pośrednictwem nieprzetworzonych gniazd, których narzędzie NPM używa do odnajdywania topologii sieci.

Więcej szczegółów na temat względnych zalet poszczególnych protokołów można znaleźć tutaj.

Jak skonfigurować węzeł do obsługi monitorowania przy użyciu protokołu TCP?

Aby węzeł obsługiwał monitorowanie przy użyciu protokołu TCP:

  • Upewnij się, że platforma węzłów jest Windows Server (2008 SP1 lub nowsza).
  • Uruchom EnableRules.ps1 skrypt programu PowerShell w węźle. Zobacz instrukcje , aby uzyskać więcej szczegółów.

Jak mogę zmienić port TCP używany przez narzędzie NPM do monitorowania?

Port TCP używany przez narzędzie NPM do monitorowania można zmienić, uruchamiając skrypt EnableRules.ps1 . Musisz wprowadzić numer portu, którego zamierzasz użyć jako parametru. Aby na przykład włączyć protokół TCP na porcie 8060, uruchom polecenie EnableRules.ps1 8060. Upewnij się, że używasz tego samego portu TCP na wszystkich węzłach używanych do monitorowania.

Skrypt konfiguruje tylko lokalnie zaporę Windows. Jeśli masz reguły zapory sieciowej lub sieciowej grupy zabezpieczeń, upewnij się, że zezwalają one na ruch przeznaczony dla portu TCP używanego przez narzędzie NPM.

Ilu agentów należy używać?

Należy użyć co najmniej jednego agenta dla każdej podsieci, którą chcesz monitorować.

Jaka jest maksymalna liczba agentów, których mogę użyć, lub widzę błąd ".... Osiągnięto limit konfiguracji"?

Narzędzie NPM ogranicza liczbę adresów IP do 5000 adresów IP na obszar roboczy. Jeśli węzeł ma adresy IPv4 i IPv6, będzie to liczyć jako 2 adresy IP dla tego węzła. W związku z tym ten limit 5000 adresów IP decyduje o górnej liczbie agentów. Nieaktywnych agentów można usunąć z karty Węzły w obszarze Konfiguracja narzędzia NPM >> . Narzędzie NPM przechowuje również historię wszystkich adresów IP, które kiedykolwiek zostały przypisane do maszyny wirtualnej hostujące agenta, a każdy z nich jest liczone jako oddzielny adres IP przyczyniający się do tego górnego limitu 5000 adresów IP. Aby zwolnić adresy IP dla obszaru roboczego, możesz użyć strony Węzły, aby usunąć adresy IP, które nie są używane.

Monitorowanie

Jak jest obliczana utrata i opóźnienie

Agenci źródłowzy wysyłają żądania TCP SYN (jeśli wybrano protokół TCP do monitorowania) lub żądania ECHO protokołu ICMP (jeśli protokół ICMP jest wybrany jako protokół do monitorowania) do docelowego adresu IP w regularnych odstępach czasu, aby upewnić się, że wszystkie ścieżki między kombinacją źródłowego adresu IP są objęte. Procent odebranych pakietów i czas rundy pakietów jest mierzony w celu obliczenia utraty i opóźnienia każdej ścieżki. Te dane są agregowane w interwale sondowania i na wszystkich ścieżkach w celu uzyskania zagregowanych wartości strat i opóźnień dla kombinacji adresów IP dla określonego interwału sondowania.

Z jaką częstotliwością agent źródłowy wysyła pakiety do miejsca docelowego na potrzeby monitorowania?

W przypadku funkcji monitor wydajności i monitora usługi ExpressRoute źródło wysyła pakiety co 5 sekund i rejestruje pomiary sieci. Te dane są agregowane w ciągu 3-minutowego interwału sondowania w celu obliczenia średnich i szczytowych wartości strat i opóźnień. W przypadku możliwości monitora łączności usług częstotliwość wysyłania pakietów do pomiaru sieci jest określana przez częstotliwość wprowadzoną przez użytkownika dla określonego testu podczas konfigurowania testu.

Ile pakietów jest wysyłanych do monitorowania?

Liczba pakietów wysyłanych przez agenta źródłowego do miejsca docelowego w sondowaniu jest adaptacyjna i zależy od naszego zastrzeżonego algorytmu, który może być inny w przypadku różnych topologii sieci. Większa liczba ścieżek sieciowych między kombinacją źródłowego adresu IP docelowego, więcej to liczba wysyłanych pakietów. System zapewnia, że wszystkie ścieżki między kombinacją źródłowego adresu IP są objęte.

W jaki sposób narzędzie NPM odnajduje topologię sieci między lokalizacją źródłową i docelową?

Narzędzie NPM używa zastrzeżonego algorytmu opartego na usłudze Traceroute do odnajdywania wszystkich ścieżek i przeskoków między lokalizacją źródłową i docelową.

Czy narzędzie NPM udostępnia informacje o poziomie routingu i przełączania

Mimo że narzędzie NPM może wykryć wszystkie możliwe trasy między agentem źródłowym a miejscem docelowym, nie zapewnia wglądu w trasę, która została pobrana przez pakiety wysyłane przez określone obciążenia. Rozwiązanie może pomóc w zidentyfikowaniu ścieżek i bazowych przeskoków sieciowych, które dodają więcej opóźnień niż oczekiwano.

Dlaczego niektóre ścieżki są w złej kondycji?

Różne ścieżki sieciowe mogą istnieć między źródłowymi i docelowymi adresami IP, a każda ścieżka może mieć inną wartość utraty i opóźnienia. Narzędzie NPM oznacza te ścieżki jako będące w złej kondycji (oznaczone kolorem czerwonym), dla których wartości strat i/lub opóźnienia są większe niż odpowiedni próg ustawiony w konfiguracji monitorowania.

Co oznacza przeskok w kolorze czerwonym na mapie topologii sieci?

Jeśli przeskok jest czerwony, oznacza, że jest częścią co najmniej jednej ścieżki w złej kondycji. Narzędzie NPM oznacza tylko ścieżki jako w złej kondycji, ale nie segreguje stanu kondycji każdej ścieżki. Aby zidentyfikować kłopotliwe przeskoki, możesz wyświetlić opóźnienie przeskoku po przeskoku i rozdzielić te, dodając więcej niż oczekiwane opóźnienie.

Jak działa lokalizacja błędów w monitor wydajności?

Narzędzie NPM używa mechanizmu probabilistycznego do przypisywania prawdopodobieństwa błędów do każdej ścieżki sieciowej, segmentu sieci i składowych przeskoków sieci na podstawie liczby ścieżek w złej kondycji, do których należą. Ponieważ segmenty sieci i przeskoki stają się częścią większej liczby ścieżek w złej kondycji, zwiększa się prawdopodobieństwo błędów skojarzone z nimi. Ten algorytm działa najlepiej, gdy masz wiele węzłów z agentem NPM połączonym ze sobą, ponieważ zwiększa to punkty danych do obliczania prawdopodobieństwa błędów.

Jakie są domyślne zapytania usługi Log Analytics dotyczące alertów

Zapytanie monitora wydajności

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

Zapytanie monitora łączności usługi

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

Zapytania monitora usługi ExpressRoute: zapytania dotyczące obwodów

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

Prywatna komunikacja równorzędna

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

Komunikacja równorzędna firmy Microsoft

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"

Typowe zapytanie

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

Czy narzędzie NPM może monitorować routery i serwery jako poszczególne urządzenia?

Narzędzie NPM identyfikuje tylko adres IP i nazwę hosta bazowych przeskoków sieci (przełączników, routerów, serwerów itp.) między źródłowymi i docelowymi adresami IP. Identyfikuje również opóźnienie między zidentyfikowanym przeskokami. Nie monitoruje indywidualnie tych bazowych przeskoków.

Czy narzędzie NPM może służyć do monitorowania łączności sieciowej między platformą Azure i usługą AWS?

Tak. Aby uzyskać szczegółowe informacje, zapoznaj się z artykułem Monitorowanie platformy Azure, usług AWS i sieci lokalnych przy użyciu narzędzia NPM .

Czy użycie przepustowości usługi ExpressRoute jest przychodzące, czy wychodzące?

Użycie przepustowości to łączna przepustowość przychodząca i wychodząca. Jest wyrażona w bitach/s.

Czy możemy uzyskać informacje o przepustowości przychodzącej i wychodzącej dla usługi ExpressRoute?

Wartości przychodzące i wychodzące zarówno dla przepustowości podstawowej, jak i pomocniczej można przechwycić.

Aby uzyskać informacje o poziomie komunikacji równorzędnej MS, użyj poniższego zapytania w wyszukiwaniu dzienników

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

Aby uzyskać informacje na poziomie prywatnej komunikacji równorzędnej, użyj poniższego zapytania w wyszukiwaniu dzienników

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

Aby uzyskać informacje o poziomie obwodu, użyj poniższego zapytania w wyszukiwaniu dzienników

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

Które regiony są obsługiwane w przypadku monitor wydajności npm?

Narzędzie NPM może monitorować łączność między sieciami w dowolnej części świata z poziomu obszaru roboczego hostowanego w jednym z obsługiwanych regionów

Które regiony są obsługiwane dla monitora łączności usługi NPM?

Narzędzie NPM może monitorować łączność z usługami w dowolnej części świata z poziomu obszaru roboczego hostowanego w jednym z obsługiwanych regionów

Które regiony są obsługiwane dla monitora usługi ExpressRoute usługi NPM?

Rozwiązanie NPM może monitorować obwody usługi ExpressRoute znajdujące się w dowolnym regionie świadczenia usługi Azure. Aby dołączyć do serwera NPM, musisz mieć obszar roboczy usługi Log Analytics, który musi być hostowany w jednym z obsługiwanych regionów

Rozwiązywanie problemów

Dlaczego niektóre przeskoki oznaczone jako niezidentyfikowane w widoku topologii sieci?

Narzędzie NPM używa zmodyfikowanej wersji usługi traceroute do odnajdywania topologii od agenta źródłowego do miejsca docelowego. Niezidentyfikowany przeskok oznacza, że przeskok sieciowy nie odpowiedział na żądanie śledzenia agenta źródłowego. Jeśli trzy kolejne przeskoki sieciowe nie reagują na usługę traceroute agenta, rozwiązanie oznacza nieodpowiadalne przeskoki jako niezidentyfikowane i nie próbuje odnaleźć większej liczby przeskoków.

Przeskok może nie odpowiadać na trasę traceroute w co najmniej jednym z poniższych scenariuszy:

  • Routery zostały skonfigurowane tak, aby nie ujawniały swojej tożsamości.
  • Urządzenia sieciowe nie zezwalają na ruch ICMP_TTL_EXCEEDED.
  • Zapora blokuje ICMP_TTL_EXCEEDED odpowiedzi z urządzenia sieciowego.

Gdy jeden z punktów końcowych znajduje się na platformie Azure, usługa traceroute wyświetla niezidentyfikowane przeskoki, ponieważ infrastruktura platformy Azure nie ujawnia tożsamości w celu śledzenia trasy.

Otrzymuję alerty dotyczące testów w złej kondycji, ale nie widzę wysokich wartości na wykresie straty i opóźnienia npm. Jak mogę sprawdzić, co jest w złej kondycji?

Narzędzie NPM zgłasza alert, jeśli koniec opóźnienia między źródłem a miejscem docelowym przekracza próg dla dowolnej ścieżki między nimi. Niektóre sieci mają wiele ścieżek łączących to samo źródło i miejsce docelowe. Narzędzie NPM zgłasza alert, że każda ścieżka jest w złej kondycji. Utrata i opóźnienie widoczne na wykresach to średnia wartość dla wszystkich ścieżek, dlatego może nie pokazywać dokładnej wartości pojedynczej ścieżki. Aby zrozumieć, gdzie został naruszony próg, poszukaj kolumny "SubType" w alercie. Jeśli problem jest spowodowany ścieżką, wartość SubType będzie NetworkPath (w przypadku testów monitor wydajności), EndpointPath (w przypadku testów monitora łączności usługi) i ExpressRoutePath (dla testów monitora usługi ExpressRotue).

Przykładowe zapytanie w celu znalezienia ścieżki jest w złej kondycji:

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

Dlaczego mój test pokazuje złą kondycję, ale topologia nie jest

Narzędzie NPM monitoruje kompleksową utratę, opóźnienie i topologię w różnych interwałach. Utrata i opóźnienie są mierzone co 5 sekund i agregowane co trzy minuty (w przypadku monitor wydajności i monitora usługi Express Route), podczas gdy topologia jest obliczana przy użyciu usługi traceroute co 10 minut. Na przykład między 3:44 i 4:04 topologia może zostać zaktualizowana trzy razy (3:44, 3:54, 4:04), ale opóźnienie i opóźnienie są aktualizowane około siedmiu razy (3:44, 3:47, 3:50, 3:53, 3:56, 3:59, 4:02). Topologia wygenerowana na 3:54 zostanie wyrenderowana dla utraty i opóźnienia obliczonego na 3:56, 3:59 i 4:02. Załóżmy, że otrzymasz alert informujący o złej kondycji obwodu usługi ER o godzinie 3:59. Zaloguj się do serwera NPM i spróbuj ustawić czas topologii na 3:59. Narzędzie NPM renderuje topologię wygenerowaną o godzinie 3:54. Aby zrozumieć ostatnią znaną topologię sieci, porównaj pola TimeProcessed (czas obliczenia utraty i opóźnienia) oraz TracerouteCompletedTime (czas obliczenia topologii).

Jaka jest różnica między polami E2EMedianLatency i AvgHopLatencyList w tabeli NetworkMonitoring

E2EMedianLatency to opóźnienie aktualizowane co trzy minuty po agregacji wyników testów tcp ping, natomiast avgHopLatencyList jest aktualizowana co 10 minut na podstawie usługi traceroute. Aby poznać dokładny czas obliczania E2EMedianLatency, użyj pola TimeProcessed. Aby poznać dokładny czas ukończenia i zaktualizowania elementu traceroute AvgHopLatencyList, użyj pola TracerouteCompletedTime

Dlaczego liczba opóźnień przeskoków według przeskoku różni się od HopLatencyValues

HopLatencyValues są źródłem punktu końcowego. Na przykład: Przeskoki — A,B,C. AvgHopLatency — 10 15 20. Oznacza to, że opóźnienie A = 10, źródło do opóźnienia B = 15, a opóźnienie źródła do C wynosi 20. Interfejs użytkownika oblicza opóźnienie przeskoku A-B jako 5 w topologii

Rozwiązanie pokazuje utratę 100%, ale istnieje łączność między źródłem a miejscem docelowym

Może się tak zdarzyć, jeśli zapora hosta lub zapora pośrednia (zapora sieciowa lub sieciowa grupa zabezpieczeń platformy Azure) blokuje komunikację między agentem źródłowym a miejscem docelowym za pośrednictwem portu używanego do monitorowania przez serwer NPM (domyślnie port ma wartość 8084, chyba że klient to zmienił).

  • Aby sprawdzić, czy zapora hosta nie blokuje komunikacji na wymaganym porcie, wyświetl stan kondycji węzłów źródłowych i docelowych z następującego widoku: Sieć monitor wydajności — Konfiguracja —>> Węzły. Jeśli są one w złej kondycji, wyświetl instrukcje i podejmij działania naprawcze. Jeśli węzły są w dobrej kondycji, przejdź do kroku b poniżej.
  • Aby sprawdzić, czy pośrednia zapora sieciowa lub sieciowa grupa zabezpieczeń platformy Azure nie blokuje komunikacji na wymaganym porcie, użyj narzędzia PsPing innej firmy, korzystając z poniższych instrukcji:
    • Narzędzie psping jest dostępne do pobrania tutaj
    • Uruchom następujące polecenie z węzła źródłowego.
      • psping -n 15 <docelowy węzeł IPAddress>:p ortNumber Domyślnie npM używa portu 8084. Jeśli jawnie to zmieniono przy użyciu skryptu EnableRules.ps1, wprowadź niestandardowy numer portu, którego używasz). Jest to polecenie ping z maszyny platformy Azure do środowiska lokalnego
  • Sprawdź, czy polecenia ping zakończyły się pomyślnie. Jeśli nie, oznacza to, że pośrednia zapora sieciowa lub sieciowa grupa zabezpieczeń platformy Azure blokuje ruch na tym porcie.
  • Teraz uruchom polecenie z węzła docelowego do źródłowego adresu IP węzła.

Występuje utrata z węzła A do B, ale nie z węzła B do A. Dlaczego?

Ponieważ ścieżki sieciowe między A do B mogą być różne od ścieżek sieciowych między B do A, można zaobserwować różne wartości utraty i opóźnienia.

Dlaczego nie odnaleziono wszystkich obwodów usługi ExpressRoute i połączeń komunikacji równorzędnej?

Usługa NPM odnajduje teraz obwody usługi ExpressRoute i połączenia komunikacji równorzędnej we wszystkich subskrypcjach, do których użytkownik ma dostęp. Wybierz wszystkie subskrypcje, w których są połączone zasoby usługi Express Route i włącz monitorowanie dla każdego odnalezionego zasobu. Narzędzie NPM wyszukuje obiekty połączenia podczas odnajdywania prywatnej komunikacji równorzędnej, dlatego sprawdź, czy sieć wirtualna jest skojarzona z komunikacją równorzędną. Narzędzie NPM nie wykrywa obwodów i komunikacji równorzędnej, które znajdują się w innej dzierżawie niż obszar roboczy usługi Log Analytics.

Funkcja monitora ER ma komunikat diagnostyczny "Ruch nie przechodzi przez obwód ANY". Co to oznacza?

Może istnieć scenariusz, w którym istnieje połączenie w dobrej kondycji między węzłami lokalnymi i węzłami platformy Azure, ale ruch nie przechodzi przez obwód usługi ExpressRoute skonfigurowany do monitorowania przez serwer NPM.

Może się tak zdarzyć, jeśli:

  • Obwód ER jest wyłączony.
  • Filtry tras są konfigurowane w taki sposób, że zapewniają priorytet innym trasom (takim jak połączenie sieci VPN lub inny obwód usługi ExpressRoute) za pośrednictwem zamierzonego obwodu usługi ExpressRoute.
  • Węzły lokalne i węzły platformy Azure wybrane do monitorowania obwodu usługi ExpressRoute w konfiguracji monitorowania nie mają łączności ze sobą za pośrednictwem zamierzonego obwodu usługi ExpressRoute. Upewnij się, że wybrano prawidłowe węzły, które mają łączność ze sobą za pośrednictwem obwodu usługi ExpressRoute, który zamierzasz monitorować.

Dlaczego monitor usługi ExpressRoute zgłasza mój obwód/komunikację równorzędną jako w złej kondycji, gdy jest dostępny i przekazuje dane.

Monitor usługi ExpressRoute porównuje wartości wydajności sieci (stratę, opóźnienie i wykorzystanie przepustowości) zgłaszane przez agentów/usługę z progami ustawionymi podczas konfiguracji. W przypadku obwodu, jeśli zgłoszone wykorzystanie przepustowości jest większe niż próg ustawiony w konfiguracji, obwód jest oznaczony jako w złej kondycji. W przypadku komunikacji równorzędnej, jeśli zgłoszone straty, opóźnienie lub wykorzystanie przepustowości jest większe niż próg ustawiony w konfiguracji, komunikacja równorzędna jest oznaczona jako w złej kondycji. Narzędzie NPM nie korzysta z metryk ani żadnych innych form danych w celu podjęcia decyzji o stanie kondycji.

Dlaczego użycie przepustowości monitora usługi ExpressRoute zgłasza wartość inną niż bity metryk w/wy

W przypadku monitora usługi ExpressRoute wykorzystanie przepustowości jest średnią przepustowości przychodzącej i wychodzącej w ciągu ostatnich 20 minut wyrażonych w bitach/s. W przypadku metryk usługi Express Route bit in/out to minutowe punkty danych. Wewnętrznie zestaw danych używany dla obu jest taki sam, ale agregacja różni się między metrykami NPM i ER. W przypadku szczegółowego, minutowego monitorowania i szybkich alertów zalecamy ustawienie alertów bezpośrednio w metrykach usługi ER

Podczas konfigurowania monitorowania obwodu usługi ExpressRoute węzły platformy Azure nie są wykrywane.

Może się to zdarzyć, jeśli węzły platformy Azure są połączone za pośrednictwem programu Operations Manager. Funkcja monitora usługi ExpressRoute obsługuje tylko te węzły platformy Azure, które są połączone jako agenci bezpośredni.

Nie mogę odnaleźć obwodów usługi ExpressRoute w portalu pakietu OMS

Chociaż narzędzie NPM może być używane zarówno z poziomu Azure Portal, jak i portalu pakietu OMS, odnajdywanie obwodu w funkcji Monitor usługi ExpressRoute działa tylko za pośrednictwem Azure Portal. Po odnalezieniu obwodów za pośrednictwem Azure Portal można użyć możliwości w jednym z dwóch portali.

W funkcji Monitor łączności usługi czas odpowiedzi usługi, utrata sieci, a także opóźnienie są wyświetlane jako NA

Może się to zdarzyć, jeśli co najmniej jedna z nich ma wartość true:

  • Usługa nie działa.
  • Węzeł używany do sprawdzania łączności sieciowej z usługą nie działa.
  • Element docelowy wprowadzony w konfiguracji testu jest niepoprawny.
  • Węzeł nie ma łączności sieciowej.

W funkcji Monitor łączności usługi jest wyświetlany prawidłowy czas odpowiedzi usługi, ale utrata sieci, a także opóźnienie są wyświetlane jako NA

Może się to zdarzyć, jeśli co najmniej jedna z nich ma wartość true:

  • Jeśli węzeł używany do sprawdzania łączności sieciowej z usługą jest Windows maszyną kliencką, usługa docelowa blokuje żądania ICMP lub zapora sieci blokuje żądania ICMP pochodzące z węzła.
  • Pole wyboru Wykonaj pomiary sieciowe jest puste w konfiguracji testu.

W funkcji Monitor łączności usługi czas odpowiedzi usługi to NA, ale utrata sieci, a także opóźnienie są prawidłowe

Może się tak zdarzyć, jeśli usługa docelowa nie jest aplikacją internetową, ale test jest skonfigurowany jako test sieci Web. Zmodyfikuj konfigurację testu i wybierz typ testu Sieć zamiast Sieć.

Różne

Czy występuje wpływ na wydajność węzła używanego do monitorowania?

Proces NPM jest skonfigurowany do zatrzymywania, jeśli korzysta z ponad 5% zasobów procesora CPU hosta. Ma to na celu zapewnienie możliwości korzystania z węzłów dla zwykłych obciążeń bez wpływu na wydajność.

Czy narzędzie NPM edytuje reguły zapory na potrzeby monitorowania?

Narzędzie NPM tworzy tylko lokalną regułę zapory Windows w węzłach, w których jest uruchamiany skrypt programu PowerShell EnableRules.ps1, aby umożliwić agentom tworzenie połączeń TCP ze sobą na określonym porcie. Rozwiązanie nie modyfikuje żadnych reguł zapory sieciowej ani sieciowej grupy zabezpieczeń.

Jak sprawdzić kondycję węzłów używanych do monitorowania?

Stan kondycji węzłów używanych do monitorowania można wyświetlić w następującym widoku: Monitor wydajności sieci — Konfiguracja —>> Węzły. Jeśli węzeł jest w złej kondycji, możesz wyświetlić szczegóły błędu i wykonać sugerowaną akcję.

Czy narzędzie NPM może zgłaszać liczby opóźnień w mikrosekundach?

Narzędzie NPM zaokrągla liczby opóźnień w interfejsie użytkownika i w milisekundach. Te same dane są przechowywane z wyższym stopniem szczegółowości (czasami do czterech miejsc dziesiętnych).

Czy narzędzie NPM obsługuje węzły wieloadowe?

Nie. Każdy węzeł NPM wymaga dedykowanego obszaru roboczego usługi Log Analytics.

Jakie dodatkowe wymagania ma narzędzie NPM dla systemu Linux?

Agent pakietu OMS dla systemu Linux wymaga również użycia interfejsu GLIBC 2.14 lub nowszego.

Następne kroki