Uso de registros de recursos para supervisar SignalR Service

En este artículo se describen cómo puede usar las características de Azure Monitor para analizar y solucionar los problemas de los datos de supervisión generados por Azure SignalR Service.

La página Información general de Azure Portal para cada Azure SignalR Service incluye una breve vista del uso de los recursos, como las conexiones simultánea y el conteo de mensajes. Esta información útil solo es una pequeña cantidad de datos de supervisión está disponible en el portal. Algunos de estos datos se recopilan automáticamente y están disponibles para su análisis en cuanto se crea el recurso.

Puede habilitar otros tipos de recopilación de datos después de modificar cierta configuración adicional. En este artículo se explica cómo configurar la recopilación de datos de registro y analizar y solucionar problemas de estos datos mediante herramientas de Azure Monitor.

• Para más información sobre la supervisión de Azure SignalR Service, consulte Supervisión de Azure SignalR Service.
• Para obtener una lista detallada de las métricas y registros recopilados para Azure SignalR Service, consulte referencia de datos de supervisión de Azure SignalR Service.

Importante

Las cadenas de conexión sin procesar solo aparecen en este artículo con fines de demostración.

Una cadena de conexión incluye la información de autorización necesaria para que la aplicación acceda al servicio Azure Web PubSub. La clave de acceso dentro de la cadena de conexión es similar a una contraseña raíz para el servicio. En entornos de producción, proteja siempre las claves de acceso. Use Azure Key Vault para administrar y rotar las claves de forma segura y proteger la cadena de conexión mediante Microsoft Entra ID y Autorizar el acceso con Microsoft Entra ID.

Evite distribuirlas a otros usuarios, codificarlas de forma rígida o guardarlas en un archivo de texto sin formato al que puedan acceder otros usuarios. Rote sus claves si cree que se han puesto en peligro.

Requisitos previos

Para habilitar los registros de recursos, debe configurar un lugar para almacenar los datos de registro, como Azure Storage o Log Analytics.

• Azure Storage conserva los registros de recursos para auditorías de directivas, análisis estáticos o copias de seguridad.
• Log Analytics es una herramienta flexible de búsqueda y de análisis de registros que permite el análisis de los registros sin procesar que genera un recurso de Azure.

Habilitación de registros de recursos

Azure SignalR Service admite registros de conectividad, mensajería y solicitudes Http. Para obtener más información sobre estos tipos de registros, consulte Categorías de registro de recursos. Los registros se almacenan en la cuenta de almacenamiento configurada en el panel Registros de diagnóstico. Para obtener más información sobre el formato de almacenamiento y los campos, consulte Almacenamiento de datos.

Crear configuraciones de diagnóstico

Los registros de recursos están inhabilitados de forma predeterminada. Para habilitar los registros de recursos mediante la configuración de diagnóstico, consulta Creación de una configuración de diagnóstico en Azure Monitor.

Consultar registros de recursos

Para consultar los registros de recursos, siga estos pasos:

1. Seleccione Registros en la instancia de Log Analytics de destino.

   

2. Escriba SignalRServiceDiagnosticLogs y seleccione Intervalo de tiempo. Para una consulta avanzada, consulte Introducción a los análisis de registros de Azure Monitor.

   

Para usar una consulta de ejemplo para Azure SignalR Service, siga estos pasos:

1. Seleccione Registros en la instancia de Log Analytics de destino.

2. Seleccione la pestaña Consultas para abrir el explorador de consultas.

3. Seleccione Tipo de recurso para agrupar consultas de ejemplo en el tipo de recurso.

4. Seleccione Ejecutar para ejecutar el script.

   

Para ver consultas de ejemplo para Azure SignalR Service, vea Consultas para la tabla SignalRServiceDiagnosticLogs.

Nota:

Los nombres de campo de consulta para destinos de Storage difieren ligeramente de los nombres de campo para Log Analytics. Para obtener más información sobre las asignaciones de nombres de campo entre tablas de Storage y Log Analytics, consulte Asignación de tablas de registro de recursos.

Solución de problemas con registros de recursos

Para solucionar problemas de Azure SignalR Service, puede habilitar los registros del lado cliente o servidor a fin de capturar errores. Cuando Azure SignalR Service expone los registros de recursos, puede aprovechar los registros de recursos para solucionar problemas de los registros del servicio.

Problemas relacionados con la conexión

Ante una situación de crecimiento o interrupción inesperada de conexiones, puede aprovechar los registros de conectividad para solucionar problemas. Los problemas típicos suelen ser cambios inesperados en el número de conexiones, conexiones que llegan a los límites de conexión y errores de autorización. En las secciones siguientes se describe cómo solucionar problemas.

Interrupción inesperada de la conexión

Si se produce una interrupción inesperada de la conexión, debe habilitar los registros en los lados servicio, servidor y cliente.

Si se desconecta una conexión, los registros de recursos registran este evento de desconexión y se ve ConnectionAborted o ConnectionEnded en operationName.

La diferencia entre ConnectionAborted y ConnectionEnded es que ConnectionEnded es una desconexión esperada desencadenada por el lado cliente o servidor. El ConnectionAborted suele ser un evento de interrupción inesperada de la conexión, y se proporciona el motivo de la anulación en message.

En la tabla siguiente se enumeran los motivos de la anulación.

Motivo	Descripción
El número de conexiones llega al límite	El número de conexiones llega al límite del nivel de precios actual. Considere la posibilidad de escalar la unidad de servicio.
La aplicación ha cerrado la conexión	El servidor de aplicaciones desencadena la anulación. Se puede considerar como una anulación esperada
Tiempo de expiración del ping de conexión	Normalmente, se debe a un problema de red. Considere la posibilidad de comprobar la disponibilidad del servidor de aplicaciones desde Internet.
Recarga del servicio, pruebe a volver a conectarse	Azure SignalR Service se está cargando de nuevo. Azure SignalR admite la reconexión automática, por lo que puede esperar a que se vuelva a conectar, o bien conectarlo de nuevo manualmente a Azure SignalR Service.
Error transitorio del servidor interno	Se produce un error transitorio en Azure SignalR Service, se debería recuperar automáticamente.
Conexión del servidor interrumpida	Interrupciones de conexión del servidor con error desconocido, considere, en primer lugar, la posibilidad de solucionar el problema con el registro del lado servicio, servidor o cliente. Intente excluir los problemas básicos (por ejemplo, problemas de red, del servidor de aplicaciones, etc.). Si el problema no se soluciona, póngase en contacto con nosotros para obtener más ayuda. Para más información, consulte Obtenga ayuda.

Crecimiento de conexiones inesperado

Para solucionar los problemas relacionados con un crecimiento de conexiones inesperado, lo primero que debe hacer es filtrar las conexiones adicionales. Puede agregar un identificador único de usuario de prueba a la conexión del cliente de prueba. Compruebe los registros de recursos. Si ve que hay más de una conexión de cliente con el mismo identificador de usuario o IP de prueba, es probable que el lado cliente esté creando más conexiones de las esperadas. Compruebe el lado cliente.

Error de autorización

Si recibe un mensaje 401 No autorizado para las solicitudes de cliente, compruebe los registros de recursos. Si encuentra Failed to validate audience. Expected Audiences: <valid audience>. Actual Audiences: <actual audience>, significa que no hay ninguna audiencia del token de acceso válida. Intente usar las audiencias válidas sugeridas en el registro.

Limitaciones

Si no puede establecer conexiones de cliente de SignalR con Azure SignalR Service, compruebe los registros de recursos. Si encuentra Connection count reaches limit en el registro de recursos, establece demasiadas conexiones con SignalR Service, lo que provoca que se alcance el límite del número de conexiones. Considere la posibilidad de escalar SignalR Service. Si encuentra Message count reaches limit en el registro de recursos, significa que utiliza el nivel gratuito y ha llegado al máximo de la cuota de mensajes. Si desea enviar más mensajes, considere la posibilidad de cambiar SignalR Service al nivel estándar. Para más información, consulte Precios de Azure SignalR Service.

Problemas relacionados con mensajes

Ante problemas relacionados con mensajes, puede aprovechar los registros de mensajería para solucionarlo. En primer lugar, habilite los registros de recursos en el servicio y los registros para el servidor y el cliente.

Nota:

Para ASP.NET Core, consulte esta página a fin de habilitar el registro en el servidor y el cliente.

Para ASP.NET, consulte esta página a fin de habilitar el registro en el servidor y el cliente.

Si no le importan los posibles efectos en el rendimiento ni ningún mensaje enviado del cliente al servidor, active Messaging en Log Source Settings/Types para habilitar el comportamiento de recopilación de registros Recopilar todo. Para obtener más información sobre este comportamiento, consulte recopilar todo.

De lo contrario, desactive Messaging para habilitar el comportamiento de recopilación de registros Recopilar parcialmente. La habilitación de este comportamiento requiere la configuración en el cliente y el servidor. Para obtener más información, consulte recopilar parcialmente.

Pérdida de mensajes

Ante problemas de pérdida de mensajes, la clave es buscar el lugar donde se pierden los mensajes. Básicamente, al usar Azure SignalR Service, hay tres componentes: el propio servicio SignalR, el servidor y el cliente. Tanto el servidor como el cliente están conectados al servicio SignalR, pero no se conectan entre sí directamente una vez completada la negociación. Por lo tanto, es necesario tener en cuenta dos direcciones para los mensajes y, para cada dirección, hay que tener en cuenta dos rutas de acceso:

• Del cliente al servidor mediante el servicio SignalR
  • Ruta de acceso 1: del cliente al servicio SignalR
  • Ruta de acceso 2: del servicio SignalR al servidor
• Del servidor al cliente mediante el servicio SignalR
  • Ruta de acceso 3: del servidor al servicio SignalR
  • Ruta de acceso 4: del servicio SignalR al cliente

En el caso del comportamiento de recopilación Recopilar todo:

Azure SignalR Service solo realiza un seguimiento de los mensajes en la dirección desde el servidor al cliente mediante el servicio SignalR. El identificador de seguimiento se genera en el servidor. El mensaje lleva el servidor del identificador de seguimiento al servicio SignalR.

Nota:

Si quiere realizar un seguimiento del mensaje y enviar mensajes desde fuera de un centro de conectividad en el servidor de aplicaciones, debe habilitar el comportamiento de recopilación Recopilar todo para recopilar los registros de los mensajes que no se originan en los clientes de diagnóstico. Los clientes de diagnóstico funcionan para los comportamientos de recopilación Recopilar todo y Recopilar parcialmente, pero tiene más prioridad para recopilar registros. Para obtener más información, consulte la sección Cliente de diagnóstico.

Si comprueba el servidor de inicio de sesión y el lado servicio, puede averiguar fácilmente si el mensaje se envía desde el servidor, llega a SignalR Service y sale de este. Básicamente, si comprueba que el mensaje recibido y el enviado coinciden o no se basan en el identificador de seguimiento de mensaje, podrá saber si el problema de pérdida de mensajes se produce en el servidor o en el servicio SignalR en la dirección en cuestión. Para obtener más información, consulte los detalles más abajo.

En el caso del comportamiento de recopilación Recopilar parcialmente:

Una vez que marque el cliente como de diagnóstico, Azure SignalR Service realiza un seguimiento de los mensajes en ambas direcciones.

Si comprueba el servidor de inicio de sesión y el lado servicio, puede averiguar fácilmente si el mensaje pasa el servidor o SignalR Service correctamente. Básicamente, si comprueba que el mensaje recibido y el enviado coinciden o no se basan en el identificador de seguimiento de mensaje, podrá saber si el problema de pérdida de mensajes se produce en el servidor o en el servicio SignalR. Para más información, consulte los siguientes detalles.

Detalles del flujo de mensajes

Para la dirección del cliente al servidor mediante el servidor SignalR, el servicio solo considera la invocación que se origine desde el cliente de diagnóstico, es decir, el mensaje generado directamente en el cliente de diagnóstico o el mensaje de servicio generado debido a la invocación indirecta del cliente de diagnóstico.

El identificador de seguimiento se genera en el servicio SignalR cuando el mensaje llegue al servicio en la ruta de acceso 1. El servicio SignalR genera un registro Received a message <MessageTracingId> from client connection <ConnectionId>. para cada mensaje en el cliente de diagnóstico. Una vez que el mensaje salga de SignalR al servidor, SignalR Service genera un mensaje de registro Sent a message <MessageTracingId> to server connection <ConnectionId> successfully.. Si ve estos dos registros, puede tener la certeza de que el mensaje se enviará a través de SignalR Service.

Nota:

Debido a la limitación de ASP.NET Core SignalR, el mensaje que procede del cliente no contiene ningún identificador de nivel de mensaje, pero ASP.NET SignalR genera un id. de invocación para cada mensaje. Puede usarlo para asignarlo con el identificador de seguimiento.

Después, el mensaje lleva el servidor del identificador de seguimiento en la ruta de acceso 2. El servidor genera un registro Received message <messagetracingId> from client connection <connectionId> cuando llegue el mensaje.

Cuando el mensaje invoca el método del centro de conectividad en el servidor, se genera un nuevo mensaje de servicio con un nuevo identificador de seguimiento. Una vez generado el mensaje de servicio, el servidor genera una plantilla de inicio de sesión Start to broadcast/send message <MessageTracingId> .... El registro real se basa en su escenario. A continuación, el mensaje se entrega al servicio SignalR en ruta de acceso 3. Una vez que el mensaje de servicio sale del servidor, se genera un registro denominado Succeeded to send message <MessageTracingId>.

Nota:

El identificador de seguimiento del mensaje del cliente no se puede asignar al identificador de seguimiento del mensaje de servicio que se enviará al servicio SignalR.

Cuando el mensaje de servicio llegue al servicio SignalR, se genera un registro denominado Received a <MessageType> message <MessageTracingId> from server connection <ConnectionId>.. Después, el servicio SignalR procesa el mensaje de servicio y lo entrega a los clientes de destino. Cuando el mensaje se envíe a los clientes en la ruta de acceso 4, se genera el registro Sent a message <MessageTracingId> to client connection <ConnectionId> successfully..

En resumen, el registro de mensajes se genera cuando el mensaje entre y salga del servicio SignalR y el servidor. Puede usar estos registros para comprobar si el mensaje se pierde en estos componentes o no.

El ejemplo siguiente es un problema típico de pérdida de mensajes.

Un cliente no recibe mensajes en un grupo

El caso típico de este problema es que el cliente se une a un grupo después de enviar un mensaje de grupo.

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

Por ejemplo, alguien puede hacer invocaciones de grupo de unión y enviar un mensaje de grupo en el mismo método de centro de conectividad. El problema aquí es que AddToGroupAsync es un método async. Ya que no hay ningún await de AddToGroupAsync para esperar hasta que finalice, el mensaje de grupo se envía antes de que AddToGroupAsync finalice. Debido al retraso de red y el del proceso de unión del cliente a algún grupo, la acción unión a grupo puede completarse después de la entrega de mensajes de grupo. Si es así, el primer mensaje de grupo no tiene ningún cliente como receptor, ya que ningún cliente se ha unido al grupo, así que se convierte en un problema de mensaje perdido.

Sin registros de recursos, no puede averiguar cuándo se une el cliente al grupo y cuándo se envía el mensaje de grupo. Una vez que habilite los registros de mensajería, podrá comparar la hora de llegada del mensaje en el servicio SignalR. Siga los pasos siguientes para solucionar el problema:

1. Busque los registros de mensajes en el servidor para ver cuándo se unió el cliente al grupo y cuándo se envió el mensaje de grupo.
2. En los registros de mensajes, consulte el identificador de seguimiento de mensajes A de unión al grupo y el identificador de seguimiento de mensajes B del mensaje de grupo.
3. Filtre estos identificadores de seguimiento de mensajes entre los registros de mensajería en el archivo de registro de destino y, después, compare sus marcas de tiempo de llegada. Encuentre el mensaje que llegó primero en el servicio SignalR.
4. Si la hora de llegada A del identificador de seguimiento de mensajes es posterior a la hora de llegada B, debe enviar el mensaje de grupo antes del cliente que se une al grupo. Debe asegurarse de que el cliente está en el grupo antes de enviar mensajes de grupo.

Si se pierde un mensaje en SignalR o en el servidor, intente obtener los registros de advertencia para el identificador de seguimiento de mensajes a fin de conocer el motivo. Si necesita más ayuda, consulte la sección Obtener ayuda.

Comportamientos de recopilación de los registros de recursos

Hay dos escenarios de uso típicos para los registros de recursos, especialmente si se trata de registros de mensajería.

Alguien puede preocuparse por la calidad de los mensajes. Por ejemplo, le importa si el mensaje se envió o recibió correctamente, o quiere registrar todos y cada uno de los mensajes que se entregan mediante el servicio SignalR.

Mientras tanto, otros pueden preocuparse por el rendimiento. Les importa la latencia del mensaje y, a veces, necesitan hacer un seguimiento del mensaje en algunas conexiones en lugar de todas por algún motivo.

Por lo tanto, el servicio SignalR proporciona dos comportamientos de recopilación.

• Recopilar todo: se recopilan registros en todas las conexiones.
• Recolectar parcialmente: se recopilan registros en determinadas conexiones.

Nota:

Para distinguir las conexiones entre los registros de recopilación y los que no recopilan registros, el servicio SignalR trata a algunos clientes como de diagnóstico en función de las configuraciones de cliente de diagnóstico del servidor y el cliente, en los que los registros de recursos siempre se recopilan, mientras que los demás no. Para obtener más información, consulte la sección Recopilar parcialmente.

Recopilar todo

Los registros de recursos se recopilan mediante todas las conexiones. Tome los registros de mensajería como ejemplo. Cuando este comportamiento está habilitado, el servicio SignalR envía una notificación al servidor para empezar a generar el identificador de seguimiento de cada mensaje. El identificador de seguimiento se lleva en el mensaje al servicio. El servicio también registra el mensaje con el identificador de seguimiento.

Nota:

Tenga en cuenta que, para garantizar el rendimiento del servicio SignalR, este no espera y analiza todo el mensaje enviado desde el cliente. Por lo tanto, los mensajes del cliente no se registran. Si el cliente está marcado como cliente de diagnóstico, se registra en el servicio SignalR.

Guía de configuración

Para habilitar este comportamiento, active la casilla de la sección Tipos de Valores de origen del registro.

Este comportamiento no requiere que actualice las configuraciones del lado servidor. Este cambio de configuración siempre se envía automáticamente al servidor.

Recopilar parcialmente

Los registros de recursos solo los recopilan los clientes de diagnóstico. Todos los mensajes se registran, incluidos los mensajes de cliente y los eventos de conectividad de los clientes de diagnóstico.

Nota:

El límite de clientes de diagnóstico es 100. Si el número de clientes de diagnóstico supera los 100, el servicio SignalR regula los clientes de diagnóstico sobrantes. Los clientes nuevos pero sobrepasados en número no se pueden conectar al servicio SignalR e inician System.Net.Http.HttpRequestException, que tiene el mensaje Response status code does not indicate success: 429 (Too Many Requests). Los clientes ya conectados trabajan sin verse afectados por la directiva de limitación.

Cliente de diagnóstico

El cliente de diagnóstico es un concepto lógico. Cualquier cliente puede ser un cliente de diagnóstico. El servidor controla qué cliente puede ser un cliente de diagnóstico. Una vez que un cliente se marca como de diagnóstico, todos los registros de recursos se habilitan en él. Para establecer que un cliente sea de diagnóstico, consulte la guía de configuración.

Guía de configuración

Para habilitar este comportamiento, debe configurar los lados servicio, servidor y cliente.

Lado servicio

Para habilitar este comportamiento, desactive la casilla de un tipo de registro específico en la sección Tipos de Valores de origen del registro.

En el servidor

Configure también ServiceOptions.DiagnosticClientFilter para definir un filtro de clientes de diagnóstico en función del contexto HTTP procedente de clientes. Por ejemplo, asigne al cliente la dirección URL del centro de conectividad <HUB_URL>?diag=yes y configure ServiceOptions.DiagnosticClientFilter para filtrar el cliente de diagnóstico. Si devuelve true, el cliente se marca como cliente de diagnóstico. De lo contrario, permanece como cliente normal. En el ejemplo siguiente se muestra cómo usar el ServiceOptions.DiagnosticClientFilter en la clase de inicio.

Las cadenas de conexión sin procesar solo aparecen en este artículo con fines de demostración. En entornos de producción, proteja siempre las claves de acceso. Use Azure Key Vault para administrar y rotar las claves de forma segura y proteger la cadena de conexión mediante Microsoft Entra ID y Autorizar el acceso con Microsoft Entra ID.

// 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();
}

En el cliente

Marque el cliente como de diagnóstico configurando el contexto HTTP. Por ejemplo, el cliente se marca como de diagnóstico agregando la cadena de consulta diag=yes.

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

Obtener ayuda

Se recomienda que solucione primero los problemas por sí mismo. La mayoría de los problemas se deben a problemas de red o del servidor de aplicaciones. Siga la guía de solución de problemas con el registro de recursos y la guía básica de solución de problemas para detectar la causa principal. Si el problema sigue sin resolverse, considere la posibilidad de abrir una incidencia en GitHub o crear un vale en Azure Portal. Proporcionar:

1. Intervalo de tiempo de 30 minutos en el que se produce el problema
2. Identificador de recurso de Azure SignalR Service
3. Detalles del problema, de la forma más específica posible: por ejemplo, AppServer no envía mensajes, interrupciones de las conexiones del cliente, etc.
4. Registros recopilados del lado servidor o cliente y otros materiales que pueden ser útiles
5. [Opcional] Código de reproducción

Nota:

Si abre una incidencia en GitHub, mantenga la información confidencial (por ejemplo, el identificador de recurso y los registros de servidor o cliente) privada y envíesela. Enviar solo a los miembros de la organización de Microsoft de forma privada.