Övervaka och felsöka Azure SignalR Service-loggar

Artikel
03/26/2024

Den här artikeln beskriver hur du kan använda Azure Monitor-funktioner för att analysera och felsöka övervakningsdata för resursloggar som genereras av Azure SignalR.

Översiktssidan i Azure-portalen för varje Azure SignalR Service innehåller en kort vy över resursanvändningen, till exempel samtidiga anslutningar och antal meddelanden. Den här användbara informationen är bara en liten del av de övervakningsdata som är tillgängliga i portalen. En del av dessa data samlas in automatiskt och är tillgängliga för analys så snart du skapar resursen.

Du kan aktivera andra typer av datainsamling efter viss konfiguration. Den här artikeln går igenom hur du konfigurerar insamling av loggdata och analyserar och felsöker dessa data med hjälp av Azure Monitor-verktyg.

Mer information om övervakning av Azure SignalR Service finns i Övervaka Azure SignalR Service.
En detaljerad lista över mått och loggar som samlats in för Azure SignalR Service finns i Referens för Övervakningsdata för Azure SignalR Service.

Förutsättningar

Om du vill aktivera resursloggar måste du konfigurera en plats där du kan lagra dina loggdata, till exempel Azure Storage eller Log Analytics.

Azure Storage behåller resursloggar för principgranskning, statisk analys eller säkerhetskopiering.
Log Analytics är ett flexibelt verktyg för loggsökning och analys som möjliggör analys av rådataloggar som genereras av en Azure-resurs.

Aktivera resursloggar

Azure SignalR Service stöder anslutningsloggar, meddelandeloggar och http-begärandeloggar. Mer information om dessa typer av loggar finns i Resursloggkategorier.

Resursloggar är inaktiverade som standard. Följ dessa steg för att aktivera resursloggar med hjälp av diagnostikinställningar:

I Azure-portalen går du till Övervakning och väljer Diagnostikinställningar.

Du får en fullständig vy över diagnostikinställningarna.
Konfigurera loggkällans inställningar.
1. I avsnittet Log Source Inställningar visar en tabell samla in beteenden för varje loggtyp.
2. Kontrollera den specifika loggtyp som du vill samla in för alla anslutningar. Annars samlas loggen endast in för diagnostikklienter.
Konfigurera loggmålinställningarna.
1. I avsnittet Log Destination Inställningar visar en tabell med diagnostikinställningar de befintliga diagnostikinställningarna. Du kan välja länken i tabellen för att få åtkomst till loggmålet för att visa de insamlade resursloggarna.
2. I det här avsnittet väljer du knappen Konfigurera loggmål Inställningar för att lägga till, uppdatera eller ta bort diagnostikinställningar.
3. Välj Lägg till diagnostikinställning för att lägga till en ny diagnostikinställning eller välj Redigera för att ändra en befintlig diagnostikinställning.
4. Ange det arkivmål som du vill använda. För närvarande har Azure SignalR Service stöd för Arkiv till ett lagringskonto och Skicka till Log Analytics.
5. Välj de loggar som du vill arkivera. Endast AllLogs är tillgängligt för resursloggen. Den styr bara om du vill arkivera loggarna. Konfigurera i avsnittet Log Source Inställningar för att konfigurera vilka loggtyper som måste genereras i Azure SignalR Service.
1. Spara den nya diagnostikinställningen. Den nya inställningen börjar gälla om cirka 10 minuter. Därefter skickas loggar till det konfigurerade arkiveringsmålet. Mer information om hur du konfigurerar loggmålinställningar finns i översikten över Azure-resursloggar.

Loggar lagras i lagringskontot som konfigurerats i fönstret Diagnostikloggar . Mer information om lagringsformat och fält finns i Datalagring.

Fråga efter resursloggar

Följ dessa steg om du vill köra frågor mot resursloggar:

Välj Loggar i mållogganalysen.
Ange SignalRServiceDiagnosticLogs och välj tidsintervall . Avancerad fråga finns i Komma igång med Log Analytics i Azure Monitor

Följ dessa steg om du vill använda exempelfrågor för Azure SignalR Service:

Välj Loggar i mållogganalysen.
Välj fliken Frågor för att öppna frågeutforskaren.
Välj Resurstyp för att gruppera exempelfrågor i resurstyp.
Välj Kör för att köra skriptet.

Exempelfrågor för Azure SignalR Service finns i Frågor för tabellen SignalRServiceDiagnosticLogs.

Kommentar

Frågefältnamn för Lagringsmål skiljer sig något från fältnamn för Log Analytics. Mer information om fältnamnsmappningar mellan Lagrings- och Log Analytics-tabeller finns i Mappning av resursloggtabeller.

Felsökning med resursloggar

Om du vill felsöka Azure SignalR Service kan du aktivera loggar på server-/klientsidan för att samla in fel. När Azure SignalR Service exponerar resursloggar kan du använda resursloggar för att felsöka loggar för tjänsten.

När du får anslutningar som oväntat växer eller släpps kan du använda anslutningsloggar för att felsöka. Vanliga problem omfattar ofta oväntade ändringar av anslutningskvantitet, anslutningar når anslutningsgränser och auktoriseringsfel. I följande avsnitt beskrivs hur du felsöker.

Oväntad anslutning har släppts

Om oväntade anslutningar släpps aktiverar du först loggar i tjänsten, servern och klientsidan.

Om en anslutning kopplas från registrerar resursloggarna den här frånkopplingshändelsen och du ser ConnectionAborted eller ConnectionEnded i operationName.

Skillnaden mellan ConnectionAborted och ConnectionEnded är att det ConnectionEnded är en förväntad frånkoppling, som utlöses av klient- eller serversidan. ConnectionAborted är vanligtvis en oväntad anslutningssläppningshändelse och orsaken till avbrottet anges i message.

I följande tabell visas orsakerna till avbrottet.

Anledning	beskrivning
Anslut ionsantalet når gränsen	Anslut ionsantalet når gränsen för den aktuella prisnivån. Överväg att skala upp tjänstenhet
Programservern stängde anslutningen	Appservern utlöser aborten. Det kan betraktas som en förväntad abort
timeout för Anslut ion ping	Vanligtvis orsakas det av nätverksproblem. Överväg att kontrollera appserverns tillgänglighet från Internet
Tjänsten läses in igen, försök att återansluta	Azure SignalR Service laddas om. Azure SignalR stöder automatisk återanslutning. Du kan vänta tills du återansluter eller återansluter till Azure SignalR Service manuellt
Tillfälliga fel för intern server	Tillfälligt fel inträffar i Azure SignalR Service, ska återställas automatiskt
Serveranslutningen har avbrutits	Serveranslutningen avbryts med okänt fel. Överväg självfelsökning med tjänst-/server-/klientsidans logg först. Försök att exkludera grundläggande problem (t.ex. nätverksproblem, problem på appserversidan osv.). Kontakta oss om problemet inte är löst. Mer information finns i avsnittet Hämta hjälp .

Oväntad anslutning växer

För att felsöka oväntade anslutningar som växer är det första du behöver göra att filtrera bort de extra anslutningarna. Du kan lägga till ett unikt testanvändar-ID i testklientanslutningen. Kontrollera resursloggarna. Om du ser att fler än en klientanslutning har samma testanvändar-ID eller IP-adress är det troligt att klientsidan skapar fler anslutningar än förväntat. Kontrollera klientsidan.

Auktoriseringen misslyckades

Om du får 401 Obehörig returnerad för klientbegäranden kontrollerar du dina resursloggar. Om du stöter på Failed to validate audience. Expected Audiences: <valid audience>. Actual Audiences: <actual audience>innebär det att alla målgrupper i din åtkomsttoken är ogiltiga. Försök att använda de giltiga målgrupper som föreslås i loggen.

Begränsning

Om du upptäcker att du inte kan upprätta SignalR-klientanslutningar till Azure SignalR Service kontrollerar du dina resursloggar. Om du stöter på Connection count reaches limit i resursloggen upprättar du för många anslutningar till SignalR Service, som når gränsen för antal anslutningar. Överväg att skala upp SignalR Service. Om du stöter på Message count reaches limit i resursloggen innebär det att du använder den kostnadsfria nivån och att du har förbrukat kvoten för meddelanden. Om du vill skicka fler meddelanden kan du överväga att ändra SignalR Service till standardnivå. Mer information finns i Prissättning för Azure SignalR Service.

När du stöter på meddelanderelaterade problem kan du använda meddelandeloggar för att felsöka. Aktivera först resursloggar i tjänsten och loggar för server och klient.

Kommentar

För ASP.NET Core, se här för att aktivera loggning i server och klient.

För ASP.NET, se här för att aktivera loggning i server och klient.

Om du inte har något emot potentiella prestandaeffekter och inget meddelande om klient-till-server-riktning kontrollerar du Messaging in Log Source Settings/Types för att aktivera insamlingsbeteende för insamling av alla loggar. Mer information om det här beteendet finns i samla in alla .

Annars avmarkerar du Messaging för att aktivera insamlingsbeteende för insamling av insamlade loggar delvis. Det här beteendet kräver konfiguration i klienten och servern för att aktivera det. Mer information finns i samla in delvis.

Meddelandeförlust

Om du stöter på problem med meddelandeförlust är nyckeln att hitta den plats där du förlorar meddelandet. I grund och botten har du tre komponenter när du använder Azure SignalR Service: SignalR Service, server och klient. Både servern och klienten är anslutna till SignalR-tjänsten men ansluter inte till varandra direkt när förhandlingen har slutförts. Därför måste du överväga två riktningar för meddelanden, och för varje riktning måste du överväga två sökvägar:

Från klient till server via SignalR-tjänsten
- Sökväg 1: Klient till SignalR-tjänst
- Sökväg 2: SignalR-tjänst till server
Från server till klient via SignalR-tjänsten
- Sökväg 3: Server till SignalR-tjänst
- Sökväg 4: SignalR-tjänst till klient

Meddelandesökväg

För att samla in alla insamlingsbeteenden:

Azure SignalR Service spårar endast meddelanden i riktning från server till klient via SignalR-tjänsten. Spårnings-ID:t genereras på servern. Meddelandet bär spårnings-ID:t till SignalR-tjänsten.

Kommentar

Om du vill spåra meddelanden och skicka meddelanden utanför en hubb på appservern måste du aktivera samla in alla insamlingsbeteenden för att samla in meddelandeloggar för meddelanden som inte kommer från diagnostikklienter. Diagnostikklienter fungerar både för att samla in alla och samla in delvis samlande beteenden, men har högre prioritet för att samla in loggar. Mer information finns i avsnittet diagnostikklient.

Genom att kontrollera inloggningsservern och tjänstsidan kan du enkelt ta reda på om meddelandet skickas från servern, kommer till SignalR-tjänsten och lämnar SignalR-tjänsten. Genom att kontrollera om det mottagna och skickade meddelandet matchas eller inte baserat på meddelandespårnings-ID kan du se om problemet med meddelandeförlusten finns i servern eller SignalR-tjänsten i den här riktningen. Mer information finns i informationen nedan.

För att samla in delvis samla in beteende:

När du har markerat klienten som diagnostikklient spårar Azure SignalR Service meddelanden i båda riktningarna.

Genom att kontrollera inloggningsservern och tjänstsidan kan du enkelt ta reda på om meddelandet skickas till servern eller SignalR-tjänsten. Genom att kontrollera om det mottagna och skickade meddelandet matchas eller inte baserat på meddelandespårnings-ID kan du se om problemet med meddelandeförlusten finns i servern eller SignalR-tjänsten. Mer information finns i följande information.

Information om meddelandeflödet

För riktningen från klient till server via SignalR-tjänsten tar SignalR-tjänsten endast hänsyn till anropet som kommer från diagnostikklienten, det vill: meddelandet som genereras direkt i diagnostikklienten eller tjänstmeddelandet som genereras på grund av anropet av diagnostikklienten indirekt.

Spårnings-ID:t genereras i SignalR-tjänsten när meddelandet kommer till SignalR-tjänsten i sökväg 1. SignalR-tjänsten genererar en logg Received a message <MessageTracingId> from client connection <ConnectionId>. för varje meddelande i diagnostikklienten. När meddelandet lämnar SignalR till servern genererar SignalR-tjänsten ett loggmeddelande Sent a message <MessageTracingId> to server connection <ConnectionId> successfully.. Om du ser dessa två loggar kan du vara säker på att meddelandet skickas via SignalR-tjänsten.

Kommentar

På grund av begränsningen för ASP.NET Core SignalR kommer meddelandet från klienten inte innehåller något meddelandenivå-ID, men ASP.NET SignalR genererar anrops-ID för varje meddelande. Du kan använda den för att mappa med spårnings-ID:t.

Sedan bär meddelandet spårnings-ID-servern i sökväg 2. Servern genererar en logg Received message <messagetracingId> from client connection <connectionId> när meddelandet kommer.

När meddelandet anropar hubbmetoden på servern genereras ett nytt tjänstmeddelande med ett nytt spårnings-ID. När tjänstmeddelandet har genererats genererar servern en inloggningsmall Start to broadcast/send message <MessageTracingId> .... Den faktiska loggen baseras på ditt scenario. Sedan levereras meddelandet till SignalR-tjänsten i Sökväg 3. När tjänstmeddelandet lämnar servern genereras en logg som heter Succeeded to send message <MessageTracingId> .

Kommentar

Spårnings-ID:t för meddelandet från klienten kan inte mappas till spårnings-ID:t för tjänstmeddelandet som ska skickas till SignalR-tjänsten.

När tjänstmeddelandet kommer till SignalR-tjänsten genereras en logg som heter Received a <MessageType> message <MessageTracingId> from server connection <ConnectionId>. . Sedan bearbetar SignalR-tjänsten tjänstmeddelandet och levererar till målklienterna. När meddelandet har skickats till klienter i sökväg 4 genereras loggen Sent a message <MessageTracingId> to client connection <ConnectionId> successfully. .

Sammanfattningsvis genereras meddelandeloggen när meddelandet skickas in och ut från SignalR-tjänsten och servern. Du kan använda dessa loggar för att kontrollera om meddelandet går förlorat i dessa komponenter eller inte.

Följande exempel är ett typiskt problem med meddelandeförlust.

En klient kan inte ta emot meddelanden i en grupp

Den typiska händelsen i det här problemet är att klienten ansluter till en grupp efter att ha skickat ett gruppmeddelande.

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

Till exempel kan någon göra anrop av kopplingsgrupp och skicka gruppmeddelande i samma hubbmetod. Problemet här är AddToGroupAsync en async metod. Eftersom det inte finns någon await för AddToGroupAsync att vänta tills det har slutförts skickar gruppmeddelandet innan AddToGroupAsync det är klart. På grund av nätverksfördröjning och fördröjningen av processen för att ansluta klienten till någon grupp kan åtgärden för anslutningsgrupper slutföras senare än leveransen av gruppmeddelanden. I så fall har det första gruppmeddelandet ingen klient som mottagare, eftersom ingen klient har anslutit till gruppen, så det blir ett meddelande som förlorats.

Utan resursloggar kan du inte ta reda på när klienten ansluter till gruppen och när gruppmeddelandet skickas. När du aktiverar meddelandeloggar kan du jämföra när meddelandet kommer i SignalR-tjänsten. Utför följande steg för att felsöka:

Leta reda på meddelandeloggarna på servern för att hitta när klienten anslöt till gruppen och när gruppmeddelandet skickas.
Hämta meddelandespårnings-ID A för att ansluta till gruppen och meddelandespårnings-ID B för gruppmeddelande från meddelandeloggarna.
Filtrera dessa meddelandespårnings-ID bland meddelandeloggar i loggarkivmålet och jämför sedan deras ankommande tidsstämplar. Du hittar det meddelande som kom först i SignalR-tjänsten.
Om meddelandespårnings-ID En ankommande tid är senare än B-ankommande tid måste du skicka gruppmeddelande innan klienten ansluter till gruppen. Du måste se till att klienten finns i gruppen innan du skickar gruppmeddelanden.

Om ett meddelande går förlorat i SignalR eller servern kan du försöka hämta varningsloggarna baserat på meddelandespårnings-ID:t för att få orsaken. Om du behöver ytterligare hjälp kan du läsa avsnittet hämta hjälp.

Resursloggar som samlar in beteenden

Det finns två vanliga scenarier för att använda resursloggar, särskilt för meddelandeloggar.

Någon kanske bryr sig om kvaliteten på varje meddelande. De är till exempel känsliga för om meddelandet har skickats/tagits emot eller om de vill registrera varje meddelande som levereras via SignalR-tjänsten.

Under tiden kan andra bry sig om prestandan. De är känsliga för svarstiden för meddelandet, och ibland måste de spåra meddelandet i några anslutningar i stället för alla anslutningar av någon anledning.

SignalR-tjänsten tillhandahåller därför två typer av insamlingsbeteenden

samla in alla: samla in loggar i alla anslutningar
samla in delvis: samla in loggar i vissa specifika anslutningar

Kommentar

För att skilja anslutningarna mellan dessa insamlingsloggar och de som inte samlar in loggar behandlar SignalR-tjänsten vissa klienter som diagnostikklient baserat på diagnostikklientkonfigurationerna för servern och klienten, där resursloggarna alltid samlas in, medan de andra inte gör det. Mer information finns i avsnittet samla in delvis.

Samla in alla

Resursloggar samlas in av alla anslutningar. Ta till exempel meddelandeloggar. När det här beteendet är aktiverat skickar SignalR-tjänsten ett meddelande till servern för att börja generera spårnings-ID för varje meddelande. Spårnings-ID:t överförs i meddelandet till tjänsten. Tjänsten loggar även meddelandet med spårnings-ID.

Kommentar

Observera att SignalR-tjänsten inte väntar och parsar hela meddelandet som skickas från klienten för att säkerställa signalR-tjänstens prestanda. Därför loggas inte klientmeddelandena. Om klienten har markerats som en diagnostikklient loggas klientmeddelandet i SignalR-tjänsten.

Konfigurationsguide

Om du vill aktivera det här beteendet markerar du kryssrutan i avsnittet Typer i log source Inställningar.

Det här beteendet kräver inte att du uppdaterar konfigurationer på serversidan. Den här konfigurationsändringen skickas alltid till servern automatiskt.

Samla in delvis

Resursloggar samlas bara in av diagnostikklienter. Alla meddelanden loggas, inklusive klientmeddelanden och anslutningshändelser i diagnostikklienterna.

Kommentar

Gränsen för antalet diagnostikklienter är 100. Om antalet diagnostikklienter överskrider 100 begränsas de outnumbered diagnostikklienterna av SignalR-tjänsten. De nya men outnumbered klienterna kan inte ansluta till SignalR-tjänsten och utlösa System.Net.Http.HttpRequestException, som har meddelandet Response status code does not indicate success: 429 (Too Many Requests). De redan anslutna klienterna fungerar utan att påverkas av begränsningsprincipen.

Diagnostikklient

Diagnostikklient är ett logiskt begrepp. Alla klienter kan vara en diagnostikklient. Servern styr vilken klient som kan vara en diagnostikklient. När en klient har markerats som en diagnostikklient aktiveras alla resursloggar i den här klienten. Information om hur du anger en klient som en diagnostikklient finns i konfigurationsguiden.

Konfigurationsguide

För att aktivera det här beteendet måste du konfigurera tjänst-, server- och klientsidan.

Tjänstsidan

Om du vill aktivera det här beteendet avmarkerar du kryssrutan för en specifik loggtyp i avsnittet Typer i log source Inställningar.

Serversidan

ServiceOptions.DiagnosticClientFilter Konfigurera även för att definiera ett filter för diagnostikklienter baserat på http-kontexten kommer från klienter. Skapa till exempel klienten med hubb-URL <HUB_URL>?diag=yesoch konfigurera ServiceOptions.DiagnosticClientFilter sedan för att filtrera diagnostikklienten. Om den returnerar truemarkeras klienten som diagnostikklient. Annars förblir den som en vanlig klient. Kan anges i startklassen ServiceOptions.DiagnosticClientFilter så här:

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

Kundsidan

Markera klienten som diagnostikklient genom att konfigurera http-kontexten. Klienten markeras till exempel som diagnostikklient genom att lägga till frågesträngen diag=yes.

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

Få hjälp

Vi rekommenderar att du felsöker själv först. De flesta problem orsakas av appserver- eller nätverksproblem. Följ felsökningsguiden med resursloggen och den grundläggande felsökningsguiden för att hitta rotorsaken. Om problemet fortfarande inte kan lösas kan du överväga att öppna ett problem i GitHub eller skapa ett ärende i Azure-portalen. Ge:

Tidsintervall cirka 30 minuter när problemet uppstår
Resurs-ID för Azure SignalR Service
Probleminformation, så specifik som möjligt: Appserver skickar till exempel inte meddelanden, klientanslutningen avbryts och så vidare
Loggar som samlas in från server-/klientsidan och annat material som kan vara användbart
[Valfritt] Återskapa kod

Kommentar

Om du öppnar ett problem i GitHub ska du hålla din känsliga information (till exempel resurs-ID, server-/klientloggar) privat. Skicka endast till medlemmar i Microsofts organisation privat.

Share via

Övervaka och felsöka Azure SignalR Service-loggar

Förutsättningar

Aktivera resursloggar

Fråga efter resursloggar

Felsökning med resursloggar

Oväntad anslutning har släppts

Oväntad anslutning växer

Auktoriseringen misslyckades

Begränsning

Meddelandeförlust

En klient kan inte ta emot meddelanden i en grupp

Resursloggar som samlar in beteenden

Samla in alla

Konfigurationsguide

Samla in delvis

Diagnostikklient

Konfigurationsguide

Tjänstsidan

Serversidan

Kundsidan

Få hjälp

Ytterligare resurser

Share via

Övervaka och felsöka Azure SignalR Service-loggar

Förutsättningar

Aktivera resursloggar

Fråga efter resursloggar

Felsökning med resursloggar

Anslutningsrelaterade problem

Oväntad anslutning har släppts

Oväntad anslutning växer

Auktoriseringen misslyckades

Begränsning

Meddelanderelaterade problem

Meddelandeförlust

En klient kan inte ta emot meddelanden i en grupp

Resursloggar som samlar in beteenden

Samla in alla

Konfigurationsguide

Samla in delvis

Diagnostikklient

Konfigurationsguide

Tjänstsidan

Serversidan

Kundsidan

Få hjälp

Ytterligare resurser