Guia de solução de problemas do Barramento de Serviço do Azure

Este artigo fornece dicas de solução de problemas e recomendações para alguns problemas que você vê ao usar o Barramento de Serviço do Azure.

Problemas de conectividade

Tempo limite ao conectar-se ao serviço

Dependendo do ambiente host e da rede, um problema de conectividade pode se apresentar aos aplicativos como um TimeoutException, OperationCanceledException, ou um ServiceBusException com Reason de e ocorre com mais freqüência quando o cliente não consegue encontrar um caminho de ServiceTimeout rede para o serviço.

Para resolver os problemas:

• Verifique se a cadeia de conexão ou o nome de domínio totalmente qualificado que você especificou ao criar o cliente está correto. Para obter informações sobre como adquirir uma cadeia de conexão, consulte Obter uma cadeia de conexão do Service Bus.
• Verifique as permissões de firewall e porta em seu ambiente de hospedagem. Verifique se as portas AMQP (Advanced Message Queuing Protocol) 5671 e 5672 estão abertas e se o ponto de extremidade é permitido através do firewall.
• Tente usar a opção de transporte Web Socket, que se conecta usando a porta 443. Para obter detalhes, consulte configurar o transporte.
• Veja se a sua rede está a bloquear endereços IP específicos. Para obter detalhes, consulte Que endereços IP preciso permitir?
• Se aplicável, verifique a configuração do proxy. Para obter detalhes, consulte: Configurando o transporte
• Para obter mais informações sobre como solucionar problemas de conectividade de rede, consulte: Problemas de conectividade, certificado ou tempo limite.

Falhas de handshake SSL (Secure Socket Layer)

Este erro pode ocorrer quando um proxy de intercetação é usado. Para verificar, recomendamos que você teste o aplicativo no ambiente host com o proxy desabilitado.

Erros de exaustão do soquete

Os aplicativos devem preferir tratar os tipos do Service Bus como singletons, criando e usando uma única instância durante o tempo de vida do aplicativo. Cada novo ServiceBusClient criado resulta em uma nova conexão AMQP, que usa um soquete. O tipo ServiceBusClient gerencia a conexão para todos os tipos criados a partir dessa instância. Cada ServiceBusReceiver, ServiceBusSessionReceiver, ServiceBusSender e ServiceBusProcessor gerencia seu próprio link AMQP para a entidade do Service Bus associada. Quando você usa ServiceBusSessionProcessor, vários links AMQP são estabelecidos dependendo do número de sessões que estão sendo processadas simultaneamente.

Os clientes são seguros para armazenar em cache quando ociosos; eles garantem um gerenciamento eficiente do uso de rede, CPU e memória, minimizando seu impacto durante os períodos de inatividade. Também é importante que um ou CloseAsync DisposeAsync seja chamado quando um cliente não for mais necessário para garantir que os recursos da rede sejam limpos corretamente.

Adicionar componentes à cadeia de conexão não funciona

A geração atual da biblioteca de cliente do Service Bus oferece suporte a cadeias de conexão somente no formato publicado pelo portal do Azure. As cadeias de conexão destinam-se a fornecer apenas informações básicas de localização e chave compartilhada. A configuração do comportamento dos clientes é feita através das suas opções.

As gerações anteriores dos clientes do Service Bus permitiam que alguns comportamentos fossem configurados adicionando componentes de chave/valor a uma cadeia de conexão. Esses componentes não são mais reconhecidos e não têm efeito sobre o comportamento do cliente.

Alternativa "TransportType=AmqpWebSockets"

Para configurar Web Sockets como o tipo de transporte, consulte Configurando o transporte.

Alternativa "Authentication=Managed Identity"

Para autenticar com a Identidade Gerenciada, consulte: Credenciais de identidade e acesso compartilhado. Para obter mais informações sobre a Azure.Identity biblioteca, consulte Autenticação e o SDK do Azure.

Registo e diagnóstico

A biblioteca de cliente do Service Bus é totalmente instrumentada para registrar informações em vários níveis de detalhe usando o .NET EventSource para emitir informações. O registro em log é realizado para cada operação e segue o padrão de marcação do ponto inicial da operação, sua conclusão e quaisquer exceções encontradas. Informações adicionais que podem oferecer informações também são registradas no contexto da operação associada.

Ativar registo

Os logs do cliente do Service Bus estão disponíveis para qualquer pessoa EventListener , optando pelas fontes começando com Azure-Messaging-ServiceBus ou optando por todas as fontes que têm a característica AzureEventSource. Para facilitar a captura de logs das bibliotecas de cliente do Azure, a Azure.Core biblioteca usada pelo Service Bus oferece um AzureEventSourceListenerarquivo .

Para obter mais informações, consulte: Registrando em log com o SDK do Azure para .NET.

Rastreio distribuído

A biblioteca de cliente do Service Bus oferece suporte ao rastreamento distribuído por meio da integração com o SDK do Application Insights. Ele também tem suporte experimental para a especificação OpenTelemetry através do tipo .NET ActivitySource introduzido no .NET 5. Para habilitar ActivitySource o suporte para uso com OpenTelemetry, consulte Suporte ActivitySource.

Para usar o suporte ao GA DiagnosticActivity, você pode integrar com o SDK do Application Insights. Mais detalhes podem ser encontrados no ApplicationInsights com o Azure Monitor.

A biblioteca cria as seguintes faixas:

Message
ServiceBusSender.Send
ServiceBusSender.Schedule
ServiceBusSender.Cancel
ServiceBusReceiver.Receive
ServiceBusReceiver.ReceiveDeferred
ServiceBusReceiver.Peek
ServiceBusReceiver.Abandon
ServiceBusReceiver.Complete
ServiceBusReceiver.DeadLetter
ServiceBusReceiver.Defer
ServiceBusReceiver.RenewMessageLock
ServiceBusSessionReceiver.RenewSessionLock
ServiceBusSessionReceiver.GetSessionState
ServiceBusSessionReceiver.SetSessionState
ServiceBusProcessor.ProcessMessage
ServiceBusSessionProcessor.ProcessSessionMessage
ServiceBusRuleManager.CreateRule
ServiceBusRuleManager.DeleteRule
ServiceBusRuleManager.GetRules

A maioria dos vãos são autoexplicativos e são iniciados e interrompidos durante a operação que leva o seu nome. A extensão que une os outros é Message. A maneira como a mensagem é rastreada é por meio do Diagnostic-Id que é definido na propriedade ServiceBusMessage.ApplicationProperties pela biblioteca durante as operações de envio e agendamento. No Application Insights, Message as extensões são exibidas como links para as várias outras extensões que foram usadas para interagir com a mensagem, por exemplo, a ServiceBusReceiver.Receive extensão, a ServiceBusSender.Send extensão e a ServiceBusReceiver.Complete extensão seriam todas vinculadas a partir da Message extensão. Aqui está um exemplo de como isso se parece no Application Insights:

Na captura de tela acima, você vê a transação de ponta a ponta que pode ser visualizada no Application Insights no portal. Nesse cenário, o aplicativo está enviando mensagens e usando o ServiceBusSessionProcessor para processá-las. A Message atividade está ligada a ServiceBusSender.Send, ServiceBusReceiver.Receive, ServiceBusSessionProcessor.ProcessSessionMessage, e ServiceBusReceiver.Complete.

Nota

Para obter mais informações, consulte Rastreamento distribuído e correlação por meio de mensagens do Service Bus.

Solucionar problemas do remetente

Não é possível enviar um lote com várias chaves de partição

Quando um aplicativo envia um lote para uma entidade habilitada para partição, todas as mensagens incluídas em uma única operação de envio devem ter o mesmo PartitionKey. Se sua entidade estiver habilitada para sessão, o mesmo requisito será válido para a SessionId propriedade. Para enviar mensagens com valores ou SessionId diferentesPartitionKey, agrupe as mensagens em instâncias separadas ServiceBusMessageBatch ou inclua-as em chamadas separadas para a sobrecarga SendMessagesAsync que usa um conjunto de ServiceBusMessage instâncias.

Lote falha ao enviar

Um lote de mensagens contém ServiceBusMessageBatch duas ou mais mensagens ou uma chamada para SendMessagesAsync onde duas ou mais mensagens são passadas. O serviço não permite que um lote de mensagens exceda 1 MB. Esse comportamento é verdadeiro se o recurso de suporte a mensagens grandes Premium estiver habilitado ou não. Se você pretende enviar uma mensagem maior que 1 MB, ela deve ser enviada individualmente em vez de agrupada com outras mensagens. Infelizmente, o tipo ServiceBusMessageBatch atualmente não suporta a validação de que um lote não contém mensagens maiores que 1 MB, pois o tamanho é restrito pelo serviço e pode mudar. Portanto, se você pretende usar o recurso premium de suporte a mensagens grandes, certifique-se de enviar mensagens com mais de 1 MB individualmente.

Solucionar problemas do recetor

O número de mensagens retornadas não corresponde ao número solicitado no recebimento em lote

Ao tentar fazer uma operação de recebimento em lote, ou seja, passar um maxMessages valor de dois ou mais para o método ReceiveMessagesAsync , não é garantido que você receba o número de mensagens solicitadas, mesmo que a fila ou assinatura tenha tantas mensagens disponíveis naquele momento e mesmo que toda a configuração maxWaitTime ainda não tenha decorrido. Para maximizar a taxa de transferência e evitar a expiração do bloqueio, uma vez que a primeira mensagem chega através do fio, o recetor espera mais 20 milissegundos por quaisquer mensagens adicionais antes de enviar as mensagens para processamento. O maxWaitTime controla quanto tempo o recetor espera para receber a primeira mensagem - as mensagens subsequentes são esperadas por 20 milissegundos. Portanto, seu aplicativo não deve assumir que todas as mensagens disponíveis são recebidas em uma chamada.

O bloqueio de mensagem ou sessão é perdido antes do tempo de expiração do bloqueio

O serviço Service Bus usa o protocolo AMQP, que é stateful. Devido à natureza do protocolo, se o link que conecta o cliente e o serviço for desanexado depois que uma mensagem for recebida, mas antes que a mensagem seja resolvida, a mensagem não poderá ser resolvida ao reconectar o link. Os links podem ser desanexados devido a uma falha de rede transitória de curto prazo, uma interrupção de rede ou devido ao tempo limite de ociosidade de 10 minutos imposto pelo serviço. A reconexão do link acontece automaticamente como parte de qualquer operação que exija o link, ou seja, resolver ou receber mensagens. Nessa situação, você recebe um ServiceBusException com de ou SessionLockLost mesmo se o tempo de expiração do MessageLockLost bloqueio ainda Reason não tiver passado.

Como procurar mensagens agendadas ou adiadas

Mensagens agendadas e adiadas são incluídas ao espiar mensagens. Eles podem ser identificados pela propriedade ServiceBusReceivedMessage.State . Depois de ter o SequenceNumber de uma mensagem adiada, você pode recebê-la com um bloqueio por meio do método ReceiveDeferredMessagesAsync .

Ao trabalhar com tópicos, você não pode espiar mensagens agendadas na assinatura, pois as mensagens permanecem no tópico até o horário de fila agendado. Como solução alternativa, você pode construir um ServiceBusReceiver passando o nome do tópico para espiar essas mensagens. Nenhuma outra operação com o recetor funciona ao usar um nome de tópico.

Como procurar mensagens de sessão em todas as sessões

Você pode usar um ServiceBusReceiver regular para espreitar todas as sessões. Para espiar uma sessão específica, você pode usar o ServiceBusSessionReceiver, mas precisa obter um bloqueio de sessão.

NotSupportedException lançada ao acessar o corpo da mensagem

Esse problema ocorre com mais freqüência em cenários de interoperabilidade ao receber uma mensagem enviada de uma biblioteca diferente que usa um formato de corpo de mensagem AMQP diferente. Se você estiver interagindo com esses tipos de mensagens, consulte o exemplo de corpo da mensagem AMQP para saber como acessar o corpo da mensagem.

Solucionar problemas do processador

A renovação de bloqueio automático não está a funcionar

A renovação do bloqueio automático depende do tempo do sistema para determinar quando renovar um bloqueio para uma mensagem ou sessão. Se a hora do sistema não for precisa, por exemplo, o relógio estiver lento, a renovação do bloqueio pode não acontecer antes que o bloqueio seja perdido. Certifique-se de que a hora do sistema é precisa se a renovação de bloqueio automático não estiver funcionando.

O processador parece travar ou ter problemas de latência ao usar alta simultaneidade

Esse comportamento geralmente é causado pela inanição de threads, particularmente ao usar o processador de sessão e usar um valor muito alto para MaxConcurrentSessions, em relação ao número de núcleos na máquina. A primeira coisa a verificar seria certificar-se de que você não está fazendo sync-over-async em nenhum dos seus manipuladores de eventos. Sync-over-async é uma maneira fácil de causar deadlocks e fome de threads. Mesmo que você não esteja sincronizando por meio de assíncrono, qualquer código de sincronização puro em seus manipuladores pode contribuir para a fome de threads. Se você determinou que esse não é o problema, por exemplo, porque você tem código assíncrono puro, você pode tentar aumentar seu TryTimeout. Ele alivia a pressão sobre o pool de threads, reduzindo o número de comutadores de contexto e tempos limite que ocorrem ao usar o processador de sessão em particular. O valor padrão para TryTimeout é 60 segundos, mas pode ser definido até 1 hora. Recomendamos testar com o TryTimeout conjunto para 5 minutos como ponto de partida e iterar a partir daí. Se nenhuma dessas sugestões funcionar, você simplesmente precisará expandir para vários hosts, reduzindo a simultaneidade em seu aplicativo, mas executando o aplicativo em vários hosts para alcançar a simultaneidade geral desejada.

Outras leituras:

• Fome do pool de threads de depuração
• Diagnosticando a fome do pool de threads do .NET Core com PerfView (Por que meu serviço não está saturando todos os núcleos ou parece parar)
• Diagnosticando problemas de esgotamento do pool de threads em aplicativos .NET Core (vídeo)

Processador de sessão leva muito tempo para alternar sessões

Isso pode ser configurado usando o SessionIdleTimeout, que informa ao processador quanto tempo esperar para receber uma mensagem de uma sessão, antes de desistir e mudar para outra. É útil se você tiver muitas sessões escassamente preenchidas, onde cada sessão tem apenas algumas mensagens. Se você espera que cada sessão tenha muitas mensagens que chegam, defini-la muito baixa pode ser contraproducente, pois resulta em encerramento desnecessário da sessão.

O processador para imediatamente

Isso geralmente é observado para cenários de demonstração ou teste. StartProcessingAsync retorna imediatamente após o início do processador. Chamar esse método não bloqueará e manterá seu aplicativo ativo enquanto o processador estiver em execução, então você precisará de algum outro mecanismo para fazer isso. Para demonstrações ou testes, basta adicionar uma Console.ReadKey() chamada depois de iniciar o processador. Para cenários de produção, você provavelmente desejará usar algum tipo de integração de estrutura como o BackgroundService para fornecer ganchos convenientes do ciclo de vida do aplicativo que podem ser usados para iniciar e descartar o processador.

Solucionar problemas de transações

Para obter informações gerais sobre transações no Service Bus, consulte Visão geral do processamento de transações do Service Bus.

Operações suportadas

Nem todas as operações são suportadas ao usar transações. Para ver a lista de transações suportadas, consulte Operações dentro de um escopo de transação.

Limite de tempo excedido

Uma transação expira após um período de tempo, por isso é importante que o processamento que ocorre dentro de um escopo de transação siga esse tempo limite.

As operações em uma transação não são repetidas

Esta ação é propositada. Considere o seguinte cenário - você está tentando concluir uma mensagem dentro de uma transação, mas há algum erro transitório que ocorre, por exemplo, ServiceBusException com um Reason de ServiceCommunicationProblem. Suponha que a solicitação realmente chegue ao serviço. Se o cliente tentasse novamente, o serviço veria duas solicitações completas. A primeira conclusão não será finalizada até que a transação seja confirmada. O segundo completo não pode sequer ser avaliado antes do primeiro terminar completo. A transação no cliente está aguardando a conclusão para terminar. Isso cria um impasse em que o serviço está esperando que o cliente conclua a transação, mas o cliente está esperando que o serviço reconheça a segunda operação concluída. A transação acabará por expirar após 2 minutos, mas esta é uma má experiência do utilizador. Por esse motivo, não repetimos as operações dentro de uma transação.

As transações entre entidades não estão a funcionar

Para executar transações que envolvem várias entidades, você precisa definir a ServiceBusClientOptions.EnableCrossEntityTransactions propriedade como true. Para obter detalhes, consulte o Exemplo de transações entre entidades .

Quotas

Informações sobre cotas do Service Bus podem ser encontradas aqui.

Problemas de conectividade, certificado ou tempo limite

As etapas a seguir ajudam você a solucionar problemas de conectividade/certificado/tempo limite para todos os serviços em *.servicebus.windows.net.

• Navegue até ou wget https://<yournamespace>.servicebus.windows.net/. Ele ajuda a verificar se você tem filtragem de IP ou problemas de rede virtual ou cadeia de certificados, que são 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>
  

• Execute o seguinte comando para verificar se alguma porta está bloqueada no firewall. As portas utilizadas são 443 (HTTPS), 5671 e 5672 (AMQP) e 9354 (Net Messaging/SBMP). Dependendo da biblioteca que você usa, outras portas também são usadas. Aqui está o comando de exemplo que verifica se a porta 5671 está bloqueada. C

  tnc <yournamespacename>.servicebus.windows.net -port 5671
  

  No Linux:

  telnet <yournamespacename>.servicebus.windows.net 5671
  

• 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 <yournamespace>.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.

• Para encontrar os endereços IP certos para adicionar à lista de permissões para suas conexões, consulte Quais endereços IP preciso adicionar à lista de permissões.

Em 30 de setembro de 2026, desativaremos o suporte ao protocolo SBMP para o Barramento de Serviço do Azure, portanto, você não poderá mais usar esse protocolo após 30 de setembro de 2026. Migre para as bibliotecas mais recentes do SDK do Barramento de Serviço do Azure usando o protocolo AMQP, que oferecem atualizações de segurança críticas e recursos aprimorados, antes dessa data.

Para obter mais informações, consulte o anúncio de aposentadoria de suporte.

Problemas que podem ocorrer com atualizações/reinicializações de serviço

Sintomas

• Os pedidos podem ser momentaneamente limitados.
• 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.

Motivo

Atualizações e reinicializações do serviço de back-end podem causar esses problemas em seus aplicativos.

Resolução

Se o código do aplicativo usar SDK, a política de repetição já está incorporada e ativa. O aplicativo se reconecta sem impacto significativo no aplicativo/fluxo de trabalho.

Acesso não autorizado: Enviar reclamações são necessárias

Sintomas

Você pode ver esse erro ao tentar acessar um tópico do Service Bus do Visual Studio em um computador local usando uma identidade gerenciada atribuída pelo usuário com permissões de envio.

Service Bus Error: Unauthorized access. 'Send' claim\(s\) are required to perform this operation.

Motivo

A identidade não tem permissões para acessar o tópico do Service Bus.

Resolução

Para resolver esse erro, instale a biblioteca Microsoft.Azure.Services.AppAuthentication . Para obter mais informações, consulte Autenticação de desenvolvimento local.

Para saber como atribuir permissões a funções, consulte Autenticar uma identidade gerenciada com a ID do Microsoft Entra para acessar recursos do Barramento de Serviço do Azure.

Exceção do Service Bus: Falha no token de colocação

Sintomas

Recebe a seguinte mensagem de erro:

Microsoft.Azure.ServiceBus.ServiceBusException: Put token failed. status-code: 403, status-description: The maximum number of '1000' tokens per connection has been reached.

Em 30 de setembro de 2026, desativaremos as bibliotecas do SDK do Barramento de Serviço do Azure WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus e com.microsoft.azure.servicebus, que não estão em conformidade com as diretrizes do SDK do Azure. Também encerraremos o suporte ao protocolo SBMP, para que você não possa mais usar esse protocolo após 30 de setembro de 2026. Migre para as bibliotecas mais recentes do SDK do Azure, que oferecem atualizações de segurança críticas e recursos aprimorados, antes dessa data.

Embora as bibliotecas mais antigas ainda possam ser usadas após 30 de setembro de 2026, elas não receberão mais suporte e atualizações oficiais da Microsoft. Para obter mais informações, consulte o anúncio de aposentadoria de suporte.

Motivo

O número de tokens de autenticação para links simultâneos em uma única conexão com um namespace do Service Bus excedeu o limite: 1000.

Resolução

Efetue um dos seguintes passos:

• Reduza o número de links simultâneos em uma única conexão ou use uma nova conexão
• Use SDKs para o Barramento de Serviço do Azure, que garante que você não entre nessa situação (recomendado)

Os bloqueios de recursos não funcionam ao usar o SDK do plano de dados

Sintomas

Você configurou um bloqueio de exclusão em um namespace do Service Bus, mas pode excluir recursos no namespace (filas, tópicos, etc.) usando o Service Bus Explorer.

Motivo

O bloqueio de recursos é preservado no Azure Resource Manager (plano de controle) e não impede que a chamada SDK do plano de dados exclua o recurso diretamente do namespace. O Service Bus Explorer autônomo usa o SDK do plano de dados, portanto, a exclusão é realizada.

Resolução

Recomendamos que você use a API baseada no Azure Resource Manager por meio do portal do Azure, PowerShell, CLI ou modelo do Gerenciador de Recursos para excluir entidades para que o bloqueio de recursos impeça que os recursos sejam excluídos acidentalmente.

A entidade não está mais disponível

Sintomas

Você vê um erro informando que a entidade não está mais disponível.

Motivo

O recurso pode ter sido excluído. Siga estas etapas para identificar por que a entidade foi excluída.

• Verifique o log de atividades para ver se há uma solicitação de exclusão do Azure Resource Manager.
• Verifique o log operacional para ver se houve uma chamada direta de API para exclusão. Para saber como coletar um log operacional, consulte Monitorar o Barramento de Serviço do Azure. Para obter o esquema e um exemplo de um log de operação, consulte Logs de operação
• Verifique o log de operações para ver se houve uma autodeleteonidle exclusão relacionada.

Próximos passos

Consulte os seguintes artigos:

• Exceções do Azure Resource Manager. Ele lista exceções geradas ao interagir com o Barramento de Serviço do Azure usando o Azure Resource Manager (por meio de modelos ou chamadas diretas).
• Exceções de mensagens. Ele fornece uma lista de exceções geradas pelo .NET Framework para o Barramento de Serviço do Azure.