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 történt ERR_CONNECTION_
a korlátozás miatt.
HTTP/1.1 vagy C#-ügyfelek esetén az URI maximális hossza 12 K , a fejlécek maximális hossza pedig 16 K.
Az SDK 1.0.6-os vagy újabb verziójával akkor dob413 Payload Too Large
, /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 SignalR Service) való JWT-hozzáférési jogkivonat létrehozásakor jelennek meg, így a jogcímek megmaradnak, és átadhatók az ASRS-ből arra 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, a WebSocket/SSE-kapcsolatok esetében pedig 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>
Ez a hiba akkor fordulhat elő, ha a kiszolgálótanúsítvány nincs megfelelően konfigurálva a HTTPS-eset HTTP.SYS. A hiba lehetséges oka az ügyfél és a kiszolgáló közötti biztonsági kötés eltérése."
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.
Hibaelhárítási útmutató
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:
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. A hub
megőrzött lekérdezési paraméter, és ha a szolgáltatás egynél hub
több hibát észlel a lekérdezésben, 400-os hibát ad vissza.
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 SSE é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éséhez és egy megújított jogkivonat beszerzéséhez.
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.
Hibaelhárítási útmutató
- 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élSkipNegotiation
van-etrue
. 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 az átirányított kiszolgálókapcsolat megszakadása miatt, 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, ezért /reconnect
visszaadja a következőt 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 a kapcsolatok számba adásának módját.
EgyeztetésThrottled
Ha túl sok ügyfél tárgyalja egyszerre a kérelmeket, az szabályozva lehet. A korlát ahhoz az egységszámhoz kapcsolódik, amelynél több egységnél magasabb a korlát. Emellett azt javasoljuk, hogy az újracsatlakozás előtt véletlenszerű késést tapasztaljon, itt ellenőrizze az újrapróbálkozási mintákat.
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.
Hibaelhárítási útmutató
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 ConfigureLogging
engedélyezheti:
.ConfigureLogging((hostingContext, logging) =>
{
logging.AddConsole();
logging.AddDebug();
})
Az Azure SignalR naplózási kategóriái mindig a következővel Microsoft.Azure.SignalR
kezdődnek: . Ha részletes naplókat szeretne engedélyezni az Azure SignalR-ből, konfigurálja az előző előtagokat a appsettings.json fájl szintjére Debug
, lásd a következő példát:
{
"Logging": {
"LogLevel": {
...
"Microsoft.Azure.SignalR": "Debug",
...
}
}
}
Kiszolgálóoldali nyomkövetések engedélyezése ASP.NET SignalR-hez
Az SDK-verzió >= 1.0.0
haszná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észletekért tekintse meg a következő szakaszt.
- 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.
Hibaelhárítási útmutató
- Az alkalmazás kiszolgálóoldali naplójának megnyitása annak megtekintéséhez, hogy történt-e rendellenes esemény
- Ellenőrizze az alkalmazás kiszolgálóoldali eseménynaplójában, hogy az alkalmazáskiszolgáló újraindult-e
- 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ő
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, és a kapcsolat nyitva marad.
Hibaelhárítási útmutató
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élda:
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. Ez a viselkedés azért fordul elő, mert 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. Amikor egy kiszolgálókapcsolat megszakad, bezárja az összes ügyfélkapcsolatot, amelyet kiszolgált.
Mivel az alkalmazáskiszolgáló és a SignalR Szolgáltatás közötti kapcsolatok állandó kapcsolatok, hálózati csatlakozási problémákat tapasztalhatnak. 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 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 SignalR Service) zárja be.
A kiszolgálóoldalon a magas processzorhasználat vagy a szálkészlet éhezése pingelési időtúllépést okozhat.
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.
Az aszinkron metódusokban általában az aszinkron szinkronizálás vagy ennek a forgatókönyvnek Task.Result
/Task.Wait()
az oka.
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ó megszakadt 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.
Hibaelhárítási útmutató
- Nyissa meg az alkalmazás kiszolgálóoldali naplóját, és ellenőrizze, hogy történt-e rendellenes esemény.
- Ellenőrizze az alkalmazás kiszolgálóoldali eseménynaplójában, hogy az alkalmazáskiszolgáló újraindult-e.
- 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:
Problémák vagy visszajelzés a hibaelhárításról? Tudassa velünk.
Következő 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.