FAQ (perguntas frequentes) sobre o Observador de Rede do Azure

O Observador de Rede fornece um conjunto de ferramentas para monitorar, diagnosticar, exibir métricas e habilitar ou desabilitar logs para recursos de IaaS (infraestrutura como serviço), que incluem máquinas virtuais, redes virtuais, gateways de aplicativo, balanceadores de carga e outros recursos em uma rede virtual do Azure. Não é uma solução para monitorar a infraestrutura PaaS (plataforma como serviço) ou para obter Web/Mobile Analytics.

O Observador de Rede fornece três conjuntos principais de funcionalidades:

• Monitoramento
  • A Exibição de topologia mostra os recursos em sua rede virtual e as relações entre eles.
  • O monitor da conexão permite monitorar a conectividade e a latência entre pontos de extremidade dentro e fora do Azure.
• Ferramentas de diagnóstico de rede
  • A Verificação de Fluxo de IP permite detectar problemas de filtragem de tráfego em um nível de VM.
  • O NSG diagnóstico permite detectar problemas de filtragem de tráfego em uma máquina virtual, conjunto de dimensionamento de máquinas virtuais ou nível de gateway de aplicativo.
  • O Próximo salto ajuda a verificar as rotas de tráfego e detectar problemas de roteamento.
  • A solução de problemas de conexão permite uma conectividade única e verificação de latência entre uma máquina virtual e o bastion host, gateway de aplicativo ou outra máquina virtual.
  • A captura de pacotes permite capturar o tráfego da máquina virtual.
  • A Solução de Problemas de VPN executa várias verificações de diagnóstico em seus gateways de VPN e conexões para ajudar a depurar problemas.
• Tráfego
  • Os logs de fluxo de rede virtual e os logs de fluxo do grupo de segurança de rede permitem registrar o tráfego de rede que passa pelas suas redes virtuais e grupos de segurança de rede (NSGs), respectivamente.
  • A Análise de Tráfego processa seus dados do log de fluxo do grupo de segurança de rede, permitindo que você visualize, consulte, analise e entenda o tráfego de rede.

Para obter informações mais detalhadas, consulte a página Visão geral do Observador de Rede.

Consulte preços do Observador de Rede para obter detalhes de preços sobre diferentes componentes de Observador de Rede.

Confira regiões do Observador de Rede para saber mais sobre as regiões que dão suporte ao Observador de Rede.

Confira Permissões RBAC do Azure necessárias para usar o Observador de Rede para obter uma lista detalhada das permissões necessárias para cada um dos recursos de Observador de Rede.

O serviço do Observador de Rede é habilitado automaticamente para cada assinatura. Você deve habilitar manualmente o Observador de Rede se tiver recusado a habilitação automática do Observador de Rede. Para obter mais informações, consulte Habilitar ou desabilitar o Observador de Rede do Azure.

O recurso pai do Observador de Rede é implantado com uma instância exclusiva em cada região. Formato de nomenclatura padrão: NetworkWatcher_RegionName. Exemplo: NetworkWatcher_centralus é o recurso do Observador de Rede para a região "EUA Central". Você pode personalizar o nome da instância do Observador de Rede usando PowerShell ou API REST.

Observador de Rede só precisa ser habilitada uma vez por região por assinatura para que seus recursos funcionem. O Observador de Rede é habilitado em uma região criando uma instância do Observador de Rede nessa região.

O recurso do Observador de Rede representa o serviço de back-end do Observador de Rede, que é totalmente gerenciado pelo Azure. No entanto, você pode criar ou excluir o recurso Observador de Rede para habilitá-lo ou desabilitá-lo em uma região específica. Para obter mais informações, consulte Habilitar ou desabilitar o Observador de Rede do Azure.

Não há suporte para mover o recurso Observador de Rede ou qualquer um de seus recursos filho entre regiões. Para obter mais informações, confira Suporte à operação Mover para recursos de rede.

Sim, há suporte para mover o recurso Observador de Rede entre grupos de recursos. Para obter mais informações, confira Suporte à operação Mover para recursos de rede.

O NetworkWatcherRG é um grupo de recursos criado automaticamente para os recursos do Observador de Rede. Por exemplo, as instâncias regionais do Observador de Rede e os recursos de log de fluxo do grupo de segurança de rede são criados no grupo de recursos NetworkWatcherRG. Você pode personalizar o nome do grupo de recursos do Observador de Rede usando PowerShell, CLI do Azure ou API REST.

O Observador de Rede do Azure não armazena dados de clientes, exceto o Monitor da Conexão. O monitor da conexão armazena dados do cliente, que são armazenados automaticamente por Observador de Rede em uma única região para atender aos requisitos de residência de dados na região.

O Observador de Rede tem os seguintes limites:

Sim. Por padrão, o serviço Observador de Rede é resiliente por zona.

Nenhuma configuração será necessária para habilitar a resiliência de zona. A resiliência por zona para recursos do Observador de Rede está disponível por padrão e é gerenciada pelo próprio serviço.

O agente do Observador de Rede é necessário para qualquer Observador de Rede que gere ou intercepte o tráfego de uma máquina virtual.

Os recursos monitor de conexão, captura de pacote e solução de problemas de conexão (teste de conectividade) exigem que a extensão observador de rede esteja presente.

A versão mais recente da extensão do Observador de Rede é atualmente 1.4.3783.1. Para obter mais informações, confira Atualizar a extensão do Observador de Rede do Azure para a versão mais recente.

• Linux: o Agente do Observador de Rede usa portas disponíveis a partir de port 50000 até chegar port 65535.
• Windows: o agente do Observador de Rede usa as portas com as quais o sistema operacional responde quando consultado para portas disponíveis.

O Agente do Observador de Rede requer conectividade TCP de saída para 169.254.169.254 por port 80 e 168.63.129.16 por port 8037. O agente usa esses endereços IP para se comunicar com a plataforma Azure.

Não, o monitor da conexão não é compatível com VMs clássicas. Para saber mais, confira Migrar recursos de IaaS do Clássico para o Azure Resource Manager.

A topologia poderá ser decorada de não Azure para Azure somente se o recurso do Azure de destino e o recurso do monitor da conexão estiverem na mesma região.

A mesma VM do Azure não pode ser usada com configurações diferentes no mesmo monitor de conexão. Por exemplo, não há suporte para usar a mesma VM com um filtro e sem um filtro no mesmo monitor da conexão.

Problemas exibidos no painel do monitor da conexão são encontrados durante a descoberta de topologia ou a exploração de salto. Pode haver casos em que o limite definido para % de perda ou RTT é violado, mas nenhum problema é encontrado nos saltos.

Não há nenhuma opção de seleção de protocolo no monitor de conexão (clássico). Os testes no monitor de conexão (clássico) usam apenas o protocolo TCP e é por isso que, durante a migração, criamos uma configuração TCP em testes no novo monitor de conexão.

Atualmente, há um limite regional quando um ponto de extremidade usa agentes do Azure Monitor e do Arc com o workspace do Log Analytics associado. Como resultado dessa limitação, o workspace associado do Log Analytics deve estar na mesma região que o ponto de extremidade arc. Os dados ingeridos em workspaces individuais podem ser sindicalizados para uma única exibição, consulte os Dados de consulta em workspaces, aplicativos e recursos do Log Analytics no Azure Monitor.

Os logs de fluxo permitem que você registre informações de fluxo de 5 tuplas sobre o tráfego IP do Azure que passa por um grupo de segurança de rede ou rede virtual do Azure. Os logs de fluxo bruto são gravados em uma conta de Armazenamento do Azure. A partir daí, você poderá processá-los, analisá-los, consultá-los ou exportá-los conforme necessário.

Os dados do log de fluxo são coletados fora do caminho do tráfego de rede, portanto, não afetam a taxa de transferência ou a latência da rede. Você pode criar ou excluir logs de fluxo sem nenhum risco de impacto no desempenho da rede.

Os logs de fluxo do grupo de segurança de rede registram o tráfego que passa por um grupo de segurança de rede. Por outro lado, o diagnóstico NSG retorna todos os grupos de segurança de rede que o tráfego está atravessando e as regras de cada grupo de segurança de rede que são aplicadas a esse tráfego. Use o diagnóstico NSG para verificar se as regras do grupo de segurança de rede estão sendo aplicadas conforme o esperado.

Não, os logs de fluxo do grupo de segurança de rede não dão suporte a protocolos ESP e AH.

Não, os logs de fluxo do grupo de segurança de rede e os logs de fluxo da rede virtual não dão suporte ao protocolo ICMP.

Sim. O recurso de log de fluxo associado também será excluído. Os dados do log de fluxo são mantidos na conta de armazenamento pelo período de retenção configurado no log de fluxo.

Sim, mas você deve excluir o recurso de log de fluxo associado. Depois de migrar um grupo de segurança de rede, você precisará recriar os logs de fluxo para habilitar o registro em log de fluxo nesse grupo.

Sim, você pode usar uma conta de armazenamento de uma assinatura diferente, desde que essa assinatura esteja na mesma região do grupo de segurança de rede e esteja associada ao mesmo locatário do Microsoft Entra do grupo de segurança de rede ou assinatura da rede virtual.

Para usar uma conta de armazenamento protegida por firewall, você deve permitir que serviços do Azure confiáveis acessem sua conta de armazenamento:

1. Acesse a conta de armazenamento inserindo o nome da conta de armazenamento na caixa de pesquisa na parte superior do portal.
2. Em Segurança + rede, selecione Rede e, em seguida, selecione Firewalls e redes virtuais.
3. Em Acesso à rede pública, selecione Habilitado em redes virtuais e endereços IP selecionados. Depois, em Exceções, marque a caixa de seleção ao lado de Permitir que os serviços do Azure na lista de serviços confiáveis acessem esta conta de armazenamento.
4. Habilite logs de fluxo criando um log de fluxo para o recurso de destino usando a conta de armazenamento. Para obter mais informações, consulteCriar um log de fluxo.

Você pode verificar os logs de armazenamento após alguns minutos. Você deverá ver um carimbo TimeStamp atualizado ou um novo arquivo JSON criado.

Atualmente, uma conta de armazenamento dá suporte a 100 regras e cada regra pode acomodar 10 prefixos de blob. Se você atingir o limite, poderá definir a política de retenção como 0 quando habilitar novos logs de fluxo de rede virtual e, em seguida, adicionar manualmente uma regra de retenção para a assinatura.

Para criar uma regra de assinatura de política de retenção, siga estas etapas:

1. Acesse a conta de armazenamento inserindo o nome da conta de armazenamento na caixa de pesquisa na parte superior do portal.
2. Em Gerenciamento de dados, selecione Gerenciamento do Ciclo de Vida.
3. Selecione + Adicionar regra.
4. Na seção Detalhes, selecione as seguintes configurações: Escopo da regra:Limitar blobs com filtros, Tipo de Blob:Blobs de Bloco, e Subtipo de Blob:Blobs de Base.
5. Na seção Blobs base , defina as configurações de retenção.
6. Na seção Conjunto de filtros , formate o prefixo de Blob como o seguinte: "insights-logs-flowlogflowevent/flowLogResourceID=/<yourSubscriptionId>_NETWORKWATCHERRG"
7. Selecione Adicionar.

A regra com período de retenção mais curto tem precedência.

O Observador de Rede tem um mecanismo de fallback interno que ele usa ao se conectar a uma conta de armazenamento por trás de um firewall (firewall habilitado). Ele tenta se conectar à conta de armazenamento usando uma chave e, se isso falhar, ele alterna para um token. Nesse caso, um erro 403 é registrado no log de atividades da conta de armazenamento.

Sim, o Observador de Rede dá suporte ao envio de dados de logs de fluxo para uma conta de armazenamento habilitada com um ponto de extremidade privado.

Os logs de fluxo são compatíveis com pontos de extremidade de serviço sem exigir nenhuma configuração extra. Para obter mais informações, confira Habilitar um ponto de extremidade de serviço.

A versão 2 dos logs de fluxo introduz o conceito de estado do fluxo e armazena informações sobre bytes e pacotes transmitidos. Para obter mais informações, confira Formato do log de fluxo do grupo de segurança de rede.

Não. Um bloqueio read-only em um grupo de segurança de rede impede a criação do log de fluxo correspondente do grupo de segurança de rede.

Sim. Um bloqueio cannot-delete em um grupo de segurança de rede não impede a criação ou modificação do log de fluxo correspondente do grupo de segurança de rede.

Sim, você pode automatizar os logs de fluxo do grupo de segurança de rede por meio de modelos do Azure Resource Manager (ARM). Para obter mais informações, confira Configurar logs de fluxo do NSG usando um modelo do Azure Resource Manager (ARM).

Sim, redes virtuais e grupos de segurança de rede podem estar em regiões diferentes da região do workspace do Log Analytics.

Sim.

No menu suspenso de seleção de recursos no painel de análise de tráfego, o grupo de recursos do recurso Rede Virtual deve ser selecionado, não o grupo de recursos da máquina virtual ou grupo de segurança de rede.

A análise de tráfego executa uma verificação de descoberta de recursos a cada 6 horas para identificar novas VMs, NICs, redes virtuais e sub-redes. Quando uma nova VM ou NIC é criada após o ciclo de descoberta mais recente e os dados de fluxo são coletados antes da próxima descoberta, a análise de tráfego ainda não pode associar o tráfego a um recurso conhecido. Como resultado, esses recursos são temporariamente rotulados como desconhecidos na exibição de análise.

Sim, você pode desabilitar o acesso público ao recurso DCE (ponto de extremidade de coleta de dados) para bloquear o tráfego de entrada público para ele. A ingestão continua funcionando sem associar o recurso DCE a um escopo de Link Privado do Azure Monitor.

Sim. Se você selecionar um workspace existente, verifique se ele foi migrado para o novo idioma de consulta. Se você não quiser atualizar o espaço de trabalho, precisará criar um novo. Para obter mais informações sobre a KQL (Linguagem de Consulta Kusto), consulte consultas de log no Azure Monitor.

Sim, sua conta de armazenamento do Azure pode estar em uma assinatura e seu workspace do Log Analytics pode estar em uma assinatura diferente.

Sim. Você pode configurar os logs de fluxo para serem enviados para uma conta de armazenamento localizada em uma assinatura diferente, desde que tenha os privilégios apropriados e que a conta de armazenamento esteja localizada na mesma região que o grupo de segurança de rede (logs de fluxo do grupo de segurança de rede) ou rede virtual (logs de fluxo da rede virtual). A conta de armazenamento de destino deve compartilhar o mesmo locatário do Microsoft Entra do grupo de segurança de rede ou da rede virtual.

Não. Todos os recursos devem estar no mesmo locatário, incluindo grupos de segurança de rede (logs de fluxo do grupo de segurança de rede), redes virtuais (logs de fluxo da rede virtual), logs de fluxo, contas de armazenamento e workspaces do Log Analytics (se a análise de tráfego estiver habilitada).

Sim.

As pastas de trabalho da Análise de Tráfego são alimentadas por consultas do Log Analytics. Se a consulta exceder os limites para análise de logs, a pasta de trabalho poderá apresentar erros de pouca memória. Para melhorar o desempenho e reduzir erros de memória baixos, os usuários podem usar clusters dedicados do Log Analytics.

Não. Se você excluir a conta de armazenamento usada para logs de fluxo, os dados armazenados no workspace do Log Analytics não serão afetados. Você ainda pode exibir dados históricos no workspace do Log Analytics (algumas métricas serão afetadas), mas a análise de tráfego não processará mais nenhum novo log de fluxo até que você atualize os logs de fluxo para usar uma conta de armazenamento diferente.

Selecione uma região com suporte. Se você selecionar uma região sem suporte, receberá um erro "Não encontrado". Para obter mais informações, consulte regiões com suporte da Análise de Tráfego.

O Microsoft.Insights provedor deve ser registrado para que o registro em log de fluxo funcione corretamente. Se você não tiver certeza se o provedor Microsoft.Insights está registrado na sua assinatura, confira as instruções em Gerenciar logs de fluxo do NSG para saber como registrá-lo.

O painel pode levar até 30 minutos para mostrar relatórios pela primeira vez. A solução deve primeiro agregar dados suficientes para derivar insights significativos e gerar relatórios.

Experimente as seguintes opções:

• Altere o intervalo de tempo na barra superior.
• Selecione um espaço de trabalho diferente do Log Analytics na barra superior.
• Tente acessar a análise de tráfego após 30 minutos, se ela tiver sido habilitada recentemente.

Você pode ver esta mensagem porque:

• A análise de tráfego foi habilitada recentemente e talvez ainda não tenha agregado dados suficientes para que ela derivasse insights significativos.
• Você está usando a versão gratuita do espaço de trabalho do Log Analytics e excedeu os limites de cota. Talvez seja necessário usar um workspace com uma capacidade maior.

Experimente as soluções sugeridas para a pergunta anterior. Se os problemas persistirem, crie preocupações no Microsoft Q&A.

Você está vendo as informações de recursos no painel; no entanto, nenhuma estatística relacionada ao fluxo está presente. Os dados podem não estar presentes devido a nenhum fluxo de comunicação entre os recursos. Aguarde 60 minutos e verifique novamente o status. Se o problema persistir e você tiver certeza de que os fluxos de comunicação entre os recursos existem, crie preocupações no Microsoft Q&A.

A análise de tráfego é medida. A medição é baseada no processamento de dados brutos do log de fluxo pelo serviço. Para saber mais, veja Preço do Observador de Rede.
Os logs aprimorados ingeridos no workspace do Log Analytics podem ser mantidos sem custo por até 31 dias (ou 90 dias se o Microsoft Sentinel estiver habilitado no workspace). Para obter mais informações, consulte os preços do Azure Monitor.

O intervalo de processamento padrão da análise de tráfego é de 60 minutos, no entanto, você pode selecionar o processamento acelerado em intervalos de 10 minutos. Para obter mais informações, consulte Agregação de dados na análise de tráfego.

A análise de tráfego cria e gerencia recursos de regra de coleta de dados (DCR) e ponto de extremidade de coleta de dados (DCE) no mesmo grupo de recursos que o espaço de trabalho, com o prefixo NWTA. Se você executar qualquer operação nesses recursos, a análise de tráfego poderá não funcionar conforme o esperado. Para obter mais informações, consulte Agregação de dados na análise de tráfego. Para obter mais informações, consulte as regras de coleta de dados no Azure Monitor e pontos de extremidade de coleta de dados no Azure Monitor.

Não é recomendável aplicar bloqueios aos recursos de DCR e DCE criados pela análise de tráfego, pois esses recursos são gerenciados pelo serviço. Os recursos bloqueados não são limpos após a exclusão dos logs de fluxo relacionados. Se você executar qualquer operação nesses recursos, a análise de tráfego poderá não funcionar conforme o esperado. Para obter mais informações, consulte Agregação de dados na análise de tráfego.

A análise de tráfego depende de sistemas internos de inteligência contra ameaças da Microsoft para considerar um IP como mal-intencionado. Esses sistemas utilizam fontes diversas de telemetria, como produtos e serviços da Microsoft, a Unidade de Crimes Digitais da Microsoft (DCU), o Centro de Resposta de Segurança da Microsoft (MSRC), e feeds externos, criando inteligência sobre essas fontes. Alguns desses dados são internos da Microsoft. Se um IP conhecido estiver sendo sinalizado como mal-intencionado, crie um tíquete de suporte para saber os detalhes.

A análise de tráfego não tem suporte interno para alertas. No entanto, como os dados da análise de tráfego são armazenados no Log Analytics, você pode escrever consultas personalizadas e definir alertas neles. Siga estas etapas:

• Você pode usar o link do Log Analytics na análise de tráfego.
• Use o esquema de análise de tráfego para gravar suas consultas.
• Selecione Nova regra de alerta para criar o alerta.
• Consulte Criar uma nova regra de alerta para criar o alerta.

Não, atualmente não há suporte. Se um espaço de trabalho do Log Analytics estiver implantado por trás de um perímetro de segurança de rede, a análise de tráfego não poderá captar dados dele.

Sim. A solução de problemas de conexão e o diagnóstico do NSG não dão suporte a ambientes privados do Gateway de Aplicativo. Para obter mais informações, confira Implantação do Gateway de Aplicativo Privado.