Come risolvere 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.
Per
Default
la modalità, fare riferimento alla risoluzione dei problemi della modalità predefinitaPer
Serverless
la modalità, vedere Risoluzione dei problemi relativi alla modalità serverlessPer
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 feedback 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 feedback 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 Connessioni client in questa guida.
Server: il server è l'acronimo del server che gestisce la negoziazione client e ospita la logica SignalR
Hub
. E le connessioni persistenti tra Server e ASRS sono denominate Connessioni 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 la 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 queste connessioniserver e quindi inviati a Hub
. Quando si elimina una connessione server, i client indirizzati a questa connessione server saranno interessati. Azure SignalR SDK ha una logica "Always Retry" per riconnettere la connessione server con un ritardo massimo di 1 minuto per ridurre al minimo gli effetti.
La connessioneserver può 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 la connessione server viene eliminata o rifiutata dal servizio. Cercare la causa radice all'interno della Guida alla risoluzione dei problemi.
Problemi o feedback 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 Information
il livello nel file appsettings.json come indicato 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 feedback 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 feedback 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 le connessioni server connesse 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 tutte le connessioni al server connesso, 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 feedback sulla risoluzione dei problemi? Segnalarli.
Integrità dei servizi
È 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 feedback 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.