Usar logs de recursos para monitorar o Serviço 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 Azure SignalR inclui uma breve exibição do uso de recursos, como conexões simultâneas e contagem de mensagens. Esta informação útil é apenas uma pequena quantidade dos dados de monitorização 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 alguma configuração. Este artigo explica como configurar a coleta de dados de log e analisar e solucionar problemas desses dados usando as ferramentas do Azure Monitor.
- Para obter mais informações sobre como monitorar o Serviço Azure SignalR, consulte Monitorar o Serviço Azure SignalR.
- Para obter uma lista detalhada das métricas e logs coletados para o Serviço Azure SignalR, consulte Referência de dados de monitoramento do Serviço 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 Azure retém logs de recursos para auditoria de políticas, análise estática ou backup.
- O Log Analytics é uma ferramenta flexível de pesquisa e análise de logs que permite a análise de logs brutos gerados por um recurso do Azure.
Ativar registos de recursos
O Serviço 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 são armazenados na conta de armazenamento configurada no painel Logs de diagnóstico. Para obter mais detalhes sobre o formato e os campos de armazenamento, consulte Armazenamento de dados.
Criar as definições de diagnóstico
Os logs de recursos são desabilitados por padrão. Para habilitar logs de recursos usando configurações de diagnóstico, consulte Criar configurações de diagnóstico no Azure Monitor.
Consultar logs de recursos
Para consultar logs de recursos, siga estas etapas:
Selecione Logs no Log Analytics de destino.
Digite SignalRServiceDiagnosticLogs e selecione o intervalo de tempo. Para consultas avançadas, consulte Introdução ao Log Analytics no Azure Monitor
Para usar consultas de exemplo para o Serviço Azure SignalR, siga estas etapas:
Selecione Logs no Log Analytics de destino.
Selecione a guia Consultas para abrir o explorador de consultas .
Selecione Tipo de recurso para agrupar consultas de exemplo em tipo de recurso.
Selecione Executar para executar o script.
Por exemplo, consultas para o Serviço SignalR do Azure, consulte Consultas para a tabela SignalRServiceDiagnosticLogs.
Nota
Os nomes de campo de consulta para destinos de armazenamento diferem ligeiramente dos nomes de campo para o Log Analytics. Para obter detalhes sobre os mapeamentos de nome de campo entre tabelas de Armazenamento e Análise de Log, consulte Mapeamento de tabela de Log de Recursos.
Solução de problemas com logs de recursos
Para solucionar problemas do Serviço SignalR do Azure, você pode habilitar logs do lado do servidor/cliente para capturar falhas. Quando o Serviço Azure SignalR expõe logs de recursos, você pode aproveitar os logs de recursos para solucionar problemas de logs para o serviço.
Problemas relacionados com a ligação
Quando você encontrar conexões crescendo ou caindo inesperadamente, você pode aproveitar os logs de conectividade para solucionar problemas. Problemas típicos geralmente envolvem alterações inesperadas na quantidade de conexão, conexões que atingem limites de conexão e falha de autorização. As seções a seguir descrevem como solucionar problemas.
Queda inesperada de conexão
Se você encontrar conexões inesperadas, primeiro habilite os logs nos lados do serviço, do servidor e do cliente.
Se uma conexão se desconectar, os logs de recursos registrarã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, que é acionada pelo lado do cliente ou servidor. O ConnectionAborted é geralmente um evento de queda de conexão inesperado, e o motivo de cancelamento é fornecido em message.
A tabela a seguir lista os motivos de anulação.
| Motivo | Description |
|---|---|
| Contagem de conexões atinge limite | A contagem de conexões atinge o limite do seu nível de preço atual. Considere aumentar a escala da unidade de serviço |
| O servidor de aplicativos fechou a conexão | O servidor do aplicativo aciona o aborto. Pode ser considerado como um aborto esperado |
| Tempo limite de ping de conexão | Geralmente é causado por problema de rede. Considere verificar a disponibilidade do servidor de aplicativos na Internet |
| Recarregamento do serviço, tente reconectar | O Serviço Azure SignalR está recarregando. O Azure SignalR suporta a reconexão automática, você pode esperar até ser reconectado ou reconectar manualmente ao Serviço Azure SignalR |
| Erro transitório do servidor interno | Erro transitório ocorre no Serviço Azure SignalR, deve ser recuperado automaticamente |
| Conexão do servidor interrompida | A conexão do servidor cai com erro desconhecido, considere a autosolução de 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, contacte-nos para obter mais ajuda. Para obter mais informações, consulte a seção Obter ajuda . |
Conexão inesperada crescendo
Para solucionar problemas sobre o aumento inesperado da conexão, a primeira coisa que você precisa fazer é filtrar as conexões extras. Você pode adicionar um ID de usuário de teste exclusivo à sua conexão de cliente de teste. Verifique os logs de recursos. Se você vir que mais de uma conexão de cliente tem 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 seu cliente.
Falha na autorização
Se você receber 401 não autorizado devolvido para solicitações de cliente, verifique seus 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 em seu 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 pode estabelecer conexões de cliente SignalR com o Serviço SignalR do Azure, verifique seus logs de recursos. Se você encontrar Connection count reaches limit no log de recursos, você estabelece muitas conexões com o Serviço SignalR, que atingem o limite de contagem de conexões. Considere expandir seu serviço SignalR. Se você encontrar Message count reaches limit no log de recursos, isso significa que você usa a camada gratuita e você usou a cota de mensagens. Se você quiser enviar mais mensagens, considere alterar seu Serviço SignalR para a camada padrão. Para obter mais informações, consulte Preços do Serviço Azure SignalR.
Problemas relacionados com mensagens
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 nos logs para servidor e cliente.
Nota
Para ASP.NET Core, consulte aqui para ativar o login no servidor e no cliente.
Para ASP.NET, consulte aqui para ativar o login no servidor e no cliente.
Se você não se importa com possíveis efeitos de desempenho e nenhuma mensagem de direção cliente-servidor, faça check-in Log Source Settings/Types para habilitar o Messaging comportamento de coleta de log de coleta de tudo. Para obter mais informações sobre esse comportamento, consulte coletar todos os .
Caso contrário, desmarque a opção para habilitar o Messaging comportamento de coleta de log de coleta parcial. Esse comportamento requer configuração no cliente e no servidor para habilitá-lo. Para obter mais informações, consulte coletar parcialmente.
Perda de mensagem
Se você encontrar problemas de perda de mensagem, a chave é localizar o local onde você perde a mensagem. Basicamente, você tem três componentes ao usar o Serviço SignalR do Azure: serviço, servidor e cliente do SignalR. O servidor e o cliente estão conectados ao serviço SignalR, mas não se conectam diretamente um ao outro depois que a negociação é concluída. Portanto, você precisa considerar duas direções para as mensagens, e para cada direção você precisa considerar dois caminhos:
- Do cliente para o servidor através do serviço SignalR
- Caminho 1: Cliente para serviço SignalR
- Caminho 2: Serviço SignalR para servidor
- Do servidor para o cliente através do serviço SignalR
- Caminho 3: Servidor para serviço SignalR
- Caminho 4: Serviço SignalR para cliente
Para coletar todos os comportamentos de coleta:
O Serviço Azure SignalR rastreia apenas mensagens na direção do servidor para o cliente por meio do serviço SignalR. O ID de rastreamento é gerado no servidor. A mensagem carrega o ID de rastreamento para o serviço SignalR.
Nota
Se quiser rastrear mensagens e enviar mensagens de fora de um hub no servidor de aplicativos, você precisará habilitar o comportamento de coleta 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 tanto para coletar todos quanto para coletar parcialmente comportamentos, mas tem maior prioridade para coletar logs. Para obter mais informações, consulte 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 SignalR e sai do serviço SignalR. Basicamente, verificando se a mensagem recebida e enviada são correspondidas ou não com base no ID de rastreamento de mensagens, você pode saber se o problema de perda de mensagem está no servidor ou no serviço SignalR nessa direção. Para obter mais informações, consulte os detalhes abaixo.
Para o comportamento de coleta parcial :
Depois de marcar o cliente como cliente de diagnóstico, o Serviço SignalR do Azure rastreia 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 está passando o servidor ou o serviço SignalR com êxito. Basicamente, verificando se a mensagem recebida e enviada são correspondidas ou não com base no ID de rastreamento de mensagens, você pode saber se o problema de perda de mensagem está no servidor ou no serviço SignalR. Para obter mais informações, consulte os seguintes detalhes.
Detalhes do fluxo de mensagens
Para a direção do cliente para o servidor via serviço SignalR, o serviço SignalR considera apenas a invocação que é originada do cliente de diagnóstico, ou seja, a mensagem gerada diretamente no cliente de diagnóstico, ou mensagem de serviço gerada devido à invocação do cliente de diagnóstico indiretamente.
O ID de rastreamento é gerado no serviço SignalR assim que a mensagem chega 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. Uma vez que a mensagem sai do SignalR para o servidor, o serviço SignalR gera uma mensagem Sent a message <MessageTracingId> to server connection <ConnectionId> successfully.de log . Se você vir esses dois logs, pode ter certeza de que a mensagem passa pelo serviço SignalR com êxito.
Nota
Devido à limitação do ASP.NET Core SignalR, a mensagem vem do cliente não contém nenhum ID de nível de mensagem, mas ASP.NET SignalR gera ID de invocação para cada mensagem. Você pode usá-lo para mapear com o ID de rastreamento.
Em seguida, a mensagem carrega o servidor de ID de rastreamento no caminho 2. O servidor gera um log Received message <messagetracingId> from client connection <connectionId> assim que a mensagem chega.
Depois que a mensagem invoca 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 Start to broadcast/send message <MessageTracingId> ...de entrada. O log real é baseado no seu cenário. Em seguida, a mensagem é entregue ao serviço SignalR no caminho 3. Quando a mensagem de serviço sai do servidor, um log chamado Succeeded to send message <MessageTracingId> é gerado.
Nota
O ID de rastreamento da mensagem do cliente não pode ser mapeado para o ID de rastreamento da mensagem de serviço a ser enviada ao serviço SignalR.
Quando a mensagem de serviço chega ao serviço SignalR, um log chamado Received a <MessageType> message <MessageTracingId> from server connection <ConnectionId>. é gerado. Em seguida, o serviço SignalR processa a mensagem de serviço e entrega ao(s) cliente(s) de destino. Uma vez que a mensagem é enviada para o(s) cliente(s) no caminho 4, o log Sent a message <MessageTracingId> to client connection <ConnectionId> successfully. é gerado.
Em resumo, o log de mensagens é gerado quando a mensagem entra e sai do serviço e do servidor SignalR. Você pode usar esses logs para validar se a mensagem foi perdida nesses componentes ou não.
O exemplo a seguir é um problema típico de perda de mensagem.
Um cliente não consegue receber mensagens em um grupo
A história típica nesta edição é que o cliente entra 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 é o AddToGroupAsync é um async método. Como não há como await AddToGroupAsync esperar até terminar, a mensagem de grupo é enviada antes AddToGroupAsync de ser concluída. Devido ao atraso da rede e ao atraso do processo de ingressar o cliente em algum grupo, a ação de ingressar no grupo pode ser concluída mais tarde do que a entrega da mensagem do grupo. Se assim for, a primeira mensagem de grupo não tem nenhum cliente como destinatário, uma vez que nenhum cliente se juntou ao grupo, então torna-se um problema de perda de mensagem.
Sem logs de recursos, você não consegue descobrir quando o cliente entra no grupo e quando a mensagem do grupo é enviada. Depois de ativar os logs de mensagens, você pode comparar a hora de chegada da mensagem no serviço SignalR. Execute as seguintes etapas para solucionar problemas:
- Localize os logs de mensagens no servidor para descobrir quando o cliente ingressou no grupo e quando a mensagem do grupo é enviada.
- Obtenha a ID de rastreamento de mensagens A de ingressar no grupo e a ID de rastreamento de mensagens B da mensagem de grupo nos logs de mensagens.
- Filtre esses IDs de rastreamento de mensagens entre os logs de mensagens no destino do arquivo de log e, em seguida, compare os carimbos de data/hora que chegam. Você encontra qual mensagem chegou primeiro no serviço SignalR.
- Se a hora de chegada do ID de rastreamento de mensagens A for posterior à hora de chegada B, você deverá enviar uma mensagem de grupo antes que o cliente ingresse no grupo. Você precisa se certificar de que o cliente está no grupo antes de enviar mensagens de grupo.
Se uma mensagem se perder no SignalR ou no servidor, tente obter os logs de aviso com base no ID de rastreamento da mensagem para obter o motivo. Se precisar de mais ajuda, consulte a secção Obter ajuda.
Comportamentos de coleta de logs de recursos
Há dois cenários típicos para usar logs de recursos, especialmente para logs de mensagens.
Alguém pode se preocupar com a qualidade de cada mensagem. Por exemplo, eles são sensíveis se a mensagem foi enviada/recebida com sucesso ou se querem gravar todas as mensagens entregues através do serviço SignalR.
Enquanto isso, outros podem se preocupar com o desempenho. Eles são sensíveis à latência da mensagem e, às vezes, precisam rastrear a mensagem em algumas conexões em vez de todas as conexões por algum motivo.
Portanto, o serviço SignalR fornece dois tipos de comportamentos de coleta
- Coletar tudo: coletar logs em todas as conexões
- Coletar parcialmente: coletar logs em algumas conexões específicas
Nota
Para distinguir as conexões entre esses logs de coleta e aqueles que não coletam logs, o serviço SignalR trata alguns clientes como clientes de diagnóstico com base nas configurações de cliente de diagnóstico de servidor e cliente, nas quais os logs de recursos sempre são coletados, enquanto os outros não. Para obter mais informações, consulte a seção coletar parcialmente.
Recolher tudo
Os logs de recursos são coletados por todas as conexões. Tomemos como exemplo os registos de mensagens. Quando esse comportamento está habilitado, o serviço SignalR envia uma notificação ao servidor para começar a gerar ID de rastreamento para cada mensagem. O ID de rastreamento é transportado na mensagem para o serviço. O serviço também registra a mensagem com ID de rastreamento.
Nota
Observe que, para garantir o desempenho do serviço SignalR, o serviço SignalR não aguarda e analisa toda a mensagem enviada do cliente. Portanto, as mensagens do cliente não são registradas. Se o cliente estiver marcado como um cliente de diagnóstico, a mensagem do cliente será registrada no serviço SignalR.
Guia de configuração
Para habilitar esse comportamento, marque a caixa de seleção na seção Tipos nas Configurações de origem do log.
Esse comportamento não requer que você atualize as configurações do lado do servidor. Esta alteração de configuração é sempre enviada para o servidor automaticamente.
Recolher parcialmente
Os logs de recursos são coletados apenas por clientes de diagnóstico. Todas as mensagens são registradas, incluindo mensagens de cliente e eventos de conectividade nos clientes de diagnóstico.
Nota
O limite do número de clientes de diagnóstico é 100. Se o número de clientes de diagnóstico exceder 100, os clientes de diagnóstico em menor número serão limitados pelo serviço SignalR. Os clientes novos, mas em menor número, não conseguem se conectar ao serviço SignalR, e lançam System.Net.Http.HttpRequestException, que tem a mensagem Response status code does not indicate success: 429 (Too Many Requests). Os clientes já conectados trabalham sem serem afetados pela política de limitação.
Cliente de diagnóstico
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. Depois que um cliente é marcado como um cliente de diagnóstico, todos os logs de recursos são habilitados nesse cliente. Para definir um cliente como um cliente de diagnóstico, consulte o guia de configuração.
Guia de configuração
Para habilitar esse comportamento, você precisa configurar o serviço, o servidor e o lado do cliente.
Lado de serviço
Para habilitar esse comportamento, desmarque a caixa de seleção para um tipo de log específico na seção Tipos nas Configurações de origem do log.
Lado do servidor
Também configurado ServiceOptions.DiagnosticClientFilter para definir um filtro de clientes de diagnóstico com base no contexto http vem de clientes. Por exemplo, faça cliente com URL <HUB_URL>?diag=yesde hub e, em seguida, 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, permanece como cliente normal. O ServiceOptions.DiagnosticClientFilter pode ser definido na sua classe de inicialização assim:
// 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
Marque o cliente como cliente de diagnóstico configurando o contexto http. Por exemplo, o cliente é marcado como cliente de diagnóstico adicionando a cadeia de caracteres de consulta diag=yes.
var connection = new HubConnectionBuilder()
.WithUrl("<HUB_URL>?diag=yes")
.Build();
Obter ajuda
Recomendamos que você solucione problemas sozinho primeiro. A maioria dos problemas é causada por problemas de servidor de aplicativos ou de rede. Siga o guia de solução de problemas com o log de recursos e o guia básico de solução de problemas para encontrar a causa raiz. Se o problema ainda não puder ser resolvido, considere abrir um problema no GitHub ou criar tíquete no portal do Azure. Fornecer:
- Intervalo de tempo de cerca de 30 minutos quando o problema ocorre
- ID de recurso do Serviço Azure SignalR
- Detalhes do problema, o mais específico possível: por exemplo, o appserver não envia mensagens, a conexão do cliente cai e assim por diante
- Logs coletados do lado do servidor/cliente e outros materiais que possam ser úteis
- [Opcional] Código de reprodução
Nota
Se você abrir um problema no GitHub, mantenha suas informações confidenciais (por exemplo, ID de recurso, logs de servidor/cliente) privadas. Envie apenas para membros na organização da Microsoft de forma privada.