Hibaelhárítási útmutató az Azure SignalR Service gyakori problémáihoz

Ez a cikk hibaelhárítási útmutatást nyújt az ügyfelek által esetleg előforduló gyakori problémákhoz.

Túl hosszú hozzáférési jogkivonat

Lehetséges hibák

• Ügyféloldali ERR_CONNECTION_
• 414 URI túl hosszú
• 413 Túl nagy hasznos adat
• A hozzáférési jogkivonat nem lehet hosszabb 4K-nál. 413 Kérelem entitás túl nagy

Gyökérok

HTTP/2 esetén az egyetlen fejléc maximális hossza 4 K, ezért ha böngészőt használ az Azure-szolgáltatás eléréséhez, hiba lép ERR_CONNECTION_ fel ebben a korlátozásban.

HTTP/1.1 vagy C#-ügyfelek esetén az URI maximális hossza 12 K, a fejléc maximális hossza 16 K.

Az SDK 1.0.6-os vagy újabb verziójával akkor jelenik 413 Payload Too Large meg, /negotiate ha a létrehozott hozzáférési jogkivonat nagyobb, mint 4 K.

Megoldás

Alapértelmezés szerint a jogcímek context.User.Claims az ASRS-hez (Azure SignalRService) való JWT-hozzáférési jogkivonat létrehozásakor jelennek meg, így a jogcímek megmaradnak, és átadhatók az ASRS-bőlarra az Hub ügyfélre, amikor az ügyfél csatlakozik a .Hub

Bizonyos esetekben context.User.Claims az alkalmazáskiszolgálók sok információt tárolnak, amelyek többségét nem az s, hanem más összetevők használják Hub.

A létrehozott hozzáférési jogkivonatot a rendszer a hálózaton keresztül továbbítja, és a WebSocket/S Standard kiadás kapcsolatok esetében a hozzáférési jogkivonatok lekérdezési sztringeken keresztül lesznek átadva. Ezért ajánlott eljárásként javasoljuk, hogy csak akkor adja át a szükséges jogcímeket az ügyféltől az ASRS-eken keresztül az alkalmazáskiszolgálóra, amikor a központnak szüksége van rá.

ClaimsProvider A hozzáférési jogkivonaton belül testre szabhatja az ASRS-nek átadott jogcímeket.

ASP.NET Core esetén:

services.AddSignalR()
        .AddAzureSignalR(options =>
            {
                // pick up necessary claims
                options.ClaimsProvider = context => context.User.Claims.Where(...);
            });

ASP.NET esetén:

services.MapAzureSignalR(GetType().FullName, options =>
            {
                // pick up necessary claims
                options.ClaimsProvider = context.Authentication?.User.Claims.Where(...);
            });

Problémák vagy visszajelzés a hibaelhárításról? Tudassa velünk.

TLS 1.2 szükséges

Lehetséges hibák

• ASP.NET "Nincs kiszolgáló elérhető" hiba #279
• ASP.NET "A kapcsolat nem aktív, az adatok nem küldhetők el a szolgáltatásnak." hiba # 324
• "Hiba történt a HTTP-kérés küldése közben.https://<API endpoint> Ennek a hibának az lehet az oka, hogy a kiszolgálótanúsítvány a HTTPS-esetben nem megfelelően van konfigurálva a HTTP.SYS-vel. Ezt a hibát az is okozhatja, hogy a biztonsági kötés nem egyezik az ügyfél és a kiszolgáló között."

Gyökérok

Az Azure Service csak a TLS1.2-t támogatja biztonsági okokból. A .NET-keretrendszer esetében előfordulhat, hogy a TLS1.2 nem az alapértelmezett protokoll. Ennek eredményeképpen az ASRS-kiszolgálókapcsolatok nem hozhatók létre sikeresen.

Troubleshooting guide

1. Ha ez a hiba helyileg reprodukálható, törölje a jelet a Csak saját kód jelölőnégyzetből, és dobja ki az összes CLR-kivételt, és helyileg hibakeresést végezhet az alkalmazáskiszolgálón, hogy lássa, milyen kivételt okoz.

   • Csak a saját kód jelölésének törlése

     

   • CLR-kivételek dobás

     

   • Tekintse meg az alkalmazás kiszolgálóoldali kódjának hibakeresése során megjelenő kivételeket:

     

2. Az ASP.NET esetén a részletes nyomkövetés engedélyezéséhez és a napló hibáinak megtekintéséhez Startup.cs a következő kódot is hozzáadhatja a sajátjához.

   app.MapAzureSignalR(this.GetType().FullName);
   // Make sure this switch is called after MapAzureSignalR
   GlobalHost.TraceManager.Switch.Level = SourceLevels.Information;
   

Megoldás

Adja hozzá a következő kódot az indításhoz:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Problémák vagy visszajelzés a hibaelhárításról? Tudassa velünk.

A rendszer 400 – Hibás kérések hibaüzenetet ad vissza az ügyfélkérésekre

Gyökérok

Ellenőrizze, hogy az ügyfélkérés több hub lekérdezési sztringgel rendelkezik-e. hub egy megőrzött lekérdezési paraméter, és a 400 akkor jelenik meg, ha a szolgáltatás egynél hub több lekérdezést észlel.

Problémák vagy visszajelzés a hibaelhárításról? Tudassa velünk.

A rendszer 401-es (Jogosulatlan) hibát ad vissza az ügyfélkérésekre

Gyökérok

A JWT-token élettartamának alapértelmezett értéke jelenleg egy (1) óra.

A ASP.NET Core SignalR esetében, ha WebSocket átviteli típust használ, akkor rendben van.

Az ASP.NET Core SignalR másik átviteli típusa, az S Standard kiadás és a hosszú lekérdezés esetén az alapértelmezett élettartam azt jelenti, hogy a kapcsolat legfeljebb egy óráig tarthat.

A SignalR ASP.NET esetében az ügyfél időről időre "életben tart" kérést /ping küld a szolgáltatásnak, ha a /ping hiba meghiúsul, az ügyfél megszakítja a kapcsolatot, és soha nem csatlakozik újra. Az ASP.NET SignalR esetében az alapértelmezett jogkivonat élettartama az összes átviteli típus esetében legfeljebb egy óráig tart.

Megoldás

Biztonsági okokból a TTL kiterjesztése nem javasolt. Javasoljuk, hogy adjon hozzá újracsatlakozási logikát az ügyféltől a kapcsolat újraindításához, amikor ilyen 401 történik. Amikor az ügyfél újraindítja a kapcsolatot, egyeztet az alkalmazáskiszolgálóval a JWT-jogkivonat ismételt lekérése és egy megújított jogkivonat lekérése érdekében.

Itt ellenőrizheti, hogyan indíthatja újra az ügyfélkapcsolatokat.

Problémák vagy visszajelzés a hibaelhárításról? Tudassa velünk.

A rendszer 404-es hibát ad vissza az ügyfélkérésekre

Egy SignalR-állandó kapcsolat esetében először /negotiate az Azure SignalR szolgáltatáshoz, majd létrehozza a valódi kapcsolatot az Azure SignalR szolgáltatással.

Troubleshooting guide

• A kimenő kérések megtekintése az ügyféltől a szolgáltatáshoz való lekéréséhez.
• Ellenőrizze a kérés URL-címét a 404-ben. Ha az URL-cím a webalkalmazásra irányul, és ehhez hasonló {your_web_app}/hubs/{hubName}, ellenőrizze, hogy az ügyfél SkipNegotiation van-e true. Az ügyfél átirányítási URL-címet kap, amikor először egyeztet az alkalmazáskiszolgálóval. Az ügyfél nem hagyhatja ki a tárgyalást az Azure SignalR használatakor.
• Egy másik 404 akkor fordulhat elő, ha a csatlakozási kérést a rendszer több mint öt (5) másodperccel a hívás után /negotiate kezeli. Ellenőrizze az ügyfélkérés időbélyegét, és nyisson meg egy problémát, ha a szolgáltatásnak küldött kérés lassú választ ad.

Problémák vagy visszajelzés a hibaelhárításról? Tudassa velünk.

404 visszaadva ASP.NET SignalR újracsatlakozási kéréséhez

Ha ASP.NET SignalR esetében az ügyfélkapcsolat megszakad, a kapcsolat leállítása előtt háromszor újracsatlakozik ugyanazzal connectionId . /reconnect segíthet, ha a kapcsolat megszakadt olyan hálózati időszakos problémák miatt, amelyek /reconnect sikeresen újra létrehozhatják az állandó kapcsolatot. Más körülmények között például az ügyfélkapcsolat megszakad, mert az átirányított kiszolgálókapcsolat megszakadt, vagy a SignalR szolgáltatás belső hibákba ütközik, például a példány újraindítása/feladatátvétele/üzembe helyezése, a kapcsolat már nem létezik, így /reconnect visszaáll 404. Ez a várt viselkedés a kapcsolat háromszori újrapróbálkozása /reconnect esetén és után. Azt javasoljuk, hogy a kapcsolat leállásakor indítsa újra a kapcsolatot.

Problémák vagy visszajelzés a hibaelhárításról? Tudassa velünk.

429 (túl sok kérés) érkezett az ügyfélkérésekhez

Két eset létezik.

Az egyidejű kapcsolatok száma meghaladja a korlátot

Ingyenes példányok esetén az egyidejű kapcsolatszám korlátja 20 Standard példányok esetén, egységenként az egyidejű kapcsolatszámkorlát 1 K, ami azt jelenti, hogy a Unit100 100 K egyidejű kapcsolatokat tesz lehetővé.

A kapcsolatok ügyfél- és kiszolgálókapcsolatokat is tartalmaznak. itt ellenőrizheti, hogy a kapcsolatok hogyan vannak megszámolva.

Túl sok egyeztetési kérés egyszerre

Javasoljuk, hogy az újracsatlakozás előtt szúrópróbaszerű késéssel próbálkozzon újra.

Problémák vagy visszajelzés a hibaelhárításról? Tudassa velünk.

500 Hiba egyeztetéskor: Az Azure SignalR szolgáltatás még nincs csatlakoztatva, próbálkozzon újra később

Gyökérok

Ez a hiba akkor jelenik meg, ha nincs kiszolgálókapcsolat az Azure SignalR Service-hez csatlakoztatva.

Troubleshooting guide

Engedélyezze a kiszolgálóoldali nyomkövetést, hogy megtudja a hiba részleteit, amikor a kiszolgáló megpróbál csatlakozni az Azure SignalR Szolgáltatáshoz.

Kiszolgálóoldali naplózás engedélyezése ASP.NET Core SignalR-hez

A ASP.NET Core SignalR kiszolgálóoldali naplózása integrálható a ILogger ASP.NET Core-keretrendszerben megadott alapú naplózással . A kiszolgálóoldali naplózást a következő mintahasználattal ConfigureLoggingengedélyezheti:

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

Az Azure SignalR naplózási kategóriái mindig a következővel Microsoft.Azure.SignalRkezdődnek: . Az Azure SignalR részletes naplóinak engedélyezéséhez konfigurálja az előző előtagokat Debug az appsettings.json fájlban az alábbi módon:

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

Kiszolgálóoldali nyomkövetések engedélyezése ASP.NET SignalR-hez

Az SDK-verzió >= 1.0.0használatakor a nyomkövetések engedélyezéséhez adja hozzá a következőhöz web.config: (Részletek)

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

Problémák vagy visszajelzés a hibaelhárításról? Tudassa velünk.

Az ügyfélkapcsolat megszakad

Amikor az ügyfél csatlakozik az Azure SignalR-hez, az ügyfél és az Azure SignalR közötti állandó kapcsolat néha különböző okokból megszakadhat. Ez a szakasz az ilyen kapcsolat megszakadását okozó számos lehetőséget ismertet, és útmutatást nyújt a kiváltó ok azonosításához.

Lehetséges hibák az ügyféloldalon

• The remote party closed the WebSocket connection without completing the close handshake
• Service timeout. 30000.00ms elapsed without receiving a message from service.
• {"type":7,"error":"Connection closed with an error."}
• {"type":7,"error":"Internal server error."}

Gyökérok

Az ügyfélkapcsolatok különböző körülmények között megszakadhatnak:

• Amikor Hub kivételeket küld a bejövő kéréssel
• Amikor az ügyfél által átirányított kiszolgálókapcsolat megszakad, a kiszolgálókapcsolatok megszakadására vonatkozó részleteket az alábbi szakaszban találja.
• Ha hálózati kapcsolati probléma történik az ügyfél és a SignalR szolgáltatás között
• Ha a SignalR szolgáltatásnak belső hibái vannak, például a példány újraindítása, a feladatátvétel, az üzembe helyezés stb.

Troubleshooting guide

1. Az alkalmazás kiszolgálóoldali naplójának megnyitása annak megtekintéséhez, hogy történt-e rendellenes esemény
2. Ellenőrizze az alkalmazás kiszolgálóoldali eseménynaplójában, hogy az alkalmazáskiszolgáló újraindult-e
3. Hozzon létre egy problémát, amely megadja az időkeretet, és küldje el nekünk az erőforrás nevét

Problémák vagy visszajelzés a hibaelhárításról? Tudassa velünk.

Az ügyfélkapcsolat folyamatosan nő

Ezt az ügyfélkapcsolat helytelen használata okozhatja. Ha valaki elfelejti leállítani/megsemmisíteni a SignalR-ügyfelet, a kapcsolat nyitva marad.

Lehetséges hibák az Azure Portal erőforrásmenüjének Monitorozás szakaszában található SignalR-metrikákból

Az ügyfélkapcsolatok hosszú ideig folyamatosan növekednek az Azure SignalR metrikáiban.

Gyökérok

A SignalR-ügyfélkapcsolat soha nem DisposeAsync lesz meghívva, a kapcsolat nyitva marad.

Troubleshooting guide

Ellenőrizze, hogy a SignalR-ügyfél soha nem zár-e be.

Megoldás

Ellenőrizze, hogy bezárja-e a kapcsolatot. Manuálisan hívhatja HubConnection.DisposeAsync() meg a kapcsolatot a használat után.

Például:

var connection = new HubConnectionBuilder()
	.WithUrl(...)
	.Build();
try
{
	await connection.StartAsync();
	// Do your stuff
	await connection.StopAsync();
}
finally
{
	await connection.DisposeAsync();
}

Gyakori helytelen ügyfélkapcsolat-használat

Azure-függvény – példa

Ez a probléma gyakran akkor fordul elő, ha valaki SignalR-ügyfélkapcsolatot hoz létre egy Azure-függvénymetódusban ahelyett, hogy statikus taggá tenné a függvényosztályban. Előfordulhat, hogy csak egy ügyfélkapcsolat létesítésére számít, de ehelyett azt látja, hogy az ügyfélkapcsolatok száma folyamatosan nő a metrikákban. Ezek a kapcsolatok csak az Azure-függvény vagy az Azure SignalR szolgáltatás újraindítása után csökkennek. Ennek a viselkedésnek az az oka, hogy az Azure-függvény minden kéréshez létrehoz egy ügyfélkapcsolatot, és ha nem állítja le az ügyfélkapcsolatot a függvénymetódusban, az ügyfél életben tartja a kapcsolatokat az Azure SignalR szolgáltatással.

Megoldás

• Ne felejtse el bezárni az ügyfélkapcsolatot, ha SignalR-ügyfeleket használ az Azure-függvényben, vagy ha a SignalR-ügyfelet önállóan használja.
• A SignalR-ügyfelek azure-függvényben való használata helyett bárhol máshol hozhat létre SignalR-ügyfeleket, és az Azure SignalR Szolgáltatáshoz készült Azure Functions-kötések használatával egyeztetheti az ügyfelet az Azure SignalR-sel. Emellett a kötés használatával üzeneteket is küldhet. Az ügyfél egyeztetésére és az üzenetek küldésére használható minták itt találhatók. További információt itt talál.
• Ha SignalR-ügyfeleket használ az Azure-függvényben, előfordulhat, hogy jobb architektúra áll rendelkezésre a forgatókönyvhöz. Ellenőrizze, hogy megfelelő kiszolgáló nélküli architektúrát tervez-e. Az Azure Functions SignalR szolgáltatáskötéseivel valós idejű kiszolgáló nélküli alkalmazásokra is hivatkozhat.

Problémák vagy visszajelzés a hibaelhárításról? Tudassa velünk.

Kiszolgálókapcsolat megszakad

Amikor az alkalmazáskiszolgáló elindul, a háttérben az Azure SDK elkezd kiszolgálókapcsolatokat kezdeményezni a távoli Azure SignalR-hez. Az Azure SignalR szolgáltatás belső verzióiban leírtak szerint az Azure SignalR a bejövő ügyfélforgalmakat ezekre a kiszolgálói kapcsolatokra irányítja. A kiszolgálókapcsolat megszakadása után az általa kiszolgált ügyfélkapcsolatok is bezárulnak.

Mivel az alkalmazáskiszolgáló és a SignalR Szolgáltatás közötti kapcsolatok állandó kapcsolatok, hálózati csatlakozási problémák léphetnek fel. A Kiszolgáló SDK-ban van egy Always Reconnect stratégia a kiszolgálói kapcsolatokhoz. Ajánlott eljárásként arra is bátorítjuk a felhasználókat, hogy szúrópróbaszerű késleltetéssel adjanak hozzá folyamatos újracsatlakozási logikát az ügyfelekhez, hogy elkerüljék a kiszolgálóra irányuló tömeges egyidejű kéréseket.

Rendszeresen vannak új verziókiadások az Azure SignalR szolgáltatáshoz, és néha az Azure-ra kiterjedő javítások vagy frissítések, illetve a függő szolgáltatások időnkénti megszakítása. Ezek az események rövid ideig tartó szolgáltatáskimaradást okozhatnak, de mindaddig, amíg az ügyféloldali kapcsolat bontási/újracsatlakozási mechanizmussal rendelkezik, a hatás minimális, mint bármely ügyféloldali kapcsolat megszakadása.

Ez a szakasz a kiszolgálókapcsolat megszakadásához vezető számos lehetőséget ismertet, és útmutatást nyújt a kiváltó ok azonosításához.

Lehetséges hibák a kiszolgáló oldalán

• [Error]Connection "..." to the service was dropped
• The remote party closed the WebSocket connection without completing the close handshake
• Service timeout. 30000.00ms elapsed without receiving a message from service.

Gyökérok

A kiszolgáló-szolgáltatás kapcsolatot az ASRS (Azure SignalRService) zárja be.

A pingelési időtúllépést a kiszolgálóoldal magas processzorhasználata vagy a szálkészlet éhezése okozhatja.

A ASP.NET SignalR esetében az SDK 1.6.0-s kiadásában kijavítottunk egy ismert hibát. Frissítse az SDK-t a legújabb verzióra.

Szálkészlet éhezése

Ha a kiszolgáló éhezik, az azt jelenti, hogy egyetlen szál sem dolgozik az üzenetfeldolgozáson. Az összes szál nem válaszol egy adott metódusban.

Ezt a forgatókönyvet általában aszinkron szinkronizálás vagy aszinkron metódusok okozzák Task.Result/Task.Wait() .

Tekintse meg ASP.NET core teljesítményre vonatkozó ajánlott eljárásokat.

További információ a szálkészlet éhezéséről.

A szálkészlet éhezésének észlelése

Ellenőrizze a szálak számát. Ha abban az időben nincsenek kiugró csúcsok, hajtsa végre az alábbi lépéseket:

• Ha Azure-alkalmazás szolgáltatást használ, ellenőrizze a szálak számát a metrikákban. Ellenőrizze az Max összesítést:

  

• Ha a .NET-keretrendszer használja, metrikákat találhat a kiszolgáló virtuális gép teljesítményfigyelőjében.

• Ha .NET Core-t használ egy tárolóban, olvassa el a diagnosztika gyűjtése tárolókban című témakört.

Kóddal is észlelheti a szálkészlet éhezést:

public class ThreadPoolStarvationDetector : EventListener
{
    private const int EventIdForThreadPoolWorkerThreadAdjustmentAdjustment = 55;
    private const uint ReasonForStarvation = 6;

    private readonly ILogger<ThreadPoolStarvationDetector> _logger;

    public ThreadPoolStarvationDetector(ILogger<ThreadPoolStarvationDetector> logger)
    {
        _logger = logger;
    }

    protected override void OnEventSourceCreated(EventSource eventSource)
    {
        if (eventSource.Name == "Microsoft-Windows-DotNETRuntime")
        {
            EnableEvents(eventSource, EventLevel.Informational, EventKeywords.All);
        }
    }

    protected override void OnEventWritten(EventWrittenEventArgs eventData)
    {
        // See: https://learn.microsoft.com/dotnet/framework/performance/thread-pool-etw-events#threadpoolworkerthreadadjustmentadjustment
        if (eventData.EventId == EventIdForThreadPoolWorkerThreadAdjustmentAdjustment &&
            eventData.Payload[2] as uint? == ReasonForStarvation)
        {
            _logger.LogWarning("Thread pool starvation detected!");
        }
    }
}

Adja hozzá a szolgáltatáshoz:

service.AddSingleton<ThreadPoolStarvationDetector>();

Ezután ellenőrizze a naplót, ha a kiszolgálókapcsolat megszakad a pingelési időtúllépés miatt.

A szálkészlet éhezésének kiváltó oka

A szálkészlet éhezésének kiváltó okának megkeresése:

• Memóriakép készítése, majd a hívásverem elemzése. További információ: Memóriaképek gyűjtése és elemzése.
• A clrmd használatával memóriaképet hozhat a szálkészlet éhezése észlelésekor. Ezután naplózza a hívási vermet.

Troubleshooting guide

1. Nyissa meg az alkalmazás kiszolgálóoldali naplóját, és ellenőrizze, hogy történt-e rendellenes esemény.
2. Ellenőrizze az alkalmazás kiszolgálóoldali eseménynaplójában, hogy az alkalmazáskiszolgáló újraindult-e.
3. Hozzon létre egy problémát. Adja meg az időkeretet, és küldje el nekünk az erőforrás nevét.

Problémák vagy visszajelzés a hibaelhárításról? Tudassa velünk.

Tippek

Hogyan tekintheti meg az ügyfél kimenő kérését?

Vegyük például ASP.NET Core-t (ASP.NET hasonló):

• Böngészőből: Vegyük példaként a Chrome-ot, az F12 használatával megnyithatja a konzolablakot, és átválthat a Hálózat lapra. Előfordulhat, hogy frissítenie kell a lapot az F5 használatával, hogy a hálózat a kezdetektől fogva rögzítve legyen.

  

• C#-ügyfélből:

  A helyi webes forgalmat a Fiddler használatával tekintheti meg. A WebSocket-forgalom a Fiddler 4.5 óta támogatott.

  

Hogyan lehet újraindítani az ügyfélkapcsolatot?

A kapcsolatlogika ALWAYS RETRY stratégiával való újraindítását tartalmazó mintakódok:

• ASP.NET Core C#-ügyfél

• ASP.NET Core JavaScript-ügyfél

• C#-ügyfél ASP.NET

• JavaScript-ügyfél ASP.NET

Problémák vagy visszajelzés a hibaelhárításról? Tudassa velünk.

További lépések

Ebben az útmutatóban megismerkedett a gyakori problémák kezelésével. További általános hibaelhárítási módszereket is megismerhet.

Kapcsolódási és üzenetkézbesítési problémák elhárítása