Lista de verificação de resiliência para serviços específicos do Azure

  • Artigo

Resiliência é a capacidade de um sistema de se recuperar de falhas e continuar funcionando. Cada tecnologia tem seus próprios modos de falha específicos, o que você deve considerar ao projetar e implementar seu aplicativo. Use esta lista de verificação para revisar as considerações de resiliência para serviços específicos do Azure. Saiba mais sobre a criação de aplicativos resilientes em Desenvolver aplicativos do Azure resilientes.

Serviço de Aplicativo

Use a camada Standard ou Premium. Essas camadas dão suporte a slots de preparo e backups automáticos. Para obter mais informações, consulte Visão geral aprofundada de planos do Serviço de Aplicativo do Azure

Evite expandir ou reduzir verticalmente. Em vez disso, selecione uma camada e o tamanho de instância que atendem aos seus requisitos de desempenho sob carga típica e, em seguida, escale horizontalmente as instâncias para manipular as alterações no volume de tráfego. Expandir e reduzir verticalmente pode disparar uma reinicialização do aplicativo.

Armazene a configuração como configurações de aplicativo. Use as configurações de aplicativo para manter definições de configuração como configurações de aplicativo. Defina as configurações em seus modelos do Resource Manager ou usando o PowerShell, para que você possa aplicá-las como parte de um processo automatizado de implantação/atualização, que é mais confiável. Para obter mais informações, consulte Configurar aplicativos Web no Serviço de Aplicativo do Azure.

Crie Planos do Serviço de Aplicativo separados para produção e teste. Não use slots em sua implantação de produção para teste. Todos os aplicativos dentro do mesmo Plano do Serviço de Aplicativo compartilham as mesmas instâncias de VM. Se você colocar a produção e implantações de teste no mesmo plano, isso poderá afetar negativamente a implantação de produção. Por exemplo, testes de carga podem prejudicar o site de produção dinâmica. Colocando as implantações de teste em um plano separado, você as isola da versão de produção.

Separe aplicativos Web de APIs da Web. Se sua solução tem um front-end da Web e uma API Web, considere decompô-los em aplicativos do Serviço de Aplicativo separados. Esse design torna mais fácil para decompor a solução pela carga de trabalho. Você pode executar o aplicativo Web e a API em Planos do Serviço de Aplicativo separados, de modo que eles possam ser dimensionados de forma independente. Se você não precisar desse nível de escalabilidade inicialmente, poderá implantar os aplicativos no mesmo plano e movê-los para planos separados posteriormente, se necessário.

Implante planos do serviço de aplicativo redundantes por zona. Em regiões com suporte, os Planos do Serviço de Aplicativo podem ser implantados como zona redundante, o que significa que as instâncias são distribuídas automaticamente entre zonas de disponibilidade. O Serviço de Aplicativo distribuirá automaticamente o tráfego entre as zonas e manipulará o failover se uma zona sofrer uma interrupção. Para obter mais informações, veja Migrar o Ambiente do Serviço de Aplicativo para o suporte a zonas de disponibilidade.

Evite usar o recurso de Serviço de Aplicativo de backup para fazer backup de Bancos de Dados SQL do Azure. Em vez disso, use os Backups automatizados do Banco de Dados SQL. O backup do Serviço de Aplicativo exporta o banco de dados para um arquivo BACPAC do SQL, que custa DTUs.

Implante em um slot de preparo. Crie um slot de implantação para preparo. Implante atualizações de aplicativo para o slot de preparo e verifique a implantação antes de trocá-la para produção. Isso reduz a chance de uma atualização inválida em produção. Isso também garante que todas as instâncias sejam aquecidas antes de serem trocadas para produção. Muitos aplicativos têm um tempo significativo de aquecimento e de resfriamento. Para obter mais informações, consulte Configurar ambientes de preparo para aplicativos Web no Serviço de Aplicativo do Azure.

Crie um slot de implantação para conter a LKG (última implantação válida). Quando você implanta uma atualização para produção, mova a implantação de produção anterior para o slot da LKG. Isso torna mais fácil reverter uma implantação incorreta. Se você descobrir um problema posteriormente, você poderá reverter rapidamente para a versão LKG. Para obter mais informações, veja Basic web application (Aplicativo Web básico).

Habilite o log de diagnósticos, incluindo o log de aplicativo e o log do servidor Web. O registro em log é importante para monitoramento e diagnóstico. Consulte Habilitar o registro de log de diagnóstico para aplicativos Web no Serviço de Aplicativo do Azure

Registre em log para o Armazenamento de Blobs. Isso torna mais fácil coletar e analisar os dados.

Criar uma conta de armazenamento separada para logs. Não use a mesma conta de armazenamento para logs e dados de aplicativo. Isso ajuda a impedir o registro em log de reduzir o desempenho do aplicativo.

Monitore o desempenho. Use um serviço de monitoramento de desempenho como o New Relic ou o Application Insights para monitorar o desempenho e o comportamento do aplicativo sob carga. O monitoramento de desempenho fornece informações sobre o aplicativo em tempo real. Ele permite a você diagnosticar problemas e executar a análise de causa raiz de falhas.

Azure Load Balancer

Selecione a SKU Standard. O Standard Load Balancer fornece uma dimensão de confiabilidade que o Basic não fornece – a das zonas de disponibilidade e da resiliência de zona. Isso significa que, quando uma zona fica inativa, o Standard Load Balancer com redundância de zona não é afetado. Isso garante que suas implantações possam resistir a falhas de zona em uma região. Além disso, o Standard Load Balancer dá suporte ao balanceamento de carga global, garantindo que o aplicativo também não seja afetado por falhas de região.

Provisione pelo menos duas instâncias. Implante o Azure LB com pelo menos duas instâncias no back-end. Uma só instância pode resultar em um ponto único de falha. Para criar para ter escala, você pode emparelhar o LB com Conjuntos de Dimensionamento de Máquinas Virtuais.

Use regras de saída. As regras de saída garantem que você não se depare com falhas de conexão como resultado do esgotamento de porta SNAT. Saiba mais sobre a conectividade de saída. Embora as regras de saída ajudem a aprimorar a solução para implantações de pequeno a médio porte, para cargas de trabalho de produção, recomendamos o acoplamento do Standard Load Balancer ou de qualquer implantação de sub-rede com o NAT da VNet.

Gateway de Aplicativo

Provisione pelo menos duas instâncias. Implante um Gateway de Aplicativo com pelo menos duas instâncias. Uma única instância é um ponto único de falha. Use duas ou mais instâncias para redundância e escalabilidade. Para se qualificar para o SLA, você deverá provisionar duas ou mais instâncias médias ou maiores.

Azure Cosmos DB

Configure a redundância de zona. Quando você usa a redundância de zona, o Azure Cosmos DB replica de forma síncrona todas as gravações entre zonas de disponibilidade. Ele faz failover automaticamente no caso de uma interrupção de zona. Para obter mais informações, consulte Obter alta disponibilidade com o Azure Cosmos DB.

Replique o banco de dados entre regiões. O Azure Cosmos DB permite associar qualquer número de regiões do Azure à sua conta de banco de dados do Azure Cosmos DB. Um banco de dados do Azure Cosmos DB pode ter várias regiões de leitura e uma de gravação. Se houver uma falha na região de gravação, você poderá ler de outra réplica. O SDK do cliente lida com isso automaticamente. Você também pode fazer failover da região de gravação para outra região. Para obter mais informações, confira Como distribuir os dados globalmente com o Azure Cosmos DB.

Hubs de Eventos

Usar pontos de verificação. Um consumidor de evento deve gravar sua posição atual no armazenamento persistente em um intervalo predefinido. Dessa forma, se o consumidor apresentar uma falha (por exemplo, falhas do consumidor ou do host), uma nova instância poderá retomar a leitura do fluxo da última posição gravada. Para obter mais informações, consulte Consumidores de evento.

Tratar mensagens duplicadas. Se um consumidor de evento falhar, o processamento de mensagem é retomado do último ponto de verificação gravado. As mensagens que já foram processadas após o último ponto de verificação serão processadas novamente. Portanto, sua lógica de processamento de mensagem deve ser idempotente, ou o aplicativo deve ser capaz de eliminar a duplicação de mensagens.

Tratar exceções. . Um consumidor de evento normalmente processa um lote de mensagens em um loop. Você deve tratar exceções neste loop de processamento para evitar a perda de um lote inteiro de mensagens se uma única mensagem causar uma exceção.

Use uma fila de mensagens mortas. Se o processamento de uma mensagem resultar em uma falha não transitória, coloque a mensagem em uma fila de mensagens mortas para que você possa acompanhar o status. Dependendo do cenário, você pode tentar novamente a mensagem mais tarde, aplicar uma transação de compensação ou executar alguma outra ação. Observe que os Hubs de Eventos não têm nenhuma funcionalidade interna de fila de mensagens mortas. Você pode usar o Armazenamento de Filas do Azure ou o Barramento de Serviço para implementar uma fila de mensagens mortas ou usar o Azure Functions ou outro mecanismo de eventos.

Configure a redundância de zona. Quando a redundância de zona está habilitada em seu namespace, os Hubs de Eventos replicam automaticamente as alterações entre várias zonas de disponibilidade. Se uma zona de disponibilidade falhar, o failover ocorrerá automaticamente. Para obter mais informações, confira Zonas de disponibilidade.

Implementar recuperação de desastres efetuando failover para um namespace secundário de Hubs de Eventos. Para saber mais, confira Recuperação de desastre geográfico dos Hubs de Eventos do Azure.

Cache Redis do Azure

Configure a redundância de zona. Quando a redundância de zona está habilitada em seu cache, o Cache do Azure para Redis espalha as máquinas virtuais que hospedam seu cache em várias zonas de disponibilidade. A redundância de zona fornece alta disponibilidade e tolerância a falhas no caso de uma interrupção do data center. Para obter mais informações, consulte Habilitar redundância de zona para o Cache do Azure para Redis.

Configurar a replicação geográfica. A replicação geográfica fornece um mecanismo para vincular duas instâncias do Cache do Azure para Redis de camada Premium. Os dados gravados no cache primário são replicados para um cache secundário de somente leitura. Para obter mais informações, confira Como configurar a replicação geográfica do Cache do Azure para Redis

Configurar a persistência de dados. A persistência do Redis permite persistir os dados armazenados no Redis. Você também pode tirar instantâneos e fazer backup dos dados, que podem ser carregados em caso de falha de hardware. Para obter mais informações, confira Como configurar persistência de dados para um Cache do Azure para Redis de camada Premium

Caso você esteja usando o Cache do Azure para Redis como um cache de dados temporário, e não como um armazenamento persistente, essas recomendações podem não ser aplicadas.

Provisione mais de uma réplica. Use pelo menos duas réplicas para alta disponibilidade de leitura ou três para alta disponibilidade de leitura/gravação.

Use a redundância de zona. Você pode implantar réplicas da Pesquisa Cognitiva em várias zonas de disponibilidade. Essa abordagem ajuda seu serviço a permanecer operacional mesmo quando ocorrem paralisações do data center. Para obter mais informações, consulte Confiabilidade na Pesquisa Cognitiva do Azure.

Configure indexadores para implantações de várias regiões. Se você tiver uma implantação de várias regiões, considere as opções para a continuidade na indexação.

  • Se a fonte de dados é com replicação geográfica, você geralmente deve apontar cada indexador de cada serviço regional da Pesquisa Cognitiva do Azure para a respectiva réplica de fonte de dados local. No entanto, essa abordagem não é recomendada para grandes conjuntos de dados armazenados no Banco de Dados SQL do Azure. O motivo é que a Pesquisa Cognitiva do Azure não pode executar a indexação incremental de réplicas de Banco de Dados SQL secundárias, somente de réplicas primárias. Em vez disso, aponte todos os indexadores para a réplica primária. Após um failover, aponte os indexadores da Pesquisa Cognitiva do Azure para a nova réplica primária.

  • Se a fonte de dados não usa replicação geográfica, aponte vários indexadores na mesma fonte de dados, de forma que os serviços da Pesquisa Cognitiva do Azure façam a indexação da fonte de dados de modo contínuo e independente. Para obter mais informações, consulte Considerações de desempenho e otimização do Azure Search.

Barramento de Serviço

Use a camada Premium para cargas de trabalho de produção. Mensagens Premium do Barramento de Serviço fornecem recursos de processamento dedicado e reservado e a capacidade de memória para dar suporte a desempenho e taxa de transferência previsíveis. A camada de Mensagens Premium também oferece acesso a novos recursos que estão disponíveis somente para clientes Premium no início. Você pode decidir o número de unidades do sistema de mensagens com base em cargas de trabalho esperadas.

Tratar mensagens duplicadas. Se um editor falha imediatamente após enviar uma mensagem ou enfrenta problemas de rede ou do sistema, pode deixar de registrar erroneamente que a mensagem foi entregue e pode enviar a mesma mensagem ao sistema duas vezes. O Barramento de Serviço pode lidar com esse problema habilitando a detecção de duplicatas. Para saber mais, confira Detecção de duplicatas.

Tratar exceções. As APIs de mensagens geram exceções quando ocorre um erro de usuário, um erro de configuração ou outro erro. O código do cliente (remetentes e receptores) deve tratar essas exceções em seu código. Isso é especialmente importante no processamento em lotes, em que o tratamento de exceção pode ser usado para evitar a perda de um lote inteiro de mensagens. Para saber mais, veja Exceções de mensagens do Barramento de Serviço.

Política de repetição. O Barramento de Serviço permite que você escolha a melhor política de repetição para os aplicativos. A política padrão é permitir no máximo nove tentativas de repetição e aguardar 30 segundos, mas isso pode ser ajustado. Para saber mais, confira Política de repetição – Barramento de Serviço.

Use uma fila de mensagens mortas. Se uma mensagem não pode ser processada ou entregue a nenhum receptor após várias tentativas, é movida para uma fila de mensagens mortas. Implemente um processo para ler mensagens da fila de mensagens mortas, inspecioná-las e corrigir o problema. Dependendo do cenário, você pode repetir a mensagem como está, fazer alterações e tentar novamente ou descartar a mensagem. Para saber mais, confira Visão geral das filas de mensagens mortas do Barramento de Serviço.

Use a redundância de zona. Quando a redundância de zona está habilitada em seu namespace, o Barramento de Serviço replica automaticamente as alterações entre várias zonas de disponibilidade. Se uma zona de disponibilidade falhar, o failover ocorrerá automaticamente. Para saber mais, confira Práticas recomendadas para isolar aplicativos contra interrupções e desastres do Barramento de Serviço.

Usar a recuperação de desastre em área geográfica. A recuperação de desastre em área geográfica garante que o processamento de dados continue a operar em uma região ou datacenter diferente, se uma região inteira do Azure ou o datacenter se tornar indisponível devido a um desastre. Para mais informações consulte Recuperação de desastre em área geográfica do Barramento de Serviço do Azure.

Armazenamento

Use armazenamento com redundância de zona. O Armazenamento com redundância de zona (ZRS) copia seus dados de forma síncrona em três zonas de disponibilidade do Azure na região primária. Se uma zona de disponibilidade sofrer uma interrupção, o Armazenamento do Azure fará failover automaticamente para uma zona alternativa. Para mais informações, confira Redundância do Armazenamento do Microsoft Azure.

Ao usar a redundância geográfica, configure o acesso de leitura. Se você usar uma arquitetura de várias regiões, utilize uma camada de armazenamento adequada para redundância global. Com RA-GRS ou RA-GZRS, seus dados são replicados para uma região secundária. O RA-GRS usa o armazenamento localmente redundante (LRS) na região primária, enquanto o RA-GZRS usa o armazenamento com redundância de zona (ZRS) na região primária. Ambas as configurações fornecem acesso somente leitura aos seus dados na região secundária. Se houver uma interrupção de armazenamento na região primária, o aplicativo poderá ler os dados da região secundária se você tiver projetado o aplicativo para essa possibilidade. Para mais informações, confira Redundância do Armazenamento do Microsoft Azure.

Para discos de VM, use discos gerenciados. Os discos gerenciados fornecem maior confiabilidade para as VMs em um conjunto de disponibilidade porque os discos ficam suficientemente isolados uns dos outros para evitar pontos únicos de falha. Além disso, discos gerenciados não estão sujeitos aos limites de IOPS de VHDs criados em uma conta de armazenamento. Para saber mais, confira Gerenciar a disponibilidade de máquinas virtuais Windows no Azure.

Para o Armazenamento de Filas, crie uma fila de backup em outra região. Para o Armazenamento de Filas, a utilidade de uma réplica somente leitura é limitada, porque não é possível enfileirar itens nem removê-los da fila. Em vez disso, crie uma fila de backup em uma conta de armazenamento em outra região. Se houver uma interrupção no Armazenamento do Azure, o aplicativo poderá usar a fila de backup até que a região primária fique disponível novamente. Dessa forma, o aplicativo pode continuar a processar novas solicitações durante a interrupção.

Banco de Dados SQL

Use a camada Standard ou Premium. Essas camadas fornecem um período de Recuperação Pontual mais longo (35 dias). Para obter mais informações, consulte Opções e desempenho de Banco de Dados SQL.

Habilitar a auditoria do Banco de Dados SQL. A auditoria pode ser usada para diagnosticar erros humanos ou ataques mal-intencionados. Para saber mais, confira Introdução à Auditoria do Banco de Dados SQL.

Use a Replicação Geográfica Ativa. Use a replicação geográfica ativa para criar uma réplica secundária legível em uma região diferente. Se o seu banco de dados primário falhar ou simplesmente precisar ser colocado offline, faça um failover manual para qualquer o banco de dados secundário. O banco de dados secundário permanece somente leitura até você fazer o failover. Para saber mais, confira Replicação Geográfica Ativa para o Banco de Dados SQL.

Use fragmentação. Considere o uso de fragmentação para particionar o banco de dados horizontalmente. A fragmentação pode proporcionar o isolamento de falhas. Para saber mais, confira Expansão com o Banco de Dados SQL do Azure.

Use a Recuperação Pontual para se recuperar de erro humano. A Recuperação Pontual retorna seu banco de dados para um ponto anterior no tempo. Para obter mais informações, consulte Recuperar um Banco de Dados SQL do Azure usando backups de banco de dados automatizados.

Use a restauração geográfica para recuperar-se de uma interrupção de serviço. A restauração geográfica restaura um banco de dados de um backup com redundância geográfica. Para obter mais informações, consulte Recuperar um Banco de Dados SQL do Azure usando backups de banco de dados automatizados.

Azure Synapse Analytics

Não desabilite o backup geográfico. Por padrão, o Synapse Analytics usa um backup completo de seus dados no Pool de SQL dedicado a cada 24 horas para recuperação de desastres. Não é recomendável desativar esse recurso. Para obter mais informações, veja Backups geográficos.

SQL Server em execução em uma VM

Fazer backup do banco de dados. Se você já estiver usando Backup do Azure para fazer backup de suas VMs, considere usar o Backup do Azure para cargas de trabalho do SQL Server usando o DPM. Com essa abordagem, há uma função de administrador de backup para a organização e um procedimento de recuperação unificado para as VMs e o SQL Server. Caso contrário, use o Backup gerenciado pelo SQL Server para o Microsoft Azure.

Gerenciador de Tráfego

Faça o failback manual. Após um failover do Gerenciador de Tráfego, faça o failback manual em vez de automaticamente. Verifique se todos os subsistemas de aplicativo estão íntegros antes de fazer o failback. Caso contrário, você pode criar uma situação em que o aplicativo alterna entre os data centers. Para obter mais informações, consulte Executar VMs em várias regiões para ter alta disponibilidade.

Criar um ponto de extremidade de investigação de integridade. Crie um ponto de extremidade personalizado que relata a integridade geral do aplicativo. Isso permite que o Gerenciador de Tráfego faça failover se qualquer caminho crítico falha, não apenas o front-end. O ponto de extremidade deve retornar um código de erro HTTP se qualquer dependência crítica está não íntegra ou inacessível. No entanto, não relate erros para serviços não críticos. Caso contrário, a investigação de integridade poderá disparar o failover quando ele não for necessário, criando falsos positivos. Para obter mais informações, consulte Monitoramento e failover do ponto de extremidade do Gerenciador de Tráfego.

Máquinas Virtuais

Evite executar uma carga de trabalho de produção em uma única VM. Uma única implantação de VM não é resiliente para manutenção (planejada ou não). Em vez disso, coloque várias VMs em um conjunto de disponibilidade ou conjunto de dimensionamento de máquinas virtuais, com um balanceador de carga na frente.

Especifique um conjunto de disponibilidade ao provisionar a VM. Atualmente, não há nenhuma maneira de adicionar uma VM a um conjunto de disponibilidade depois que a VM é provisionada. Quando você adiciona uma nova VM a um conjunto de disponibilidade existente, verifique se você criou um adaptador de rede para a VM e adicione o adaptador de rede ao pool de endereços de back-end no balanceador de carga. Caso contrário, o balanceador de carga não roteará o tráfego de rede para essa VM.

Coloque cada camada de aplicativo em um conjunto de disponibilidade separado. Em um aplicativo de N camadas, não coloque as VMs de camadas diferentes no mesmo conjunto de disponibilidade. VMs em um conjunto de disponibilidade são colocadas em FDs (domínios de falha) e UDs (domínios de atualização). No entanto, para obter o benefício de redundância de FDs e UDs, todas as VMs no conjunto de disponibilidade devem ser capazes de lidar com as mesmas solicitações de cliente.

Replique VMs usando o Azure Site Recovery. Quando você replicar VMs do Azure usando a Recuperação de Site, todos os discos de VM serão replicados continuamente para a região de destino assincronamente. Os pontos de replicação são criados a cada poucos minutos. Isso fornece um RPO (Objetivo de Ponto de Recuperação) na ordem de minutos. Você pode realizar simulações de recuperação de desastre quantas vezes quiser sem afetar o aplicativo de produção ou a replicação contínua. Para saber mais, confira Realizar uma análise detalhada da recuperação de desastre para o Azure.

Escolha o tamanho de VM correto com base nos requisitos de desempenho. Ao mover uma carga de trabalho existente para o Azure, comece com o tamanho da VM que mais se aproxima de seus servidores locais. Em seguida, meça o desempenho da carga de trabalho real com relação à CPU, memória e IOPS e ajuste o tamanho, se necessário. Isso ajuda a garantir que o aplicativo se comporte como esperado em um ambiente de nuvem. Além disso, se você precisar de várias NICs, esteja ciente do limite de NIC para cada tamanho.

Usar discos gerenciados para VHDs. Os discos gerenciados fornecem maior confiabilidade para as VMs em um conjunto de disponibilidade porque os discos ficam suficientemente isolados uns dos outros para evitar pontos únicos de falha. Além disso, discos gerenciados não estão sujeitos aos limites de IOPS de VHDs criados em uma conta de armazenamento. Para saber mais, confira Gerenciar a disponibilidade de máquinas virtuais Windows no Azure.

Instale aplicativos em um disco de dados, não no disco de SO. Caso contrário, você poderá atingir o limite de tamanho do disco.

Use o Backup do Azure para fazer backup de VMs. Os backups protegem contra perda de dados acidental. Para obter mais informações, consulte Proteger VMs do Azure com um cofre dos Serviços de Recuperação.

Habilitar os logs de diagnóstico. Inclua métricas de integridade básicas, logs de infraestrutura e diagnóstico de inicialização. O diagnóstico de inicialização poderá ajudar a diagnosticar uma falha de inicialização se sua VM entrar em um estado não inicializável. Para obter mais informações, consulte Visão Geral dos Logs de Diagnóstico do Azure.

Configure o Azure Monitor. Colete e analise dados de monitoramento de máquinas virtuais do Azure, incluindo o sistema operacional convidado e as cargas de trabalho executadas nele; confira Azure Monitor e Guia de Início Rápido: Azure Monitor.

Rede Virtual

Para permitir ou bloquear endereços IP públicos, adicione um grupo de segurança de rede à sub-rede. Bloqueie o acesso de usuários mal-intencionados ou permita o acesso somente de usuários que têm o privilégio de acessar o aplicativo.

Crie uma investigação de integridade personalizada. As investigações de integridade do balanceador de carga podem testar HTTP ou TCP. Se uma VM for executada em um servidor HTTP, a investigação HTTP será um melhor indicador do status de integridade do que uma investigação TCP. Para uma investigação HTTP, use um ponto de extremidade personalizado que relata a integridade geral do aplicativo, incluindo todas as dependências críticas. Para obter mais informações, veja Visão geral do Azure Load Balancer.

Não bloqueie a investigação de integridade. A investigação de integridade do balanceador de carga é enviada de um endereço IP conhecido, 168.63.129.16. Não bloqueie o tráfego de ou para esse IP em nenhuma política de firewall ou regra de grupo de segurança de rede. Bloquear a investigação de integridade faria com que o balanceador de carga remova a VM da rotação.

Habilite o registro em log do balanceador de carga. Os logs de mostram quantas muitas VMs no back-end não estão recebendo o tráfego de rede devido a respostas de investigação com falha. Para obter mais informações, consulte Log Analytics para o Azure Load Balancer.