Dela via

Så här felsöker du problem med anslutning och meddelandeleverans

  • Artikel

Den här vägledningen beskriver flera sätt att göra självdiagnostik för att hitta rotorsaken direkt eller begränsa problemet. Självdiagnosresultatet är också användbart när du rapporterar det till oss för vidare undersökning.

Först måste du kontrollera från Azure Portal vilken ServiceMode är Azure SignalR Service (även kallat ASRS) som konfigurerats för.

ServiceMode

För det andra måste du samla in tjänstspårningar för att felsöka. Information om hur du samlar in spårningar finns i Så här avbildar du tjänstspårningar.

Har du problem eller feedback om felsökningen? Berätta för oss.

Så här samlar du in tjänstspårningar

För att förenkla felsökningsprocessen tillhandahåller Azure SignalR-tjänsten livespårningsverktyg för att exponera tjänstspårningar i anslutnings- och meddelandekategorier . Spårningarna omfattar men är inte begränsade till anslutningsanslutna/frånkopplade händelser och mottagna/vänstra händelser. Med livespårningsverktyget kan du samla in, visa, sortera, filtrera och exportera livespårningar. Mer information finns i Så här använder du livespårningsverktyget.

Har du problem eller feedback om felsökningen? Berätta för oss.

Felsökning av standardläge

När ASRS är i standardläge finns det tre roller: Klient, Server och Tjänst:

  • Klient: Klienten står för klienter som är anslutna till ASRS. Beständiga anslutningar som ansluter klienten och ASRS kallas klientanslutningar i den här vägledningen.

  • Server: Servern står för den server som hanterar klientförhandling och är värd för SignalR-logik Hub . Och de beständiga anslutningarna mellan Server och ASRS kallas serveranslutningar i den här vägledningen.

  • Tjänst: Tjänsten är det korta namnet på ASRS i den här vägledningen.

Se Internals of Azure SignalR Service (Internt i Azure SignalR Service) för detaljerad introduktion av hela arkitekturen och arbetsflödet.

Det finns flera sätt som kan hjälpa dig att begränsa problemet.

  • Om problemet inträffar på rätt sätt eller om den kan återskapas är det raka sättet att visa den pågående trafiken.

  • Om problemet är svårt att återskapa kan spårningar och loggar hjälpa dig.

Så här visar du trafiken och begränsar problemet

Att fånga den pågående trafiken är det enklaste sättet att begränsa problemet. Du kan avbilda nätverksspårningarna med hjälp av de alternativ som beskrivs nedan:

Klientbegäranden

För en beständig SignalR-anslutning omdirigeras den först /negotiate till din värdbaserade appserver och omdirigeras sedan till Azure SignalR-tjänsten och upprättar sedan den verkliga beständiga anslutningen till Azure SignalR-tjänsten. Mer information finns i Internals of Azure SignalR Service (Internt i Azure SignalR Service).

Med nätverksspårningen på klientsidan i handen kontrollerar du vilken begäran som misslyckas med vilken statuskod och vilket svar och letar efter lösningar i felsökningsguiden.

Serverbegäranden

SignalR Server underhåller serveranslutningen mellan server och tjänst. När appservern startar startar den WebSocket-anslutningen till Azure SignalR-tjänsten. Alla klienttrafik dirigeras via Azure SignalR-tjänsten till dessa serveranslutningaroch skickas sedan till Hub. När en serveranslutning avbryts påverkas klienterna som dirigeras till den här serveranslutningen . Vår Azure SignalR SDK har logiken "Försök alltid igen" för att återansluta serveranslutningen med högst 1 minuts fördröjning för att minimera effekterna.

Serveranslutningarkan minska på grund av instabilitet i nätverket eller regelbundet underhåll av Azure SignalR Service eller dina värdbaserade programserveruppdateringar/-underhåll. Så länge klientsidan har mekanismen för frånkoppling/återanslutning är effekten minimal som alla klientsidan orsakade frånkopplings-återanslutning.

Visa nätverksspårningen på serversidan för att hitta statuskoden och felinformationen varför Serveranslutningen avbryts eller avvisas av tjänsten. Leta efter rotorsaken i felsökningsguiden.

Har du problem eller feedback om felsökningen? Berätta för oss.

Så här lägger du till loggar

Loggar kan vara användbara för att diagnostisera problem och övervaka körningsstatusen.

Så här aktiverar du logg på klientsidan

Loggningsupplevelsen på klientsidan är exakt densamma som när du använder lokalt installerad SignalR.

Aktivera loggning på klientsidan för ASP.NET Core SignalR
Aktivera loggning på klientsidan för ASP.NET SignalR

Så här aktiverar du logg på serversidan

Aktivera loggning på serversidan för ASP.NET Core SignalR

Loggning på serversidan för ASP.NET Core SignalR integrering med den ILogger baserade loggning som tillhandahålls i ramverket ASP.NET Core . Du kan aktivera loggning på serversidan med hjälp ConfigureLoggingav , en exempelanvändning på följande sätt:

.ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddConsole();
            logging.AddDebug();
        })

Loggningskategorier för Azure SignalR börjar alltid med Microsoft.Azure.SignalR. Om du vill aktivera detaljerade loggar från Azure SignalR konfigurerar du de föregående prefixen till Information nivå i din appsettings.json-fil som nedan:

{
    "Logging": {
        "LogLevel": {
            ...
            "Microsoft.Azure.SignalR": "Information",
            ...
        }
    }
}

Kontrollera om det finns några onormala varnings-/felloggar registrerade.

Aktivera spårningar på serversidan för ASP.NET SignalR

När du använder SDK-versionen >= 1.0.0kan du aktivera spårningar genom att lägga till följande i web.config: (Information)

<system.diagnostics>
    <sources>
      <source name="Microsoft.Azure.SignalR" switchName="SignalRSwitch">
        <listeners>
          <add name="ASRS" />
        </listeners>
      </source>
    </sources>
    <!-- Sets the trace verbosity level -->
    <switches>
      <add name="SignalRSwitch" value="Information" />
    </switches>
    <!-- Specifies the trace writer for output -->
    <sharedListeners>
      <add name="ASRS" type="System.Diagnostics.TextWriterTraceListener" initializeData="asrs.log.txt" />
    </sharedListeners>
    <trace autoflush="true" />
  </system.diagnostics>

Kontrollera om det finns några onormala varnings-/felloggar registrerade.

Så här aktiverar du loggar i Azure SignalR-tjänsten

Du kan också aktivera diagnostikloggar för Azure SignalR-tjänsten. Dessa loggar innehåller detaljerad information om varje anslutning som är ansluten till Azure SignalR-tjänsten.

Har du problem eller feedback om felsökningen? Berätta för oss.

Felsökning av serverlöst läge

När ASRS är i serverlöst läge stöder Serverless endast ASP.NET Core SignalR läge och ASP.NET SignalR stöder INTE det här läget.

För att diagnostisera anslutningsproblem i Serverless läge är det enklaste sättet att visa trafik på klientsidan. Aktivera loggar på klientsidan och loggar på tjänstsidan kan också vara till hjälp.

Har du problem eller feedback om felsökningen? Berätta för oss.

Felsökning av klassiskt läge

Classic läget är föråldrat och uppmuntras inte att använda. I klassiskt läge använder Azure SignalR-tjänsten anslutna serveranslutningar för att avgöra om den aktuella tjänsten är i default läge eller serverless läge. Klassiskt läge kan leda till problem med mellanliggande klientanslutningar eftersom Azure SignalR, när det plötsligt uppstår en plötslig minskning av all ansluten serveranslutning, till exempel på grund av instabilitet i nätverket, tror att den nu växlas till serverless läge och klienter som är anslutna under den här perioden aldrig dirigeras till den värdbaserade appservern. Aktivera loggar på tjänstsidan och kontrollera om det finns några klienter som registrerats som ServerlessModeEntered om du har en värdbaserad appserver, men vissa klienter når aldrig appserversidan. Om du ser någon av dessa klienter avbryter du klientanslutningarna och låter sedan klienterna starta om.

Problem med felsökningslägets classic anslutning och meddelandeleverans liknar felsökning av standardlägesproblem.

Har du problem eller feedback om felsökningen? Berätta för oss.

Service Health:

Du kan kontrollera hälso-API:et för tjänsthälsa.

  • Begäran: GET https://{instance_name}.service.signalr.net/api/v1/health

  • Svarsstatuskod:

    • 200: frisk.
    • 503: tjänsten är inte felfri. Du kan:
      • Vänta i flera minuter på automatisk återställning.
      • Kontrollera att ip-adressen är samma som ip-adressen från portalen.
      • Eller starta om instansen.
      • Om alla ovanstående alternativ inte fungerar kontaktar du oss genom att lägga till en ny supportbegäran i Azure Portal.

Mer om haveriberedskap.

Har du problem eller feedback om felsökningen? Berätta för oss.

Nästa steg

I den här guiden har du lärt dig hur du felsöker problem med anslutning och meddelandeleverans. Du kan också lära dig hur du hanterar vanliga problem.

Felsökningsguide