Resourcelogboeken gebruiken om SignalR Service te bewaken

In dit artikel wordt beschreven hoe u Azure Monitor-functies kunt gebruiken om de bewakingsgegevens voor resourcelogboeken te analyseren en op te lossen die zijn gegenereerd door Azure SignalR.

De pagina Overzicht in Azure Portal voor elke Azure SignalR-service bevat een korte weergave van het resourcegebruik, zoals gelijktijdige verbindingen en het aantal berichten. Deze nuttige informatie is slechts een kleine hoeveelheid bewakingsgegevens die beschikbaar zijn in de portal. Sommige van deze gegevens worden automatisch verzameld en zijn beschikbaar voor analyse zodra u de resource maakt.

U kunt na enige configuratie andere typen gegevensverzameling inschakelen. In dit artikel wordt uitgelegd hoe u logboekgegevensverzameling configureert en analyseert en problemen met deze gegevens kunt oplossen met behulp van Azure Monitor-hulpprogramma's.

• Zie Azure SignalR Service bewaken voor meer informatie over het bewaken van Azure SignalR Service.
• Zie de naslaginformatie over bewakingsgegevens van Azure SignalR Service voor een gedetailleerd overzicht van de metrische gegevens en logboeken die zijn verzameld voor Azure SignalR Service.

Vereisten

Als u resourcelogboeken wilt inschakelen, moet u een locatie instellen voor het opslaan van uw logboekgegevens, zoals Azure Storage of Log Analytics.

• Azure Storage behoudt resourcelogboeken voor beleidscontrole, statische analyse of back-up.
• Log Analytics is een flexibel hulpprogramma voor zoeken en analyseren van logboeken waarmee onbewerkte logboeken kunnen worden geanalyseerd die door een Azure-resource worden gegenereerd.

Resourcelogboeken inschakelen

Azure SignalR Service ondersteunt connectiviteitslogboeken, berichtenlogboeken en Http-aanvraaglogboeken. Zie Resourcelogboekcategorieën voor meer informatie over deze typen logboeken. Logboeken worden opgeslagen in het opslagaccount dat is geconfigureerd in het deelvenster Diagnostische logboeken . Zie Gegevensopslag voor meer informatie over de opslagindeling en -velden.

Diagnostische instellingen maken

Resourcelogboeken zijn standaard uitgeschakeld. Zie Diagnostische instellingen maken in Azure Monitor om resourcelogboeken in te schakelen met behulp van diagnostische instellingen.

Query's uitvoeren op resourcelogboeken

Voer de volgende stappen uit om query's uit te voeren op resourcelogboeken:

1. Selecteer Logboeken in uw doellogboekanalyse.

   

2. Voer SignalRServiceDiagnosticLogs in en selecteer tijdsbereik. Zie Aan de slag met Log Analytics in Azure Monitor voor geavanceerde query's

   

Als u voorbeeldquery's voor Azure SignalR Service wilt gebruiken, voert u de volgende stappen uit:

1. Selecteer Logboeken in uw doellogboekanalyse.

2. Selecteer het tabblad Query's om queryverkenner te openen.

3. Selecteer Resourcetype om voorbeeldquery's in het resourcetype te groeperen.

4. Selecteer Uitvoeren om het script uit te voeren.

   

Zie Query's voor de tabel SignalRServiceDiagnosticLogs bijvoorbeeld voor de tabel SignalRServiceDiagnosticLogs.

Notitie

Namen van queryvelden voor opslagbestemmingen verschillen enigszins van veldnamen voor Log Analytics. Zie Tabeltoewijzing van resourcelogboeken voor meer informatie over de veldnaamtoewijzingen tussen Opslag- en Log Analytics-tabellen.

Problemen met resourcelogboeken oplossen

Als u problemen met Azure SignalR Service wilt oplossen, kunt u logboeken aan de server-/clientzijde inschakelen om fouten vast te leggen. Wanneer Azure SignalR Service resourcelogboeken weergeeft, kunt u gebruikmaken van resourcelogboeken om problemen met logboeken voor de service op te lossen.

Problemen met betrekking tot de verbinding

Wanneer u onverwacht verbindingen tegenkomt die onverwacht toenemen of dalen, kunt u profiteren van connectiviteitslogboeken om problemen op te lossen. Veelvoorkomende problemen zijn vaak onverwachte wijzigingen in de verbindingshoeveelheid, verbindingen bereiken verbindingslimieten en autorisatiefouten. In de volgende secties wordt beschreven hoe u problemen kunt oplossen.

Onverwacht verwijderen van verbinding

Als er onverwachte verbindingen worden verbroken, schakelt u eerst logboeken in service-, server- en clientzijden in.

Als een verbinding wordt verbroken, registreren de resourcelogboeken deze verbroken gebeurtenis en ziet ConnectionAborted of ConnectionEnded in operationName.

Het verschil tussen ConnectionAborted en ConnectionEnded is dat ConnectionEnded is een verwachte verbroken verbinding, die wordt geactiveerd door client- of serverzijde. Het ConnectionAborted is meestal een onverwachte gebeurtenis voor het verwijderen van de verbinding en de afgebroken reden wordt opgegeven in message.

De volgende tabel bevat de afgebroken redenen.

Reden	Beschrijving
Het aantal verbindingen bereikt de limiet	Het aantal verbindingen bereikt de limiet van uw huidige prijscategorie. Overweeg om service-eenheid omhoog te schalen
De verbinding met de toepassingsserver is verbroken	De app-server activeert de abortus. Het kan worden beschouwd als een verwachte abortus
Time-out voor ping van verbinding	Meestal wordt dit veroorzaakt door een netwerkprobleem. Overweeg om de beschikbaarheid van uw app-server vanaf internet te controleren
Service opnieuw laden, probeer opnieuw verbinding te maken	Azure SignalR Service wordt opnieuw geladen. Azure SignalR biedt ondersteuning voor automatisch opnieuw verbinden. U kunt wachten totdat u opnieuw verbinding maakt of handmatig opnieuw verbinding maakt met Azure SignalR Service
Tijdelijke fout op de interne server	Tijdelijke fout treedt op in Azure SignalR Service, moet automatisch worden hersteld
Serververbinding verbroken	Serververbinding daalt met onbekende fout, overweeg eerst zelf problemen op te lossen met service-/server-/clientlogboek. Probeer basisproblemen uit te sluiten (bijvoorbeeld netwerkprobleem, probleem aan de serverzijde van de app, enzovoort). Als het probleem niet is opgelost, neemt u contact met ons op voor meer hulp. Zie de sectie Help ophalen voor meer informatie.

Onverwachte verbinding groeit

Als u problemen met onverwachte verbindingen wilt oplossen, moet u eerst de extra verbindingen filteren. U kunt een unieke testgebruiker-id toevoegen aan uw testclientverbinding. Controleer de resourcelogboeken. Als u ziet dat meerdere clientverbindingen dezelfde testgebruikers-id of hetzelfde IP-adres hebben, maakt de client waarschijnlijk meer verbindingen dan verwacht. Controleer de clientzijde.

Autorisatiefout

Als er 401 Niet-geautoriseerd wordt geretourneerd voor clientaanvragen, controleert u de resourcelogboeken. Als u tegenkomt Failed to validate audience. Expected Audiences: <valid audience>. Actual Audiences: <actual audience>, betekent dit dat alle doelgroepen in uw toegangstoken ongeldig zijn. Probeer de geldige doelgroepen te gebruiken die in het logboek worden voorgesteld.

Beperking

Als u merkt dat u geen SignalR-clientverbindingen met Azure SignalR Service tot stand kunt brengen, controleert u de resourcelogboeken. Als u in het resourcelogboek te maken Connection count reaches limit krijgt, brengt u te veel verbindingen tot stand met SignalR Service, die de limiet voor het aantal verbindingen bereiken. Overweeg om uw SignalR-service omhoog te schalen. Als u in het resourcelogboek tegenkomt Message count reaches limit , betekent dit dat u de gratis laag gebruikt en dat u het quotum van berichten hebt gebruikt. Als u meer berichten wilt verzenden, kunt u overwegen om uw SignalR-service te wijzigen in de standard-laag. Zie prijzen voor Azure SignalR Service voor meer informatie.

Problemen met betrekking tot berichten

Wanneer u problemen ondervindt met betrekking tot berichten, kunt u gebruikmaken van berichtenlogboeken om problemen op te lossen. Schakel eerst resourcelogboeken in in service en logboeken voor server en client.

Notitie

Voor ASP.NET Core raadpleegt u hier om logboekregistratie in te schakelen op de server en client.

Zie voor ASP.NET hier om logboekregistratie in te schakelen op de server en client.

Als u geen rekening houdt met mogelijke prestatie-effecten en geen bericht over de richting van de client naar de server, schakelt u het Messaging in Log Source Settings/Types om het verzamelen van alle logboeken in te schakelen. Zie Alles verzamelen voor meer informatie over dit gedrag.

Schakel anders het Messaging selectievakje uit om het verzamelen van logboeken gedeeltelijk in te schakelen. Dit gedrag vereist configuratie in client en server om dit in te schakelen. Zie Verzamelen gedeeltelijk voor meer informatie.

Berichtverlies

Als u problemen ondervindt met het verlies van berichten, is de sleutel om de plaats te vinden waar u het bericht kwijtraakt. In principe hebt u drie onderdelen bij het gebruik van Azure SignalR Service: SignalR-service, -server en -client. Zowel de server als de client zijn verbonden met SignalR-service, maar maken niet rechtstreeks verbinding met elkaar zodra de onderhandeling is voltooid. Daarom moet u twee richtingen voor berichten overwegen en voor elke richting moet u twee paden overwegen:

• Van client naar server via SignalR-service
  • Pad 1: Client naar SignalR-service
  • Pad 2: SignalR-service naar server
• Van server naar client via SignalR-service
  • Pad 3: Server naar SignalR-service
  • Pad 4: SignalR-service naar client

Voor het verzamelen van alle verzamelgedrag:

Azure SignalR Service traceert alleen berichten in de richting van de server naar de client via SignalR-service. De tracerings-id wordt gegenereerd op de server. Het bericht bevat de tracerings-id naar de SignalR-service.

Notitie

Als u berichten wilt traceren en berichten wilt verzenden van buiten een hub in uw app-server, moet u het verzamelen van alle verzamelgedrag inschakelen voor het verzamelen van berichtenlogboeken voor de berichten die niet afkomstig zijn van diagnostische clients. Diagnostische clients werken voor zowel het verzamelen van alle en het gedeeltelijk verzamelen van gedrag, maar heeft een hogere prioriteit voor het verzamelen van logboeken. Zie de sectie diagnostische client voor meer informatie.

Door de aanmeldingsserver en de servicezijde te controleren, kunt u eenvoudig achterhalen of het bericht wordt verzonden vanaf de server, aankomt bij signalR-service en vertrekt van signalR-service. In principe kunt u door te controleren of het ontvangen en verzonden bericht overeenkomt of niet op basis van de tracerings-id van berichten, zien of het probleem met het verlies van berichten zich in deze richting in de server- of SignalR-service bevindt. Zie de onderstaande details voor meer informatie.

Voor het verzamelen van gedeeltelijk verzamelen gedrag:

Zodra u de client als diagnostische client markeert, traceert Azure SignalR Service berichten in beide richtingen.

Door de aanmeldingsserver en servicezijde te controleren, kunt u eenvoudig achterhalen of het bericht de server of SignalR-service doorgeeft. In principe kunt u zien of het ontvangen en verzonden bericht overeenkomt of niet op basis van de tracerings-id van berichten, kunt u zien of het probleem met het verlies van berichten zich in de server- of SignalR-service bevindt. Zie de volgende details voor meer informatie.

Details van de berichtstroom

Voor de richting van client naar server via SignalR-service, beschouwt SignalR-service alleen de aanroep die afkomstig is van de diagnostische client, dat wil gezegd, het bericht dat rechtstreeks in de diagnostische client wordt gegenereerd of het servicebericht dat is gegenereerd vanwege de aanroep van de diagnostische client indirect.

De tracerings-id wordt gegenereerd in de SignalR-service zodra het bericht binnenkomt bij signalr-service in Path 1. SignalR-service genereert een logboek Received a message <MessageTracingId> from client connection <ConnectionId>. voor elk bericht in de diagnostische client. Zodra het bericht van signalr naar server vertrekt, genereert SignalR-service een logboekbericht Sent a message <MessageTracingId> to server connection <ConnectionId> successfully.. Als u deze twee logboeken ziet, kunt u er zeker van zijn dat het bericht is doorgegeven via de SignalR-service.

Notitie

Vanwege de beperking van ASP.NET Core SignalR bevat het bericht geen id op berichtniveau, maar ASP.NET SignalR genereert aanroep-id voor elk bericht. U kunt deze gebruiken om toe te wijzen met de tracerings-id.

Vervolgens bevat het bericht de tracerings-id-server in pad 2. Server genereert een logboek Received message <messagetracingId> from client connection <connectionId> zodra het bericht binnenkomt.

Zodra het bericht de hubmethode op de server aanroept, wordt er een nieuw servicebericht gegenereerd met een nieuwe tracerings-id. Zodra het servicebericht is gegenereerd, genereert de server een aanmeldingssjabloon Start to broadcast/send message <MessageTracingId> .... Het werkelijke logboek is gebaseerd op uw scenario. Vervolgens wordt het bericht bezorgd bij de SignalR-service in Path 3. Zodra het servicebericht van de server verlaat, wordt er een aangeroepen Succeeded to send message <MessageTracingId> logboek gegenereerd.

Notitie

De tracerings-id van het bericht van de client kan niet worden toegewezen aan de tracerings-id van het servicebericht dat moet worden verzonden naar de SignalR-service.

Zodra het servicebericht bij SignalR-service aankomt, wordt er een aangeroepen Received a <MessageType> message <MessageTracingId> from server connection <ConnectionId>. logboek gegenereerd. Vervolgens verwerkt de SignalR-service het servicebericht en levert deze aan de doelclient(s). Zodra het bericht is verzonden naar de client(s) in Pad 4, wordt het logboek Sent a message <MessageTracingId> to client connection <ConnectionId> successfully. gegenereerd.

Kortom, het berichtenlogboek wordt gegenereerd wanneer het bericht binnen en uit de SignalR-service en -server gaat. U kunt deze logboeken gebruiken om te controleren of het bericht verloren gaat in deze onderdelen of niet.

Het volgende voorbeeld is een typisch probleem met verlies van berichten.

Een client ontvangt geen berichten in een groep

Het typische verhaal in dit probleem is dat de client lid wordt van een groep nadat een groepsbericht is verzonden.

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

Iemand kan bijvoorbeeld aanroepen van een joingroep maken en een groepsbericht verzenden in dezelfde hubmethode. Het probleem hier is een AddToGroupAsync async methode. Omdat er geen await wacht totdat AddToGroupAsync het is voltooid, wordt het groepsbericht verzonden voordat AddToGroupAsync het is voltooid. Als gevolg van netwerkvertraging en de vertraging van het proces voor het toevoegen van een client aan een bepaalde groep, kan de actie joingroep later worden voltooid dan de bezorging van groepsberichten. Als dat het geval is, heeft het eerste groepsbericht geen client als ontvanger, omdat er geen client lid is geworden van de groep, waardoor het een probleem wordt dat verloren gaat.

Zonder resourcelogboeken kunt u niet achterhalen wanneer de client lid wordt van de groep en wanneer het groepsbericht wordt verzonden. Zodra u berichtenlogboeken hebt ingeschakeld, kunt u het bericht dat binnenkomt in signalr-service vergelijken. Ga als volgt te werk om problemen op te lossen:

1. Zoek de berichtenlogboeken op de server om te vinden wanneer de client lid is van de groep en wanneer het groepsbericht wordt verzonden.
2. Haal de berichttracerings-id A op van deelname aan de groep en de berichttracerings-id B van het groepsbericht uit de berichtenlogboeken.
3. Filter deze berichttracerings-id tussen berichtenlogboeken in het doel van het logboekarchief en vergelijk vervolgens de binnenkomende tijdstempels. U vindt welk bericht het eerst in signalR-service is aangekomen.
4. Als berichttracerings-id A later is dan B binnenkomt, moet u een groepsbericht verzenden voordat de client deelneemt aan de groep. U moet ervoor zorgen dat de client zich in de groep bevindt voordat u groepsberichten verzendt.

Als een bericht verloren gaat in SignalR of server, probeert u de waarschuwingslogboeken op te halen op basis van de tracerings-id van het bericht om de reden op te halen. Als u meer hulp nodig hebt, raadpleegt u de sectie Help ophalen.

Resourcelogboeken verzamelen gedrag

Er zijn twee typische scenario's voor het gebruik van resourcelogboeken, met name voor berichtenlogboeken.

Iemand kan zich zorgen maken over de kwaliteit van elk bericht. Ze zijn bijvoorbeeld gevoelig voor of het bericht is verzonden/ontvangen of ze willen elk bericht opnemen dat wordt bezorgd via signalr-service.

In de tussentijd kunnen anderen zich zorgen maken over de prestaties. Ze zijn gevoelig voor de latentie van het bericht en soms moeten ze het bericht in een paar verbindingen bijhouden in plaats van alle verbindingen om een of andere reden.

Daarom biedt SignalR-service twee soorten verzamelgedrag

• alles verzamelen: logboeken verzamelen in alle verbindingen
• gedeeltelijk verzamelen: logboeken verzamelen in bepaalde specifieke verbindingen

Notitie

Om de verbindingen tussen die logboeken te verzamelen en die geen logboeken verzamelen, behandelt SignalR een bepaalde client als diagnostische client op basis van de diagnostische clientconfiguraties van de server en client, waarin de resourcelogboeken altijd worden verzameld, terwijl de andere niet. Zie de sectie Gedeeltelijk verzamelen voor meer informatie.

Alles verzamelen

Resourcelogboeken worden verzameld door alle verbindingen. Neem bijvoorbeeld berichtenlogboeken. Wanneer dit gedrag is ingeschakeld, stuurt SignalR-service een melding naar de server om tracerings-id voor elk bericht te genereren. De tracerings-id wordt in het bericht naar de service verzonden. De service registreert ook het bericht met tracerings-id.

Notitie

Let op: om ervoor te zorgen dat de prestaties van de SignalR-service niet worden verwacht en geparseerd, wordt het hele bericht dat vanaf de client wordt verzonden, niet geparseerd. Daarom worden de clientberichten niet geregistreerd. Als de client is gemarkeerd als een diagnostische client, wordt het clientbericht geregistreerd in signalr-service.

Configuratiehandleiding

Als u dit gedrag wilt inschakelen, schakelt u het selectievakje in de sectie Typen in de instellingen van de logboekbron in.

Dit gedrag vereist niet dat u configuraties aan de serverzijde bijwerkt. Deze configuratiewijziging wordt altijd automatisch naar de server verzonden.

Gedeeltelijk verzamelen

Resourcelogboeken worden alleen verzameld door diagnostische clients. Alle berichten worden geregistreerd, inclusief clientberichten en connectiviteitsgebeurtenissen in de diagnostische clients.

Notitie

De limiet van het aantal diagnostische clients is 100. Als het aantal diagnostische clients groter is dan 100, worden de niet-genummerde diagnostische clients beperkt door de SignalR-service. De nieuwe maar niet-genummerde clients kunnen geen verbinding maken met de SignalR-service en gooien System.Net.Http.HttpRequestException, die het bericht Response status code does not indicate success: 429 (Too Many Requests)bevat. De al verbonden clients werken zonder dat dit wordt beïnvloed door het beperkingsbeleid.

Diagnostische client

Diagnostische client is een logisch concept. Elke client kan een diagnostische client zijn. De server bepaalt welke client een diagnostische client kan zijn. Zodra een client is gemarkeerd als een diagnostische client, worden alle resourcelogboeken ingeschakeld in deze client. Als u een client wilt instellen als een diagnostische client, raadpleegt u de configuratiehandleiding.

Configuratiehandleiding

Als u dit gedrag wilt inschakelen, moet u de service, server en clientzijde configureren.

Servicezijde

Als u dit gedrag wilt inschakelen, schakelt u het selectievakje voor een specifiek logboektype uit in de sectie Typen in de instellingen van de logboekbron.

Serverzijde

U kunt ServiceOptions.DiagnosticClientFilter ook een filter van diagnostische clients definiëren op basis van de HTTP-context van clients. Maak bijvoorbeeld de client met de hub-URL <HUB_URL>?diag=yesen stel deze in ServiceOptions.DiagnosticClientFilter om de diagnostische client te filteren. Als deze wordt geretourneerd true, wordt de client gemarkeerd als diagnostische client. Anders blijft het als normale client. U ServiceOptions.DiagnosticClientFilter kunt deze als volgt instellen in uw opstartklasse:

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

Clientzijde

Markeer de client als diagnostische client door de HTTP-context te configureren. De client wordt bijvoorbeeld gemarkeerd als diagnostische client door de querytekenreeks diag=yestoe te voegen.

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

Hulp vragen

U wordt aangeraden eerst zelf problemen op te lossen. De meeste problemen worden veroorzaakt door problemen met de app-server of het netwerk. Volg de handleiding voor probleemoplossing met resourcelogboeken en basisgids voor probleemoplossing om de hoofdoorzaak te vinden. Als het probleem nog steeds niet kan worden opgelost, kunt u een probleem openen in GitHub of een ticket maken in Azure Portal. Geef op:

1. Tijdsbereik ongeveer 30 minuten wanneer het probleem optreedt
2. Resource-id van Azure SignalR Service
3. Details van het probleem, zo specifiek mogelijk: appserver verzendt bijvoorbeeld geen berichten, clientverbindingsuitval, enzovoort
4. Logboeken die zijn verzameld van server-/clientzijde en ander materiaal dat nuttig kan zijn
5. [Optioneel] Code opnieuwprocode

Notitie

Als u een probleem opent in GitHub, houdt u uw gevoelige informatie (bijvoorbeeld resource-id, server-/clientlogboeken) privé. Alleen privé verzenden naar leden in de Microsoft-organisatie.