Share via


Criar um monitor de ligação com o ARMClient

Importante

A partir de 1 de julho de 2021, não poderá adicionar novos testes numa área de trabalho existente ou ativar uma nova área de trabalho no Monitor de Desempenho de Rede. Também não poderá adicionar novos monitores de ligação no Monitor de Ligação (clássico). Pode continuar a utilizar os testes e monitores de ligação criados antes de 1 de julho de 2021. Para minimizar a interrupção do serviço nas cargas de trabalho atuais, migre os testes do Monitor de Desempenho de Rede ou migre de Monitor de Ligação (clássico) para o novo Monitor de Ligação no Azure Observador de Rede antes de 29 de fevereiro de 2024.

Saiba como criar Monitor de Ligação para monitorizar a comunicação entre os seus recursos com o ARMClient. Suporta implementações híbridas e na cloud do Azure.

Antes de começar

Nos monitores de ligação que criar no Monitor de Ligação, pode adicionar máquinas no local e VMs do Azure como origens. Estes monitores de ligação também podem monitorizar a conectividade aos pontos finais. Os pontos finais podem estar no Azure ou em qualquer outro URL ou IP.

Monitor de Ligação inclui as seguintes entidades:

  • Recurso de monitorização de ligação – um recurso do Azure específico da região. Todas as seguintes entidades são propriedades de um recurso de monitorização de ligação.

  • Ponto final – uma origem ou destino que participa em verificações de conectividade. Exemplos de pontos finais incluem VMs do Azure, agentes no local, URLs e IPs.

  • Configuração de teste – uma configuração específica do protocolo para um teste. Com base no protocolo que escolheu, pode definir a porta, os limiares, a frequência de teste e outros parâmetros.

  • Grupo de teste – o grupo que contém pontos finais de origem, pontos finais de destino e configurações de teste. Um monitor de ligação pode conter mais do que um grupo de teste.

  • Test – a combinação de um ponto final de origem, ponto final de destino e configuração de teste. Um teste é o nível mais granular no qual os dados de monitorização estão disponíveis. Os dados de monitorização incluem a percentagem de verificações que falharam e o tempo de ida e volta (RTT).

    Diagrama a mostrar um monitor de ligação, a definir a relação entre grupos de teste e testes

Passos para criar um monitor de ligação com o ARMClient

Utilize o seguinte código para criar um monitor de ligação com o 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>

    }

   }

  ]

 }

} "

Eis o comando de implementação:

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

Descrição das Propriedades

  • connectionMonitorName - Nome do recurso do Monitor de ligação

  • SUB – ID da subscrição onde pretende criar o monitor de ligação

  • NW - Observador de Rede ID de recurso no qual o CM será criado

  • location - Região na qual o monitor de ligação será criado

  • Pontos Finais

    • name – Nome exclusivo para cada ponto final
    • resourceId – para pontos finais do Azure, o ID do recurso refere-se ao ID de recurso do Azure Resource Manager para máquinas virtuais. Para pontos finais que não são do Azure, o ID do recurso refere-se ao ID de recurso do Azure Resource Manager para a área de trabalho do Log Analytics ligada a agentes não Azure.
    • address – aplicável apenas quando o ID de recurso não for especificado ou se o ID do recurso for uma área de trabalho do Log Analytics. Se for utilizado com o ID de recurso do Log Analytics, isto refere-se ao FQDN do agente que pode ser utilizado para monitorização. Se for utilizado sem o ID de recurso, pode ser o URL ou IP de qualquer ponto final público.
    • filter – para pontos finais não Azure, utilize o filtro para selecionar agentes da área de trabalho do Log Analytics que serão utilizados para monitorização no recurso monitor de Ligação. Se os filtros não estiverem definidos, todos os agentes pertencentes à área de trabalho do Log Analytics podem ser utilizados para monitorização
      • type – Definir o tipo como "Endereço do Agente"
      • address – defina o endereço como o FQDN do agente no local
  • Grupos de Teste

    • name - Atribua um nome ao grupo de teste.
    • testConfigurations - Configurações de Teste com base nos pontos finais de origem que se ligam aos pontos finais de destino
    • origens – escolha a partir dos pontos finais criados acima. Os pontos finais de origem baseados no Azure precisam de ter a extensão do Azure Observador de Rede instalada e os pontos finais de origem não baseados no Azure têm de ter o agente do Log Analytics do Azure instalado. Para instalar um agente para a sua origem, veja Instalar agentes de monitorização.
    • destinos – escolha entre os pontos finais criados acima. Pode monitorizar a conectividade às VMs do Azure ou a qualquer ponto final (um IP público, URL ou FQDN) ao especificá-las como destinos. Num único grupo de teste, pode adicionar VMs do Azure, URLs de Office 365, URLs de Dynamics 365 e pontos finais personalizados.
    • desativar – utilize este campo para desativar a monitorização para todas as origens e destinos especificados pelo grupo de teste.
  • Configurações de Teste

    • name - Nome da configuração de teste.

    • testFrequencySec - Especifique a frequência com que as origens enviarão ping para destinos no protocolo e na porta que especificou. Pode escolher 30 segundos, 1 minuto, 5 minutos, 15 minutos ou 30 minutos. As origens irão testar a conectividade a destinos com base no valor que escolher. Por exemplo, se selecionar 30 segundos, as origens verificarão a conectividade ao destino pelo menos uma vez num período de 30 segundos.

    • protocolo – pode escolher TCP, ICMP, HTTP ou HTTPS. Consoante o protocolo, pode efetuar algumas configurações específicas do protocolo

      • preferHTTPS - Especifique se deve utilizar HTTPS em http, quando a porta utilizada não é 80 nem 443
      • porta – especifique a porta de destino à sua escolha.
      • disableTraceRoute – aplica-se a configurações de teste cujo protocolo é TCP ou ICMP. Impede que as origens descubram topologia e hop-by-hop RTT.
      • method - Isto aplica-se a configurações de teste cujo protocolo é HTTP. Selecione o método de pedido HTTP – GET ou POST
      • path - Especifique os parâmetros do caminho a acrescentar ao URL
      • validStatusCodes – escolha os códigos de estado aplicáveis. Se o código de resposta não corresponder a esta lista, receberá uma mensagem de diagnóstico
      • requestHeaders - Especifique cadeias de cabeçalho de pedido personalizadas que serão transmitidas para o destino
    • successThreshold - Pode definir limiares nos seguintes parâmetros de rede:

      • checksFailedPercent - Defina a percentagem de verificações que podem falhar quando as origens verificam a conectividade aos destinos com os critérios que especificou. Para o protocolo TCP ou ICMP, a percentagem de verificações falhadas pode ser equiparada à percentagem de perda de pacotes. Para o protocolo HTTP, este campo representa a percentagem de pedidos HTTP que não receberam resposta.
      • roundTripTimeMs - Defina o RTT em milissegundos para saber quanto tempo as origens podem demorar a ligar ao destino através da configuração de teste.

Limites de dimensionamento

Os monitores de ligação têm os seguintes limites de dimensionamento:

  • Máximo de monitores de ligação por subscrição por região: 100
  • Máximo de grupos de teste por monitor de ligação: 20
  • Máximo de origens e destinos por monitor de ligação: 100
  • Configurações de teste máximas por monitor de ligação: 20 através do ARMClient

Passos seguintes