Partage via

Comment résoudre les problèmes de connectivité et de remise de messages

  • Article

Ce guide présente plusieurs méthodes pour faciliter l’auto-diagnostic afin de trouver la cause racine directement ou de réduire le problème. Le résultat de l’auto-diagnostic est également utile lorsqu’il nous est communiqué pour un examen plus approfondi.

Tout d’abord, vous devez vérifier à partir du portail Azure sur quel ServiceMode Azure SignalR Service (également appelé ASRS) est configuré.

ServiceMode

Deuxièmement, vous devez capturer les traces de service pour résoudre les problèmes. Pour savoir comment capturer des traces, consultez Capture de traces de service.

Vous avez des problèmes ou des commentaires sur la résolution des problèmes ? Faites-le nous savoir.

Comment capturer des traces de service

Pour simplifier le processus de résolution des problèmes, le service Azure SignalR fournit l’outil Live Trace pour exposer les traces de service dans les catégories connectivité et messagerie. Les traces incluent, mais sans s’y limiter, les événements de connexion connecté/déconnecté et les événements de messages reçus/laissés. Avec l’outil Live Trace, vous pouvez capturer, afficher, trier, filtrer et exporter des traces actives. Pour plus d’informations, consultez Comment utiliser l’outil live trace.

Vous avez des problèmes ou des commentaires sur la résolution des problèmes ? Faites-le nous savoir.

Résolution des problèmes en mode par défaut

Quand ASRS est en mode par défaut , il existe trois rôles : client, serveur et service :

  • Client : le client correspond aux clients connectés à ASRS. Les connexions persistantes entre le client et ASRS sont appelées Connexions clientes dans ce guide.

  • Serveur : Serveur désigne le serveur qui sert la négociation du client et héberge la logique Hub de SignalR. Les connexions persistantes entre le serveur et ASRS sont appelées Connexions serveur dans ce guide.

  • Service : le service est le nom court d’ASRS dans cette aide.

Pour une présentation détaillée de l’ensemble de l’architecture et du workflow, reportez-vous à Internals of Azure SignalR Service.

Il existe plusieurs façons de vous aider à cerner le problème.

  • Si le problème surgit dès le début ou s’il est reproductible, la méthode la plus simple consiste à afficher le trafic en cours.

  • Si le problème est difficile à reproduire, les traces et les journaux peuvent vous aider.

Comment afficher le trafic et cerner le problème

La capture du trafic en cours est la manière la plus simple de cerner le problème. Vous pouvez capturer les traces du réseau à l’aide des options décrites ci-dessous :

Requêtes de clients

Pour une connexion persistante SignalR, il faut d’abord négocier (/negotiate) avec votre serveur d’applications hébergé et la rediriger vers Azure SignalR Service, puis établir la connexion persistante réelle à Azure SignalR Service. Reportez-vous à Internals of Azure SignalR Service pour connaître les étapes détaillées.

Avec la trace du réseau côté client en main, vérifiez quelle requête échoue avec quel code d’état et quelle réponse, et cherchez des solutions dans le guide de résolution des problèmes.

Requêtes serveur

Le serveur SignalR maintient la connexion serveur entre le serveur et le service. Lorsque le serveur d’applications démarre, il établit la connexion WebSocket avec Azure SignalR Service. Tous les trafics client sont acheminés via Azure SignalR Service vers ces connexions serveur, puis distribués au Hub. Quand une connexion serveur est interrompue, les clients acheminés vers cette connexion serveur sont affectés. Notre Kit de développement logiciel (SDK) Azure SignalR suit une logique « Toujours réessayer » pour reconnecter la connexion serveur avec un délai d’une minute au maximum pour réduire les effets.

Les connexions serveur peuvent être interrompues en raison de l’instabilité du réseau ou de la maintenance régulière d’Azure SignalR Service, ou encore de la mise à jour/maintenance de votre serveur d’applications hébergé. Tant que le mécanisme de déconnexion/reconnexion opère côté client, les effets sont minimes, comme toute déconnexion/reconnexion intervenant côté client.

Consultez la trace du réseau côté serveur pour connaître le code d’état et les détails de l’erreur pour laquelle la connexion serveur est interrompue ou rejetée par le service. Recherchez la cause racine dans le Guide de résolution des problèmes.

Vous avez des problèmes ou des commentaires sur la résolution des problèmes ? Faites-le nous savoir.

Comment ajouter des journaux

Les journaux peuvent être utiles pour diagnostiquer les problèmes et surveiller l’état d’exécution.

Comment activer le journal côté client

L’expérience de journalisation côté client est exactement la même que lors de l’utilisation de SignalR auto-hébergé.

Activer la journalisation côté client pour ASP.NET Core SignalR
Activer la journalisation côté client pour ASP.NET SignalR

Comment activer le journal côté serveur

Activer la journalisation côté serveur pour ASP.NET Core SignalR

La journalisation côté serveur pour ASP.NET Core SignalR s’intègre à la journalisation basée sur ILogger fournie dans l’infrastructure ASP.NET Core. Vous pouvez activer la journalisation côté serveur à l’aide de ConfigureLogging, un exemple d’utilisation comme suit :

.ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddConsole();
            logging.AddDebug();
        })

Les catégories d’enregistreur d’événements pour Azure SignalR commencent toujours par Microsoft.Azure.SignalR. Pour activer les journaux détaillés d’Azure SignalR, configurez les préfixes précédents sur le niveau Information dans votre fichier appsettings.json comme ci-dessous :

{
    "Logging": {
        "LogLevel": {
            ...
            "Microsoft.Azure.SignalR": "Information",
            ...
        }
    }
}

Vérifiez si des journaux d’avertissements et d’erreurs anormaux sont enregistrés.

Activer les traces côté serveur pour ASP.NET SignalR

En cas d’utilisation d’une version du Kit de développement logiciel (SDK) >= 1.0.0, vous pouvez activer les traces en ajoutant le code suivant au fichier web.config : (Détails).

<system.diagnostics>
    <sources>
      <source name="Microsoft.Azure.SignalR" switchName="SignalRSwitch">
        <listeners>
          <add name="ASRS" />
        </listeners>
      </source>
    </sources>
    <!-- Sets the trace verbosity level -->
    <switches>
      <add name="SignalRSwitch" value="Information" />
    </switches>
    <!-- Specifies the trace writer for output -->
    <sharedListeners>
      <add name="ASRS" type="System.Diagnostics.TextWriterTraceListener" initializeData="asrs.log.txt" />
    </sharedListeners>
    <trace autoflush="true" />
  </system.diagnostics>

Vérifiez si des journaux d’avertissements et d’erreurs anormaux sont enregistrés.

Comment activer les journaux dans Azure SignalR Service

Vous pouvez également activer les journaux de diagnostic pour Azure SignalR Service. Ces journaux fournissent des informations détaillées sur chaque connexion à Azure SignalR Service.

Vous avez des problèmes ou des commentaires sur la résolution des problèmes ? Faites-le nous savoir.

Résolution des problèmes en mode serverless

Quand ASRS est en mode serverless, seul ASP.NET Core SignalR prend en charge le mode Serverless ; ASP.NET SignalR ne prend PAS en charge ce mode.

Pour diagnostiquer les problèmes de connectivité en mode Serverless, la méthode la plus simple consiste à consulter le trafic côté client. Activer les journaux côté clientet les journaux côté service peut également être utile.

Vous avez des problèmes ou des commentaires sur la résolution des problèmes ? Faites-le nous savoir.

Résolution des problèmes en mode classique

ClassicLe mode est obsolète et son utilisation est déconseillée. Dans ce mode classique, Azure SignalR Service utilise les connexions serveur établies pour déterminer si le service actuel est en mode default ou serverless. Le mode classique peut entraîner des problèmes intermédiaires de connectivité client, car, en cas d’interruption soudaine de toutes les connexions serveur, par exemple en raison de l’instabilité du réseau, Azure SignalR considère avoir basculé en mode serverless et les clients connectés pendant cette période ne seront jamais acheminés vers le serveur d’applications hébergé. Activez les journaux côté service, et vérifiez si des clients sont enregistrés en mode ServerlessModeEntered si vous avez un serveur d’applications hébergé, mais que certains clients ne l’atteignent jamais. Si vous voyez l’un de ces clients, abandonnez les connexions client, puis laissez les clients redémarrer.

La résolution des problèmes de connectivité et de remise des messages en mode classic est similaire à la résolution des problèmes en mode par défaut.

Vous avez des problèmes ou des commentaires sur la résolution des problèmes ? Faites-le nous savoir.

Intégrité du service

Vous pouvez vérifier l’API d’intégrité pour connaître l’intégrité du service.

  • Demande : GET https://{instance_name}.service.signalr.net/api/v1/health

  • Code d’état de la réponse :

    • 200 : Sain.
    • 503 : Votre service n’est pas sain. Vous pouvez :
      • Patienter quelques minutes pour la récupération automatique ;
      • Vérifier que l’adresse IP est identique à celle du portail.
      • Redémarrer l’instance.
      • Si aucune des options ci-dessus ne fonctionne, contactez-nous en ajoutant une nouvelle demande de support dans Portail Azure.

En savoir plus sur la récupération d’urgence.

Vous avez des problèmes ou des commentaires sur la résolution des problèmes ? Faites-le nous savoir.

Étapes suivantes

Dans ce guide, vous avez appris à résoudre les problèmes de connectivité et de remise des messages. Vous pouvez également apprendre à gérer les problèmes courants.

Guide de résolution des problèmes