Como solucionar problemas de conectividade e entrega de mensagens
Estas diretrizes apresentam várias maneiras de ajudar a realizar o diagnóstico automático para localizar a causa raiz diretamente ou restringir o problema. O resultado de autodiagnóstico também é útil ao reportá-los para nós para uma investigação mais a fundo.
Primeiro, você precisa verificar no portal do Azure qual ServiceMode é o Serviço do SignalR do Azure (também conhecido como ASRS) configurado para.
Para o modo
Default, consulte solução de problemas do modo padrãoPara o modo
Serverless, consulte solução de problemas do modo sem servidorPara o modo
Classic, consulte solução de problemas do modo clássico
Em segundo lugar, você precisa capturar rastreamentos de serviço para solucionar problemas. Para saber como capturar rastreamentos, confira Como capturar rastreamentos de serviço.
Está com problemas ou tem comentários sobre a solução de problemas? Fale conosco.
Como capturar rastreamentos de serviço
Para simplificar o processo de solução de problemas, o Serviço do Azure SignalR fornece uma ferramenta de rastreamento em tempo real para expor os rastreamentos de serviço nas categorias conectividade e mensagens. Os rastreamentos incluem, mas não estão limitados a eventos de conexão conectados/desconectados e eventos de mensagem recebidas/deixadas. Com a ferramenta de rastreamento em tempo real, você pode capturar, ver, classificar, filtrar e exportar rastreamentos em tempo real. Para obter mais informações, consulte Como usar a ferramenta de rastreamento ao vivo.
Está com problemas ou tem comentários sobre a solução de problemas? Fale conosco.
Solução de problemas do modo padrão
Quando ASRS está no modo Padrão, existem três funções: Cliente, Servidor e Serviço:
Cliente: o cliente representa os clientes conectados ao ASRS. As conexões persistentes que conectam o cliente e o ASRS são chamadas de Conexões de cliente nestas diretrizes.
Servidor: o servidor significa o servidor que atende à negociação do cliente e hospeda a lógica
Hubdo SignalR. E as conexões persistentes entre Servidor e ASRS são chamadas de Conexões de servidor nestas diretrizes.Serviço: Serviço é o nome curto para ASRS nestas diretrizes.
Consulte os Elementos internos do Serviço de SignalR do Azure para obter a introdução detalhada de toda a arquitetura e o fluxo de trabalho.
Há várias maneiras que podem ajudá-lo a restringir o problema.
Se o problema ocorrer logo no caminho ou se for reproduzido, a maneira mais direta é exibir o tráfego contínuo.
Se o problema for difícil de ser reproduzido, os rastreamentos e logs poderão ajudar.
Como exibir o tráfego e restringir o problema
Capturar o tráfego contínuo é a maneira mais direta de restringir o problema. Você pode capturar os Rastreamentos de rede usando as opções descritas abaixo:
Solicitações de cliente
Para uma conexão persistente de SignalR, primeiro /negotiate para o servidor de aplicativo hospedado e redirecionado para o serviço de SignalR do Azure e, em seguida, estabelece a conexão persistente real com o serviço do SignalR do Azure. Consulte os Elementos internos do Serviço de SignalR do Azure para obter as etapas detalhadas.
Com o rastreamento de rede do lado do cliente em mãos, verifique qual solicitação falha com o código de status e qual resposta e procure soluções no Guia de solução de problemas.
Solicitações do servidor
O Servidor do SignalR mantém a Conexão do servidor entre o Servidor e o Serviço. Quando o servidor de aplicativos é iniciado, ele inicia a conexão WebSocket com o Serviço do SignalR do Azure. Todos os tráfegos do cliente são roteados por meio do Serviço do Signaler do Azure para essas Conexões de servidore, em seguida, enviados para o Hub. Quando uma Conexão de servidor é removida, os clientes roteados para essa Conexão de servidor serão afetados. Nosso SDK do Signaler do Azure tem uma lógica "Sempre Repetir" para reconectar a Conexão do servidor com no máximo 1 minuto de atraso para minimizar os efeitos.
As Conexões do servidorpodem ser descartadas devido à instabilidade da rede ou à manutenção regular do Serviço do SignalR do Azure ou às atualizações/manutenções do servidor de aplicativos hospedados. Desde que o lado do cliente tenha o mecanismo de desconexão/reconexão, o efeito é mínimo, como qualquer reconexão de desconexão provocava pelo do lado do cliente.
Exiba o rastreamento de rede do lado do servidor para descobrir o código de status e detalhes do erro por que a Conexão do servidor é removida ou rejeitada pelo Serviço. Procure a causa raiz dentro do Guia de Solução de Problemas.
Está com problemas ou tem comentários sobre a solução de problemas? Fale conosco.
Como adicionar loops
Os logs podem ser úteis para diagnosticar problemas e monitorar o status de execução.
Como habilitar o log do lado do cliente
A experiência de registro no lado do cliente é exatamente a mesma que ao usar o SignalR auto-hospedado.
Habilitar o registro de log do lado do cliente para ASP.NET Core SignalR
Habilitar o registro de log do lado do cliente para ASP.NET SignalR
Como habilitar o log do lado do servidor
Habilitar o registro de log do lado do servidor para ASP.NET Core SignalR
O registro em log do lado do servidor do ASP.NET Core SignalR se integra ao ILogger registro em log base fornecido na estrutura ASP.NET Core. Habilite o registro em log do lado do servidor usando ConfigureLogging, um exemplo de uso da seguinte maneira:
.ConfigureLogging((hostingContext, logging) =>
{
logging.AddConsole();
logging.AddDebug();
})
As categorias de agente para o Azure SignalR sempre começam com Microsoft.Azure.SignalR. Para habilitar logs detalhados do Azure SignalR, configure os prefixos anteriores para o nível Information no arquivo appsettings.jsno conforme abaixo:
{
"Logging": {
"LogLevel": {
...
"Microsoft.Azure.SignalR": "Information",
...
}
}
}
Verifique se há algum log de aviso/erro anormal registrado.
Habilitar rastreamentos do lado do servidor para ASP.NET SignalR
Ao usar o SDK versão >= 1.0.0, você pode habilitar os rastreamentos adicionando o seguinte a web.config: (Detalhes)
<system.diagnostics>
<sources>
<source name="Microsoft.Azure.SignalR" switchName="SignalRSwitch">
<listeners>
<add name="ASRS" />
</listeners>
</source>
</sources>
<!-- Sets the trace verbosity level -->
<switches>
<add name="SignalRSwitch" value="Information" />
</switches>
<!-- Specifies the trace writer for output -->
<sharedListeners>
<add name="ASRS" type="System.Diagnostics.TextWriterTraceListener" initializeData="asrs.log.txt" />
</sharedListeners>
<trace autoflush="true" />
</system.diagnostics>
Verifique se há algum log de aviso/erro anormal registrado.
Como habilitar logs dentro do serviço de SignalR do Azure
Você também pode habilitar os logs de diagnóstico para o Serviço de SignalR do Azure, esses logs fornecem informações detalhadas de cada conexão conectada ao Serviço de SignalR do Azure.
Está com problemas ou tem comentários sobre a solução de problemas? Fale conosco.
Solução de problemas do modo sem servidor
Quando o ASRS está no modo Sem servidor, somente o modo ASP.NET Core SignalR dá suporte Serverless e o modo SP.NET SignalR não dá suporte a esse modo.
Para diagnosticar problemas de conectividade no modo Serverless, a maneira mais direta é Exibir o tráfego do lado do cliente. Habilitar os logs do lado do cliente e logs do lado do serviço também podem ser úteis.
Está com problemas ou tem comentários sobre a solução de problemas? Fale conosco.
Solução de problemas do modo clássico
Classic o modo está obsoleto e o seu uso não é recomendado. Quando no modo clássico, o serviço do SignalR do Azure usa as Conexões do servidor conectado para determinar se o serviço atual está no modo default ou no modo serverless. O modo clássico pode levar a problemas intermediários de conectividade do cliente porque, quando há uma queda repentina de toda a Conexão de Servidorconectada, por exemplo, devido à instabilidade da rede, o SignalR do Azure acredita que agora ele está alternado para o modo serverless e os clientes conectados durante esse período nunca serão roteados para o servidor de aplicativos hospedado. Habilite os logs do lado do serviço e verifique se há clientes registrados como ServerlessModeEntered se você tiver o servidor de aplicativos hospedado, no entanto, alguns clientes nunca alcançam o lado do servidor de aplicativos. Se você vir algum desses clientes, anule as conexões do cliente e deixe que os clientes reiniciem.
A solução de problemas do modo de conectividade classic e da entrega de mensagens é semelhante à solução de problemas do modo padrão.
Está com problemas ou tem comentários sobre a solução de problemas? Fale conosco.
Integridade do serviço
Você pode verificar a integridade da API de integridade do serviço.
Solicitação: GET
https://{instance_name}.service.signalr.net/api/v1/healthCódigo de status de resposta:
- 200: Íntegro.
- 503: seu serviço não está íntegro. Você pode:
- Aguarde alguns minutos para a recuperação automática.
- Verifique se o endereço IP é o mesmo que o IP do Portal.
- Ou reinicie a instância.
- Se todas as opções acima não funcionarem, entre em contato conosco adicionando uma nova solicitação de suporte no portal do Azure.
Mais sobre a recuperação de desastres.
Está com problemas ou tem comentários sobre a solução de problemas? Fale conosco.
Próximas etapas
Neste guia, você aprendeu sobre como solucionar problemas de conectividade e entrega de mensagens. Você também pode aprender a lidar com problemas comuns.