Compartilhar via

Solucionar problemas de conectividade – Hubs de Eventos do Azure

  • Artigo

Há várias razões para os aplicativos cliente não poderem se conectar a um hub de eventos. Os problemas de conectividade podem ser permanentes ou transitórios.

Se o problema acontecer o tempo todo (permanente), verifique essas configurações e outras opções mencionadas na seção Solucionar problemas permanentes de conectividade neste artigo.

  • Cadeia de conexão
  • Configurações de firewall da sua organização
  • Configurações do firewall de IP
  • Configurações de segurança de rede (pontos de extremidade de serviço, pontos de extremidade privados etc.) e mais

Para problemas transitórios, experimente as opções a seguir, que podem ajudar a solucionar problemas. Para saber mais, veja Solucionar problemas de conectividade transitória.

  • Atualizar para a versão mais recente do SDK
  • Executar comandos para verificar os pacotes perdidos
  • Obtenha os rastreamentos de rede.

Solucionar problemas de conectividade permanentes

Se o aplicativo não for capaz de se conectar ao hub de eventos, siga as etapas desta seção para solucionar o problema.

Verificar se há uma interrupção do serviço

Verifique a interrupção do serviço dos Hubs de Eventos do Azure no site de status do serviço do Azure.

Verificar cadeia de conexão

Verifique se a cadeia de conexão que você está usando está correta. Veja Obter cadeia de conexão para obter a cadeia de conexão usando o portal do Azure, a CLI ou o PowerShell.

Para clientes Kafka, verifique se os arquivos producer.config ou consumer.config estão configurados corretamente. Para saber mais, veja Enviar e receber mensagens com o Kafka nos Hubs de Eventos.

Quais protocolos posso usar para enviar e receber eventos?

Produtores ou remetentes podem usar protocolos AMQP (Advanced Messaging Queuing Protocol), Kafka ou HTTPS para enviar eventos para um hub de eventos.

Consumidores ou receptores usam AMQP ou Kafka para receber eventos de um hub de eventos. Os Hubs de Eventos são compatíveis apenas com o modelo de pull para que os consumidores recebam eventos dele. Mesmo quando você usa manipuladores de eventos para lidar com eventos de um hub de eventos, o processador de eventos usa internamente o modelo de pull para receber eventos do hub de eventos.

AMQP

Você pode usar o protocolo AMQP 1.0 para enviar e receber eventos dos Hubs de Eventos do Azure. O AMQP fornece uma comunicação confiável, de desempenho e segura para enviar e receber eventos. Você pode usá-lo para streaming de alto desempenho e em tempo real, e ele é compatível com a maioria dos SDKs dos Hubs de Eventos do Azure.

HTTPS/API REST

Você só pode enviar eventos para Hubs de Eventos usando solicitações HTTP POST. Os Hubs de Eventos não dão suporte ao recebimento de eventos via HTTPS. É adequado para clientes leves em que uma conexão TCP direta não é viável.

Apache Kafka

Os Hubs de Eventos do Azure têm um ponto de extremidade do Kafka interno que dá suporte a produtores e consumidores do Kafka. Os aplicativos criados por meio do Kafka podem usar o protocolo Kafka (versão 1.0 ou posterior) para enviar e receber eventos dos Hubs de Eventos sem alterações de código.

Os SDKs do Azure abstraem os protocolos de comunicação subjacentes e fornecem uma maneira simplificada de enviar e receber eventos de Hubs de Eventos usando linguagens como C#, Java, Python, JavaScript etc.

Quais portas preciso abrir no firewall?

É possível usar os seguintes protocolos com os Hubs de Eventos do Azure para enviar e receber eventos:

  • Advanced Message Queuing Protocol 1.0 (AMQP)
  • Protocolo de Transferência de Hipertexto individual com Segurança da Camada de Transporte (HTTPS)
  • Apache Kafka

Consulte a tabela a seguir para as portas de saída que você precisa abrir para usar esses protocolos para se comunicar com os Hubs de Eventos do Azure.

Protocolo Portas Detalhes
AMQP 5671 e 5672 Consulte Guia do protocolo AMQP
HTTPS 443 Essa porta é usada para a API REST/HTTP e para AMQP-over-WebSockets.
Kafka 9093 Consulte Usar Hubs de Eventos de aplicativos Kafka

A porta HTTPS também é necessária para a comunicação de saída quando o AMQP é usado pela porta 5671, pois várias operações de gerenciamento executadas pelos SDKs do cliente e pela aquisição de tokens de Microsoft Entra ID (quando usado) são executadas em HTTPS.

Geralmente, os SDKs oficiais do Azure usam o protocolo AMQP para enviar e receber eventos dos Hubs de eventos. A opção de protocolo AMQP-over-WebSockets é executada na porta TCP 443 da mesma forma que o API HTTP, mas sua funcionalidade é idêntica à do AMQP simples. Essa opção tem uma latência de conexão inicial maior devido às idas e voltas extras de handshake e um pouco mais de sobrecarga como compensação para o compartilhamento da porta HTTPS. Se esse modo estiver selecionado, a porta TCP 443 será suficiente para a comunicação. As opções a seguir permitem selecionar o modo AMQP simples ou AMQP WebSockets:

Idioma Opção
.NET Propriedade EventHubConnectionOptions.TransportType com EventHubsTransportType.AmqpTcp ou EventHubsTransportType.AmqpWebSockets
Java com.microsoft.azure.eventhubs.EventProcessorClientBuilder.transporttype com AmqpTransportType.AMQP ou AmqpTransportType.AMQP_WEB_SOCKETS
Nó EventHubConsumerClientOptions tem uma propriedadewebSocketOptions.
Python EventHubConsumerClient.transport_type com TransportType.AmqpOverWebSocket ou TransportType.AmqpOverWebSocket

Quais endereços IP preciso permitir?

Quando você está trabalhando com o Azure, às vezes é preciso permitir intervalos de endereços IP específicos ou URLs em seu firewall corporativo ou proxy para acessar todos os serviços do Azure que você está usando ou tentando usar. Verifique se o tráfego é permitido em endereços IP usados pelos Hubs de Eventos. Para endereços IP usados pelos Hubs de Eventos do Azure: consulte Intervalos de IP e marcas de serviço do Azure – Nuvem pública.

Além disso, verifique se o endereço IP do seu namespace é permitido. Para localizar os endereços IP corretos a fim de permitir suas conexões, siga estas etapas:

  1. Execute o seguinte comando de um prompt de comando:

    nslookup <YourNamespaceName>.servicebus.windows.net

  2. Anote o endereço IP retornado em Non-authoritative answer.

Se você usar um namespace hospedado em um cluster mais antigo (baseado nos Serviços de Nuvem – CNAME terminando em *.cloudapp.net) e o namespace tiver redundância de zona, você precisará seguir algumas etapas adicionais. Se o seu namespace estiver em um cluster mais recente (baseado em Conjunto de Dimensionamento de Máquinas Virtuais – CNAME terminando em *.cloudapp.azure.com) e for redundante em zonas, você poderá pular as etapas abaixo.

  1. Primeiro, execute nslookup no namespace.

    nslookup <yournamespace>.servicebus.windows.net

  2. Anote o nome na seção resposta não autoritativa, que está em um dos seguintes formatos:

    <name>-s1.cloudapp.net
<name>-s2.cloudapp.net
<name>-s3.cloudapp.net

  3. Execute nslookup para cada um com sufixos s1, s2 e s3 para obter os endereços IP de todas as três instâncias em execução em três zonas de disponibilidade,

    Observação

    O endereço IP retornado pelo comando nslookup não é um endereço IP estático. No entanto, ele permanece constante até que a implantação subjacente seja excluída ou movida para um cluster diferente.

Que IPs de cliente estão enviando ou recebendo eventos do meu namespace e para ele?

Primeiro, habilite a filtragem de IP no namespace.

Em seguida, habilite os logs de diagnóstico para Eventos de conexão de rede virtual dos Hubs de Eventos seguindo as instruções em Habilitar logs de diagnóstico. Você verá o endereço de IP para o qual a conexão é negada.

{
    "SubscriptionId": "0000000-0000-0000-0000-000000000000",
    "NamespaceName": "namespace-name",
    "IPAddress": "1.2.3.4",
    "Action": "Deny Connection",
    "Reason": "IPAddress doesn't belong to a subnet with Service Endpoint enabled.",
    "Count": "65",
    "ResourceId": "/subscriptions/0000000-0000-0000-0000-000000000000/resourcegroups/testrg/providers/microsoft.eventhub/namespaces/namespace-name",
    "Category": "EventHubVNetConnectionEvent"
}

Importante

Os logs de rede virtual são gerados apenas quando o namespace permite o acesso de endereços IP específicos (regras de filtro de IP). Se você não quiser restringir o acesso ao seu namespace usando esses recursos e ainda quiser que os logs de rede virtual rastreiem os endereços de IP dos clientes que se conectam ao namespace dos Hubs de Eventos, poderá usar a seguinte solução alternativa: Habilitar a filtragem de IPe adicionar o intervalo IPv4 endereçável total (0.0.0.0/1 - 128.0.0.0/1) e o intervalo IPv6 (::/1 - 8000::/1).

Observação

Atualmente, não é possível determinar o IP de origem de uma mensagem ou evento individual.

Verificar se a marca de serviço Hubs de Eventos é permitida em seus grupos de segurança de rede

Se o aplicativo estiver sendo executado dentro de uma sub-rede e se houver um grupo de segurança de rede associado, confirme se a saída da Internet é permitida ou se a marca de serviço Hubs de Eventos (EventHub) é permitida. Veja Marcas de serviço de rede virtual e pesquise EventHub.

Verifique se o aplicativo precisa ser executado em uma sub-rede específica de uma rede virtual

Confirme se o aplicativo está sendo executado em uma sub-rede de rede virtual que tem acesso ao namespace. Se não for, execute o aplicativo na sub-rede que tem acesso ao namespace ou adicione o endereço IP do computador no qual o aplicativo está sendo executado no Firewall de IP.

Quando você cria um ponto de extremidade de serviço de rede virtual para um namespace de Hub de Eventos, o namespace aceita o tráfego somente da sub-rede associada ao ponto de extremidade de serviço. Porém há uma exceção a esse comportamento. Você pode adicionar endereços IP específicos no firewall do IP para habilitar o acesso ao ponto de extremidade público do hub de eventos. Para obter mais informações, veja Pontos de extremidade de serviço de rede.

Verificar as configurações de firewall de IP para o namespace

Verifique se o endereço IP público do computador no qual o aplicativo está em execução não está bloqueado pelo IP do domínio.

Por padrão, os namespaces dos Hubs de Eventos são acessíveis da Internet, desde que a solicitação acompanhe autenticação e autorização válidas. Com o firewall de IP, você pode restringi-lo ainda mais a apenas um conjunto de endereços ou intervalos de endereços IPv4 ou IPv6 na notação CIDR (Roteamento Entre Domínios Sem Classe).

As regras de firewall de IP são aplicadas no nível do namespace dos Hubs de Eventos. Portanto, as regras se aplicam a todas as conexões de clientes que usam qualquer protocolo com suporte. Qualquer tentativa de conexão de um endereço IP que não corresponda a uma regra de IP permitida no namespace dos Hubs de Eventos será rejeitada como não autorizada. A resposta não menciona a regra de IP. As regras de filtro IP são aplicadas na ordem e a primeira regra que corresponde ao endereço IP determina a ação de aceitar ou rejeitar.

Para saber mais, veja Configurar regras de firewall de IP para um namespace do Hubs de Eventos do Azure. Para verificar se você tem problemas de filtragem de IP, rede virtual ou cadeia de certificados, veja Solucionar problemas relacionados à rede.

Verificar se o namespace pode ser acessado usando apenas um ponto de extremidade privado

Se o namespace dos Hubs de Eventos estiver configurado para ser acessível apenas por meio do ponto de extremidade privado, confirme se o aplicativo cliente está acessando o namespace pelo ponto de extremidade privado.

O serviço do Link Privado do Azure permite que você acesse a Hubs de Eventos do Azure por meio de um ponto de extremidade privado na rede virtual. O ponto de extremidade privado é uma interface de rede que conecta você de forma privada e segura a um serviço com tecnologia do Link Privado do Azure. O ponto de extremidade privado usa um endereço IP privado da rede virtual, colocando efetivamente o serviço na sua rede virtual. Todo o tráfego para o serviço pode ser roteado por meio do ponto de extremidade privado; assim, nenhum gateway, nenhum dispositivo NAT, nenhuma conexão ExpressRoute ou VPN e nenhum endereço IP público é necessário. O tráfego entre a rede virtual e o serviço percorre a rede de backbone da Microsoft, eliminando a exposição da Internet pública. Você pode se conectar a uma instância de um recurso do Azure, fornecendo o nível mais alto de granularidade no controle de acesso.

Para saber mais, confira Configurar pontos de extremidade privados. Veja a seção Validar se a conexão de ponto de extremidade privado funciona para confirmar que um ponto de extremidade privado é usado.

Para solucionar problemas relacionados à rede com os Hubs de Eventos, siga estas etapas:

Acesse o wget https://<yournamespacename>.servicebus.windows.net/. Ele ajuda a verificar se você tem problemas de filtragem de IP ou de rede virtual ou de cadeia de certificados (mais comuns ao usar o SDK do Java).

Um exemplo de mensagem de ação bem-sucedida:

<feed xmlns="http://www.w3.org/2005/Atom"><title type="text">Publicly Listed Services</title><subtitle type="text">This is the list of publicly-listed services currently available.</subtitle><id>uuid:27fcd1e2-3a99-44b1-8f1e-3e92b52f0171;id=30</id><updated>2019-12-27T13:11:47Z</updated><generator>Service Bus 1.1</generator></feed>

Um exemplo de mensagem de erro de falha:

<Error>
    <Code>400</Code>
    <Detail>
        Bad Request. To know more visit https://aka.ms/sbResourceMgrExceptions. . TrackingId:b786d4d1-cbaf-47a8-a3d1-be689cda2a98_G22, SystemTracker:NoSystemTracker, Timestamp:2019-12-27T13:12:40
    </Detail>
</Error>

Solucionar problemas de conectividade transitórios

Se você estiver enfrentando problemas de conectividade intermitente, confira as seções a seguir para obter dicas de solução de problemas.

Usar a versão mais recente do cliente do SDK

Alguns dos problemas transitórios de conectividade podem ter sido corrigidos em versões posteriores do SDK à que você está usando. Verifique se você está usando a versão mais recente dos SDKs do cliente em seus aplicativos. Os SDKs são aprimorados continuamente com recursos novos/atualizados e correções de bugs, portanto, sempre teste com o pacote mais recente. Verifique as notas sobre a versão para problemas corrigidos e os recursos adicionados/atualizados.

Para obter informações sobre SDKs do cliente, veja o artigo Hubs de Eventos do Azure – SDKs do cliente.

Executar o comando para verificar os pacotes descartados

Quando houver problemas de conectividade intermitente, execute o seguinte comando para verificar se há algum pacote descartado. Este comando tenta estabelecer 25 conexões TCP diferentes a cada 1 segundo com o serviço. Em seguida, você pode verificar quantos deles tiveram êxito/falharam e também ver a latência da conexão TCP. Você pode baixar a ferramenta pspingpsping.

.\psping.exe -n 25 -i 1 -q <yournamespacename>.servicebus.windows.net:5671 -nobanner

Você pode usar comandos equivalentes se estiver usando outras ferramentas, como tnc, ping e assim sucessivamente.

Obtenha um rastreamento de rede se as etapas anteriores não ajudarem e analise-o usando ferramentas como o Wireshark. Entre em contato com o Suporte da Microsoft, se necessário.

Atualizações/reinicializações de serviço

Problemas transitórios de conectividade podem ocorrer devido a atualizações e reinicializações do serviço de back-end. Quando eles ocorrem, os seguintes sintomas podem estar presentes:

  • Pode haver uma queda nas mensagens/solicitações de entrada.
  • O arquivo de log pode conter mensagens de erro.
  • Os aplicativos podem ser desconectados do serviço por alguns segundos.
  • As solicitações podem ficar momentaneamente limitadas.

Se o código do aplicativo utilizar o SDK, a política de repetição já estará interna e ativa. O aplicativo se reconecta sem impacto significativo sobre o aplicativo/fluxo de trabalho. Capturar esses erros transitórios, recuar e tentar fazer a chamada novamente garante que o seu código seja resiliente a esses problemas transitórios.

Próximas etapas

Veja os artigos a seguir: