Registros de recursos para Azure SignalR Service

Artículo
06/11/2022
Tiempo de lectura: 22 minutos

En este tutorial se explica qué son los registros de recursos de Azure SignalR Service, cómo se configuran y cómo se solucionan sus problemas.

Requisitos previos

Para habilitar los registros de recursos, necesitará un lugar donde almacenar los datos de registro. En este tutorial se utiliza Azure Storage y Log Analytics.

Azure Storage: conserva los registros de recursos para auditorías de directivas, análisis estáticos o copias de seguridad.
Log Analytics: 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.

Configuración de registros de recursos para Azure SignalR Service

Puede ver registros de recursos para Azure SignalR Service. Estos registros proporcionan una vista más completa de la conectividad con la instancia de Azure SignalR Service. Los registros de recursos proporcionan información detallada de cada conexión. Por ejemplo, información básica (identificador de usuario, identificador de conexión y tipo de transporte, etc.) e información de eventos (evento Connect, Disconnect, Abort, etc.) de la conexión. Los registros de recursos se pueden usar para la identificación de problemas, el seguimiento de la conexión y el análisis.

Habilitación de registros de recursos

Los registros de recursos están inhabilitados de forma predeterminada. Para habilitar los registros de recursos, siga estos pasos:

En Azure Portal, en Supervisión, seleccione Configuración de diagnóstico.
A continuación, obtendrá una vista completa de la configuración de diagnóstico.
Configure los valores de origen del registro.
1. En la sección Valores de origen del registro verá una tabla con los comportamientos de recopilación de cada tipo de registro.
2. Compruebe el tipo de registro específico que quiere recopilar para todas las conexiones. De lo contrario, el registro solo se recopilará para los clientes de diagnóstico.
Configure los valores de destino del registro.
1. En la sección Valores de destino del registro verá una tabla de configuración de diagnóstico con la configuración de diagnóstico existente. Puede seleccionar el vínculo de la tabla para acceder al destino del registro y ver los registros de recursos recopilados.
2. En esta sección, seleccione el botón Configurar valores de destino del registro para agregar, actualizar o eliminar la configuración de diagnóstico.
3. Seleccione Agregar configuración de diagnóstico para agregar una nueva configuración de diagnóstico, o bien seleccione Editar para modificar una configuración de diagnóstico existente.
4. Establezca el destino de archivo que desee. Actualmente, el servicio SignalR admite las opciones Archivar en una cuenta de almacenamiento y Enviar a Log Analytics.
5. Seleccione los registros que desea archivar. Solo AllLogs está disponible para el registro de recursos. Solo controla si quiere archivar los registros. Para configurar los tipos de registro que deben generarse en el servicio SignalR, vaya a la sección Valores de origen del registro.
1. Guarde la nueva configuración de diagnóstico. La nueva configuración se aplicará en unos 10 minutos. Después, los registros se enviarán al destino de archivo configurado. Para obtener más información sobre la configuración de valores de destino de registros, consulte la información general sobre los registros de recursos de Azure.

Categorías de registros de recursos

Azure SignalR admite dos tipos de registro: de conectividad y de mensajería.

Registros de conectividad

Los registros de conectividad proporcionan información detallada para las conexiones del centro de conectividad de SignalR. Por ejemplo, información básica (identificador de usuario, identificador de conexión, tipo de transporte, etc.) e información de eventos (evento Connect, Disconnect, Abort, etc.). Por este motivo, un registro de conectividad resulta útil para solucionar problemas de conexión. Para obtener una guía de solución de problemas de conexión típicos, consulte Problemas de conexión.

Registros de mensajería

Los registros de mensajería proporcionan información de seguimiento de los mensajes del centro de conectividad de SignalR recibidos y enviados mediante el servicio SignalR. Por ejemplo, el identificador de seguimiento y el tipo de mensaje del mensaje. El identificador de seguimiento y el tipo de mensaje también se registran en el servidor de aplicaciones. Por lo general, el mensaje se registra cuando llega al servidor o sale de este. Por lo tanto, los registros de mensajería resultan útiles para solucionar problemas relacionados con los mensajes. Para obtener una guía de solución de problemas relacionados con los mensajes típicos, consulte Problemas relacionados con los mensajes.

Nota

Este tipo de registro se genera para cada mensaje. Si los mensajes se envían con frecuencia, los registros de mensajería podrían afectar al rendimiento del servicio SignalR. Sin embargo, puede elegir diferentes comportamientos de recopilación para minimizar el impacto en el rendimiento. Consulte los comportamientos de recopilación de registros de recursos a continuación.

Registros de solicitudes HTTP

Los registros de solicitudes HTTP proporcionan información detallada sobre las solicitudes HTTP que recibe Azure Web PubSub. Por ejemplo, el código de estado y la dirección URL de la solicitud. Un registro de solicitudes HTTP resulta útil para solucionar problemas relacionados con las solicitudes.

Archivar en una cuenta de almacenamiento

Los registros se almacenan en la cuenta de almacenamiento configurada en el panel Registros de diagnóstico. Se crea automáticamente un contenedor denominado insights-logs-alllogs para almacenar los registros de recursos. Dentro del contenedor, los registros se almacenan en el archivo resourceId=/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/XXXX/PROVIDERS/MICROSOFT.SIGNALRSERVICE/SIGNALR/XXX/y=YYYY/m=MM/d=DD/h=HH/m=00/PT1H.json. Básicamente, la ruta de acceso se combina mediante resource ID y Date Time. Los archivos de registro se dividen por hour. Por lo tanto, los minutos siempre son m=00.

Todos los registros se almacenan en el formato de notación de objetos JavaScript (JSON). Cada entrada tiene campos de cadena que usan el formato descrito en las secciones siguientes.

Las cadenas JSON de registros de archivo incluyen elementos enumerados en las tablas siguientes:

Formato

Nombre	Descripción
time	Hora del evento de registro
level	Nivel del evento de registro
resourceId	Identificador de recurso de Azure SignalR Service
ubicación	Ubicación de Azure SignalR Service
category	Categoría del evento de registro
operationName	Nombre de operación del evento
callerIpAddress	Dirección IP del servidor o cliente
properties	Propiedades detalladas relacionadas con este evento de registro. Para más información, consulte la siguiente tabla de propiedades.

Propiedades de tabla

Nombre	Descripción
type	Tipo del evento de registro. Actualmente, se proporciona información sobre la conectividad con Azure SignalR Service. Solo está disponible el tipo `ConnectivityLogs`.
collection	Colección del evento de registro. Los valores permitidos son: `Connection`, `Authorization` y `Throttling`
connectionId	Identidad de la conexión
transportType	Tipo de transporte de la conexión. Los valores permitidos son: `Websockets` \| `ServerSentEvents` \| `LongPolling`
connectionType	Tipo de la conexión. Los valores permitidos son: `Server` \| `Client` `Server`: conexión desde el lado servidor; `Client`: conexión desde el lado cliente.
userId	Identidad del usuario
message	Mensaje detallado del evento de registro

El código siguiente es un ejemplo de una cadena JSON de registro de archivo:

{
    "properties": {
        "message": "Entered Serverless mode.",
        "type": "ConnectivityLogs",
        "collection": "Connection",
        "connectionId": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "userId": "User",
        "transportType": "WebSockets",
        "connectionType": "Client"
    },
    "operationName": "ServerlessModeEntered",
    "category": "AllLogs",
    "level": "Informational",
    "callerIpAddress": "xxx.xxx.xxx.xxx",
    "time": "2019-01-01T00:00:00Z",
    "resourceId": "/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/XXXX/PROVIDERS/MICROSOFT.SIGNALRSERVICE/SIGNALR/XXX",
    "location": "xxxx"
}

Esquema de registros de archivo para Log Analytics

Para ver los registros de recursos, siga estos pasos:

Seleccione Logs en la instancia de Log Analytics de destino.
Escriba SignalRServiceDiagnosticLogs y seleccione el intervalo de tiempo para consultar los registros de recursos. Para una consulta avanzada, consulte Introducción a los análisis de registros de Azure Monitor.

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

Seleccione Logs en la instancia de Log Analytics de destino.
Seleccione Queries para abrir el explorador de consultas.
Seleccione Resource type para agrupar consultas de ejemplo en el tipo de recurso.
Seleccione Run para ejecutar el script.

Las columnas de registros de archivo incluyen elementos enumerados en la tabla siguiente:

Nombre	Descripción
TimeGenerated	Hora del evento de registro
Colección	Colección del evento de registro. Los valores permitidos son: `Connection`, `Authorization` y `Throttling`
OperationName	Nombre de operación del evento
Location	Ubicación de Azure SignalR Service
Nivel	Nivel del evento de registro
CallerIpAddress	Dirección IP del servidor o cliente
Message	Mensaje detallado del evento de registro
UserId	Identidad del usuario
ConnectionId	Identidad de la conexión
ConnectionType	Tipo de la conexión. Los valores permitidos son: `Server` \| `Client` `Server`: conexión desde el lado servidor; `Client`: conexión desde el lado cliente.
TransportType	Tipo de transporte de la conexión. Los valores permitidos son: `Websockets` \| `ServerSentEvents` \| `LongPolling`

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. Ahora, Azure SignalR Service expone registros de recursos. También puede habilitar registros del lado servicio.

Cuando se encuentra en una situación de crecimiento o interrupción inesperada de la conexión, puede aprovechar los registros de recursos 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. Consulte las secciones siguientes sobre el modo de solucionar problemas.

Ante una situación de crecimiento o interrupción inesperada de la conexión, 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, errores de autorización y pérdidas de mensajes. Consulte las secciones siguientes sobre el modo de solucionar problemas.

Cambios inesperados en el número de conexiones

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 registrarán el evento de desconexión; verá 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. Aunque ConnectionAborted suele ser un evento de interrupción inesperada de la conexión, se proporcionará el motivo de la anulación en message.

Las opciones de la anulación se muestran en la siguiente tabla:

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 de servicios, reconexión	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. Después, compruébelo en 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 cree y establezca 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 enviar mensajes adicionales. Para más información, consulte Precios de Azure SignalR Service.

Ante un problema relacionado con mensajes, puede aprovechar los registros de mensajería para solucionarlo. En primer lugar, habilite los registros de recursos en el servicio, 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 importa el posible impacto 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 la sección 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 la sección Recopilar parcialmente.

Pérdida de mensajes

Ante un problema de pérdida de mensajes, la clave es buscar el lugar donde se pierden los mensajes. Básicamente, al usar el servicio SignalR, hay tres componentes: el propio servicio SignalR, el servidor y el cliente. Tanto el servidor como el cliente están conectados al servicio SignalR, y 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. Además, 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

Message path

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

El servicio SignalR 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 generará en el servidor, y el mensaje llevará el 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. La recopilación de registros tiene la máxima prioridad. 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 al servicio SignalR 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, el servicio SignalR realizará 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 el servicio SignalR 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 obtener más información, consulte los detalles más abajo.

Detalles del flujo de mensajes

Para la dirección del cliente al servidor mediante el servidor SignalR, el servicio solo considerará 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 generará en el servicio SignalR cuando el mensaje llegue al servicio en la ruta de acceso 1. El servicio SignalR generará un registro Received a message <MessageTracingId> from client connection <ConnectionId>. para cada mensaje en el cliente de diagnóstico. Cuando el mensaje salga del servicio SignalR y vaya al servidor, el servicio generará un registro Sent a message <MessageTracingId> to server connection <ConnectionId> successfully.. Si ve estos dos registros, significa que el mensaje pasa correctamente por el servicio SignalR.

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. Sin embargo, ASP.NET SignalR genera el identificador de invocación de cada mensaje; puede usar este identificador para la asignación al identificador de seguimiento.

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

Cuando el mensaje invoque el método del centro de conectividad en el servidor, se generará un nuevo mensaje de servicio con un nuevo identificador de seguimiento. Una vez generado el mensaje de servicio, el servidor generará una plantilla de inicio de sesión Start to broadcast/send message <MessageTracingId> .... El registro real se basará en su escenario. Después, el mensaje se entregará al servicio SignalR en laruta de acceso 3; una vez que el mensaje de servicio salga del servidor, se generará un registro llamado 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 generará 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 generará el registro Sent a message <MessageTracingId> to client connection <ConnectionId> successfully..

En resumen, el registro de mensajes se generará 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.

A continuación, se muestra un problema de pérdida de mensajes típico.

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("ReveiceGroupMessage", 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. No hay ningún await de AddToGroupAsync para esperar a que finalice; el mensaje de grupo enviado 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 tendrá ningún cliente como receptor, ya que ningún cliente se ha unido al grupo. Por lo tanto, se convertirá en un problema de pérdida de mensajes.

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 que se indican a continuación para solucionar los problemas:

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.
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.
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; verá qué mensaje llegó primero al servicio SignalR.
Si el identificador de seguimiento de mensajes A llega más tarde que el B, debe enviar un mensaje de grupo antes de que el cliente se una al grupo. Después, tendrá que 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.

Tema avanzado

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 tratará 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 incluirá en el mensaje al servicio, y el servicio registrará 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. Sin embargo, si el cliente está marcado como cliente de diagnóstico, sí se registrará 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 enviará 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 regulará los clientes de diagnóstico sobrantes. Los clientes nuevos pero sobrantes no se podrán conectar al servicio SignalR, y se producirá System.Net.Http.HttpRequestException con el mensaje Response status code does not indicate success: 429 (Too Many Requests), mientras que los que ya se hayan conectado funcionarán 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 habilitarán en él. Para establecer que un cliente sea de diagnóstico, consulte la guía de configuración siguiente.

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 marcará como de diagnóstico; de lo contrario, se mantendrá como cliente normal. ServiceOptions.DiagnosticClientFilter se puede establecer en la clase de inicio de la siguiente manera:

// 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. Proporcione:

Intervalo de tiempo de 30 minutos en el que se produce el problema
Identificador de recurso de Azure SignalR Service
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.
Registros recopilados del lado servidor o cliente y otros materiales que pueden ser útiles
[Opcional] Código de reproducción

Nota

Si abre la 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 solo a los miembros de la organización de Microsoft de forma privada.

Registros de recursos para Azure SignalR Service

Requisitos previos

Configuración de registros de recursos para Azure SignalR Service

Habilitación de registros de recursos

Categorías de registros de recursos

Registros de conectividad

Registros de mensajería

Registros de solicitudes HTTP

Archivar en una cuenta de almacenamiento

Esquema de registros de archivo para Log Analytics

Solución de problemas con registros de recursos

Problemas relacionados con la conexión

Cambios inesperados en el número de conexiones

Interrupción inesperada de la conexión

Crecimiento de conexiones inesperado

Error de autorización

Limitaciones

Problemas relacionados con mensajes

Pérdida de mensajes

Un cliente no recibe mensajes en un grupo

Tema avanzado

Comportamientos de recopilación de los registros de recursos

Recopilar todo

Guía de configuración

Recopilar parcialmente

Cliente de diagnóstico

Guía de configuración

Lado servicio

En el servidor

En el cliente

Obtener ayuda