Partilhar via

Solucionar problemas de conectividade - Hubs de Eventos do Azure

  • Artigo

Existem várias razões para as aplicações cliente não conseguirem ligar-se 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 de conectividade permanente deste artigo.

  • Connection string
  • Configurações de firewall da sua organização
  • Definições de firewall de IP
  • Configurações de segurança de rede (pontos de extremidade de serviço, pontos de extremidade privados, etc.) e muito mais

Para problemas transitórios, tente as seguintes opções que podem ajudar na solução de problemas. Para obter mais informações, consulte Solucionar problemas de conectividade transitória.

  • Atualizar para a versão mais recente do SDK
  • Executar comandos para verificar pacotes descartados
  • Obtenha rastreios de rede.

Solucionar problemas permanentes de conectividade

Se a aplicação não se conseguir ligar ao hub de eventos, siga os passos desta secção para resolver o problema.

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

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

Verificar a cadeia de conexão

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

Para clientes Kafka, verifique se os arquivos producer.config ou consumer.config estão configurados corretamente. Para obter mais informações, consulte Enviar e receber mensagens com Kafka em Hubs de Eventos.

Que protocolos posso usar para enviar e receber eventos?

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

Os consumidores ou recetores usam AMQP ou Kafka para receber eventos de um hub de eventos. Os Hubs de Eventos suportam apenas o modelo pull para que os consumidores recebam eventos dele. Mesmo quando você usa manipuladores de eventos para manipular eventos de um hub de eventos, o processador de eventos usa internamente o modelo 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 comunicação confiável, eficiente e segura para enviar e receber eventos. Você pode usá-lo para streaming de alto desempenho e em tempo real e é suportado pela maioria dos SDKs de Hubs de Eventos do Azure.

HTTPS/REST API

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

Apache Kafka

Os Hubs de Eventos do Azure têm um ponto de extremidade Kafka incorporado que suporta produtores e consumidores Kafka. Os aplicativos criados usando Kafka podem usar o protocolo Kafka (versão 1.0 ou posterior) para enviar e receber eventos de 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.

Que portas preciso abrir no firewall?

Você pode usar os seguintes protocolos com os Hubs de Eventos do Azure para enviar e receber eventos:

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

Consulte a tabela a seguir para obter 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 o guia de protocolo AMQP
HTTPS 443 Esta porta é usada para a API HTTP/REST e para AMQP-over-WebSockets.
Kafka 9093 Consulte Usar Hubs de Eventos de aplicativos Kafka

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

Os SDKs oficiais do Azure geralmente usam o protocolo AMQP para enviar e receber eventos de Hubs de Eventos. A opção de protocolo AMQP-over-WebSockets é executada pela porta TCP 443 tal como a API HTTP, mas é funcionalmente idêntica à AMQP simples. Esta opção tem maior latência de conexão inicial devido a viagens de ida e volta extras de handshake e um pouco mais de sobrecarga como compensação para compartilhar a porta HTTPS. Se este modo estiver selecionado, a porta TCP 443 é suficiente para comunicação. As opções a seguir permitem selecionar o modo AMQP ou AMQP WebSockets simples:

Idioma Opção
.NET EventHubConnectionOptions.TransportType propriedade 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 webSocketOptions propriedade.
Python EventHubConsumerClient.transport_type com TransportType.Amqp ou TransportType.AmqpOverWebSocket

Que endereços IP devo permitir?

Quando você está trabalhando com o Azure, às vezes você precisa 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 por Hubs de Eventos. Para endereços IP usados pelos Hubs de Eventos do Azure: consulte Intervalos de IP do Azure e Tags de Serviço - Nuvem Pública.

Além disso, verifique se o endereço IP do seu namespace é permitido. Para encontrar os endereços IP certos para permitir suas conexões, siga estas etapas:

  1. Execute o seguinte comando a partir de uma linha de comandos:

    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 em Serviços de Nuvem - CNAME terminando em *.cloudapp.net) e o namespace for redundante de zona, será necessário seguir algumas etapas extras. Se o namespace estiver em um cluster mais recente (baseado no Conjunto de Escala de Máquina Virtual - CNAME terminando em *.cloudapp.azure.com) e zona redundante, você poderá ignorar as etapas abaixo.

  1. Primeiro, você executa nslookup no namespace.

    nslookup <yournamespace>.servicebus.windows.net

  2. Anote o nome na seção de resposta não autorizada, 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 os 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,

    Nota

    O endereço IP retornado pelo nslookup comando 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.

Quais IPs de cliente estão enviando ou recebendo eventos do meu namespace?

Primeiro, habilite a filtragem de IP no namespace.

Em seguida, habilite os logs de diagnóstico para eventos de conexão de rede virtual de Hubs de Eventos seguindo as instruções em Habilitar logs de diagnóstico. Você vê o endereço 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 somente se o namespace permitir acesso a partir de endereços IP específicos (regras de filtro IP). Se você não quiser restringir o acesso ao seu namespace usando esses recursos e ainda quiser obter logs de rede virtual para rastrear endereços IP de clientes que se conectam ao namespace Hubs de Eventos, você pode usar a seguinte solução alternativa: Habilite a filtragem IP e adicione o intervalo IPv4 endereçável total (128.0.0.0/1 - 0.0.0.0/1) e o intervalo IPv6 ().::/1 - 8000::/1

Nota

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

Verifique se a etiqueta de serviço Hubs de Eventos é permitida nos seus grupos de segurança de rede

Se seu aplicativo estiver sendo executado dentro de uma sub-rede e houver um grupo de segurança de rede associado, confirme se o tráfego de saída da Internet é permitido ou se a marca de serviço Hubs de Eventos (EventHub) é permitida. Consulte 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 seu aplicativo está sendo executado em uma sub-rede de rede virtual que tem acesso ao namespace. Se não estiver, execute o aplicativo na sub-rede que tem acesso ao namespace ou adicione o endereço IP da máquina na qual o aplicativo está sendo executado ao firewall IP.

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

Verifique as configurações do Firewall IP para seu namespace

Verifique se o endereço IP público da máquina na qual o aplicativo está sendo executado não está bloqueado pelo firewall IP.

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

As regras de firewall IP são aplicadas no nível de namespace dos Hubs de Eventos. Portanto, as regras se aplicam a todas as conexões de clientes usando qualquer protocolo suportado. Qualquer tentativa de conexão de um endereço IP que não corresponda a uma regra IP permitida no namespace Hubs de Eventos é rejeitada como não autorizada. A resposta não menciona a regra de IP. As regras de filtro IP são aplicadas em ordem e a primeira regra que corresponde ao endereço IP determina a ação de aceitação ou rejeição.

Para obter mais informações, consulte Configurar regras de firewall IP para um namespace de Hubs de Eventos do Azure. Para verificar se você tem problemas de filtragem de IP, rede virtual ou cadeia de certificados, consulte Solucionar problemas relacionados à rede.

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

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

O serviço Azure Private Link permite-lhe aceder aos Hubs de Eventos do Azure através de um ponto de extremidade privado na sua rede virtual. Um ponto final privado é uma interface de rede que o liga a um serviço de forma privada e segura com a tecnologia Azure Private Link. O ponto final privado utiliza um endereço IP privado da sua rede virtual, para que possa aceder ao serviço de forma eficaz na sua rede virtual. Todo o tráfego para o serviço pode ser encaminhado através do ponto final privado, pelo que não são necessários gateways, dispositivos NAT, ligações ExpressRoute ou VPN nem endereços IP públicos. 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, oferecendo o mais alto nível de granularidade no controle de acesso.

Para obter mais informações, consulte Configurar pontos de extremidade privados. Consulte a seção Validar que a conexão de ponto de extremidade privado funciona para confirmar que um ponto de extremidade privado é usado.

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

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

Um exemplo de mensagem 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>

Resolver problemas de conectividade transitórios

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

Usar a versão mais recente do SDK do cliente

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

Para obter informações sobre SDKs de cliente, consulte o artigo Hubs de Eventos do Azure - SDKs de Cliente.

Execute o comando para verificar os pacotes descartados

Quando houver problemas intermitentes de conectividade, 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, poderá verificar quantas tiveram êxito-falharam e ver a latência da ligação TCP. Você pode baixar a psping ferramenta aqui.

.\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, pinge assim por diante.

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.

Upgrades/reinícios de serviços

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

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

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

Próximos passos

Consulte os seguintes artigos: