Monitorare e risolvere i problemi relativi ai log di Servizio Azure SignalR

Questo articolo descrive come usare le funzionalità di Monitoraggio di Azure per analizzare e risolvere i problemi relativi ai dati di monitoraggio dei log delle risorse generati da Azure SignalR.

La pagina Panoramica nella portale di Azure per ogni Servizio Azure SignalR include una breve visualizzazione dell'utilizzo delle risorse, ad esempio connessioni simultanee e numero di messaggi. Queste informazioni utili sono solo una piccola quantità di dati di monitoraggio disponibili nel portale. Alcuni di questi dati vengono raccolti automaticamente e sono disponibili per l'analisi non appena si crea la risorsa.

È possibile abilitare altri tipi di raccolta dati dopo alcune configurazioni. Questo articolo illustra come configurare la raccolta dei dati di log e l'analisi e la risoluzione dei problemi di questi dati usando gli strumenti di Monitoraggio di Azure.

• Per altre informazioni sul monitoraggio Servizio Azure SignalR, vedere Monitorare Servizio Azure SignalR.
• Per un elenco dettagliato delle metriche e dei log raccolti per Servizio Azure SignalR, vedere Servizio Azure SignalR informazioni di riferimento sui dati di monitoraggio.

Prerequisiti

Per abilitare i log delle risorse, è necessario configurare una posizione in cui archiviare i dati di log, ad esempio Archiviazione di Azure o Log Analytics.

• Archiviazione di Azure conserva i log delle risorse per il controllo dei criteri, l'analisi statica o il backup.
• Log Analytics è uno strumento flessibile di ricerca e analisi dei log che consente l'analisi dei log non elaborati generati da una risorsa di Azure.

Abilitare i log risorse

Servizio Azure SignalR supporta i log di connettività, i log di messaggistica e i log delle richieste HTTP. Per altre informazioni su questi tipi di log, vedere Categorie di log delle risorse.

I log delle risorse sono disabilitati per impostazione predefinita. Per abilitare i log delle risorse usando le impostazioni di diagnostica, seguire questa procedura:

1. Nella portale di Azure, in Monitoraggio selezionare Impostazioni di diagnostica.

   

   Si ottiene una visualizzazione completa delle impostazioni di diagnostica.

   

2. Configurare le impostazioni dell'origine log.

   1. Nella sezione Origine log Impostazioni una tabella mostra la raccolta dei comportamenti per ogni tipo di log.
   2. Controllare il tipo di log specifico che si vuole raccogliere per tutte le connessioni. In caso contrario, il log viene raccolto solo per i client di diagnostica.

3. Configurare le impostazioni di destinazione del log.

   1. Nella sezione Destinazione log Impostazioni una tabella delle impostazioni di diagnostica visualizza le impostazioni di diagnostica esistenti. È possibile selezionare il collegamento nella tabella per ottenere l'accesso alla destinazione del log per visualizzare i log delle risorse raccolti.
   2. In questa sezione selezionare il pulsante Configura destinazione log Impostazioni per aggiungere, aggiornare o eliminare le impostazioni di diagnostica.
   3. Selezionare Aggiungi impostazione di diagnostica per aggiungere una nuova impostazione di diagnostica o selezionare Modifica per modificare un'impostazione di diagnostica esistente.
   4. Impostare la destinazione di archiviazione desiderata. Attualmente, Servizio Azure SignalR supporta l'archiviazione in un account di archiviazione e Invia a Log Analytics.
   5. Selezionare i log da archiviare. È disponibile solo AllLogs per il log delle risorse. Controlla solo se si desidera archiviare i log. Per configurare i tipi di log da generare in Servizio Azure SignalR, configurare nella sezione Origine log Impostazioni.

   

   6. Salvare la nuova impostazione di diagnostica. La nuova impostazione ha effetto in circa 10 minuti. Successivamente, i log vengono inviati alla destinazione di archiviazione configurata. Per altre informazioni sulla configurazione delle impostazioni di destinazione dei log, vedere la panoramica dei log delle risorse di Azure.

I log vengono archiviati nell'account Archiviazione configurato nel riquadro Log di diagnostica. Per altri dettagli sul formato di archiviazione e i campi, vedere Archiviazione dati.

Eseguire query sui log delle risorse

Per eseguire query sui log delle risorse, seguire questa procedura:

1. Selezionare Log nella destinazione Log Analytics.

   

2. Immettere SignalRServiceDiagnosticLogs e selezionare Intervallo di tempo. Per query avanzate, vedere Introduzione a Log Analytics in Monitoraggio di Azure

   

Per usare query di esempio per Servizio Azure SignalR, seguire questa procedura:

1. Selezionare Log nella destinazione Log Analytics.

2. Selezionare la scheda Query per aprire Esplora query.

3. Selezionare Tipo di risorsa per raggruppare le query di esempio nel tipo di risorsa.

4. Selezionare Esegui per eseguire lo script.

   

Per le query di esempio per Servizio Azure SignalR, vedere Query per la tabella SignalRServiceDiagnosticLogs.

Nota

I nomi dei campi di query per Archiviazione destinazioni differiscono leggermente dai nomi dei campi per Log Analytics. Per informazioni dettagliate sui mapping dei nomi di campo tra Archiviazione e tabelle di Log Analytics, vedere Mapping delle tabelle dei log delle risorse.

Risoluzione dei problemi relativi ai log delle risorse

Per risolvere i problemi Servizio Azure SignalR, è possibile abilitare i log lato server/client per acquisire gli errori. Quando Servizio Azure SignalR espone i log delle risorse, è possibile sfruttare i log delle risorse per risolvere i problemi relativi ai log per il servizio.

Problemi relativi alla connessione

Quando si verificano connessioni che aumentano o eliminano in modo imprevisto, è possibile sfruttare i log di connettività per risolvere i problemi. I problemi tipici spesso comportano modifiche impreviste alla quantità di connessione, le connessioni raggiungono i limiti di connessione e l'errore di autorizzazione. Le sezioni seguenti descrivono come risolvere i problemi.

Eliminazione imprevista della connessione

Se si verificano connessioni impreviste, abilitare prima i log nei lati del servizio, del server e del client.

Se una connessione si disconnette, i log delle risorse registrano questo evento di disconnessione e vengono visualizzati ConnectionAborted o ConnectionEnded in operationName.

La differenza tra ConnectionAborted e ConnectionEnded è che ConnectionEnded si tratta di una disconnessione prevista, che viene attivata dal lato client o server. è ConnectionAborted in genere un evento imprevisto di eliminazione della connessione e il motivo dell'interruzione viene fornito in message.

Nella tabella seguente sono elencati i motivi di interruzione.

Motivo	Descrizione
il numero di Connessione ion raggiunge il limite	Connessione conteggio raggiunge il limite del piano tariffario corrente. Prendere in considerazione l'aumento delle prestazioni dell'unità di servizio
Il server applicazioni ha chiuso la connessione	Il server app attiva l'aborto. Può essere considerato come un aborto previsto
timeout ping Connessione ion	In genere è causato da un problema di rete. Valutare la possibilità di controllare la disponibilità del server app da Internet
Ricaricamento del servizio, provare a riconnettersi	Servizio Azure SignalR ricarica. Azure SignalR supporta la riconnessione automatica, è possibile attendere la riconnessione o la riconnessione manuale a Servizio Azure SignalR
Errore temporaneo del server interno	Si verifica un errore temporaneo in Servizio Azure SignalR, deve essere ripristinato automaticamente
Connessione al server eliminata	La connessione al server viene eliminata con un errore sconosciuto, prendere in considerazione la risoluzione dei problemi self-troubleshooting con il log lato servizio/server/client. Provare a escludere i problemi di base (ad esempio problema di rete, problema lato server app e così via). Se il problema non viene risolto, contattare Microsoft per ulteriore assistenza. Per altre informazioni, vedere la sezione Ottenere la Guida .

Aumento imprevisto della connessione

Per risolvere i problemi relativi all'aumento della connessione imprevista, è necessario filtrare le connessioni aggiuntive. È possibile aggiungere un ID utente di test univoco alla connessione client di test. Controllare i log delle risorse. Se vengono visualizzate più connessioni client con lo stesso ID utente o IP di test, è probabile che il lato client crei più connessioni del previsto. Controllare il lato client.

Errore di autorizzazione

Se viene restituito 401 Non autorizzato per le richieste client, controllare i log delle risorse. Se si verifica Failed to validate audience. Expected Audiences: <valid audience>. Actual Audiences: <actual audience>, significa che tutti i gruppi di destinatari nel token di accesso non sono validi. Provare a usare i gruppi di destinatari validi suggeriti nel log.

Limitazione

Se non è possibile stabilire connessioni client SignalR a Servizio Azure SignalR, controllare i log delle risorse. Se si verifica Connection count reaches limit nel log delle risorse, si stabiliscono troppe connessioni a Servizio SignalR, che raggiungono il limite di conteggio delle connessioni. Valutare la possibilità di aumentare le Servizio SignalR. Se si verifica Message count reaches limit nel log delle risorse, significa usare il livello gratuito ed è stata usata la quota di messaggi. Se si desidera inviare altri messaggi, è consigliabile modificare il Servizio SignalR al livello standard. Per altre informazioni, vedere prezzi Servizio Azure SignalR.

Problemi relativi ai messaggi

Quando si riscontrano problemi correlati ai messaggi, è possibile sfruttare i log di messaggistica per risolvere i problemi. Prima di tutto, abilitare i log delle risorse nel servizio e nei log per server e client.

Nota

Per ASP.NET Core, vedere qui per abilitare la registrazione nel server e nel client.

Per ASP.NET, vedere qui per abilitare la registrazione nel server e nel client.

Se non si è interessati a potenziali effetti sulle prestazioni e nessun messaggio di direzione da client a server, controllare in MessagingLog Source Settings/Types per abilitare il comportamento di raccolta dei log collect-all . Per altre informazioni su questo comportamento, vedere Raccogliere tutti .

In caso contrario, deselezionare per Messaging abilitare il comportamento di raccolta dei log parzialmente raccolti. Questo comportamento richiede la configurazione nel client e nel server per abilitarla. Per altre informazioni, vedere Raccogliere parzialmente.

Perdita di messaggi

Se si verificano problemi di perdita di messaggi, la chiave consiste nel individuare la posizione in cui si perde il messaggio. Fondamentalmente, si hanno tre componenti quando si usa Servizio Azure SignalR: servizio SignalR, server e client. Sia il server che il client sono connessi al servizio SignalR, ma non si connettono l'uno all'altro direttamente al termine della negoziazione. Pertanto, è necessario prendere in considerazione due direzioni per i messaggi e per ogni direzione è necessario considerare due percorsi:

• Dal client al server tramite il servizio SignalR
  • Percorso 1: dal client al servizio SignalR
  • Percorso 2: servizio SignalR al server
• Dal server al client tramite il servizio SignalR
  • Percorso 3: Da server a servizio SignalR
  • Percorso 4: servizio SignalR al client

Per raccogliere tutti i comportamenti di raccolta:

Servizio Azure SignalR solo traccia i messaggi nella direzione dal server al client tramite il servizio SignalR. L'ID di traccia viene generato nel server. Il messaggio contiene l'ID di traccia al servizio SignalR.

Nota

Se si vuole tracciare il messaggio e inviare messaggi dall'esterno di un hub nel server app, è necessario abilitare la raccolta di tutti i comportamenti di raccolta per raccogliere i log dei messaggi per i messaggi non originati dai client di diagnostica. I client di diagnostica funzionano sia per raccogliere tutti che raccogliere parzialmente i comportamenti, ma ha una priorità più alta per raccogliere i log. Per altre informazioni, vedere la sezione client di diagnostica.

Controllando il server di accesso e il lato servizio, è possibile scoprire facilmente se il messaggio viene inviato dal server, arriva al servizio SignalR e lascia dal servizio SignalR. In pratica, controllando se il messaggio ricevuto e inviato viene confrontato o meno in base all'ID di traccia dei messaggi, è possibile stabilire se il problema di perdita dei messaggi si trova nel server o nel servizio SignalR in questa direzione. Per altre informazioni, vedere i dettagli seguenti.

Per raccogliere parzialmente il comportamento:

Dopo aver contrassegnato il client come client di diagnostica, Servizio Azure SignalR traccia i messaggi in entrambe le direzioni.

Controllando il server di accesso e il lato servizio, è possibile scoprire facilmente se il messaggio passa correttamente il server o il servizio SignalR. In pratica, controllando se il messaggio ricevuto e inviato viene confrontato o meno in base all'ID di traccia dei messaggi, è possibile stabilire se il problema di perdita dei messaggi si trova nel server o nel servizio SignalR. Per altre informazioni, vedere i dettagli riportati di seguito.

Dettagli del flusso del messaggio

Per la direzione dal client al server tramite il servizio SignalR, il servizio SignalR considera solo la chiamata originata dal client di diagnostica, ovvero il messaggio generato direttamente nel client di diagnostica o il messaggio del servizio generato a causa della chiamata del client di diagnostica indirettamente.

L'ID di traccia viene generato nel servizio SignalR dopo che il messaggio arriva al servizio SignalR nel percorso 1. Il servizio SignalR genera un log Received a message <MessageTracingId> from client connection <ConnectionId>. per ogni messaggio nel client di diagnostica. Quando il messaggio viene lasciato dal signalR al server, il servizio SignalR genera un messaggio Sent a message <MessageTracingId> to server connection <ConnectionId> successfully.di log. Se vengono visualizzati questi due log, è possibile assicurarsi che il messaggio passi correttamente tramite il servizio SignalR.

Nota

A causa della limitazione di ASP.NET Core SignalR, il messaggio proviene dal client non contiene alcun ID livello di messaggio, ma ASP.NET SignalR genera l'ID chiamata per ogni messaggio. È possibile usarlo per eseguire il mapping con l'ID di traccia.

Il messaggio contiene quindi il server ID traccia nel percorso 2. Il server genera un log Received message <messagetracingId> from client connection <connectionId> al momento dell'arrivo del messaggio.

Dopo che il messaggio richiama il metodo hub nel server, viene generato un nuovo messaggio del servizio con un nuovo ID di traccia. Dopo aver generato il messaggio del servizio, il server genera un modello Start to broadcast/send message <MessageTracingId> ...di accesso . Il log effettivo si basa sullo scenario in uso. Il messaggio viene quindi recapitato al servizio SignalR nel percorso 3. Quando il messaggio del servizio esce dal server, viene generato un log denominato Succeeded to send message <MessageTracingId> .

Nota

L'ID di traccia del messaggio dal client non può essere mappato all'ID di traccia del messaggio del servizio da inviare al servizio SignalR.

Quando il messaggio del servizio arriva al servizio SignalR, viene generato un log denominato Received a <MessageType> message <MessageTracingId> from server connection <ConnectionId>. . Il servizio SignalR elabora quindi il messaggio del servizio e recapita al client di destinazione. Dopo che il messaggio viene inviato ai client nel percorso 4, viene generato il log Sent a message <MessageTracingId> to client connection <ConnectionId> successfully. .

In sintesi, il log dei messaggi viene generato quando il messaggio viene inserito e fuori dal servizio SignalR e dal server. È possibile usare questi log per verificare se il messaggio viene perso in questi componenti o meno.

L'esempio seguente è un tipico problema di perdita di messaggi.

Un client non riesce a ricevere messaggi in un gruppo

La storia tipica di questo problema è che il client si unisce a un gruppo dopo l'invio di un messaggio di gruppo.

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

Ad esempio, un utente può effettuare chiamate del gruppo di join e inviare un messaggio di gruppo nello stesso metodo hub. Il problema qui è che AddToGroupAsync è un async metodo. Poiché non await è previsto che l'oggetto AddToGroupAsync attenda il completamento, il messaggio di gruppo viene inviato prima AddToGroupAsync del completamento. A causa del ritardo di rete e del ritardo del processo di aggiunta del client a un gruppo, l'azione di gruppo di join può essere completata in un secondo momento rispetto al recapito dei messaggi di gruppo. In tal caso, il primo messaggio di gruppo non ha alcun client come ricevitore, poiché nessun client ha aggiunto il gruppo, quindi diventa un messaggio perso.

Senza i log delle risorse, non è possibile scoprire quando il client si unisce al gruppo e quando viene inviato il messaggio di gruppo. Dopo aver abilitato i log di messaggistica, è possibile confrontare il messaggio in arrivo nel servizio SignalR. Per risolvere i problemi, seguire questa procedura:

1. Trovare i log dei messaggi nel server per trovare quando il client è stato aggiunto al gruppo e quando viene inviato il messaggio di gruppo.
2. Ottenere l'ID di traccia del messaggio A dell'aggiunta al gruppo e l'ID di traccia del messaggio B del messaggio dai log dei messaggi.
3. Filtrare questi ID di traccia dei messaggi tra i log di messaggistica nella destinazione di archiviazione dei log, quindi confrontare i timestamp in arrivo. Si trova il messaggio arrivato per primo nel servizio SignalR.
4. Se l'ID di traccia dei messaggi L'ora di arrivo È successiva a B, è necessario inviare un messaggio di gruppo prima che il client si unisce al gruppo. Prima di inviare messaggi di gruppo, è necessario assicurarsi che il client si trovi nel gruppo.

Se un messaggio viene perso in SignalR o nel server, provare a ottenere i log degli avvisi in base all'ID di traccia dei messaggi per ottenere il motivo. Per altre informazioni, vedere la sezione Ottenere assistenza.

Log delle risorse che raccolgono comportamenti

Esistono due scenari tipici per l'uso dei log delle risorse, in particolare per i log di messaggistica.

Qualcuno può preoccuparsi della qualità di ogni messaggio. Ad esempio, è sensibile se il messaggio è stato inviato/ricevuto correttamente o vuole registrare ogni messaggio recapitato tramite il servizio SignalR.

Nel frattempo, altri potrebbero preoccuparsi delle prestazioni. Sono sensibili alla latenza del messaggio e a volte devono tenere traccia del messaggio in alcune connessioni invece di tutte le connessioni per qualche motivo.

Pertanto, il servizio SignalR fornisce due tipi di comportamenti di raccolta

• raccogliere tutti: raccogliere i log in tutte le connessioni
• collect parzialmente: raccogliere i log in alcune connessioni specifiche

Nota

Per distinguere le connessioni tra i log di raccolta e quelli che non raccolgono i log, il servizio SignalR considera alcuni client come client di diagnostica in base alle configurazioni client di diagnostica del server e del client, in cui i log delle risorse vengono sempre raccolti, mentre gli altri no. Per altre informazioni, vedere la sezione collect parzialmente.

Raccogli tutto

I log delle risorse vengono raccolti da tutte le connessioni. Ad esempio, prendere i log di messaggistica. Quando questo comportamento è abilitato, il servizio SignalR invia una notifica al server per avviare la generazione dell'ID di traccia per ogni messaggio. L'ID di traccia viene trasportato nel messaggio al servizio. Il servizio registra anche il messaggio con l'ID di traccia.

Nota

Si noti che per garantire le prestazioni del servizio SignalR, il servizio SignalR non attende e analizza l'intero messaggio inviato dal client. Di conseguenza, i messaggi client non vengono registrati. Se il client è contrassegnato come client di diagnostica, il messaggio client viene registrato nel servizio SignalR.

Guida alla configurazione

Per abilitare questo comportamento, selezionare la casella di controllo nella sezione Tipi del Impostazioni origine log.

Questo comportamento non richiede l'aggiornamento delle configurazioni lato server. Questa modifica di configurazione viene sempre inviata automaticamente al server.

Raccogliere parzialmente

I log delle risorse vengono raccolti solo dai client di diagnostica. Tutti i messaggi vengono registrati, inclusi i messaggi client e gli eventi di connettività nei client di diagnostica.

Nota

Il limite del numero dei client di diagnostica è 100. Se il numero di client di diagnostica supera 100, i client di diagnostica non numerati vengono limitati dal servizio SignalR. I nuovi client ma in numero non riescono a connettersi al servizio SignalR e generano System.Net.Http.HttpRequestException, con il messaggio Response status code does not indicate success: 429 (Too Many Requests). I client già connessi funzionano senza influire sui criteri di limitazione.

Client di diagnostica

Il client di diagnostica è un concetto logico. Qualsiasi client può essere un client di diagnostica. Il server controlla quale client può essere un client di diagnostica. Dopo che un client è contrassegnato come client di diagnostica, tutti i log delle risorse vengono abilitati in questo client. Per impostare un client come client di diagnostica, vedere la guida alla configurazione.

Guida alla configurazione

Per abilitare questo comportamento, è necessario configurare il servizio, il server e il lato client.

Lato servizio

Per abilitare questo comportamento, deselezionare la casella di controllo per un tipo di log specifico nella sezione Tipi del Impostazioni origine log.

Lato server

Configurare ServiceOptions.DiagnosticClientFilter anche per definire un filtro dei client di diagnostica in base al contesto HTTP proviene dai client. Ad esempio, impostare il client con l'URL <HUB_URL>?diag=yesdell'hub, quindi configurare ServiceOptions.DiagnosticClientFilter per filtrare il client di diagnostica. Se restituisce true, il client viene contrassegnato come client di diagnostica. In caso contrario, rimane come normale client. Può ServiceOptions.DiagnosticClientFilter essere impostato nella classe di avvio come segue:

// 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();
}

Lato client

Contrassegnare il client come client di diagnostica configurando il contesto HTTP. Ad esempio, il client viene contrassegnato come client di diagnostica aggiungendo la stringa diag=yesdi query .

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

Come ottenere assistenza

È consigliabile risolvere i problemi da soli. La maggior parte dei problemi è causata da problemi di rete o server app. Seguire la guida alla risoluzione dei problemi con il log delle risorse e la guida alla risoluzione dei problemi di base per trovare la causa radice. Se il problema non può ancora essere risolto, prendere in considerazione l'apertura di un problema in GitHub o la creazione di un ticket in portale di Azure. Provider:

1. Intervallo di tempo di circa 30 minuti quando si verifica il problema
2. ID risorsa di Servizio Azure SignalR
3. Dettagli del problema, il più specifico possibile: ad esempio, appserver non invia messaggi, la connessione client viene eliminata e così via
4. Log raccolti dal lato server/client e altro materiale che potrebbe essere utile
5. [Facoltativo] Codice di riproduzione

Nota

Se si apre un problema in GitHub, mantenere private le informazioni riservate (ad esempio, ID risorsa, log server/client). Inviare solo ai membri dell'organizzazione Microsoft privatamente.