Como solucionar problemas de conectividade e entrega de mensagens

Esta orientação apresenta várias maneiras de ajudar a fazer o autodiagnóstico para encontrar a causa raiz diretamente ou reduzir o problema. O resultado do autodiagnóstico também é útil ao nos relatar para uma investigação mais aprofundada.

Primeiro, você precisa verificar no portal do Azure para qual ServiceMode está configurado o Serviço Azure SignalR (também conhecido como ASRS).

• Para Default o modo, consulte a solução de problemas do modo padrão

• Para Serverless o modo, consulte a solução de problemas do modo sem servidor

• Para Classic o modo, consulte a 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, consulte Como capturar rastreamentos de serviço.

Tem problemas ou comentários sobre a solução de problemas? Deixe-nos saber.

Como capturar rastreamentos de serviço

Para simplificar o processo de solução de problemas, o serviço Azure SignalR fornece uma ferramenta de rastreamento ao vivo para expor rastreamentos de serviço em categorias de conectividade e mensagens . Os rastreamentos incluem, mas não estão limitados a, eventos conectados/desconectados de conexão e eventos de mensagem recebida/deixada. Com a ferramenta de rastreamento ao vivo, você pode capturar, visualizar, classificar, filtrar e exportar rastreamentos em tempo real. Para obter mais informações, consulte Como usar a ferramenta de rastreamento em tempo real.

Tem problemas ou comentários sobre a solução de problemas? Deixe-nos saber.

Solução de problemas do modo padrão

Quando o ASRS está no modo Padrão, há três funções: Cliente, Servidor e Serviço:

• Cliente: Cliente significa os clientes conectados à ASRS. As conexões persistentes que conectam o cliente e o ASRS são chamadas de Conexões de Cliente nesta orientação.

• Servidor: Servidor significa o servidor que serve a negociação do cliente e hospeda a lógica do SignalRHub. E as conexões persistentes entre Servidor e ASRS são chamadas de Conexões de Servidor nesta orientação.

• Serviço: Serviço é o nome abreviado para ASRS nesta orientação.

Consulte Internos do Serviço Azure SignalR para obter a introdução detalhada de toda a arquitetura e fluxo de trabalho.

Há várias maneiras que podem ajudá-lo a reduzir o problema.

• Se o problema acontecer no caminho certo ou for reprovável, a maneira direta é visualizar o tráfego em andamento.

• Se o problema for difícil de reproduzir, rastreamentos e logs podem ajudar.

Como visualizar o tráfego e reduzir o problema

Capturar o tráfego contínuo é a maneira mais direta de reduzir o problema. Você pode capturar os rastreamentos de rede usando as opções descritas abaixo:

• Coletar um rastreamento de rede com o Fiddler

• Coletar um rastreamento de rede com tcpdump

• Coletar um rastreamento de rede no navegador

Pedidos de cliente

Para uma conexão persistente do SignalR, ele primeiro /negotiate para o servidor de aplicativos hospedado e, em seguida, redirecionado para o serviço Azure SignalR e, em seguida, estabelece a conexão persistente real com o serviço Azure SignalR. Consulte Internos do Serviço Azure SignalR para obter as etapas detalhadas.

Com o rastreamento de rede do lado do cliente em mãos, verifique qual solicitação falha com qual código de status e qual resposta e procure soluções dentro do Guia de Solução de Problemas.

Pedidos ao servidor

O SignalR Server 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 Azure SignalR. Todos os tráfegos de cliente são roteados através do serviço Azure SignalR para estas Ligaçõesde Servidor e, em seguida, enviados para o Hub. Quando uma Conexão de Servidor cair, os clientes roteados para essa Conexão de Servidor serão afetados. Nosso SDK do Azure SignalR tem uma lógica "Sempre Repetir" para reconectar a Conexão do Servidor com atraso máximo de 1 minuto para minimizar os efeitos.

As Conexõesde Servidor podem cair devido à instabilidade da rede ou à manutenção regular do Serviço Azure SignalR ou às atualizações/manutenção do servidor de aplicativos hospedado. Contanto que o lado do cliente tenha o mecanismo de desconexão/reconexão, o efeito é mínimo, como qualquer desconexão-reconexão causada pelo lado do cliente.

Exiba o rastreamento de rede do lado do servidor para localizar o código de status e os detalhes do erro por que a Conexão do Servidor cai ou é rejeitada pelo Serviço. Procure a causa raiz dentro do Guia de Solução de Problemas.

Tem problemas ou comentários sobre a solução de problemas? Deixe-nos saber.

Como adicionar registos

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 do lado do cliente é exatamente a mesma que ao usar o SignalR auto-hospedado.

Habilite o log do lado do cliente para ASP.NET Core SignalR

• Registo do cliente JavaScript

• Log do cliente .NET

Habilite o log do lado do cliente para ASP.NET SignalR

• Cliente .NET

• Habilitando o rastreamento em clientes do Windows Phone 8

• Ativando o rastreamento no cliente JavaScript

Como habilitar o log do lado do servidor

Habilite o log do lado do servidor para ASP.NET Core SignalR

Log do lado do servidor para ASP.NET Core SignalR integração com o ILogger log baseado fornecido na ASP.NET Core estrutura. Você pode habilitar o log do lado do servidor usando ConfigureLogging, um exemplo de uso da seguinte maneira:

.ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddConsole();
            logging.AddDebug();
        })

As categorias de logger para o Azure SignalR sempre começam com Microsoft.Azure.SignalR. Para habilitar logs detalhados do Azure SignalR, configure os prefixos anteriores para nivelar Information em seu arquivo appsettings.json como abaixo:

{
    "Logging": {
        "LogLevel": {
            ...
            "Microsoft.Azure.SignalR": "Information",
            ...
        }
    }
}

Verifique se há algum aviso anormal / log de erro registrado.

Habilite rastreamentos do lado do servidor para ASP.NET SignalR

Ao usar o SDK versão >= , você pode habilitar rastreamentos adicionando o seguinte a web.config: (Detalhes1.0.0)

<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 aviso anormal / log de erro registrado.

Como habilitar logs dentro do serviço Azure SignalR

Você também pode habilitar logs de diagnóstico para o serviço Azure SignalR, esses logs fornecem informações detalhadas de cada conexão conectada ao serviço Azure SignalR.

Tem problemas ou comentários sobre a solução de problemas? Deixe-nos saber.

Solução de problemas do modo sem servidor

Quando o ASRS está no modo sem servidor, apenas ASP.NET Core SignalR suporta o modo e ASP.NET SignalR NÃO suporta Serverless este modo.

Para diagnosticar problemas de conectividade no Serverless modo, a maneira mais direta é visualizar o tráfego do lado do cliente. Habilitar logs do lado do cliente e logs do lado do serviço também pode ser útil.

Tem problemas ou comentários sobre a solução de problemas? Deixe-nos saber.

Solução de problemas do modo clássico

Classic O modo está obsoleto e não é incentivado a usar. Quando no modo Clássico, o serviço Azure SignalR usa as Conexões de Servidor conectadas para determinar se o serviço atual está no default modo ou serverless modo. 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 Servidor conectada, por exemplo, devido à instabilidade da rede, o Azure SignalR acredita que agora mudou para o modo e os clientes conectados durante esse período nunca serão roteados para serverless o servidor de aplicativo hospedado. Habilite os logs do lado do serviço e verifique se há clientes registrados como ServerlessModeEntered se você tivesse hospedado o servidor de aplicativos, no entanto, alguns clientes nunca chegam ao lado do servidor de aplicativos. Se você vir qualquer um desses clientes, anule as conexões de cliente e, em seguida, deixe os clientes reiniciarem.

A solução de problemas de conectividade do modo e a entrega de mensagens são semelhantes à solução de problemas classicdo modo padrão.

Tem problemas ou comentários sobre a solução de problemas? Deixe-nos saber.

Estado de funcionamento dos serviços

Você pode verificar a integridade do serviço na api de integridade.

• Pedido: GET https://{instance_name}.service.signalr.net/api/v1/health

• Código de status da resposta:

  • 200: saudável.
  • 503: Seu serviço não é saudável. É possível:
    • 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 informações sobre recuperação de desastres.

Tem problemas ou comentários sobre a solução de problemas? Deixe-nos saber.

Próximos passos

Neste guia, você aprendeu sobre como solucionar problemas de conectividade e entrega de mensagens. Você também pode aprender a lidar com os problemas comuns.