Usare i log delle risorse per monitorare il servizio 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 nel portale di Azure per ogni Servizio Azure SignalR include una breve visualizzazione dell'utilizzo delle risorse, ad esempio connessioni simultanee e conteggio dei messaggi. Queste informazioni utili sono solo una piccola quantità dei 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 del Servizio Azure SignalR, vedere Monitorare il Servizio Azure SignalR.
• Per un elenco dettagliato delle metriche e dei log raccolti per il Servizio Azure SignalR, vedere Informazioni di riferimento sui dati di monitoraggio del Servizio Azure SignalR.

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

Il 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 vengono archiviati nell'account di archiviazione configurato nel riquadro Log di diagnostica. Per altri dettagli sul formato di archiviazione e sui campi, vedere Archiviazione dati.

Creare impostazioni di diagnostica

I log delle risorse sono disabilitati per impostazione predefinita. Per abilitare i log delle risorse usando le impostazioni di diagnostica, vedere Creare impostazioni di diagnostica in Monitoraggio di Azure.

Eseguire query sui log delle risorse

Per eseguire query sui log delle risorse, procedere come segue:

1. Selezionare Log nella destinazione Log Analytics.

   

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

   

Per usare query di esempio per il 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 query di esempio per il Servizio Azure SignalR, vedere Query per la tabella SignalRServiceDiagnosticLogs.

Nota

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

Risoluzione dei problemi relativi ai log delle risorse

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

Problemi relativi alla connessione

Quando si riscontrano connessioni che aumentano o si interrompono in modo imprevisto, è possibile sfruttare i log di connettività per risolvere i problemi. I problemi tipici riguardano spesso modifiche inattese della quantità di connessioni, il raggiungimento dei limiti di connessione ed errori di autorizzazione. Le seguenti sezioni descrivono come risolvere i problemi.

Interruzione imprevista della connessione

Se si verificano cadute di connessioni inattese, attivare innanzitutto i log sul lato del servizio, del server e del client.

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

La differenza tra ConnectionAborted e ConnectionEnded è che ConnectionEnded è una disconnessione prevista, che viene attivata dal lato client o server. ConnectionAborted è in genere un evento imprevisto di interruzione 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 connessioni raggiunge il limite	Il numero di connessioni raggiunge il limite del livello di prezzo corrente. È consigliabile aumentare le prestazioni dell'unità di servizio
Il server applicazioni ha chiuso la connessione	Il server applicazioni attiva l'interruzione. Può essere considerata come un'interruzione prevista
Timeout del ping di connessione	In genere è causato da un problema di rete. Controllare la disponibilità del server applicazioni da Internet
Ricaricamento del servizio, tentativo di riconnessione	Il Servizio Azure SignalR si sta ricaricando. Azure SignalR supporta la riconnessione automatica; è possibile attendere la riconnessione al Servizio Azure SignalR o effettuarla manualmente
Errore temporaneo del server interno	Si verifica un errore temporaneo nel Servizio Azure SignalR, che deve essere ripristinato automaticamente
Connessione al server interrotta	La connessione al server si interrompe con un errore sconosciuto; è consigliabile procedere prima di tutto alla risoluzione dei problemi autonoma con il log lato servizio/server/client. Provare a escludere i problemi di base (ad esempio problema di rete, problema lato server applicazioni e così via). Se il problema non viene risolto, contattare Microsoft per ulteriore assistenza. Per altre informazioni, vedere la sezione Richiesta supporto.

Aumento imprevisto delle connessioni

Per risolvere i problemi relativi all'aumento imprevisto delle connessioni, è 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 l'errore 401 Non autorizzato per le richieste client, controllare i log delle risorse. Se viene riscontrato l'errore Failed to validate audience. Expected Audiences: <valid audience>. Actual Audiences: <actual audience>, significa che i gruppi di destinatari nel token di accesso sono tutti non validi. Provare a usare i gruppi di destinatari validi suggeriti nel log.

Limitazione

Se non è possibile stabilire connessioni client SignalR al Servizio Azure SignalR, controllare i log delle risorse. Se viene riscontrato l'errore Connection count reaches limit nel log delle risorse, significa che sono state stabilite troppe connessioni al Servizio SignalR, raggiungendo il numero limite. È consigliabile ridimensionare il Servizio SignalR. Se viene riscontrato l'errore Message count reaches limit nel log delle risorse, significa che si sta utilizzando il livello gratuito ed è stata esaurita la quota di messaggi. Se si vogliono inviare altri messaggi, è consigliabile passare al livello standard del Servizio SignalR. Per altre informazioni, vedere Prezzi del Servizio Azure SignalR.

Problemi relativi ai messaggi

Se si riscontrano problemi relativi ai messaggi, è possibile sfruttare i log di messaggistica per risolverli. 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 i potenziali effetti sulle prestazioni e l'assenza di messaggi in direzione client-server non costituiscono un problema, selezionare l'opzione Messaging in Log Source Settings/Types per abilitare il comportamento di raccolta di log collect-all. Per altre informazioni su questo comportamento, vedere Raccogliere tutto.

In caso contrario, deselezionare Messaging per abilitare il comportamento di raccolta di log collect-partially. Questo comportamento deve essere abilitato nella configurazione nel client e nel server. Per altre informazioni, vedere Raccogliere parzialmente.

Perdita di messaggi

Se si verificano problemi di perdita di messaggi, è necessario individuare la posizione in cui vengono persi. Fondamentalmente, si hanno tre componenti quando si usa il 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 considerare due direzioni per i messaggi, per ognuna delle quali è necessario considerare due percorsi:

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

Per il comportamento di raccolta Raccogliere tutti:

Il Servizio Azure SignalR traccia solo 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 applicazioni, è necessario abilitare il comportamento di raccolta Raccogliere tutti per raccogliere i log dei messaggi non provenienti dai client di diagnostica. I client di diagnostica funzionano sia per il comportamento Raccogliere tutti sia per Raccogliere parzialmente, ma hanno una priorità più alta per la raccolta di log. Per altre informazioni, vedere la sezione sul 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 parte dal Servizio SignalR. In pratica, controllando se il messaggio ricevuto e quello inviato corrispondono o meno in base all'ID di traccia dei messaggi, è possibile stabilire se il problema di perdita dei messaggi si verifica nel server o nel Servizio SignalR in questa direzione. Per altre informazioni, vedere i dettagli seguenti.

Per il comportamento Raccogliere parzialmente:

Dopo aver contrassegnato il client come client di diagnostica, il 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 nel server o nel Servizio SignalR. In pratica, controllando se il messaggio ricevuto e quello inviato corrispondono o meno in base all'ID di traccia dei messaggi, è possibile stabilire se il problema di perdita dei messaggi si verifica nel server o nel Servizio SignalR. Per altre informazioni, vedere i dettagli riportati di seguito.

Dettagli del flusso messaggi

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 indiretta del client di diagnostica.

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 da SignalR al server, il Servizio SignalR genera un messaggio di log Sent a message <MessageTracingId> to server connection <ConnectionId> successfully.. Se vengono visualizzati questi due log, si ha la certezza che il messaggio passi correttamente tramite il Servizio SignalR.

Nota

A causa della limitazione di ASP.NET Core SignalR, il messaggio che 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 di ID di 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 di accesso Start to broadcast/send message <MessageTracingId> .... 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 proveniente 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 entra ed esce dal Servizio SignalR e dal server. È possibile usare questi log per verificare se il messaggio si perde 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

Il motivo tipico 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("ReceiveGroupMessage", name, "I'm in group"); // send group message
    }
}

Ad esempio, un utente può effettuare chiamate di join group e send group message nello stesso metodo hub. Il problema è che AddToGroupAsync è un metodo async. Poiché non è incluso un metodo await affinché AddToGroupAsync attenda fino al completamento, il messaggio di gruppo viene inviato prima del completamento di AddToGroupAsync. A causa del ritardo di rete e del ritardo del processo di aggiunta del client a un gruppo, l'azione join group 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 si è aggiunto al gruppo, quindi diventa un messaggio perso.

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

1. Trovare i log dei messaggi nel server per scoprire quando il client si è aggiunto al gruppo e quando è stato 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 di gruppo 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 di arrivo. Si trova quale messaggio è arrivato per primo nel Servizio SignalR.
4. Se l'ora di arrivo dell'ID di traccia del messaggio A è successiva all'ora di arrivo di B, è necessario inviare un messaggio di gruppo prima che il client si aggiunga al gruppo. Prima di inviare messaggi di gruppo, è necessario assicurarsi che il client si trovi nel gruppo.

Se un messaggio va 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 Richiesta supporto.

Comportamenti di raccolta dei log delle risorse

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

È possibile che ci si preoccupi della qualità di ogni messaggio. Ad esempio, in alcuni casi è importante capire se il messaggio è stato inviato/ricevuto o si vuole registrare ogni messaggio recapitato tramite il Servizio SignalR.

In altri casi, ci si potrebbe preoccupare delle prestazioni. È importante capire qual è la latenza del messaggio e a volte è necessario monitorare il messaggio in poche connessioni invece che in tutte per qualche motivo.

Pertanto, il Servizio SignalR offre due tipi di comportamenti di raccolta

• Raccogliere tutti: raccoglie i log in tutte le connessioni
• Raccogliere parzialmente: raccoglie i log in alcune connessioni specifiche

Nota

Per distinguere le connessioni tra quelle che raccolgono i log e quelle che non lo fanno, il Servizio SignalR considera un certo client come client di diagnostica in base alle configurazioni di 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 Raccogliere parzialmente.

Raccogliere tutti

I log delle risorse vengono raccolti da tutte le connessioni. Ad esempio, considerare i log di messaggistica. Se 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 trasferito nel messaggio al servizio. Il servizio registra anche il messaggio con l'ID di traccia.

Nota

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

Guida alla configurazione

Per abilitare questo comportamento, selezionare la casella di controllo nella sezione Tipi in Impostazioni di origine dei 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 raccoltisolo dai client di diagnostica. Tutti i messaggi vengono registrati, inclusi i messaggi dei 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 in numero superiore vengono limitati dal Servizio SignalR. I nuovi client in numero superiore 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 essere interessati dai 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 viene 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 i lati servizio, server e client.

Lato servizio

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

Lato server

Configurare anche ServiceOptions.DiagnosticClientFilter per definire un filtro dei client di diagnostica in base al contesto HTTP proveniente dai client. Ad esempio, impostare il client con l'URL <HUB_URL>?diag=yes dell'hub, quindi configurare ServiceOptions.DiagnosticClientFilter per filtrare il client di diagnostica. Se restituisce true, il client è contrassegnato come client di diagnostica. In caso contrario, rimane come normale client. ServiceOptions.DiagnosticClientFilter può 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 di query diag=yes.

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

Come ottenere assistenza

È consigliabile risolvere i problemi in autonomia. La maggior parte dei problemi è causata da problemi di rete o del server applicazioni. 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, valutare se aprire un caso in GitHub o creare un ticket nel portale di Azure. Provider:

1. Intervallo di tempo di circa 30 minuti da quando si verifica il problema
2. ID risorsa del Servizio Azure SignalR
3. Dettagli del problema, il più specifico possibile: ad esempio, il server applicazioni non invia messaggi, la connessione client viene interrotta 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.