Delen via

Connectiviteits- en berichtbezorgingsproblemen oplossen

  • Artikel

In deze richtlijnen worden verschillende manieren geïntroduceerd om zelfdiagnose uit te voeren om de hoofdoorzaak rechtstreeks te vinden of het probleem te beperken. Het zelfdiagnoseresultaat is ook nuttig bij het rapporteren ervan voor verder onderzoek.

Eerst moet u controleren in de Azure-portal waarnaar ServiceMode de Azure SignalR-service (ook wel ASRS genoemd) is geconfigureerd.

ServiceMode

Ten tweede moet u servicetraceringen vastleggen om problemen op te lossen. Raadpleeg servicetraceringen vastleggen voor informatie over het vastleggen van traceringen.

Hebt u problemen of feedback over de probleemoplossing? Laat het ons weten.

Servicetraceringen vastleggen

Om het probleemoplossingsproces te vereenvoudigen, biedt de Azure SignalR-service een hulpprogramma voor live tracering om servicetraceringen beschikbaar te maken voor connectiviteits - en berichtencategorieën . De traceringen omvatten, maar zijn niet beperkt tot verbonden/verbroken gebeurtenissen en ontvangen/linkse berichten. Met live traceringshulpprogramma kunt u livetraceringen vastleggen, weergeven, sorteren, filteren en exporteren. Zie Het hulpprogramma Live Trace gebruiken voor meer informatie.

Hebt u problemen of feedback over de probleemoplossing? Laat het ons weten.

Problemen met de standaardmodus oplossen

Wanneer ASRS zich in de standaardmodus bevindt, zijn er drie rollen: Client, Server en Service:

  • Client: Client staat voor de clients die zijn verbonden met ASRS. De permanente verbindingen die client en ASRS verbinden, worden client-Verbinding maken ionen genoemd in deze richtlijnen.

  • Server: Server staat voor de server die fungeert voor clientonderhandeling en host SignalR-logicaHub. En de permanente verbindingen tussen Server en ASRS worden Server Verbinding maken ions genoemd in deze richtlijnen.

  • Service: Service is de korte naam voor ASRS in deze richtlijnen.

Raadpleeg Internals van Azure SignalR Service voor de gedetailleerde introductie van de hele architectuur en werkstroom.

Er zijn verschillende manieren waarmee u het probleem kunt beperken.

  • Als het probleem zich direct voordoet of opnieuw kan worden uitgevoerd, is de rechte weg om het lopende verkeer te bekijken.

  • Als het probleem moeilijk te repropro's is, kunnen traceringen en logboeken helpen.

Het verkeer weergeven en het probleem beperken

Het vastleggen van het lopende verkeer is de meest eenvoudige manier om het probleem te beperken. U kunt de netwerktraceringen vastleggen met behulp van de onderstaande opties:

Aanvragen van clients

Voor een permanente SignalR-verbinding wordt deze eerst /negotiate naar uw gehoste app-server geleid en vervolgens omgeleid naar de Azure SignalR-service en wordt vervolgens de echte permanente verbinding met de Azure SignalR-service tot stand gebracht. Raadpleeg Internals of Azure SignalR Service voor de gedetailleerde stappen.

Met de netwerktracering aan de clientzijde controleert u welke aanvraag mislukt met welke statuscode en welk antwoord, en zoekt u naar oplossingen in de gids voor probleemoplossing.

Serveraanvragen

SignalR Server onderhoudt de server Verbinding maken ion tussen server en service. Wanneer de app-server wordt gestart, wordt de WebSocket-verbinding met de Azure SignalR-service gestart. Alle clientverkeer wordt gerouteerd via de Azure SignalR-service naar deze Server Verbinding maken ions en vervolgens verzonden naar de Hub. Wanneer een server Verbinding maken ion wordt gedaald, worden de clients die naar deze server worden doorgestuurd, beïnvloed Verbinding maken ion. Onze Azure SignalR SDK heeft een logica 'Altijd opnieuw proberen' om opnieuw verbinding te maken met de server Verbinding maken ion met maximaal 1 minuut vertraging om de effecten te minimaliseren.

Server Verbinding maken ions kan dalen vanwege netwerkinstabiliteit of regelmatig onderhoud van Azure SignalR Service, of uw gehoste app-serverupdates/onderhoud. Zolang de clientzijde het mechanisme voor verbinding verbreken/opnieuw verbinden heeft, is het effect minimaal, net als elke clientzijde veroorzaakt dat de verbinding opnieuw tot stand is gebracht.

Bekijk de netwerktracering aan de serverzijde om de statuscode en foutdetails te vinden waarom Server Verbinding maken ion wordt afgeslagen of geweigerd door de Service. Zoek de hoofdoorzaak in de gids voor probleemoplossing.

Hebt u problemen of feedback over de probleemoplossing? Laat het ons weten.

Logboeken toevoegen

Logboeken kunnen handig zijn om problemen vast te stellen en de actieve status te bewaken.

Logboek aan clientzijde inschakelen

Logboekregistratie aan de clientzijde is precies hetzelfde als bij het gebruik van zelf-hostende SignalR.

Logboekregistratie aan clientzijde inschakelen voor ASP.NET Core SignalR
Logboekregistratie aan clientzijde inschakelen voor ASP.NET SignalR

Logboek aan serverzijde inschakelen

Logboekregistratie aan serverzijde inschakelen voor ASP.NET Core SignalR

Logboekregistratie aan de serverzijde voor ASP.NET Core SignalR integratie met de logboekregistratie op basis van het ILoggerASP.NET Core framework. U kunt logboekregistratie aan de serverzijde als volgt inschakelen met behulp van ConfigureLoggingeen voorbeeldgebruik:

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

Logboekregistratiecategorieën voor Azure SignalR beginnen altijd met Microsoft.Azure.SignalR. Als u gedetailleerde logboeken van Azure SignalR wilt inschakelen, configureert u de voorgaande voorvoegsels die Information u in uw bestand appsettings.json wilt e-mailen, zoals hieronder:

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

Controleer of er abnormale waarschuwings- en foutlogboeken zijn vastgelegd.

Traceringen aan de serverzijde inschakelen voor ASP.NET SignalR

Wanneer u SDK-versie >= 1.0.0gebruikt, kunt u traceringen inschakelen door het volgende toe te voegen aan web.config: (Details)

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

Controleer of er abnormale waarschuwings- en foutlogboeken zijn vastgelegd.

Logboeken inschakelen in Azure SignalR-service

U kunt ook diagnostische logboeken inschakelen voor de Azure SignalR-service. Deze logboeken bieden gedetailleerde informatie over elke verbinding die is verbonden met de Azure SignalR-service.

Hebt u problemen of feedback over de probleemoplossing? Laat het ons weten.

Problemen met serverloze modus oplossen

Wanneer ASRS zich in de serverloze modus bevindt, ondersteunt Serverless alleen ASP.NET Core SignalR de modus en ASP.NET SignalRdeze modus niet ondersteunt.

Om connectiviteitsproblemen in Serverless de modus vast te stellen, is de meest directe manier om verkeer aan de clientzijde weer te geven. Logboeken aan de clientzijde en logboeken aan de servicezijde inschakelen, kan ook handig zijn.

Hebt u problemen of feedback over de probleemoplossing? Laat het ons weten.

Problemen met klassieke modus oplossen

Classic de modus is verouderd en wordt niet aangemoedigd om te gebruiken. Wanneer de Azure SignalR-service zich in de klassieke modus bevindt, worden de verbonden server-Verbinding maken ionen gebruikt om te bepalen of de huidige service zich in default de modus of serverless modus bevindt. Klassieke modus kan leiden tot tussenliggende problemen met clientconnectiviteit, omdat, wanneer er plotseling een daling is van alle verbonden server Verbinding maken ion, bijvoorbeeld vanwege netwerkinstabiliteit, Azure SignalR denkt dat deze nu is overgeschakeld naar serverless de modus en clients die tijdens deze periode zijn verbonden, nooit worden doorgestuurd naar de gehoste app-server. Schakel logboeken aan de servicezijde in en controleer of er clients zijn geregistreerd alsof ServerlessModeEntered u een gehoste app-server hebt, maar sommige clients bereiken nooit de serverzijde van de app. Als u een van deze clients ziet, verwijdert u de clientverbindingen en laat u de clients opnieuw opstarten.

Connectiviteitsmodus classic en problemen met berichtbezorging zijn vergelijkbaar met het oplossen van problemen met de standaardmodus.

Hebt u problemen of feedback over de probleemoplossing? Laat het ons weten.

Status van service

U kunt de status-API controleren op servicestatus.

  • Aanvraag: GET https://{instance_name}.service.signalr.net/api/v1/health

  • Antwoordstatuscode:

    • 200: gezond.
    • 503: uw service is beschadigd. U kunt:
      • Wacht enkele minuten tot autoherstel is uitgevoerd.
      • Controleer of het IP-adres hetzelfde is als het IP-adres van de portal.
      • Of start het exemplaar opnieuw op.
      • Als alle bovenstaande opties niet werken, neemt u contact met ons op door een nieuwe ondersteuningsaanvraag toe te voegen in Azure Portal.

Meer informatie over herstel na noodgevallen.

Hebt u problemen of feedback over de probleemoplossing? Laat het ons weten.

Volgende stappen

In deze handleiding hebt u geleerd hoe u connectiviteits- en berichtbezorgingsproblemen kunt oplossen. U kunt ook leren hoe u de veelvoorkomende problemen kunt afhandelen.

Handleiding voor het oplossen van problemen