Az Azure SignalR szolgáltatás naplóinak monitorozása és hibaelhárítása

  • Cikk

Ez a cikk azt ismerteti, hogyan használhatja az Azure Monitor funkcióit az Azure SignalR által létrehozott erőforrásnapló-figyelési adatok elemzéséhez és hibaelhárításához.

Az Azure Portal Áttekintés lapja az egyes Azure SignalR-szolgáltatásokhoz tartalmazza az erőforrás-használat rövid nézetét, például az egyidejű kapcsolatokat és az üzenetek számát. Ez a hasznos információ csak kis mennyiségű, a portálon elérhető monitorozási adat. Ezen adatok egy része automatikusan lesz összegyűjtve, és az erőforrás létrehozása után azonnal elérhető elemzésre.

Bizonyos konfigurációk után más típusú adatgyűjtést is engedélyezhet. Ez a cikk bemutatja a naplóadatok gyűjtésének konfigurálását, valamint az adatok azure monitorozási eszközökkel történő elemzését és hibaelhárítását.

  • Az Azure SignalR Szolgáltatás monitorozásával kapcsolatos további információkért lásd: Monitor Azure SignalR Service.
  • Az Azure SignalR Service-hez gyűjtött metrikák és naplók részletes listáját az Azure SignalR Service monitorozási adatreferenciájában találja.

Előfeltételek

Az erőforrásnaplók engedélyezéséhez be kell állítania egy helyet a naplóadatok tárolásához, például az Azure Storage-hoz vagy a Log Analyticshez.

  • Az Azure Storage megőrzi az erőforrásnaplókat a szabályzatok naplózásához, statikus elemzéséhez vagy biztonsági mentéséhez.
  • A Log Analytics egy rugalmas naplókeresési és -elemzési eszköz, amely lehetővé teszi az Azure-erőforrások által létrehozott nyers naplók elemzését.

Erőforrásnaplók engedélyezése

Az Azure SignalR Service támogatja a kapcsolati naplókat, az üzenetkezelési naplókat és a Http-kérelmek naplóit. Az ilyen típusú naplókról további információt az erőforrásnapló-kategóriákban talál.

Az erőforrásnaplók alapértelmezés szerint le vannak tiltva. Ha diagnosztikai beállításokkal szeretné engedélyezni az erőforrásnaplókat, kövesse az alábbi lépéseket:

  1. Az Azure Portal Monitorozás területén válassza a Diagnosztikai beállítások lehetőséget.

    Ablaktábla-navigáció a diagnosztikai beállításokhoz.

    A diagnosztikai beállítások teljes megtekintése.

    Diagnosztikai beállítások teljes nézete.

  2. Konfigurálja a naplóforrás beállításait.

    1. A Naplóforrás Gépház szakaszban egy táblázat mutatja az egyes naplótípusok gyűjtési viselkedését.
    2. Ellenőrizze, hogy az összes kapcsolathoz milyen naplótípust szeretne gyűjteni. Ellenkező esetben a napló csak diagnosztikai ügyfelek számára lesz összegyűjtve.

  3. Konfigurálja a napló célbeállítását.

    1. A Naplócél Gépház szakaszban a diagnosztikai beállítások táblázata megjeleníti a meglévő diagnosztikai beállításokat. A táblázatban található hivatkozásra kattintva hozzáférést kaphat a napló céljához az összegyűjtött erőforrásnaplók megtekintéséhez.
    2. Ebben a szakaszban válassza a Diagnosztikai beállítások hozzáadásához, frissítéséhez vagy törléséhez a Napló célhelyének konfigurálása Gépház gombot.
    3. Válassza a Diagnosztikai beállítás hozzáadása lehetőséget egy új diagnosztikai beállítás hozzáadásához, vagy válassza a Szerkesztés lehetőséget egy meglévő diagnosztikai beállítás módosításához.
    4. Állítsa be a kívánt archív célt. Az Azure SignalR Szolgáltatás jelenleg támogatja az archiválást egy tárfiókba , és a Küldés a Log Analyticsbe.
    5. Jelölje ki az archiválni kívánt naplókat. Csak AllLogs az erőforrásnaplóhoz érhető el. Csak azt szabályozza, hogy archiválni szeretné-e a naplókat. Annak konfigurálásához, hogy mely naplótípusokat kell létrehozni az Azure SignalR Service-ben, konfigurálja a Naplóforrás Gépház szakaszban.

    Diagnosztikai beállítások panel.

    1. Mentse az új diagnosztikai beállítást. Az új beállítás körülbelül 10 perc múlva lép érvénybe. Ezt követően a rendszer elküldi a naplókat a konfigurált archiválási célnak. A napló célbeállításainak konfigurálásával kapcsolatos további információkért tekintse meg az Azure-erőforrásnaplók áttekintését.

A naplók a Diagnosztikai naplók panelen konfigurált Storage-fiókban vannak tárolva. A tárolási formátumról és a mezőkről további információt az Adattárolás című témakörben talál.

Erőforrásnaplók lekérdezése

Az erőforrásnaplók lekérdezéséhez kövesse az alábbi lépéseket:

  1. Válassza a Naplók lehetőséget a cél Log Analyticsben.

    Log Analytics menüelem

  2. Adja meg a SignalRServiceDiagnosticLogs értéket, és válassza ki az időtartományt. Speciális lekérdezésért tekintse meg a Log Analytics használatának első lépéseit az Azure Monitorban

    Lekérdezésnapló a Log Analyticsben

Ha minta lekérdezéseket szeretne használni az Azure SignalR Service-hez, kövesse az alábbi lépéseket:

  1. Válassza a Naplók lehetőséget a cél Log Analyticsben.

  2. A Lekérdezéskezelő megnyitásához válassza a Lekérdezések lapot.

  3. Válassza az Erőforrástípus lehetőséget a minta lekérdezések erőforrástípusba való csoportosításához.

  4. Válassza a Futtatás lehetőséget a szkript futtatásához.

    Minta lekérdezés a Log Analyticsben

Az Azure SignalR Service lekérdezéseihez lásd a SignalRServiceDiagnosticLogs tábla lekérdezéseit.

Feljegyzés

A Storage-célhelyek lekérdezésmezőinek nevei kissé eltérnek a Log Analytics mezőneveitől. A Storage és a Log Analytics táblák közötti mezőnév-megfeleltetés részleteiért tekintse meg az Erőforrásnapló táblaleképezés című témakört.

Hibaelhárítás erőforrásnaplókkal

Az Azure SignalR Szolgáltatás hibaelhárításához engedélyezheti a kiszolgáló/ügyféloldali naplók rögzítését a hibák rögzítéséhez. Amikor az Azure SignalR Szolgáltatás erőforrásnaplókat tesz elérhetővé, az erőforrásnaplók segítségével elháríthatja a szolgáltatás naplóit.

Ha váratlanul növekvő vagy csökkenő kapcsolatokba ütközik, a hibaelhárításhoz kihasználhatja a kapcsolati naplók előnyeit. A tipikus problémák gyakran váratlan kapcsolatmennyiség-módosításokat, kapcsolódási korlátokat érnek el, és engedélyezési hiba lépnek fel. A következő szakaszok ismertetik a hibaelhárítás módját.

Váratlan kapcsolat megszakadása

Ha váratlan kapcsolatok merülnek fel, először engedélyezze a naplókat a szolgáltatás, a kiszolgáló és az ügyféloldalon.

Ha egy kapcsolat megszakad, az erőforrásnaplók rögzítik ezt a kapcsolatbontási eseményt, és megjelenik ConnectionAborted vagy ConnectionEnded megjelenik.operationName

A különbség ConnectionAbortedConnectionEnded és az, hogy ConnectionEnded ez egy várható leválasztás, amelyet az ügyfél- vagy kiszolgálóoldal vált ki. Ez ConnectionAborted általában egy váratlan kapcsolatlehagyási esemény, és a megszakítás okát a rendszer megadja.message

Az alábbi táblázat a megszakítás okait sorolja fel.

Ok Leírás
Csatlakozás ionok száma eléri a korlátot Csatlakozás a darabszám eléri az aktuális árszint korlátját. Fontolja meg a szolgáltatási egység vertikális felskálázását
Az alkalmazáskiszolgáló lezárta a kapcsolatot Az alkalmazáskiszolgáló elindítja az abortuszt. Ez tekinthető a várt abortusz
Csatlakozás ion ping időtúllépése Ezt általában hálózati probléma okozza. Fontolja meg az alkalmazáskiszolgáló internetről való elérhetőségének ellenőrzését
Szolgáltatás újratöltése, újracsatlakozás Az Azure SignalR szolgáltatás újra betöltődik. Az Azure SignalR támogatja az automatikus újracsatlakozást, megvárhatja, amíg újracsatlakozik, vagy manuálisan újracsatlakozik az Azure SignalR Szolgáltatáshoz
Belső kiszolgáló átmeneti hibája Átmeneti hiba történik az Azure SignalR Service-ben, automatikusan helyre kell állítani
Kiszolgálókapcsolat megszakadt A kiszolgálókapcsolat ismeretlen hiba miatt megszakad, először fontolja meg a szolgáltatás/kiszolgáló/ügyféloldali napló önelhárítását. Próbálja kizárni az alapszintű problémákat (pl. hálózati probléma, alkalmazáskiszolgáló oldalán felmerülő probléma stb.). Ha a probléma nem oldódott meg, forduljon hozzánk további segítségért. További információ: Segítség kérése szakasz.

Váratlan kapcsolat növekedése

A váratlan kapcsolatok növekedésével kapcsolatos hibák elhárításához az első teendő a további kapcsolatok kiszűrése. A tesztügyfél-kapcsolathoz hozzáadhat egy egyedi tesztfelhasználói azonosítót. Ellenőrizze az erőforrásnaplókat. Ha egynél több ügyfélkapcsolat ugyanazt a tesztfelhasználói azonosítót vagy IP-címet látja, valószínű, hogy az ügyféloldal a vártnál több kapcsolatot hoz létre. Ellenőrizze az ügyféloldalát.

Engedélyezési hiba

Ha 401 jogosulatlanul visszaadott ügyfélkérést kap, ellenőrizze az erőforrásnaplókat. Ha találkozik Failed to validate audience. Expected Audiences: <valid audience>. Actual Audiences: <actual audience>, az azt jelenti, hogy a hozzáférési jogkivonat összes célközönsége érvénytelen. Próbálja meg használni a naplóban javasolt érvényes célközönségeket.

Szabályozás

Ha úgy találja, hogy nem tud SignalR-ügyfélkapcsolatokat létesíteni az Azure SignalR Szolgáltatással, ellenőrizze az erőforrásnaplókat. Ha az erőforrásnaplóban találkozik Connection count reaches limit , túl sok kapcsolatot létesít a SignalR szolgáltatással, ami eléri a kapcsolatszám korlátját. Fontolja meg a SignalR szolgáltatás vertikális felskálázását. Ha az erőforrásnaplóban találkozik Message count reaches limit , az azt jelenti, hogy ingyenes szintet használ, és felhasználta az üzenetek kvótáját. Ha további üzeneteket szeretne küldeni, fontolja meg a SignalR szolgáltatás standard szintre való módosítását. További információkért tekintse meg az Azure SignalR Service díjszabását.

Ha üzenetekkel kapcsolatos problémákba ütközik, kihasználhatja az üzenetkezelési naplók előnyeit a hibaelhárításhoz. Először engedélyezze az erőforrásnaplókat a szolgáltatásban, valamint a kiszolgáló és az ügyfél naplóit.

Feljegyzés

A ASP.NET Core szolgáltatásról itt olvashat, amely lehetővé teszi a naplózást a kiszolgálón és az ügyfélen.

A ASP.NET itt tekinthet meg a kiszolgálói és ügyfélbeli naplózás engedélyezéséhez.

Ha nem bánja a lehetséges teljesítményeffektusokat, és nincs ügyfél–kiszolgáló irányú üzenet, a bejelentkezést Log Source Settings/Types be kell jelentkeznie a Messaging teljes körű naplógyűjtési viselkedés engedélyezéséhez. Erről a viselkedésről további információt az összes összegyűjtése című témakörben talál.

Ellenkező esetben törölje a jelölést a Messaging részben naplógyűjtési viselkedés engedélyezéséhez. Ehhez a viselkedéshez az ügyfél és a kiszolgáló konfigurációja szükséges ahhoz, hogy engedélyezve legyen. További információ: részleges adatgyűjtés.

Üzenetvesztés

Ha üzenetvesztési problémákat tapasztal, a kulcs az üzenet elvesztésének helyének megkeresése. Alapvetően három összetevővel rendelkezik az Azure SignalR Szolgáltatás használatakor: SignalR szolgáltatás, kiszolgáló és ügyfél. A kiszolgáló és az ügyfél is csatlakozik a SignalR szolgáltatáshoz, de nem csatlakozik közvetlenül egymáshoz a tárgyalás befejezése után. Ezért két irányt kell figyelembe vennie az üzenetekhez, és minden irányhoz két útvonalat kell figyelembe vennie:

  • Ügyfélről kiszolgálóra a SignalR szolgáltatáson keresztül
    • 1. elérési út: Ügyfél–SignalR szolgáltatás
    • 2. elérési út: SignalR szolgáltatás a kiszolgálóhoz
  • Kiszolgálóról ügyfélre a SignalR szolgáltatáson keresztül
    • 3. elérési út: Kiszolgáló a SignalR szolgáltatáshoz
    • 4. elérési út: SignalR szolgáltatás az ügyfél felé

Üzenet elérési útja

Gyűjtse össze az összes gyűjtési viselkedést:

Az Azure SignalR Service csak a SignalR szolgáltatáson keresztül követ nyomon üzeneteket a kiszolgálóról az ügyfél felé irányuló irányban. A nyomkövetési azonosító a kiszolgálón jön létre. Az üzenet a nyomkövetési azonosítót a SignalR szolgáltatásnak látja el.

Feljegyzés

Ha az alkalmazáskiszolgáló egyik központján kívülről szeretne üzeneteket nyomon követni és üzeneteket küldeni, engedélyeznie kell az összes gyűjtési viselkedés gyűjtését a nem diagnosztikai ügyfelektől származó üzenetek üzenetnaplóinak gyűjtéséhez. A diagnosztikai ügyfelek mind az összeset összegyűjtik, részbengyűjtik a viselkedéseket, de magasabb prioritással rendelkezik a naplók gyűjtéséhez. További információt a diagnosztikai ügyfél szakaszában talál.

A bejelentkezési kiszolgáló és a szolgáltatás oldalának ellenőrzésével könnyen kiderítheti, hogy az üzenet a kiszolgálóról érkezik-e, megérkezik-e a SignalR szolgáltatáshoz, és távozik-e a SignalR szolgáltatásból. Alapvetően azzal, hogy ellenőrzi, hogy a fogadott és az elküldött üzenet megfelel-e az üzenetkövetési azonosítónak, megállapíthatja, hogy az üzenetvesztéssel kapcsolatos probléma a kiszolgáló vagy a SignalR szolgáltatásban van-e ebben az irányban. További információt az alábbi részletekben talál.

Részleges gyűjtési viselkedés gyűjtése esetén:

Miután diagnosztikai ügyfélként jelölte meg az ügyfelet, az Azure SignalR Service mindkét irányban nyomon követi az üzeneteket.

A bejelentkezési kiszolgáló és a szolgáltatás oldalának ellenőrzésével könnyen megállapíthatja, hogy az üzenet sikeresen átadta-e a kiszolgálót vagy a SignalR szolgáltatást. Alapvetően azzal, hogy ellenőrzi, hogy a fogadott és az elküldött üzenet megfelel-e az üzenetkövetési azonosítónak, megállapíthatja, hogy az üzenetvesztési probléma a kiszolgáló vagy a SignalR szolgáltatásban van-e. További információt az alábbi részletekben talál.

Az üzenetfolyam részletei

Az ügyfélről a kiszolgálóra a SignalR szolgáltatáson keresztüli irányra vonatkozóan a SignalR szolgáltatás csak a diagnosztikai ügyféltől származó meghívást veszi figyelembe, vagyis a diagnosztikai ügyfélben közvetlenül generált üzenetet, vagy a diagnosztikai ügyfél indirekt meghívása miatt létrehozott szolgáltatásüzenetet.

A nyomkövetési azonosító a SignalR szolgáltatásban jön létre, amint az üzenet megérkezik a SignalR szolgáltatáshoz az 1. elérési úton. A SignalR szolgáltatás naplót Received a message <MessageTracingId> from client connection <ConnectionId>. hoz létre a diagnosztikai ügyfél minden egyes üzenetéhez. Miután az üzenet a SignalR-ből a kiszolgálóra távozik, a SignalR szolgáltatás létrehoz egy naplóüzenetet Sent a message <MessageTracingId> to server connection <ConnectionId> successfully.. Ha ezt a két naplót látja, biztos lehet abban, hogy az üzenet sikeresen áthalad a SignalR szolgáltatáson.

Feljegyzés

Az ASP.NET Core SignalR korlátozása miatt az ügyféltől érkező üzenet nem tartalmaz üzenetszintű azonosítót, de ASP.NET SignalR minden üzenethez létrehoz hívásazonosítót . Ezzel megfeleltetheti a nyomkövetési azonosítót.

Ezután az üzenet hordozza a nyomkövetési azonosító kiszolgálóját a 2. elérési úton. A kiszolgáló létrehoz egy naplót Received message <messagetracingId> from client connection <connectionId> , amint az üzenet megérkezik.

Miután az üzenet meghívja a központi metódust a kiszolgálón, egy új szolgáltatásüzenet jön létre egy új nyomkövetési azonosítóval. A szolgáltatásüzenet létrehozása után a kiszolgáló létrehoz egy bejelentkezési sablont Start to broadcast/send message <MessageTracingId> .... A tényleges napló az Ön forgatókönyvén alapul. Ezután az üzenet a SignalR szolgáltatásba érkezik a 3. elérési úton. Miután a szolgáltatásüzenet elhagyja a kiszolgálót, létre kell hozni egy naplót Succeeded to send message <MessageTracingId> .

Feljegyzés

Az ügyféltől érkező üzenet nyomkövetési azonosítója nem képezhető le a SignalR szolgáltatásnak küldendő szolgáltatásüzenet nyomkövetési azonosítójára.

Miután a szolgáltatásüzenet megérkezik a SignalR szolgáltatáshoz, létrejön egy napló, amelyet meghívunk Received a <MessageType> message <MessageTracingId> from server connection <ConnectionId>. . Ezután a SignalR szolgáltatás feldolgozza a szolgáltatásüzenetet, és kézbesíti a célügyfél(ek)nek. Miután az üzenetet elküldte a 4. elérési út ügyfél(ek)nek, a rendszer naplót Sent a message <MessageTracingId> to client connection <ConnectionId> successfully. hoz létre.

Összefoglalva, az üzenetnapló akkor jön létre, amikor az üzenet be- és kimegy a SignalR szolgáltatásból és a kiszolgálóról. Ezekkel a naplókkal ellenőrizheti, hogy az üzenet elveszik-e ezekben az összetevőkben.

Az alábbi példa egy tipikus üzenetvesztési probléma.

Az ügyfél nem fogad üzeneteket egy csoportban

A probléma tipikus története, hogy az ügyfél egy csoportüzenet elküldése után csatlakozik egy csoporthoz.

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

Előfordulhat például, hogy valaki meghívást küld a csatlakozási csoportra , és ugyanabban a központi metódusban küld csoportüzenetet . A probléma itt egy AddToGroupAsyncasync módszer. Mivel a csoportüzenet a befejezésig nem awaitAddToGroupAsync várja meg a várakozást, a csoportüzenet a befejezés előtt AddToGroupAsync küldi el. A hálózati késés és az ügyfél egy csoporthoz való csatlakozásának késleltetése miatt az illesztési csoport művelete később fejeződhet be, mint a csoportos üzenetkézbesítés. Ha igen, az első csoportüzenetben nincs ügyfél fogadóként, mivel egyetlen ügyfél sem csatlakozott a csoporthoz, így az üzenet elveszett problémává válik.

Erőforrásnaplók nélkül nem tudhatja meg, hogy az ügyfél mikor csatlakozik a csoporthoz, és mikor küldi el a csoportüzenetet. Miután engedélyezte az üzenetkezelési naplókat, összehasonlíthatja a SignalR szolgáltatásban érkező üzenet érkezési idejét. Végezze el a következő lépéseket a hibaelhárításhoz:

  1. Keresse meg a kiszolgáló üzenetnaplóit, és keresse meg, hogy az ügyfél mikor csatlakozott a csoporthoz, és mikor küldi el a csoportüzenetet.
  2. Kérje le a csoporthoz való csatlakozás üzenetkövetési azonosítóját és a csoportüzenet B azonosítóját az üzenetnaplókból.
  3. Szűrje ezeket az üzenetkövetési azonosítókat a naplóarchívumbeli üzenetnaplók között, majd hasonlítsa össze az érkező időbélyegeket. A SignalR szolgáltatásban megtalálja, hogy melyik üzenet érkezett először.
  4. Ha az üzenetkövetés azonosítója az A érkezési idő későbbi, mint B érkezési idő, akkor a csoportüzenetet el kell küldenie, mielőtt az ügyfél csatlakozna a csoporthoz. A csoportüzenetek küldése előtt győződjön meg arról, hogy az ügyfél a csoportban van.

Ha egy üzenet elveszik a SignalR-ben vagy a kiszolgálón, próbálja meg lekérni a figyelmeztető naplókat az üzenetkövetési azonosító alapján az ok lekéréséhez. Ha további segítségre van szüksége, tekintse meg a Súgó beolvasása szakaszt.

Az erőforrásnaplók gyűjtik a viselkedéseket

Az erőforrásnaplók használatának két tipikus forgatókönyve van, különösen az üzenetkezelési naplók esetében.

Előfordulhat, hogy valaki törődik az egyes üzenetek minőségével. Például érzékenyek arra, hogy az üzenet sikeresen el lett-e küldve/fogadva, vagy szeretné rögzíteni a SignalR szolgáltatáson keresztül küldött összes üzenetet.

Addig is másokat is érdekelhet a teljesítmény. Érzékenyek az üzenet késésére, és néha valamilyen okból az összes kapcsolat helyett néhány kapcsolatban kell nyomon követniük az üzenetet.

Ezért a SignalR szolgáltatás kétféle gyűjtési viselkedést biztosít

  • összes összegyűjtése: naplók gyűjtése minden kapcsolatban
  • részleges adatgyűjtés: naplók gyűjtése bizonyos kapcsolatokban

Feljegyzés

Ha meg szeretné különböztetni a naplókat gyűjtő és a nem naplókat gyűjtők közötti kapcsolatokat, a SignalR szolgáltatás bizonyos ügyfeleket diagnosztikai ügyfélként kezel a kiszolgáló és az ügyfél diagnosztikai ügyfélkonfigurációi alapján, amelyekben az erőforrásnaplók mindig összegyűjtve lesznek, míg a többiek nem. További információkért lásd a részben gyűjtött szakaszt.

Az összes összegyűjtése

Az erőforrásnaplókat az összes kapcsolat gyűjti. Készítsen például üzenetkezelési naplókat. Ha ez a viselkedés engedélyezve van, a SignalR szolgáltatás értesítést küld a kiszolgálónak az egyes üzenetek nyomkövetési azonosítójának létrehozásához. A nyomkövetési azonosítót a rendszer a szolgáltatásnak küldi el az üzenetben. A szolgáltatás nyomkövetési azonosítóval is naplózza az üzenetet.

Feljegyzés

Vegye figyelembe, hogy a SignalR szolgáltatás teljesítményének biztosítása érdekében a SignalR szolgáltatás nem várja meg és elemzi az ügyféltől küldött teljes üzenetet. Ezért az ügyfélüzenetek nem lesznek naplózva. Ha az ügyfél diagnosztikai ügyfélként van megjelölve, az ügyfélüzenet be lesz jelentkezve a SignalR szolgáltatásba.

Konfigurációs útmutató

A viselkedés engedélyezéséhez jelölje be a Naplóforrás Gépház Típusok szakaszának jelölőnégyzetét.

Ez a viselkedés nem igényli a kiszolgálóoldali konfigurációk frissítését. Ezt a konfigurációmódosítást a rendszer mindig automatikusan elküldi a kiszolgálónak.

Részleges adatgyűjtés

Az erőforrásnaplókat csak diagnosztikai ügyfelek gyűjtik. A rendszer minden üzenetet naplóz, beleértve az ügyfélüzeneteket és a diagnosztikai ügyfelek kapcsolati eseményeit is.

Feljegyzés

A diagnosztikai ügyfelek számának korlátja 100. Ha a diagnosztikai ügyfelek száma meghaladja a 100-t, a kiszámlázott diagnosztikai ügyfeleket a SignalR szolgáltatás szabályozza. Az új, de kiugróan számozott ügyfelek nem csatlakoznak a SignalR szolgáltatáshoz, és dobják System.Net.Http.HttpRequestExceptionaz üzenetet Response status code does not indicate success: 429 (Too Many Requests). A már csatlakoztatott ügyfelek úgy működnek, hogy nem érintik a szabályozási szabályzatot.

Diagnosztikai ügyfél

A diagnosztikai ügyfél logikai fogalom. Bármely ügyfél lehet diagnosztikai ügyfél. A kiszolgáló szabályozza, hogy melyik ügyfél lehet diagnosztikai ügyfél. Miután egy ügyfél diagnosztikai ügyfélként van megjelölve, az összes erőforrásnapló engedélyezve lesz ebben az ügyfélben. Az ügyfél diagnosztikai ügyfélként való beállításához tekintse meg a konfigurációs útmutatót.

Konfigurációs útmutató

A viselkedés engedélyezéséhez konfigurálnia kell a szolgáltatás, a kiszolgáló és az ügyféloldalt.

Szolgáltatásoldal

A viselkedés engedélyezéséhez törölje a jelet egy adott naplótípus jelölőnégyzetének jelölésétől a Naplóforrás Gépház Típusok szakaszában.

Kiszolgálóoldal

Emellett a diagnosztikai ügyfelek http-környezeten alapuló szűrőjének meghatározására is be van állítva ServiceOptions.DiagnosticClientFilter az ügyfelektől. Például állítsa be a központi URL-címmel <HUB_URL>?diag=yesrendelkező ügyfelet, majd állítsa be ServiceOptions.DiagnosticClientFilter a diagnosztikai ügyfél szűrésére. Ha visszaadja true, az ügyfél diagnosztikai ügyfélként van megjelölve. Ellenkező esetben normál ügyfélként marad. Az ServiceOptions.DiagnosticClientFilter indítási osztályban a következő módon állítható be:

// 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();
}
Ügyféloldal

Jelölje meg az ügyfelet diagnosztikai ügyfélként a HTTP-környezet konfigurálásával. Az ügyfél például a lekérdezési sztring diag=yeshozzáadásával diagnosztikai ügyfélként van megjelölve.

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

Segítség kérése

Javasoljuk, hogy először saját maga hárítsa el a hibaelhárítást. A legtöbb problémát az alkalmazáskiszolgáló vagy a hálózati problémák okozzák. Kövesse a hibaelhárítási útmutatót az erőforrásnaplóval és az alapvető hibaelhárítási útmutatóval a kiváltó ok megtalálásához. Ha a probléma továbbra sem oldható meg, érdemes lehet megnyitni egy problémát a GitHubon, vagy létrehozni egy jegyet az Azure Portalon. Adja meg a következőt:

  1. A probléma bekövetkezésekor körülbelül 30 perc az időtartomány
  2. Az Azure SignalR Szolgáltatás erőforrás-azonosítója
  3. Probléma részletei, a lehető legrészletesen: Az AppServer például nem küld üzeneteket, az ügyfélkapcsolat megszakad stb.
  4. A kiszolgáló/ügyfél oldaláról gyűjtött naplók és egyéb hasznos anyagok
  5. [Nem kötelező] Repro-kód

Feljegyzés

Ha problémát nyit meg a GitHubon, tartsa bizalmas adatait (például erőforrás-azonosítóját, kiszolgálói/ügyfélnaplóit). Csak privát módon küldheti el a Microsoft-szervezet tagjainak.