Share via


Come risolvere i problemi di connettività e recapito dei messaggi

Queste indicazioni illustrano diversi modi per eseguire la diagnosi automatica per trovare direttamente la causa radice o limitare il problema. Il risultato dell'auto-diagnosi è utile anche quando viene segnalato a microsoft per ulteriori indagini.

In primo luogo, è necessario controllare dal portale di Azure quale ServiceMode è il Servizio Azure SignalR (noto anche come ASRS) configurato.

ServiceMode

  • Per Default la modalità, fare riferimento alla risoluzione dei problemi della modalità predefinita

  • Per Serverless la modalità, vedere Risoluzione dei problemi relativi alla modalità serverless

  • Per Classic la modalità, fare riferimento alla risoluzione dei problemi della modalità classica

In secondo luogo, è necessario acquisire le tracce del servizio per la risoluzione dei problemi. Per informazioni su come acquisire le tracce, vedere Come acquisire le tracce del servizio.

Problemi o commenti sulla risoluzione dei problemi? Segnalarli.

Come acquisire le tracce del servizio

Per semplificare il processo di risoluzione dei problemi, il servizio Azure SignalR offre lo strumento di traccia in tempo reale per esporre le tracce del servizio nelle categorie di connettività e messaggistica . Le tracce includono ma non sono limitate agli eventi connessi/disconnessi e agli eventi ricevuti/sinistro dei messaggi. Con lo strumento di traccia in tempo reale è possibile acquisire, visualizzare, ordinare, filtrare ed esportare tracce in tempo reale. Per altre informazioni, vedere Come usare lo strumento di traccia in tempo reale.

Problemi o commenti sulla risoluzione dei problemi? Segnalarli.

Risoluzione dei problemi relativi alla modalità predefinita

Quando ASRS è in modalità predefinita , sono disponibili tre ruoli: Client, Server e Servizio:

  • Client: il client è l'acronimo dei client connessi ad ASRS. Le connessioni persistenti che connettono client e ASRS sono denominate Connessione client in questa guida.

  • Server: il server è l'acronimo del server che gestisce la negoziazione client e ospita la logica SignalRHub. E le connessioni persistenti tra Server e ASRS sono denominate Connessione server in queste linee guida.

  • Servizio: il servizio è il nome breve per ASRS in questa guida.

Per un'introduzione dettagliata dell'intera architettura e del flusso di lavoro, vedere Internals of Servizio Azure SignalR (Internals of Servizio Azure SignalR for the detailed introduction of the whole architecture and workflow).

Esistono diversi modi per limitare il problema.

  • Se il problema si verifica nel modo o è riprovare, il modo semplice consiste nel visualizzare il traffico in corso.

  • Se il problema è difficile da riprovare, le tracce e i log possono risultare utili.

Come visualizzare il traffico e limitare il problema

L'acquisizione del traffico in corso è il modo più semplice per limitare il problema. È possibile acquisire le tracce di rete usando le opzioni descritte di seguito:

Richieste client

Per una connessione permanente di SignalR, viene prima /negotiate indirizzato al server app ospitato e quindi reindirizzato al servizio Azure SignalR e quindi stabilisce la connessione permanente reale al servizio Azure SignalR. Per informazioni dettagliate, vedere Internals of Servizio Azure SignalR (Internals of Servizio Azure SignalR).

Con la traccia di rete sul lato client in mano, verificare quale richiesta ha esito negativo con il codice di stato e la risposta e cercare soluzioni all'interno della Guida alla risoluzione dei problemi.

Richieste server

Il server SignalR gestisce l'Connessione server tra server e servizio. All'avvio del server app, avvia la connessione WebSocket al servizio Azure SignalR. Tutti i traffici client vengono instradati tramite il servizio Azure SignalR a questi Connessione iondel server e quindi inviati a Hub. Quando un Connessione server viene eliminato, i client indirizzati a questo Connessione server saranno interessati. Azure SignalR SDK ha una logica "Always Retry" per riconnettere il server Connessione ion con un ritardo massimo di 1 minuto per ridurre al minimo gli effetti.

Il server Connessione ionpuò cadere a causa dell'instabilità della rete o della manutenzione regolare di Servizio Azure SignalR o degli aggiornamenti/manutenzione del server app ospitata. Finché il lato client ha il meccanismo di disconnessione/riconnessione, l'effetto è minimo come qualsiasi lato client ha causato la riconnessione.

Visualizzare la traccia di rete lato server per trovare il codice di stato e i dettagli dell'errore per cui il server Connessione ion viene eliminato o rifiutato dal servizio. Cercare la causa radice all'interno della Guida alla risoluzione dei problemi.

Problemi o commenti sulla risoluzione dei problemi? Segnalarli.

Come aggiungere i log

I log possono essere utili per diagnosticare i problemi e monitorare lo stato di esecuzione.

Come abilitare il log lato client

L'esperienza di registrazione lato client è esattamente la stessa di quando si usa SignalR self-hosted.

Abilitare la registrazione lato client per ASP.NET Core SignalR
Abilitare la registrazione lato client per ASP.NET SignalR

Come abilitare il log lato server

Abilitare la registrazione lato server per ASP.NET Core SignalR

Registrazione lato server per ASP.NET Core SignalR l'integrazione con la ILogger registrazione basata fornita nel ASP.NET Core framework. È possibile abilitare la registrazione lato server usando ConfigureLogging, un utilizzo di esempio come indicato di seguito:

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

Le categorie di logger per Azure SignalR iniziano sempre con Microsoft.Azure.SignalR. Per abilitare i log dettagliati da Azure SignalR, configurare i prefissi precedenti per il Information livello nel file appsettings.json , come illustrato di seguito:

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

Controllare se sono presenti log di avviso/errore anomali registrati.

Abilitare le tracce lato server per ASP.NET SignalR

Quando si usa la versione >dell'SDK = 1.0.0, è possibile abilitare le tracce aggiungendo quanto segue a web.config: (Dettagli)

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

Controllare se sono presenti log di avviso/errore anomali registrati.

Come abilitare i log all'interno del servizio Azure SignalR

È anche possibile abilitare i log di diagnostica per il servizio Azure SignalR, che forniscono informazioni dettagliate su ogni connessione connessa al servizio Azure SignalR.

Problemi o commenti sulla risoluzione dei problemi? Segnalarli.

Risoluzione dei problemi relativi alla modalità serverless

Quando ASRS è in modalità serverless , solo ASP.NET Core SignalR supporta Serverless la modalità e ASP.NET SignalRnon supporta questa modalità.

Per diagnosticare i problemi di connettività in Serverless modalità, il modo più semplice consiste nel visualizzare il traffico lato client. Abilitare i log sul lato client e i log lato servizio possono essere utili.

Problemi o commenti sulla risoluzione dei problemi? Segnalarli.

Risoluzione dei problemi della modalità classica

Classic la modalità è obsoleta e non è consigliabile usarla. Quando si usa la modalità classica, il servizio Azure SignalR usa i Connessione server connessi per determinare se il servizio corrente è in default modalità o serverless modalità. La modalità classica può causare problemi di connettività client intermedi perché, quando si verifica un calo improvviso di tutti i Connessione server connessi, ad esempio a causa dell'instabilità della rete, Azure SignalR ritiene che sia ora passato alla serverless modalità e i client connessi durante questo periodo non verranno mai instradati al server app ospitato. Abilitare i log sul lato servizio e verificare se sono presenti client registrati come ServerlessModeEntered se fosse stato ospitato il server app, tuttavia alcuni client non raggiungono mai il lato server dell'app. Se viene visualizzato uno di questi client, interrompere le connessioni client e quindi consentire il riavvio dei client.

La risoluzione dei problemi di classic connettività della modalità e recapito dei messaggi è simile alla risoluzione dei problemi di modalità predefinita.

Problemi o commenti sulla risoluzione dei problemi? Segnalarli.

Service Health

È possibile controllare l'integrità dei servizi nell'API integrità.

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

  • Codice di stato della risposta:

    • 200: sano.
    • 503: il servizio non è integro. È possibile:
      • Attendere alcuni minuti per il salvataggio automatico.
      • Controllare che l'indirizzo IP sia uguale all'indirizzo IP del portale.
      • Oppure riavviare l'istanza.
      • Se tutte le opzioni precedenti non funzionano, contattare Microsoft aggiungendo una nuova richiesta di supporto in portale di Azure.

Altre informazioni sul ripristino di emergenza.

Problemi o commenti sulla risoluzione dei problemi? Segnalarli.

Passaggi successivi

In questa guida si è appreso come risolvere i problemi di connettività e recapito dei messaggi. È anche possibile imparare a gestire i problemi comuni.