Udostępnij za pośrednictwem


Tworzenie monitora połączeń przy użyciu klienta ARMClient

Ważne

Monitor połączeń (klasyczny) jest przestarzały i nie jest już dostępny. Aby uzyskać więcej informacji, zobacz Migrowanie z monitora połączeń (klasycznego) w celu migracji monitorów połączeń z monitora połączeń (klasycznego) do nowego monitora połączeń.

Dowiedz się, jak utworzyć Monitor połączenia do monitorowania komunikacji między zasobami przy użyciu klienta ARMClient. Obsługuje wdrożenia hybrydowe i wdrożenia w chmurze platformy Azure.

Zanim rozpoczniesz

W monitorach połączeń tworzonych w Monitor połączenia można dodawać zarówno maszyny lokalne, jak i maszyny wirtualne platformy Azure jako źródła. Te monitory połączeń mogą również monitorować łączność z punktami końcowymi. Punkty końcowe mogą znajdować się na platformie Azure lub w dowolnym innym adresie URL lub adresie IP.

Monitor połączenia obejmuje następujące jednostki:

  • Zasób monitora połączeń — zasób platformy Azure specyficzny dla regionu. Wszystkie poniższe jednostki to właściwości zasobu monitora połączeń.

  • Endpoint — źródło lub miejsce docelowe, które uczestniczy w sprawdzaniu łączności. Przykłady punktów końcowych to maszyny wirtualne platformy Azure, agenci lokalni, adresy URL i adresy IP.

  • Konfiguracja testu — konfiguracja specyficzna dla protokołu dla testu. Na podstawie wybranego protokołu można zdefiniować port, progi, częstotliwość testu i inne parametry.

  • Grupa testowa — grupa zawierająca źródłowe punkty końcowe, docelowe punkty końcowe i konfiguracje testowe. Monitor połączeń może zawierać więcej niż jedną grupę testową.

  • Test — kombinacja źródłowego punktu końcowego, docelowego punktu końcowego i konfiguracji testu. Test jest najbardziej szczegółowym poziomem, na którym są dostępne dane monitorowania. Dane monitorowania obejmują procent testów, które zakończyły się niepowodzeniem, oraz czas rundy (RTT).

    Diagram przedstawiający monitor połączeń, definiujący relację między grupami testowym i testami

Kroki tworzenia monitora połączeń przy użyciu klienta ARMClient

Użyj poniższego kodu, aby utworzyć monitor połączeń przy użyciu klienta ARMClient.

$connectionMonitorName = "sampleConnectionMonitor"

$ARM = "https://management.azure.com"

$SUB = "subscriptions/<subscription id 1>;"

$NW = "resourceGroups/NetworkWatcherRG/providers/Microsoft.Network/networkWatchers/NetworkWatcher\_<region>"

$body =

"{

location: '<region>',

properties: {

endpoints: [{

name: 'endpoint_workspace_machine',

type: 'MMAWorkspaceMachine',

resourceId: '/subscriptions/<subscription id>/resourcegroups/<resource group>/providers/Microsoft.OperationalInsights/workspaces/sampleWorkspace',

//Example 1: Choose a machine

address : '<non-Azure machine FQDN>'
}

//Example 2: Select IP from chosen machines

address : '<non-Azure machine FQDN>

"scope": {
      "include": [
            {
                  "address": "<IP belonging to machine chosen above>"  
	    }
       ]
      }
   }    
   
name: 'endpoint_workspace_network',

type: 'MMAWorkspaceNetwork',

resourceId: '/subscriptions/<subscription id>/resourcegroups/<resource group>/providers/Microsoft.OperationalInsights/workspaces/sampleWorkspace',

 coverage level : 'high', //Optional
 
 //Include subnets. You can also exclude IPs from subnet to exclude from monitoring
 
 scope: {
      "include": [
            {
                  "address": "<subnet 1 mask>" // Eg: 10.10.1.0/28
            },
            {
                  "address": "<subnet 2 mask>" 
            }
      ],
      "exclude": [
      		{ 
      		"address" : "<ip-from-included-subnets-that-should-be-excluded>"
		}
      ]
     }
},

//Use a Azure VM as an endpoint
{

name: 'endpoint_virtualmachine',

resourceId: '/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/virtualMachines/<vm-name>'

},

//Use an Azure VNET or Subnet as an endpoint

 {

name: 'endpoint_vnet_subnet',

resourceId: '<resource id of VNET or subnet'
coverage level: 'high' //Optional

//Scope is optional.

  "scope": {
      "include": [
            {
                  "address": "<subnet 1 mask>" // Eg: 10.10.1.0/28 .This subnet should match with any existing subnet in vnet
            }
      ],
    "exclude": [
            {
                  "address": "<ip-from-included-subnets-that-should-be-excluded>" // If used with include, IP should be part of the subnet defined above. Without include, this could be any address within vnet range or any specific subnet range as a whole.
            }
      ]
  }
   },

//Endpoint as a URL
{

name: 'azure portal'

address: '<URL>'

   },

//Endpoint as an IP 
 {

    name: 'ip',

     address: '<IP>'

 }

  ],

  testGroups: [{

    name: 'Connectivity to Azure Portal and Public IP',

    testConfigurations: ['http', 'https', 'tcpEnabled', 'icmpEnabled'],

    sources: ['vm1', 'workspace'],

    destinations: ['azure portal', 'ip']

   },

{

    name: 'Connectivty from Azure VM 1 to Azure VM 2',

   // Choose your protocol
   
    testConfigurations: ['http', 'https', 'tcpDisabled', 'icmpDisabled'],

    sources: ['vm1'],

    destinations: ['vm2'],

    disable: true

   }

  ],

  testConfigurations: [{

    name: 'http',

    testFrequencySec: <frequency>,

    protocol: 'HTTP',

    successThreshold: {

     checksFailedPercent: <threshold for checks failed %>,

     roundTripTimeMs: <threshold for RTT>

    }

   }, {

    name: 'https',

    testFrequencySec: <frequency>,

    protocol: 'HTTP',

    httpConfiguration: {
    
     port: '<port of choice>'
  
    preferHTTPS: true // If port chosen isn't 80 or 443
    
    method: 'GET', //Choose GET or POST
    
    path: '/', //Specify path for request
         
    requestHeaders: [
            {
              "name": "Content-Type",
              "value": "appication/json"
            }
          ],
          
    validStatusCodeRanges: [ "102", "200-202", "3xx" ], //Samples
          
    },

    successThreshold: {

     checksFailedPercent: <choose your checks failed threshold>,

     roundTripTimeMs: <choose your RTT threshold>

    }

   }, 
   {

    name: 'tcpEnabled',

    testFrequencySec: <frequency>,

    protocol: 'TCP',

    tcpConfiguration: {

     port: 80

    },

    successThreshold: {

     checksFailedPercent: <choose your checks failed threshold>,

     roundTripTimeMs: <choose your RTT threshold>

    }

   }, {

    name: 'icmpEnabled',

    testFrequencySec: <frequency>,

    protocol: 'ICMP',

    successThreshold: {

     checksFailedPercent: <choose your checks failed threshold>,

     roundTripTimeMs: <choose your RTT threshold>

    }

   }, {

    name: 'icmpDisabled',

    testFrequencySec: <frequency>,

    protocol: 'ICMP',

    icmpConfiguration: {

     disableTraceRoute: true

    },

    successThreshold: {

     checksFailedPercent: <choose your checks failed threshold>,

     roundTripTimeMs: <choose your RTT threshold>

    }

   }, {

    name: 'tcpDisabled',

    testFrequencySec: <frequency>,

    protocol: 'TCP',

    tcpConfiguration: {

     port: 80,

     disableTraceRoute: true

    },

    successThreshold: {

     checksFailedPercent: <choose your checks failed threshold>,

     roundTripTimeMs: <choose your RTT threshold>

    }

   }

  ]

 }

} "

Oto polecenie wdrożenia:

armclient PUT $ARM/$SUB/$NW/connectionMonitors/$connectionMonitorName/?api-version=2019-07-01 $body -verbose

Opis właściwości

  • connectionMonitorName — nazwa zasobu monitora połączeń

  • SUB — identyfikator subskrypcji subskrypcji, w której chcesz utworzyć monitor połączeń

  • NW — identyfikator zasobu usługi Network Watcher, w którym jest tworzony cm

  • location — region, w którym jest tworzony monitor połączeń

  • Punkty końcowe

    • name — unikatowa nazwa dla każdego punktu końcowego
    • resourceId — w przypadku punktów końcowych platformy Azure identyfikator zasobu odnosi się do identyfikatora zasobu usługi Azure Resource Manager dla maszyn wirtualnych. W przypadku punktów końcowych spoza platformy Azure identyfikator zasobu odnosi się do identyfikatora zasobu usługi Azure Resource Manager dla obszaru roboczego usługi Log Analytics połączonego z agentami spoza platformy Azure.
    • address — dotyczy tylko wtedy, gdy identyfikator zasobu nie jest określony lub jeśli identyfikator zasobu jest obszarem roboczym usługi Log Analytics. Jeśli jest używany z identyfikatorem zasobu usługi Log Analytics, oznacza to nazwę FQDN agenta, który może być używany do monitorowania. Jeśli nie określono identyfikatora zasobu, może to być adres URL lub adres IP dowolnego publicznego punktu końcowego.
    • filter — w przypadku punktów końcowych spoza platformy Azure użyj filtru, aby wybrać agentów z obszaru roboczego usługi Log Analytics, który będzie używany do monitorowania w zasobie Monitor połączeń. Jeśli filtry nie są ustawione, wszyscy agenci należący do obszaru roboczego usługi Log Analytics mogą służyć do monitorowania
      • type — ustaw typ jako "Adres agenta"
      • address — ustaw adres jako nazwę FQDN agenta lokalnego
  • Grupy testów

    • name — nazwij grupę testową.
    • testConfigurations — konfiguracje testów oparte na tym, które źródłowe punkty końcowe łączą się z docelowymi punktami końcowymi
    • sources — wybierz z punktów końcowych utworzonych powyżej. Punkty końcowe źródłowe oparte na platformie Azure muszą mieć zainstalowane rozszerzenie usługi Azure Network Watcher, a punkty końcowe źródłowe nienależące do platformy Azure muszą mieć zainstalowanego agenta usługi Log Analytics platformy Azure. Aby zainstalować agenta dla źródła, zobacz Instalowanie agentów monitorowania.
    • destinations — wybierz z punktów końcowych utworzonych powyżej. Możesz monitorować łączność z maszynami wirtualnymi platformy Azure lub dowolnym punktem końcowym (publicznym adresem IP, adresem URL lub nazwą FQDN), określając je jako lokalizacje docelowe. W jednej grupie testowej można dodawać maszyny wirtualne platformy Azure, adresy URL usługi Office 365, adresy URL usługi Dynamics 365 i niestandardowe punkty końcowe.
    • disable — to pole służy do wyłączania monitorowania dla wszystkich źródeł i miejsc docelowych, które określa grupa testowa.
  • Konfiguracje testów

    • name — nazwa konfiguracji testu.

    • testFrequencySec — określ, jak często źródła będą wysyłać polecenia ping do miejsc docelowych w określonym protokole i porcie. Możesz wybrać 30 sekund, 1 minutę, 5 minut, 15 minut lub 30 minut. Źródła przetestują łączność z miejscami docelowymi na podstawie wybranej wartości. Jeśli na przykład wybierzesz 30 sekund, źródła będą sprawdzać łączność z miejscem docelowym co najmniej raz w okresie 30 sekund.

    • protokół — możesz wybrać protokół TCP, ICMP, HTTP lub HTTPS. W zależności od protokołu można wykonać kilka konfiguracji specyficznych dla protokołu

      • preferHTTPS — określ, czy używać protokołu HTTPS za pośrednictwem protokołu HTTP, jeśli używany port nie jest ani 80, ani 443
      • port — określ wybrany port docelowy.
      • disableTraceRoute — dotyczy to konfiguracji testowych, których protokół to TCP lub ICMP. Zatrzymuje źródła od odnajdywania topologii i przeskoku RTT.
      • metoda — dotyczy to konfiguracji testowych, których protokół to HTTP. Wybierz metodę żądania HTTP — get lub POST
      • path — określ parametry ścieżki, które mają być dołączane do adresu URL
      • validStatusCodes — wybierz odpowiednie kody stanu. Jeśli kod odpowiedzi nie jest zgodny z tą listą, zostanie wyświetlony komunikat diagnostyczny
      • requestHeaders — określ niestandardowe ciągi nagłówka żądania, które zostaną przekazane do miejsca docelowego
    • successThreshold — można ustawić progi dla następujących parametrów sieci:

      • checksFailedPercent — ustaw procent testów, które mogą zakończyć się niepowodzeniem, gdy źródła sprawdzają łączność z miejscami docelowymi, korzystając z określonych kryteriów. W przypadku protokołu TCP lub ICMP procent nieudanych testów można porównać do wartości procentowej utraty pakietów. W przypadku protokołu HTTP to pole reprezentuje procent żądań HTTP, które nie otrzymały odpowiedzi.
      • roundTripTimeMs — ustaw protokół RTT w milisekundach, aby określić, jak długo źródła mogą łączyć się z miejscem docelowym w ramach konfiguracji testowej.

Limity skalowania

Monitory połączeń mają następujące limity skalowania:

  • Maksymalna liczba monitorów połączeń na subskrypcję na region: 100
  • Maksymalna liczba grup testowych na monitor połączenia: 20
  • Maksymalna liczba źródeł i miejsc docelowych na monitor połączenia: 100
  • Maksymalna liczba konfiguracji testów na monitor połączeń: 20 za pośrednictwem klienta ARMClient

Następne kroki