Solucionar problemas do processador de eventos dos Hubs de Eventos do Azure

Este artigo ajuda você a solucionar problemas de processador de eventos Hubs de Eventos do Azure ao usar o EventProcessorClient tipo. Use-o para resolver problemas comuns de propriedade, CPU, memória e receptor. Para obter soluções para outros problemas comuns que você pode encontrar ao usar Hubs de Eventos do Azure, consulte Solucionar problemas Hubs de Eventos do Azure.

412 erros de pré-condição ao utilizar um processador de eventos

412 erros de pré-condição ocorrem quando o cliente tenta assumir ou renovar a propriedade de uma partição, mas a versão local do registro de propriedade está desatualizada. Esse problema ocorre quando outra instância do processador rouba a propriedade da partição. Para obter mais informações, consulte a secção seguinte.

A propriedade da partição muda com frequência

Quando o número de EventProcessorClient instâncias é alterado (ou seja, quando você adiciona ou remove instâncias), as instâncias em execução tentam balancear as partições entre si. Por alguns minutos depois que o número de processadores muda, as partições mudam de proprietário. Depois de ser balanceada, a titularidade da partição é estável e muda raramente. Se a propriedade da partição for alterada com frequência quando o número de processadores for constante, provavelmente indicará um problema. Registre um problema GitHub com logs e uma reprodução.

O CheckpointStore determina a propriedade da partição por meio de registros de propriedade. Em cada intervalo de balanceamento de carga, o EventProcessorClient executa as seguintes tarefas:

  1. Busque os registros de propriedade mais recentes.
  2. Verifique os registros para ver quais registros não atualizaram o carimbo de data/hora dentro do intervalo de expiração da propriedade da partição. Somente registros que correspondem a esses critérios são considerados.
  3. Se houver partições não atribuídas e a carga não estiver balanceada entre instâncias de EventProcessorClient, o cliente do processador de eventos tentará assumir uma partição.
  4. Atualize o registro de propriedade das partições que possui que têm um link ativo para essa partição.

Você pode configurar os intervalos de balanceamento de carga e expiração de propriedade ao criar o EventProcessorClient por meio do EventProcessorClientBuilder, conforme descrito na seguinte lista:

Por exemplo, se um registro de propriedade foi atualizado às 9h30 e partitionOwnershipExpirationInterval é de 2 minutos. Quando ocorre um ciclo de balanceamento de carga e ele detecta que o registro de propriedade não foi atualizado nos últimos 2 minutos ou até as 9h32, considera a partição sem proprietário.

Se ocorrer um erro em um dos consumidores de partição, ele fechará o consumidor correspondente, mas não tentará recuperá-lo até o próximo ciclo de balanceamento de carga.

"... o receptor atual '<RECEIVER_NAME>' com época '0' está sendo desconectado"

A mensagem de erro inteira é semelhante à seguinte saída:

New receiver 'nil' with higher epoch of '0' is created hence current receiver 'nil' with epoch '0'
is getting disconnected. If you are recreating the receiver, make sure a higher epoch is used.
TrackingId:&lt;GUID&gt;, SystemTracker:&lt;NAMESPACE&gt;:eventhub:&lt;EVENT_HUB_NAME&gt;|&lt;CONSUMER_GROUP&gt;,
Timestamp:2022-01-01T12:00:00}"}

Esse erro ocorre quando o balanceamento de carga ocorre depois que você adiciona ou remove EventProcessorClient instâncias. O balanceamento de carga é um processo contínuo. Quando você usa o BlobCheckpointStore com seu consumidor, aproximadamente a cada 30 segundos (por padrão), o consumidor verifica quais consumidores têm a reivindicação de cada partição. Em seguida, ele executa alguma lógica para determinar se ele precisa 'roubar' uma partição de outro consumidor. O mecanismo de serviço usado para afirmar a propriedade exclusiva sobre uma partição é conhecido como Época.

No entanto, se você não estiver adicionando ou removendo instâncias, existe um problema subjacente que você deve resolver. Para obter mais informações, consulte a seção A propriedade da partição muda com frequência e Registrar problemas do GitHub.

Alto uso da CPU

O alto uso da CPU geralmente acontece porque uma instância possui muitas partições. Não exceda três partições para cada núcleo de CPU. Comece com 1,5 partições para cada núcleo da CPU e faça testes aumentando o número de partições atribuídas.

Sem memória e escolhendo o tamanho do heap

O problema de memória insuficiente (OOM) pode acontecer se o heap máximo atual da JVM for insuficiente para executar o aplicativo. Talvez você queira medir o requisito de heap do aplicativo. Em seguida, com base no resultado, dimensione o heap definindo a memória máxima apropriada do heap usando a opção JVM -Xmx.

Não especifique -Xmx como um valor maior que a memória disponível ou o conjunto de limites para o host (a VM ou o contêiner) – por exemplo, a memória solicitada na configuração do contêiner. Aloque memória suficiente para que o host dê suporte ao heap de Java.

As etapas a seguir descrevem uma maneira típica de medir o valor do Heap Java máximo:

  1. Execute o aplicativo em um ambiente próximo à produção, onde o aplicativo envia, recebe e processa eventos sob a carga de pico esperada na produção.

  2. Aguarde até que o aplicativo atinja um estado estável. Neste estágio, o aplicativo e a JVM carregam todos os objetos de domínio, tipos de classe, instâncias estáticas, pools de objetos (pools de conexões TCP, BD) e assim por diante.

    No estado estável, você verá o padrão estável serrilhado para a coleção de heap, conforme mostrado na seguinte captura de tela:

    Captura de tela da coleção de memória de heap mostrando o padrão estável serrilhado.

  3. Depois que o aplicativo atingir um estado estável, force uma coleta de lixo completa (GC) por meio de ferramentas como o JConsole. Observe a memória ocupada após o GC completo. Você deseja dimensionar o heap de modo que apenas 30% sejam ocupados após o GC completo. Use esse valor para definir o tamanho máximo do heap (usando -Xmx).

Se você estiver usando contêiner, dimensione-o para ter cerca de 1 GB adicional de memória para as necessidades fora do heap da instância da JVM.

O cliente do processador para de receber

O cliente do processador geralmente é executado continuamente em um aplicativo host por dias a fio. Às vezes, ele percebe que EventProcessorClient não está processando uma ou mais partições. Normalmente, não há informações suficientes para determinar por que a exceção ocorreu. A parada EventProcessorClient é o sintoma de uma causa subjacente (ou seja, a condição de corrida) que ocorreu ao tentar se recuperar de um erro transitório. Para obter as informações necessárias, consulte Arquivar problemas do GitHub.

Dados do evento duplicados recebidos quando o processador é reiniciado

O serviço EventProcessorClient e Hubs de Eventos garante uma entrega pelo menos uma vez. Você pode adicionar metadados para discernir eventos duplicados. Para obter mais informações, consulte Os Hubs de Eventos do Azure garantem uma entrega pelo menos uma vez? no Stack Overflow. Se você precisar de entrega somente uma vez, considere Barramento de Serviço, que aguarda uma confirmação do cliente. Para obter uma comparação dos serviços de mensagens, consulte Escolhendo entre os serviços de mensagens do Azure.

Cliente de consumidor de baixo nível para de receber

A biblioteca do Event Hubs fornece o cliente consumidor de baixo nível EventHubConsumerAsyncClient. Ele foi projetado para usuários avançados que precisam de maior controle e flexibilidade em seus aplicativos Reactive. Esse cliente oferece uma interface de baixo nível para que você possa gerenciar o controle de pressão, as threads e a recuperação dentro da cadeia do Reactor. Ao contrário de EventProcessorClient, EventHubConsumerAsyncClient não inclui mecanismos de recuperação automática para todas as causas terminais. Portanto, você deve lidar com eventos terminais e selecionar operadores apropriados do Reactor para implementar estratégias de recuperação.

O EventHubConsumerAsyncClient::receiveFromPartition método emite um erro de terminal quando a conexão encontra um erro não retriável ou quando uma série de tentativas de recuperação de conexão falham consecutivamente, esgotando o limite máximo de repetição. Embora o receptor de baixo nível tente se recuperar de erros transitórios, espera-se que os usuários do cliente de consumidor lidem com eventos de terminal. Se a recepção contínua de eventos for desejada, o aplicativo deverá ajustar a cadeia reator para criar um novo cliente de consumidor em um evento de terminal.

Migrar da biblioteca de clientes herdada para a nova

O guia de migração inclui etapas para migrar do cliente herdado e migrar pontos de verificação herdados.

Próximas etapas

Se as diretrizes de solução de problemas neste artigo não ajudarem a resolver problemas ao usar o SDK do Azure para bibliotecas de cliente Java, registre um problema no SDK do Azure para Java GitHub repositório.

  • Last updated on