Utiliser les journaux de ressources pour surveiller SignalR Service

Cet article explique comment utiliser les fonctionnalités d’Azure Monitor pour analyser et dépanner les données de surveillance des journaux de ressources générées par Azure SignalR.

La page Vue d’ensemble du portail Azure pour chaque service Azure SignalR inclut une brève vue de l’utilisation des ressources, comme les connexions simultanées et le nombre de messages. Ces informations utiles ne sont qu’un exemple des nombreuses données de surveillance disponibles dans le portail. Certaines de ces données sont collectées automatiquement et peuvent être analysées dès que vous créez la ressource.

Vous pouvez activer d’autres types de collecte de données avec une certaine configuration. Cet article décrit la configuration de la collecte des données de journal et l’analyse et la résolution des problèmes de ces données à l’aide des outils Azure Monitor.

• Pour plus d’informations sur la surveillance d’Azure SignalR Service, consultez Surveiller Azure SignalR Service.
• Pour obtenir une liste détaillée des métriques et des journaux collectés pour Azure SignalR Service, consultez informations de référence sur les données de surveillance d’Azure SignalR Service.

Important

Des chaînes de connexion brutes sont utilisées dans cet article uniquement à des fins de démonstration.

Une chaîne de connexion contient les informations d’autorisation requises pour que votre application accède au service Azure Web PubSub. La clé d’accès à l’intérieur dans la chaîne de connexion est semblable à un mot de passe racine pour votre service. Dans les environnements de production, protégez toujours vos clés d’accès. Utilisez Azure Key Vault pour gérer et permuter vos clés de façon sécurisée, et sécurisez votre chaîne de connexion en utilisant Microsoft Entra ID.

Évitez de distribuer des clés d’accès à d’autres utilisateurs, de les coder en dur ou de les enregistrer en texte brut dans un emplacement accessible à d’autres personnes. Effectuez une rotation de vos clés si vous pensez qu’elles ont pu être compromises.

Prérequis

Pour activer les journaux de ressources, vous devez configurer un emplacement pour stocker vos données de journal, telles que Stockage Azure ou Log Analytics.

• Le Stockage Azure conserve les journaux de ressources pour l’audit de stratégie, l’analyse statique ou la sauvegarde.
• Log Analytics est un outil analytique et de recherche dans les journaux flexible qui permet d’analyser les journaux bruts générés par une ressource Azure.

Activer les journaux de ressources

Azure SignalR Service prend en charge les journaux de connectivité, les journaux de messagerie et les journaux de requête Http. Pour plus d’informations sur ces types de journaux, consultez Catégories de journaux de ressources. Les journaux sont stockés dans le compte de stockage configuré dans le volet Journaux de diagnostic. Pour plus d’informations sur le format de stockage et les champs, consultez Stockage de données.

Créer des paramètres de diagnostic

Les journaux de ressources sont désactivés par défaut. Pour activer les journaux de ressources à l’aide des paramètres de diagnostic, consultez Créer des paramètres de diagnostic dans Azure Monitor.

Interroger les journaux de ressources

Pour interroger les journaux de ressources, procédez de la manière suivante :

1. Sélectionnez Journaux dans votre espace de travail Log Analytics cible.

   

2. Entrez SignalRServiceDiagnosticLogs et sélectionnez un intervalle de temps. Pour une requête avancée, voir Bien démarrer avec Log Analytics dans Azure Monitor

   

Pour utiliser des exemples de requêtes pour Azure SignalR Service, procédez de la manière suivante :

1. Sélectionnez Journaux dans votre espace de travail Log Analytics cible.

2. Sélectionnez l’onglet Requêtes pour ouvrir l’explorateur de requêtes.

3. Sélectionnez Type de ressource pour regrouper des exemples de requêtes dans le type de ressource.

4. Sélectionnez Exécuter pour exécuter le script.

   

Pour obtenir des exemples de requêtes pour Azure SignalR Service, consultez Requêtes pour la table SignalRServiceDiagnosticLogs.

Remarque

Les noms de champs de requête pour les destinations Stockage diffèrent légèrement des noms de champs pour Log Analytics. Pour plus d’informations sur les mappages de noms de champs entre les tables Storage et Log Analytics, consultez Mappage de table de journal des ressources.

Résolution des problèmes à l’aide des journaux de ressources

Pour résoudre des problèmes liés à Azure SignalR Service, vous pouvez activer les journaux côté serveur ou client pour capturer les défaillances. Quand Azure SignalR Service expose les journaux de ressources, exploitez ces journaux pour résoudre les problèmes liés aux journaux d’activité du service.

Problèmes liés à la connexion

Lorsque vos connexions augmentent ou diminues de manière inattendue, exploitez les journaux de connectivité pour résoudre les problèmes. Les problèmes classiques impliquent souvent des modifications inattendues de quantité de connexion, des connexions qui atteignent les limites de connexions et des échecs d’autorisations. Les sections suivantes décrivent comment résoudre les problèmes.

Abandon de connexion inattendu

Si vous rencontrez un abandon de connexion inattendu, commencez par activer les journaux des côtés service, serveur et client.

Si une connexion est perdue, les journaux de ressources enregistrent cet événement de déconnexion et ConnectionAborted ou ConnectionEnded apparaît dans operationName.

La différence entre ConnectionAborted et ConnectionEnded est que ConnectionEnded est une déconnexion attendue déclenchée par le côté client ou serveur. ConnectionAborted est généralement un événement d’abandon de connexion inattendu, dont le motif est fourni dans message.

Le tableau suivant répertorie les raisons d’abandon.

Motif	Description
Le nombre de connexions atteint la limite	Le nombre de connexions atteint la limite de votre niveau tarifaire actuel. Envisagez une montée en puissance de l’unité de service
Le serveur d’applications a fermé la connexion	Le serveur d’applications déclenche l’abandon. Celui-ci peut être considéré comme un abandon attendu
Expiration de test ping de connexion	Généralement, cela est causé par un problème réseau. Songez à vérifier la disponibilité de votre serveur d’applications à partir d’Internet
Rechargement du service, tentative de reconnexion	Azure SignalR Service est en cours de rechargement. Azure SignalR prend en charge la reconnexion automatique. Vous pouvez attendre la reconnexion ou vous reconnecter manuellement à Azure SignalR Service
Erreur temporaire de serveur interne	Une erreur temporaire se produit dans Azure SignalR Service, qui doit être récupérée automatiquement
Connexion au serveur abandonnée	La connexion au serveur est abandonnée en raison d’une erreur inconnue. Envisagez de résoudre automatiquement le problème avec le journal côté service/serveur/client. Essayez d’exclure les problèmes de base (par exemple, problème de réseau, problème côté serveur d’applications, etc.). Si le problème n’est pas résolu, contactez-nous pour obtenir une aide supplémentaire. Pour plus d’informations, voir la section Obtenir de l’aide.

Croissance inattendue des connexions

Pour résoudre les problèmes de croissance inattendue des connexions, la première chose à faire est de filtrer les connexions supplémentaires. Vous pouvez ajouter un ID d’utilisateur de test unique à votre connexion de client de test. Vérifiez les journaux de la ressource. Si vous constatez que plusieurs connexions clientes ont le même ID d’utilisateur de test ou la même adresse IP, il est probable que le côté client crée plus de connexions que prévu. Vérifiez votre côté client.

Échec de l’autorisation

Si l’erreur 401 Non autorisé est retournée pour des demandes de clients, vérifiez vos journaux de ressources. Si vous rencontrez l’erreur Failed to validate audience. Expected Audiences: <valid audience>. Actual Audiences: <actual audience>, cela signifie qu’aucune des audiences dans votre jeton d’accès n’est valide. Essayez d’utiliser les audiences valides suggérées dans le journal.

Limitation

Si vous constatez que vous ne pouvez pas établir de connexions de client SignalR à Azure SignalR Service, vérifiez vos journaux de ressources. Si vous rencontrez Connection count reaches limit dans le journal de ressources, cela signifie que vous établissez un trop grand nombre de connexions à Azure SignalR Service, et que la limite du nombre de connexions est atteinte. Envisagez une montée en puissance de votre Azure SignalR Service. Si vous rencontrez Message count reaches limit dans le journal de ressources, cela signifie que vous utilisez le niveau gratuit et que le quota de messages est épuisé. Si vous souhaitez envoyer davantage de messages, envisagez de remplacer votre SignalR Service par le niveau standard. Pour plus d’informations, consultez Tarification d’Azure SignalR Service.

Problèmes liés aux messages

Lorsque vous rencontrez des problèmes liés au message, exploitez les journaux de messagerie pour les résoudre. Tout d’abord, activez les journaux de ressources dans le service et les journaux pour le serveur et le client.

Remarque

Pour ASP.NET Core, consultez cette page pour activer la journalisation dans le serveur et le client.

Pour ASP.NET, consultez cette page pour activer la journalisation dans le serveur et le client.

Si l’impact potentiel sur le niveau de performance et l’absence de message de direction du client au serveur ne vous dérangent pas, Vérifiez Messaging dans Log Source Settings/Types pour activer le comportement de collecte des journaux Collecter tout. Pour plus d’informations sur ce comportement, consultez Collecter tout.

Sinon, décochez Messaging pour activer le comportement des journaux Collecter partiellement. Ce comportement nécessite une configuration dans le client et le serveur pour être activé. Pour plus d’informations, consultez Collecter partiellement.

Perte de message

Si vous rencontrez des problèmes de perte de message, la solution consiste à localiser l’emplacement où vous perdez le message. En fait, vous avez trois composants lors de l’utilisation d’Azure SignalR Service : le service SignalR, le serveur et le client. Le serveur et le client sont tous les deux connectés au service SignalR, mais ne se connectent pas directement l’un à l’autre une fois la négociation terminée. Par conséquent, vous devez prendre en compte deux directions pour les messages, et pour chaque direction, vous devez prendre en compte deux chemins :

• Du client au serveur via le service SignalR
  • Chemin 1 : Du client au service SignalR
  • Chemin 2 : Du service SignalR au serveur
• Du serveur au client via le service SignalR
  • Chemin 3 : Du serveur au service SignalR
  • Chemin 4 : Du service SignalR au client

Pour le comportement de collecte Collecter tout :

Azure SignalR Service suit uniquement les messages dont la direction est du serveur au client via le service SignalR. L’ID de suivi est généré dans le serveur. Le message porte l’ID de suivi vers le service SignalR.

Remarque

Si vous souhaitez suivre un message et envoyer des messages à partir de l’extérieur d’un hub dans votre serveur d’applications, vous devez activer le comportement de collecte Collecter tout pour collecter les journaux des messages pour les messages qui ne proviennent pas de clients de diagnostic. Les clients de diagnostic fonctionnent pour les deux comportements de collecte Collecter tout et Collecter partiellement, mais ont une priorité plus élevée pour collecter les journaux. Pour plus d’informations, consultez la section Client de diagnostic.

En vérifiant le côté serveur et service de connexion, vous pouvez facilement déterminer si le message est envoyé à partir du serveur, s’il arrive au service SignalR et s’il quitte le service SignalR. En fait, en vérifiant si les messages reçus et envoyés sont mis en correspondance, ou non, en fonction de l’ID de suivi des messages, vous pouvez indiquer si le problème de perte de message se trouve dans le serveur ou dans le service SignalR dans cette direction. Pour plus d’informations, consultez les détails ci-dessous.

Pour le comportement de collecte Collecter partiellement :

Une fois que vous avez marqué le client comme client de diagnostic, Azure SignalR Service trace les messages dans les deux directions.

En vérifiant le côté serveur et service de connexion, vous pouvez facilement déterminer si le message est correctement transmis au serveur ou au service SignalR. En fait, en vérifiant si les messages reçus et envoyés sont mis en correspondance, ou non, en fonction de l’ID de suivi des messages, vous pouvez indiquer si le problème de perte de message se trouve dans le serveur ou dans le service SignalR. Pour plus d’informations, consultez les détails suivants :

Détails du flux de messages

Pour la direction du client vers le serveur via le service SignalR, le service SignalR tient uniquement en compte l’appel provenant du client de diagnostic, autrement dit, le message généré directement dans le client de diagnostic ou le message de service généré en raison de l’appel indirect du client de diagnostic.

L’ID de suivi est généré dans le service SignalR une fois que le message y arrive dans Chemin 1. Le service SignalR génère un journal Received a message <MessageTracingId> from client connection <ConnectionId>. pour chaque message dans le client de diagnostic. Une fois que le message quitte SignalR pour le serveur, le service SignalR génère un message de journal Sent a message <MessageTracingId> to server connection <ConnectionId> successfully.. Si ces deux journaux sont visibles, vous pouvez être certain que le message a correctement été transmis par le service SignalR.

Remarque

En raison de la limitation de SignalR ASP.NET Core, le message provient du client qui ne contient aucun ID de niveau message, mais SignalR ASP.NET génère l’ID d’appel pour chaque message. Vous pouvez l’utiliser pour mapper avec l’ID de suivi.

Ensuite, le message porte l’ID de suivi du serveur dans le Chemin 2. Le serveur génère un journal Received message <messagetracingId> from client connection <connectionId> une fois le message arrivé.

Une fois que le message appelle la méthode de hub dans le serveur, un nouveau message de service est généré avec un nouvel ID de suivi. Une fois le message de service généré, le serveur génère un modèle de connexion Start to broadcast/send message <MessageTracingId> .... Le journal réel est basé sur votre scénario. Le message est ensuite remis au service SignalR dans Chemin 3. Une fois que le message de service quitte le serveur, un journal appelé Succeeded to send message <MessageTracingId> est généré.

Remarque

L’ID de suivi du message en provenance du client ne peut pas être mappé à l’ID de suivi du message de service à envoyer au service SignalR.

Une fois que le message de service arrive au service SignalR, un journal appelé Received a <MessageType> message <MessageTracingId> from server connection <ConnectionId>. est généré. Le service SignalR traite ensuite le message de service et le transmet au(x) client(s) cible(s). Une fois que le message est envoyé au(x) client(s) dans le Chemin 4, le journal Sent a message <MessageTracingId> to client connection <ConnectionId> successfully. est généré.

En résumé, le journal des messages est généré lorsque le message arrive au service SignalR et au serveur, et qu’il les quitte. Vous pouvez utiliser ces journaux pour vérifier si le message est, ou non, perdu dans ces composants.

L’exemple suivant est un problème de perte de message classique.

Un client ne parvient pas à recevoir des messages dans un groupe

L’histoire classique de ce problème est que le client rejoint un groupe après avoir envoyé un message de groupe.

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
    }
}

Par exemple, une personne peut effectuer des appels d’un groupe de jointures et envoyer un message de groupe dans la même méthode de hub. Le problème est que AddToGroupAsync est une méthode async. Puisqu’il n’y a pas await pour que AddToGroupAsync attende qu’il se termine, le message de groupe est envoyé avant la fin de AddToGroupAsync. En raison d’un délai réseau et du délai du processus de jointure du client à un groupe, la fin de l’action de rejoindre un groupe peut être ultérieure à la remise des messages de groupe. Dans ce cas, le premier message de groupe n’a pas de client en tant que récepteur, car aucun client n’a rejoint le groupe. Ainsi, cela devient un problème perdu.

Sans journaux de ressources, vous ne pouvez pas savoir quand le client rejoint le groupe et quand le message de groupe est envoyé. Une fois que vous activez les journaux de messagerie, vous pouvez comparer l’heure d’arrivée du message dans le service SignalR. Effectuez les étapes suivantes pour résoudre le problème :

1. Recherchez les journaux des messages sur le serveur pour déterminer quand le client a rejoint le groupe et quand le message de groupe est envoyé.
2. Obtenez l’ID de suivi du message A de jonction au groupe et l’ID de suivi de message B du message de groupe à partir des journaux des messages.
3. Filtrez ces ID de suivi des messages entre les journaux de messagerie dans votre cible d’archivage des journaux, puis comparez l’horodatage de leur arrivée. Vous trouverez le message arrivé en premier dans le service SignalR.
4. Si l’heure d’arrivée de l’ID de suivi des messages A est postérieure à l’heure d’arrivée de B, vous devez envoyer un message de groupe avant le client qui rejoint le groupe. Vous devez vous assurer que le client se trouve dans le groupe avant d’envoyer des messages de groupe.

Si un message est perdu dans SignalR ou le serveur, essayez d’obtenir les journaux d’avertissement en fonction de l’ID de suivi des messages pour en obtenir la raison. Si vous avez besoin d’aide supplémentaire, consultez la section Obtenir de l’aide.

Comportements de collecte des journaux de ressources

Il existe deux scénarios classiques pour l’utilisation des journaux de ressources, en particulier pour les journaux de messagerie.

Un utilisateur peut s’occuper de la qualité de chaque message. Par exemple, quelqu’un qui soit sensibilisé au fait que le message a été correctement envoyé/reçu, ou qui veuille enregistrer chaque message qui est remis via le service SignalR.

En parallèle, d’autres peuvent se préoccuper des performances. Ils se soucient de la latence du message, et parfois, ils doivent, pour une raison ou pour une autre, suivre le message dans quelques connexions plutôt que dans toutes les connexions.

Par conséquent, le service SignalR fournit deux types de comportements de collecte

• Collecter tout : collecter des journaux dans toutes les connexions
• Collecter partiellement : collecter des journaux dans certaines connexions spécifiques

Remarque

Pour distinguer les connexions entre ces journaux de collecte et celles qui ne collectent pas de journaux, le service SignalR traite un client comme client de diagnostic en fonction des configurations de client de diagnostic du serveur et du client, dans lesquelles les journaux de ressources sont toujours collectés, tandis que les autres ne le sont pas. Pour plus d’informations, consultez la section Collecter partiellement.

Collecter tout

Les journaux de ressources sont collectés par toutes les connexions. Prenez les journaux de messagerie, par exemple. Lorsque ce comportement est activé, le service SignalR envoie une notification au serveur pour commencer à générer l’ID de suivi de chaque message. L’ID de suivi est transféré dans le message au service. Le service enregistre également le message avec l’ID de suivi.

Remarque

Notez que pour assurer ses performances, le service SignalR n’attend pas et analyse l’ensemble du message envoyé à partir du client. Par conséquent, les messages du client ne sont pas journalisés. Si le client est marqué comme client de diagnostic, le message du client est consigné dans le service SignalR.

Guide de configuration

Pour activer ce comportement, cochez la case dans la section Types des Paramètres de source des journaux.

Ce comportement ne vous oblige pas à mettre à jour les configurations côté serveur. Cette modification de configuration est toujours automatiquement envoyée au serveur.

Collecter partiellement

Les journaux de ressources sont collectés uniquement par les clients de diagnostic. Tous les messages sont consignés, y compris les messages du client et les événements de connectivité dans les clients de diagnostic.

Remarque

La limite du nombre de clients de diagnostic est 100. Si le nombre de clients de diagnostic dépasse 100, les clients de diagnostic en surnombre sont limités par le service SignalR. Les clients nouveaux mais en surnombre ne parviennent pas à se connecter au service SignalR et lèvent System.Net.Http.HttpRequestException, qui a le message Response status code does not indicate success: 429 (Too Many Requests). Les clients déjà connectés fonctionnent sans être affectés par la stratégie de limitation.

Client de diagnostic

Le client de diagnostic est un concept logique. Tout client peut être un client de diagnostic. Le serveur contrôle quel client peut être client de diagnostic. Une fois qu’un client est marqué comme client de diagnostic, tous les journaux de ressources sont activés dans ce client. Pour définir un client comme client de diagnostic, consultez le guide de configuration.

Guide de configuration

Pour activer ce comportement, vous devez effectuer une configuration côté service, serveur et client.

Côté service

Pour activer ce comportement, décochez la case d’un type de journal spécifique dans la section Types des Paramètres de source des journaux.

Côté serveur

Configurez également ServiceOptions.DiagnosticClientFilter pour définir un filtre de clients de diagnostic en fonction du contexte HTTP à partir des clients. Par exemple, définissez un client avec l’URL du hub <HUB_URL>?diag=yes, puis configurez ServiceOptions.DiagnosticClientFilter pour filtrer le client de diagnostic. S’il retourne true, le client est marqué comme client de diagnostic. Sinon, il reste un client normal. L’exemple suivant montre comment utiliser le ServiceOptions.DiagnosticClientFilter dans votre classe de démarrage.

Des chaînes de connexion brutes sont utilisées dans cet article uniquement à des fins de démonstration. Dans les environnements de production, protégez toujours vos clés d’accès. Utilisez Azure Key Vault pour gérer et permuter vos clés de façon sécurisée, et sécurisez votre chaîne de connexion en utilisant 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();
}

Côté client

Marquez le client comme client de diagnostic en configurant le contexte HTTP. Par exemple, le client est marqué comme client de diagnostic en ajoutant la chaîne de requête diag=yes.

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

Obtenir de l’aide

Nous vous recommandons de commencer par tenter de résoudre les problèmes par vous-même. La plupart des problèmes sont dus à des problèmes de serveur d’applications ou de réseau. Suivez le guide de résolution des problèmes avec le journal de ressources et le guide de résolution des problèmes de base pour trouver la cause racine. Si vous ne parvenez toujours pas à résoudre le problème, envisagez de signaler un problème dans GitHub ou de créer un ticket dans le portail Azure. Fournisseur :

1. Intervalle de temps d’environ 30 minutes lorsque le problème se produit
2. ID de ressource d’Azure SignalR Service
3. Détails du problème, aussi précis que possible : Par exemple, AppServer n’envoie pas de messages, la connexion du client est interrompue, etc.
4. Journaux collectés du côté serveur/client et autres éléments pouvant être utiles
5. [Facultatif] Code de reproduction

Remarque

Si vous signalez un problème dans GitHub, conservez vos informations sensibles (par exemple, l’ID de ressource, les journaux serveur ou client) privées. Envoyez uniquement aux membres de l’organisation Microsoft en privé.