Monitorar e solucionar problemas de logs do Serviço do Azure SignalR

Este artigo descreve como você pode usar os recursos do Azure Monitor para analisar e solucionar problemas dos dados de monitoramento do log de recursos gerados pelo Azure SignalR.

A página Visão geral no portal do Azure para cada Serviço do Azure SignalR inclui uma breve exibição do uso do recurso, como conexões simultâneas e contagem de mensagens. Essas informações úteis são apenas uma pequena quantidade dos dados de monitoramento disponíveis no portal. Alguns desses dados são coletados automaticamente e ficam disponíveis para análise assim que você cria o recurso.

Você pode habilitar outros tipos de coleta de dados após algumas configurações. Este artigo explica como configurar a coleta de dados de log e analisar e solucionar problemas com esses dados usando as ferramentas do Azure Monitor.

• Para obter mais informações sobre como monitorar o Serviço do Azure SignalR, consulte Monitorar o Serviço do Azure SignalR.
• Para obter uma listagem detalhada das métricas e logs coletados para o Serviço do Azure SignalR, consulte a referência de dados de monitoramento do Serviço do Azure SignalR.

Pré-requisitos

Para habilitar os logs de recursos, você precisa configurar um local para armazenar seus dados de log, como o Armazenamento do Azure ou o Log Analytics.

• O Armazenamento do Microsoft Azure mantém os logs de recursos para auditoria de política, análise estática ou backup.
• O Log Analytics é uma ferramenta de análise e pesquisa de logs flexível que permite a análise de logs brutos gerados por um recurso do Azure.

Habilitar logs de recursos

O Serviço do Azure SignalR dá suporte a logs de conectividade, logs de mensagens e logs de solicitação HTTP. Para obter mais detalhes sobre esses tipos de logs, consulte Categorias de log de recursos.

Os logs de recursos estão desabilitados por padrão. Para habilitar os logs de recursos usando as configurações de diagnóstico, siga estas etapas:

1. No portal do Azure, em Monitoramento, selecione Configurações de diagnóstico.

   

   Você verá a exibição completa das configurações de diagnóstico.

   

2. Defina as configurações de origem do log.

   1. Na seção Configurações de Origem de Log, há uma tabela mostrando a coleta de comportamentos para cada tipo de log.
   2. Marque o tipo de log específico que deseja coletar para todas as conexões. Caso contrário, o log só será coletado para clientes de diagnóstico.

3. Definir as configurações de destino do log.

   1. Na seção Configurações de Destino do Log, há uma tabela exibindo as configurações de diagnóstico existentes. É possível selecionar o link na tabela para obter acesso ao destino de log para exibir os logs de recursos coletados.
   2. Nesta seção, selecione o botão Definir Configurações de Destino de Log para adicionar, atualizar ou excluir configurações de diagnóstico.
   3. Selecione Adicionar configuração de diagnóstico para adicionar uma nova configuração de diagnóstico ou selecione Editar para modificar uma já existente.
   4. Defina o destino de arquivo desejado. Atualmente, o Serviço do Azure SignalR dá suporte a Arquivar em uma conta de armazenamento e Enviar ao Log Analytics.
   5. Selecione os logs que deseja arquivar. Apenas AllLogs está disponível para o log de recursos. Ele só controla se você deseja arquivar os logs. Use a seção Configurações de Origem do Log para configurar quais tipos de log precisam ser gerados no Serviço do Azure SignalR.

   

   6. Salve a nova configuração de diagnóstico. A nova configuração terá efeito em aproximadamente 10 minutos. Depois disso, os logs são enviados para o destino de arquivamento configurado. Para obter mais informações sobre como definir as configurações de destino do log, veja a Visão geral dos logs de recursos do Azure.

Os logs são armazenados na conta de armazenamento configurada no painel Logs de diagnóstico. Para obter mais detalhes sobre o formato de armazenamento e os campos, consulte Armazenamento de dados.

Consultar os logs de recursos

Para consultar os logs de recursos, siga estas etapas:

1. Selecione Logs no Log Analytics de destino.

   

2. Insira SignalRServiceDiagnosticLogs e selecione o intervalo de tempo. Para obter mais informações, veja Introdução ao Log Analytics no Azure Monitor

   

Para usar consultas de exemplo para o Serviço do Azure SignalR, siga estas etapas:

1. Selecione Logs no Log Analytics de destino.

2. Selecione a guia Consultas para abrir o gerenciador de consultas.

3. Selecione o Tipo de recurso para agrupar consultas de exemplo no tipo de recurso.

4. Selecione Executar para executar o script.

   

Para consultas de exemplo para o Serviço do Azure SignalR, confira Consultas para a tabela SignalRServiceDiagnosticLogs.

Observação

Os nomes do campo de consulta para os destinos de armazenamento diferem ligeiramente dos nomes de campo do Log Analytics. Para obter detalhes sobre os mapeamentos de nomes de campo entre as tabelas de armazenamento e do Log Analytics, consulte Mapeamento de tabela do Log de Recursos.

Solução de problemas com os logs de recursos

Para solucionar problemas do Serviço do Azure SignalR, é possível habilitar os logs do lado do servidor/cliente para capturar falhas. Quando o Serviço do Azure SignalR expõe logs de recursos, você pode aproveitar esses logs para solucionar problemas relacionados ao serviço.

Problemas relacionados à conexão

Ao encontrar conexões crescendo ou caindo inesperadamente, você pode aproveitar os logs de conectividade para solucionar problemas. Os problemas típicos frequentemente envolvem alterações inesperadas na quantidade de conexões, as conexões atingem os limites de conexão e falhas de autorização. As seções a seguir descrevem como solucionar problemas.

Interrupção de conexão inesperada

Se você encontrar uma interrupção de conexões inesperada, habilite primeiro os logs dos lados do serviço, do servidor e do cliente.

Se uma conexão for desconectada, os logs de recursos gravarão esse evento de desconexão e você verá ConnectionAborted ou ConnectionEnded em operationName.

A diferença entre ConnectionAborted e ConnectionEnded é que ConnectionEnded é uma desconexão esperada e é disparada pelo lado do cliente ou do servidor. O ConnectionAborted é geralmente um evento de interrupção de conexão inesperado e o motivo da anulação é fornecido no message.

A tabela a seguir lista os motivos da anulação.

Motivo	Descrição
A contagem de conexões atinge o limite	A contagem de conexões atinge o limite da camada de preço atual. Considere escalar verticalmente a unidade de serviço
O servidor de aplicativos encerrou a conexão	O servidor de aplicativos dispara a anulação. Ela pode ser considerada como uma anulação esperada
Tempo limite de ping de conexão	Geralmente, isso é causado por um problema de rede. Considere verificar a disponibilidade do servidor de aplicativos na Internet
Recarregamento de serviço, tente reconectar	O Serviço do Azure SignalR está recarregando. O Azure SignalR dá suporte à reconexão automática, você pode aguardar até que seja reconectado ou reconectar-se manualmente ao Serviço do Azure SignalR
Erro transitório do servidor interno	O erro transitório ocorre no Serviço do Azure SignalR, deve ser recuperado automaticamente
Conexão do servidor interrompida	A conexão do servidor é interrompida com erro desconhecido, considere solucionar os problemas com o log do lado do serviço/servidor/cliente primeiro. Tente excluir problemas básicos (por exemplo, problema de rede, problema do lado do servidor de aplicativos etc.). Se o problema não for resolvido, entre em contato conosco para obter mais ajuda. Para saber mais, veja a seção Obter ajuda.

Aumento de conexão inesperado

Para solucionar problemas de aumento de conexão inesperado, a primeira coisa que você precisa fazer é filtrar as conexões adicionais. Você pode adicionar uma ID de usuário de teste exclusiva à conexão de cliente de teste. Verifique os logs de recurso. Se você perceber que mais de uma conexão de cliente possui o mesmo ID de usuário de teste ou IP, é provável que o lado do cliente esteja criando mais conexões do que o esperado. Verifique o lado do cliente.

Falha de autorização

Se você receber o erro 401 Não Autorizado para as solicitações do cliente, verifique os logs de recursos. Se você encontrar Failed to validate audience. Expected Audiences: <valid audience>. Actual Audiences: <actual audience>, isso significa que todos os públicos no token de acesso são inválidos. Tente usar os públicos válidos sugeridos no log.

Limitação

Se você achar que não é possível estabelecer conexões de cliente do SignalR com o Serviço do Azure SignalR, verifique os logs de recursos. Se você encontrar Connection count reaches limit no log de recursos, significa que você estabeleceu um número excessivo de conexões com o Serviço do SignalR, o que atinge o limite de contagem de conexões. Considere a possibilidade de escalar verticalmente o Serviço do SignalR. Se você encontrar Message count reaches limit no registro de recursos, significa que está usando a camada gratuita e esgotou a cota de mensagens. Se você quiser enviar mais mensagens, considere alterar o Serviço do SignalR para a camada standard. Para saber mais, veja Preços do Serviço do Azure SignalR.

Problemas relacionados à mensagem

Ao encontrar problemas relacionados a mensagens, você pode aproveitar os logs de mensagens para solucionar problemas. Primeiro, habilite os logs de recursos no serviço e os logs para servidor e cliente.

Observação

Para o ASP.NET Core, confira aqui como habilitar o log no servidor e no cliente.

Para o ASP.NET, confira aqui como habilitar o registro em log no servidor e no cliente.

Se não se importar com possíveis efeitos no desempenho e nenhuma mensagem na direção cliente para servidor, verifique Messaging em Log Source Settings/Types para habilitar o comportamento de coleta de logs collect-all. Para obter mais informações sobre esse comportamento, confira coletar tudo .

Caso contrário, desmarque Messaging para habilitar o comportamento de coleta de logs collect-partially. Esse comportamento requer a configuração no cliente e no servidor para ser habilitado. Para obter mais informações, confira coletar parcialmente.

Perda de mensagens

Se você encontrar problemas de perda de mensagens, a chave é localizar o ponto onde a mensagem é perdida. Basicamente, você tem três componentes ao usar o Serviço do Azure SignalR: o serviço SignalR, o servidor e o cliente. Tanto o servidor quanto o cliente estão conectados ao serviço SignalR, mas não se conectam um ao outro diretamente depois que a negociação é concluída. Portanto, você precisa considerar duas direções para as mensagens e, para cada direção, precisa considerar dois caminhos:

• Do cliente para o servidor por meio do serviço SignalR
  • Caminho 1: cliente para o serviço SignalR
  • Caminho 2: serviço SignalR para o servidor
• Do servidor para o cliente por meio do serviço SignalR
  • Caminho 3: servidor para o serviço SignalR
  • Caminho 4: serviço SignalR para o cliente

Para o comportamento de coleta coletar tudo:

O Serviço do Azure SignalR só rastreia mensagens na direção do servidor para o cliente por meio do serviço SignalR. A ID de rastreamento é gerada no servidor. A mensagem carrega a ID de rastreamento para o serviço SignalR.

Observação

Se você quiser rastrear mensagens e enviar mensagens de fora de um hub no seu servidor do aplicativo, será necessário habilitar o comportamento de coleta coletar tudo para coletar logs de mensagens para as mensagens que não são originadas de clientes de diagnóstico. Os clientes de diagnóstico funcionam para os comportamentos de coleta coletar todos e coletar parcialmente, mas têm prioridade maior para coletar logs. Para obter mais informações, confira a seção Cliente de diagnóstico.

Ao verificar o servidor de entrada e o lado do serviço, você pode descobrir facilmente se a mensagem é enviada do servidor, chega ao serviço do SignalR e sai do serviço do SignalR. Basicamente, ao verificar se a mensagem recebida e enviada corresponde ou não com base na ID de rastreamento de mensagens, você pode informar se o problema de perda de mensagem está no servidor ou no serviço SignalR nessa direção. Para obter mais informações, confira os detalhes abaixo.

Para o comportamento de coleta coletar parcialmente:

Depois de marcar o cliente como cliente de diagnóstico, o Serviço do Azure SignalR rastreará mensagens em ambas as direções.

Ao verificar o servidor de entrada e o lado do serviço, você pode descobrir facilmente se a mensagem é passada pelo servidor ou pelo serviço do SignalR com êxito. Basicamente, ao verificar se a mensagem recebida e enviada corresponde ou não com base na ID de rastreamento de mensagens, você pode informar se o problema de perda de mensagem está no servidor ou no serviço SignalR. Para saber mais, consulte os detalhes a seguir.

Detalhes do fluxo de mensagens

Para a direção do cliente para o servidor por meio do serviço SignalR, o serviço SignalR considerará apenas a invocação originada do cliente de diagnóstico, ou seja, a mensagem gerada diretamente no cliente de diagnóstico ou a mensagem de serviço gerada devido à invocação do cliente de diagnóstico indiretamente.

A ID de rastreamento é gerada no serviço SignalR assim que a mensagem chegar ao serviço SignalR no Caminho 1. O serviço SignalR gera um log Received a message <MessageTracingId> from client connection <ConnectionId>. para cada mensagem no cliente de diagnóstico. Depois que a mensagem sair do SignalR para o servidor, o serviço do SignalR gera uma mensagem de log Sent a message <MessageTracingId> to server connection <ConnectionId> successfully.. Se você vir esses dois logs, está confirmado que a mensagem passa pelo serviço do SignalR com êxito.

Observação

Devido à limitação do ASP.NET Core SignalR, a mensagem enviada pelo cliente não contém nenhuma ID de nível de mensagem, mas o ASP.NET SignalR gera uma ID de invocação para cada mensagem. Você pode usá-la para mapear com a ID de rastreamento.

Em seguida, a mensagem carrega o servidor da ID de rastreamento no Caminho 2. O servidor gera um log Received message <messagetracingId> from client connection <connectionId> quando a mensagem chega.

Depois que a mensagem invocar o método hub no servidor, uma nova mensagem de serviço é gerada com uma nova ID de rastreamento. Depois que a mensagem de serviço é gerada, o servidor gera um modelo de entrada Start to broadcast/send message <MessageTracingId> .... O log real é baseado em seu cenário. Em seguida, a mensagem é entregue ao serviço SignalR no Caminho 3. Depois que a mensagem de serviço sai do servidor, um log chamado Succeeded to send message <MessageTracingId> é gerado.

Observação

A ID de rastreamento da mensagem do cliente não pode ser mapeada para a ID de rastreamento da mensagem de serviço a ser enviada para o serviço SignalR.

Assim que a mensagem de serviço chegar ao serviço SignalR, é gerado um log chamado Received a <MessageType> message <MessageTracingId> from server connection <ConnectionId>.. Em seguida, o serviço SignalR processa a mensagem de serviço e a entrega para os clientes de destino. Depois que a mensagem for enviada aos clientes no Caminho 4, é gerado o log Sent a message <MessageTracingId> to client connection <ConnectionId> successfully..

Resumindo, o log de mensagens é gerado quando a mensagem entrar e sair do serviço SignalR e do servidor. Você pode usar esses logs para validar se a mensagem é perdida nesses componentes ou não.

O exemplo a seguir é um problema típico de perda de mensagem.

Um cliente não recebe mensagens em um grupo

A história típica desse problema é que o cliente ingressa em um grupo depois de enviar uma mensagem de grupo.

Class Chat : Hub
{
    public void JoinAndSendGroup(string name, string groupName)
    {
        Groups.AddToGroupAsync(Context.ConnectionId, groupName); // join group
        Clients.Group(groupName).SendAsync("ReveiceGroupMessage", name, "I'm in group"); // send group message
    }
}

Por exemplo, alguém pode fazer invocações de ingressar no grupo e enviar mensagem de grupo no mesmo método de hub. O problema aqui é que AddToGroupAsync é um método async. Como não há await para o AddToGroupAsync aguardar até que seja concluído, a mensagem de grupo é enviada antes de AddToGroupAsync ser concluído. Devido ao atraso na rede e ao atraso do processo de ingresso do cliente a algum grupo, pode ser que a ação de ingressar no grupo seja concluída após à entrega da mensagem ao grupo. Nesse caso, a primeira mensagem de grupo não tem nenhum cliente como destinatário, já que nenhum cliente se juntou ao grupo, então isso se torna um problema de mensagem perdida.

Sem logs de recursos, não é possível descobrir quando o cliente ingressa no grupo e quando a mensagem de grupo é enviada. Depois de habilitar os logs de mensagens, você poderá comparar o tempo de chegada da mensagem no serviço SignalR. Execute as etapas a seguir para solucionar o problema:

1. Localize os logs de mensagem no servidor para descobrir quando o cliente ingressou no grupo e quando a mensagem de grupo foi enviada.
2. Obtenha a ID de rastreamento de mensagem A sobre o ingresso no grupo e a ID de rastreamento de mensagem B sobre mensagem de grupo dos logs de mensagens.
3. Filtre essas IDs de rastreamento de mensagem entre os logs de mensagens em seu destino de arquivo de log e, em seguida, compare seus carimbos de data/hora de chegada. Você encontra qual mensagem chegou primeiro no serviço do SignalR.
4. Se o tempo de chegada da ID de rastreamento da mensagem A for posterior ao tempo de chegada da ID de rastreamento da mensagem B, você deve estar enviando uma mensagem de grupo antes do cliente se juntar ao grupo. Você precisa verificar se o cliente está no grupo antes de enviar mensagens de grupo.

Se uma mensagem for perdida no SignalR ou no servidor, tente obter os logs de aviso com base na ID de rastreamento de mensagens para descobrir o motivo. Se precisar de mais ajuda, confira a seção Obter ajuda.

Comportamentos de coleta de logs de recurso

Há dois cenários típicos para usar os logs de recursos, especialmente para logs de mensagens.

Alguém pode se importar com a qualidade de cada mensagem. Por exemplo, o usuário deseja saber se a mensagem foi enviada/recebida com êxito ou deseja registrar todas as mensagens que são entregues por meio do serviço SignalR.

Enquanto isso, outras pessoas podem se importar com o desempenho. Elas se interessam pela latência da mensagem e, às vezes, precisam acompanhar a mensagem em apenas algumas conexões e não em todas por algum motivo.

Portanto, o serviço SignalR fornece dois tipos de comportamentos de coleta

• coletar tudo: coletam-se logs em todas as conexões
• coletar parcialmente: coletam-se logs em algumas conexões específicas

Observação

Para distinguir as conexões entre aquelas que coletam logs e aquelas que não coletam logs, o serviço SignalR trata alguns clientes como clientes de diagnóstico com base nas configurações de cliente e servidor, onde os logs de recursos sempre são coletados, enquanto os outros não são. Para obter mais informações, confira a seção Coletar parcialmente.

Coletar tudo

Os logs de recursos são coletados por todas as conexões. Peguemos os logs de mensagens como exemplo. Quando esse comportamento estiver habilitado, o serviço SignalR envia uma notificação ao servidor para começar a gerar a ID de rastreamento para cada mensagem. A ID de rastreamento é transportada na mensagem para o serviço. O serviço também registra a mensagem com a ID de rastreamento.

Observação

Observe que, para garantir o desempenho do serviço SignalR, o serviço SignalR não aguarda e analisa a mensagem completa enviada pelo cliente. Portanto, as mensagens do cliente não são registradas. Mas se o cliente estiver marcado como um cliente de diagnóstico, a mensagem do cliente é registrada no serviço SignalR.

Guia de configuração

Para habilitar esse comportamento, marque a caixa de seleção na seção Tipos em Configurações de Origem do Log.

Esse comportamento não exige a atualização das configurações no lado do servidor. Essa alteração de configuração sempre é enviada ao servidor automaticamente.

Coletar parcialmente

Os logs de recursos são coletados apenas por clientes de diagnóstico. Todas as mensagens são registradas, incluindo as mensagens de cliente os eventos de conectividade nos clientes de diagnóstico.

Observação

O limite de quantidade de clientes de diagnóstico é 100. Se a quantidade de clientes de diagnóstico exceder 100, os excedentes são limitados pelo serviço SignalR. Os clientes novos, mas em maior número, falham ao se conectar ao serviço SignalR e lançam System.Net.Http.HttpRequestException, que possui a mensagem Response status code does not indicate success: 429 (Too Many Requests). Os clientes já conectados funcionam sem serem afetados pela política de limitação.

Cliente de diagnóstico

O cliente de diagnóstico é um conceito lógico. Qualquer cliente pode ser um cliente de diagnóstico. O servidor controla qual cliente pode ser um cliente de diagnóstico. Assim que um cliente for marcado como cliente de diagnóstico, todos os logs de recursos são habilitados para ele. Para definir um cliente como um cliente de diagnóstico, confira o guia de configuração.

Guia de configuração

Para habilitar esse comportamento, você precisa configurar o lado do cliente, do servidor e o serviço.

Lado do serviço

Para habilitar esse comportamento, desmarque a caixa de seleção de um tipo de log específico na seção Tipos em Configurações de Origem do Log.

Lado do Servidor

Também configura ServiceOptions.DiagnosticClientFilter para definir um filtro de clientes de diagnóstico com base no contexto http que vem de clientes. Por exemplo, crie o cliente com a URL de hub <HUB_URL>?diag=yes, depois configure ServiceOptions.DiagnosticClientFilter para filtrar o cliente de diagnóstico. Se ele retornar true, o cliente será marcado como cliente de diagnóstico. Caso contrário, ele permanecerá como cliente normal. O ServiceOptions.DiagnosticClientFilter pode ser definido em sua classe de inicialização da seguinte maneira:

// sample: mark a client as diagnostic client when it has query string "?diag=yes" in hub URL
public IServiceProvider ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    services
        .AddSignalR()
        .AddAzureSignalR(o =>
        {
            o.ConnectionString = "<YOUR_ASRS_CONNECTION_STRING>";
            o.DiagnosticClientFilter = context => context.Request.Query["diag"] == "yes";
        });

    return services.BuildServiceProvider();
}

Lado do cliente

Configure o contexto http para marcar o cliente como cliente de diagnóstico. Por exemplo, o cliente é marcado como cliente de diagnóstico ao adicionar-se a cadeia de caracteres de consulta diag=yes.

var connection = new HubConnectionBuilder()
    .WithUrl("<HUB_URL>?diag=yes")
    .Build();

Obter ajuda

É recomendável que você solucione problemas por conta própria primeiro. A maioria dos problemas são causados por problemas de rede ou do servidor de aplicativos. Siga o Guia de solução de problemas com o log de recursos e o Guia de solução de problemas básicos para encontrar a causa raiz. Se o problema ainda não puder ser resolvido, considere abrir um problema no GitHub ou criar um tíquete no portal do Azure. Provedor:

1. Um intervalo de tempo de cerca de 30 minutos quando o problema ocorre
2. A ID do recurso do Serviço do Azure SignalR
3. Os detalhes do problema, o mais específico possível: por exemplo, o AppServer não envia mensagens, interrupções de conexão do cliente e assim por diante
4. Os logs coletados do lado do servidor/cliente e outros materiais que podem ser úteis
5. [Opcional] O código de reprodução

Observação

Se você abrir um problema no GitHub, mantenha suas informações confidenciais (por exemplo, ID do recurso, logs de servidor/cliente) privadas. Envie somente para membros da organização da Microsoft em particular.