Sdílet prostřednictvím

Monitorování služby SignalR Service pomocí protokolů prostředků

  • Článek

Tento článek popisuje, jak pomocí funkcí služby Azure Monitor analyzovat a řešit potíže s daty monitorování protokolů prostředků generovaným službou Azure SignalR.

Stránka Přehled na webu Azure Portal pro každou službu Azure SignalR obsahuje stručný přehled o využití prostředků, jako jsou souběžná připojení a počet zpráv. Tyto užitečné informace jsou jen malé množství dat monitorování dostupných na portálu. Některá z těchto dat se shromažďují automaticky a jsou k dispozici pro analýzu hned po vytvoření prostředku.

Po určité konfiguraci můžete povolit jiné typy shromažďování dat. Tento článek vás provede konfigurací shromažďování dat protokolu a analýzou a řešením potíží s daty pomocí nástrojů služby Azure Monitor.

  • Další informace o monitorování služby Azure SignalR najdete v tématu Monitorování služby Azure SignalR.
  • Podrobný seznam metrik a protokolů shromážděných pro službu Azure SignalR najdete v referenčních informacích k datům monitorování služby Azure SignalR.

Důležité

Nezpracované připojovací řetězec se v tomto článku zobrazují jenom pro demonstrační účely.

Připojovací řetězec obsahuje informace o autorizaci vyžadované pro vaši aplikaci pro přístup ke službě Azure Web PubSub. Přístupový klíč uvnitř připojovací řetězec je podobný kořenovému heslu pro vaši službu. V produkčních prostředích vždy chraňte přístupové klíče. Pomocí služby Azure Key Vault můžete bezpečně spravovat a obměňovat klíče a zabezpečit připojovací řetězec pomocí ID Microsoft Entra a autorizovat přístup pomocí Microsoft Entra ID.

Vyhněte se distribuci přístupových klíčů ostatním uživatelům, jejich pevnému kódování nebo jejich uložení kdekoli ve formátu prostého textu, který je přístupný ostatním uživatelům. Otočte klíče, pokud se domníváte, že mohly být ohroženy.

Požadavky

Pokud chcete povolit protokoly prostředků, musíte nastavit místo pro ukládání dat protokolů, jako je Azure Storage nebo Log Analytics.

  • Azure Storage uchovává protokoly prostředků pro audit zásad, statickou analýzu nebo zálohování.
  • Log Analytics je flexibilní nástroj pro prohledávání protokolů a analýzu, který umožňuje analýzu nezpracovaných protokolů generovaných prostředkem Azure.

Povolení protokolů prostředků

Služba Azure SignalR podporuje protokoly připojení, protokoly zasílání zpráv a protokoly požadavků HTTP. Další podrobnosti o těchtotypech Protokoly se ukládají do účtu úložiště nakonfigurovaného v podokně Diagnostické protokoly . Další podrobnosti o formátu úložiště a polích najdete v tématu Úložiště dat.

Vytvoření nastavení diagnostiky

Protokoly prostředků jsou ve výchozím nastavení zakázané. Pokud chcete povolit protokoly prostředků pomocí nastavení diagnostiky, přečtěte si téma Vytvoření nastavení diagnostiky ve službě Azure Monitor.

Dotazování protokolů prostředků

Pokud chcete dotazovat protokoly prostředků, postupujte takto:

  1. V cílové službě Log Analytics vyberte protokoly .

    Položka nabídky Log Analytics

  2. Zadejte SignalRServiceDiagnosticLogs a vyberte časový rozsah. Pokročilé dotazy najdete v tématu Začínáme se službou Log Analytics ve službě Azure Monitor.

    Protokol dotazů v Log Analytics

Pokud chcete použít ukázkové dotazy pro službu Azure SignalR, postupujte takto:

  1. V cílové službě Log Analytics vyberte protokoly .

  2. Výběrem karty Dotazy otevřete Průzkumníka dotazů.

  3. Výběrem typu prostředek seskupíte ukázkové dotazy v typu prostředku.

  4. Vyberte Spustit a spusťte skript.

    Ukázkový dotaz v Log Analytics

Například dotazy pro službu Azure SignalR najdete v tématu Dotazy pro tabulku SignalRServiceDiagnosticLogs.

Poznámka:

Názvy polí dotazů pro cíle úložiště se mírně liší od názvů polí pro Log Analytics. Podrobnosti o mapování názvů polí mezi tabulkami Úložiště a Log Analytics najdete v tématu Mapování tabulek protokolu prostředků.

Řešení potíží s protokoly prostředků

Pokud chcete řešit potíže se službou Azure SignalR, můžete povolit protokoly na straně serveru nebo klienta, aby zachytily chyby. Když služba Azure SignalR zveřejňuje protokoly prostředků, můžete využít protokoly prostředků k řešení potíží s protokoly služby.

Když narazíte na neočekávaně rostoucí nebo zahazující připojení, můžete využít protokoly připojení k řešení potíží. Typické problémy často zahrnují neočekávané změny počtu připojení, dosažení limitů připojení a selhání autorizace. Následující části popisují, jak řešit potíže.

Neočekávané zahození připojení

Pokud dojde k neočekávanému poklesu připojení, nejprve povolte protokoly na straně služby, serveru a klienta.

Pokud se připojení odpojí, zaznamená se tato událost odpojení do protokolu prostředků a zobrazí se nebo ConnectionEnded je zobrazí ConnectionAborted operationName.

Rozdíl mezi ConnectionAborted očekávaným ConnectionEnded ConnectionEnded odpojením, který se aktivuje na straně klienta nebo serveru. Obvykle ConnectionAborted se jedná o neočekávanou událost vyřazení připojení a důvod přerušení je uveden v message.

Následující tabulka uvádí důvody přerušení.

Důvod Popis
Počet připojení dosáhne limitu Počet připojení dosáhne limitu aktuální cenové úrovně. Zvažte vertikální navýšení kapacity jednotky služby.
Aplikační server ukončil připojení Aplikační server aktivuje potrat. To může být považováno za očekávaný potrat
Vypršení časového limitu příkazu Ping připojení Obvykle je příčinou problém se sítí. Zvažte kontrolu dostupnosti aplikačního serveru z internetu.
Opětovné načítání služby, zkuste se znovu připojit. Služba Azure SignalR se znovu načítá. Azure SignalR podporuje automatické opětovné připojení, můžete počkat, až se znovu připojíte nebo ručně znovu připojíte ke službě Azure SignalR.
Vnitřní přechodná chyba serveru Ve službě Azure SignalR dochází k přechodné chybě, měla by se automaticky obnovit.
Vyřazené připojení k serveru Selhání připojení k serveru s neznámou chybou, nejprve zvažte samoobslužné řešení potíží s protokolem na straně služby, serveru nebo klienta. Zkuste vyloučit základní problémy (např. problém se sítí, problém na straně serveru aplikace atd.). Pokud se problém nevyřeší, požádejte nás o další pomoc. Další informace najdete v části Získání nápovědy .

Neočekávané zvětšující se připojení

Při řešení potíží s neočekávaným růstem připojení je potřeba nejdřív vyfiltrovat další připojení. Do připojení testovacího klienta můžete přidat jedinečné ID testovacího uživatele. Zkontrolujte protokoly prostředků. Pokud se zobrazí více než jedno připojení klientů se stejným testovacím ID uživatele nebo IP adresou, pravděpodobně na straně klienta vytváří více připojení, než se čekalo. Zkontrolujte svoji stranu klienta.

Selhání autorizace

Pokud se pro požadavky klientů vrátí 401 Neautorizováno, zkontrolujte protokoly prostředků. Pokud narazíte Failed to validate audience. Expected Audiences: <valid audience>. Actual Audiences: <actual audience>, znamená to, že všechny cílové skupiny ve vašem přístupového tokenu jsou neplatné. Zkuste použít platné cílové skupiny navrhované v protokolu.

Omezování

Pokud zjistíte, že nemůžete navázat připojení klienta SignalR ke službě Azure SignalR, zkontrolujte protokoly prostředků. Pokud v protokolu prostředků narazíte Connection count reaches limit , vytvoříte příliš mnoho připojení ke službě SignalR, která dosáhne limitu počtu připojení. Zvažte vertikální navýšení kapacity služby SignalR. Pokud v protokolu prostředků narazíte Message count reaches limit , znamená to, že používáte úroveň Free a jste použili kvótu zpráv. Pokud chcete odesílat další zprávy, zvažte změnu služby SignalR na úroveň Standard. Další informace najdete v tématu o cenách služby Azure SignalR.

Při řešení potíží souvisejících se zprávami můžete využít protokoly zasílání zpráv. Nejprve povolte protokoly prostředků ve službě a protokolech pro server a klienta.

Poznámka:

Informace o ASP.NET Core najdete tady , pokud chcete povolit protokolování na serveru a klientovi.

Informace o ASP.NET najdete tady , pokud chcete povolit protokolování na serveru a klientovi.

Pokud vám nevadí potenciální efekty výkonu a žádná zpráva směru mezi klientem a serverem, zkontrolujte Messaging Log Source Settings/Types , jestli chcete povolit chování shromažďování všech protokolů. Další informace o tomto chování naleznete v tématu shromažďování všech .

V opačném případě zrušte zaškrtnutí políčka Messaging povolit chování shromažďování protokolů shromažďování dat částečně . Toto chování vyžaduje konfiguraci v klientovi a serveru, aby bylo možné ho povolit. Další informace najdete v části Shromažďování částečně.

Ztráta zpráv

Pokud dojde k problémům se ztrátou zpráv, klíčem je najít místo, kde zprávu ztratíte. V podstatě máte při používání služby Azure SignalR tři komponenty: služba SignalR, server a klient. Server i klient jsou připojené ke službě SignalR, ale po dokončení vyjednávání se k sobě nepřipojují přímo. Proto je potřeba vzít v úvahu dva směry zpráv a pro každý směr, který potřebujete zvážit dvě cesty:

  • Z klienta na server přes službu SignalR
    • Cesta 1: Klient do služby SignalR
    • Cesta 2: Služba SignalR na server
  • Ze serveru do klienta přes službu SignalR
    • Cesta 3: Server do služby SignalR
    • Cesta 4: Služba SignalR pro klienta

Cesta ke zprávě

Shromažďování veškerého chování při shromažďování:

Služba Azure SignalR service trasuje zprávy pouze směrem od serveru k klientovi prostřednictvím služby SignalR. ID trasování se vygeneruje na serveru. Zpráva přenáší ID trasování do služby SignalR.

Poznámka:

Pokud chcete trasovat zprávy a posílat zprávy mimo centrum na aplikačním serveru, musíte povolit shromažďování všech shromažďovaných chování ke shromažďování protokolů zpráv pro zprávy, které nepocházejí z diagnostických klientů. Diagnostická klienti pracují pro shromažďování všech a shromažďování částečně shromažďovaných chování, ale mají vyšší prioritu shromažďování protokolů. Další informace najdete v části Diagnostického klienta.

Kontrolou přihlašovacího serveru a služby můžete snadno zjistit, jestli se zpráva odesílá ze serveru, dorazí do služby SignalR a odejde ze služby SignalR. V podstatě pomocí kontroly, jestli se přijatá a odeslaná zpráva shoduje nebo není založena na ID trasování zpráv, můžete zjistit, jestli je problém se ztrátou zpráv v serveru nebo službě SignalR tímto směrem. Další informace najdete v následujících podrobnostech .

Pro shromažďování částečně shromažďovaných chování:

Jakmile klienta označíte jako diagnostického klienta, Služba Azure SignalR bude trasovat zprávy v obou směrech.

Kontrolou přihlašovacího serveru a služby můžete snadno zjistit, jestli zpráva úspěšně předává server nebo službu SignalR. V podstatě můžete zkontrolovat, jestli se přijatá a odeslaná zpráva shoduje nebo není založena na ID trasování zpráv, můžete zjistit, jestli je problém se ztrátou zpráv na serveru nebo službě SignalR. Další informace najdete v následujících podrobnostech.

Podrobnosti o toku zpráv

Pro směr od klienta k serveru přes službu SignalR služba SignalR považuje vyvolání, které pochází z diagnostického klienta, tj. zpráva vygenerovaná přímo v diagnostickém klientovi nebo zpráva služby vygenerovaná z důvodu nepřímého vyvolání diagnostického klienta.

ID trasování se vygeneruje ve službě SignalR, jakmile zpráva dorazí do služby SignalR v cestě 1. Služba SignalR generuje protokol Received a message <MessageTracingId> from client connection <ConnectionId>. pro každou zprávu v diagnostickém klientovi. Jakmile zpráva odejde ze služby SignalR na server, služba SignalR vygeneruje zprávu Sent a message <MessageTracingId> to server connection <ConnectionId> successfully.protokolu . Pokud se zobrazí tyto dva protokoly, můžete se ujistit, že zpráva úspěšně prochází službou SignalR.

Poznámka:

Vzhledem k omezení ASP.NET Core SignalR zpráva pochází z klienta neobsahuje žádné ID na úrovni zprávy, ale ASP.NET SignalR generuje ID vyvolání pro každou zprávu. Můžete ho použít k mapování s ID trasování.

Zpráva pak nese trasovací ID Server v cestě 2. Server po doručení zprávy vygeneruje protokol Received message <messagetracingId> from client connection <connectionId> .

Jakmile zpráva vyvolá metodu centra na serveru, vygeneruje se nová zpráva služby s novým ID trasování. Po vygenerování zprávy služby server vygeneruje šablonu Start to broadcast/send message <MessageTracingId> ...přihlášení . Skutečný protokol je založený na vašem scénáři. Zpráva se pak doručí do služby SignalR v cestě 3. Po opuštění zprávy služby ze serveru se vygeneruje protokol Succeeded to send message <MessageTracingId> .

Poznámka:

ID trasování zprávy od klienta se nemůže namapovat na ID trasování zprávy služby, která se má odeslat do služby SignalR.

Jakmile zpráva služby dorazí do služby SignalR, vygeneruje se protokol Received a <MessageType> message <MessageTracingId> from server connection <ConnectionId>. . Služba SignalR pak zpracuje zprávu služby a doručí cílovému klientovi. Po odeslání zprávy do klientů v cestě 4 se vygeneruje protokol Sent a message <MessageTracingId> to client connection <ConnectionId> successfully. .

V souhrnu se protokol zpráv vygeneruje, když zpráva přejde do a ze služby SignalR a ze serveru. Tyto protokoly můžete použít k ověření ztráty zprávy v těchto součástech nebo ne.

Následující příklad je typickým problémem se ztrátou zpráv.

Klientovi se nedaří přijímat zprávy ve skupině

Typickým příběhem v tomto problému je, že se klient připojí ke skupině po odeslání zprávy skupiny.

Class Chat : Hub
{
    public void JoinAndSendGroup(string name, string groupName)
    {
        Groups.AddToGroupAsync(Context.ConnectionId, groupName); // join group
        Clients.Group(groupName).SendAsync("ReceiveGroupMessage", name, "I'm in group"); // send group message
    }
}

Někdo může například vyvolání skupiny připojení a odeslání zprávy skupiny ve stejné metodě centra. Tento problém je AddToGroupAsync async metoda. Vzhledem k tomu, že await není možné AddToGroupAsync čekat na dokončení, zpráva skupiny se odešle před AddToGroupAsync dokončením. Kvůli zpoždění sítě a zpoždění procesu připojení klienta k určité skupině se akce skupiny připojení může dokončit později než doručení zprávy skupiny. Pokud ano, první zpráva skupiny nemá jako příjemce žádného klienta, protože se ke skupině nepřipojil žádný klient, takže se stane problémem se ztrátou zprávy.

Bez protokolů prostředků nemůžete zjistit, kdy se klient připojí ke skupině a kdy se odešle zpráva skupiny. Jakmile povolíte protokoly zasílání zpráv, můžete porovnat čas doručení zprávy ve službě SignalR. Při řešení potíží postupujte následovně:

  1. Vyhledejte protokoly zpráv na serveru, abyste zjistili, kdy se klient připojil ke skupině a kdy byla zpráva skupiny odeslána.
  2. Získejte ID trasování zpráv A pro připojení ke skupině a ID trasování zpráv B zprávy ze protokolů zpráv.
  3. Vyfiltrujte toto ID trasování zpráv mezi protokoly zpráv v cíli archivu protokolu a pak porovnejte jejich příchozí časová razítka. Zjistíte, která zpráva byla doručena jako první ve službě SignalR.
  4. Pokud je ID trasování zpráv A přicházející čas pozdější než B, musíte odeslat zprávu skupiny před tím, než se klient připojí ke skupině. Před odesláním zpráv skupiny se musíte ujistit, že je klient ve skupině.

Pokud dojde ke ztrátě zprávy v SignalR nebo serveru, zkuste získat protokoly upozornění na základě ID trasování zpráv, abyste získali důvod. Pokud potřebujete další pomoc, přečtěte si část získat nápovědu.

Protokoly prostředků shromažďující chování

Existují dva typické scénáře použití protokolů prostředků, zejména pro protokoly zasílání zpráv.

Někdo se může starat o kvalitu každé zprávy. Jsou například citlivá na to, jestli byla zpráva úspěšně odeslána nebo přijata, nebo chtějí zaznamenat každou zprávu doručenou prostřednictvím služby SignalR.

Mezitím se na výkonu můžou starat i ostatní. Jsou citliví na latenci zprávy a někdy potřebují zprávu sledovat v několika připojeních místo všech připojení z nějakého důvodu.

Služba SignalR proto poskytuje dva druhy shromažďování chování.

  • collect all: collect logs in all connections
  • shromažďování částečně: shromažďování protokolů v některých konkrétních připojeních

Poznámka:

Aby bylo možné rozlišovat připojení mezi těmito protokoly a protokoly, které neshromažďují protokoly, služba SignalR považuje některého klienta za diagnostického klienta na základě konfigurací serveru a klienta, ve kterém se protokoly prostředků vždy shromažďují, zatímco ostatní ne. Další informace najdete v části Shromažďování částečně.

Shromáždit vše

Protokoly prostředků jsou shromažďovány všemi připojeními. Například protokoly zasílání zpráv. Pokud je toto chování povolené, služba SignalR odešle na server oznámení, aby začala generovat ID trasování pro každou zprávu. ID trasování se přenáší ve zprávě do služby. Služba také protokoluje zprávu s ID trasování.

Poznámka:

Upozorňujeme, že pokud chcete zajistit výkon služby SignalR, služba SignalR nečeká a parsuje celou zprávu odeslanou z klienta. Proto se zprávy klienta nezaprotokolují. Pokud je klient označený jako diagnostický klient, zaprotokoluje se zpráva klienta ve službě SignalR.

Průvodce konfigurací

Pokud chcete toto chování povolit, zaškrtněte políčko v části Typy v nastavení zdroje protokolů.

Toto chování nevyžaduje aktualizaci konfigurace na straně serveru. Tato změna konfigurace se vždy odesílá na server automaticky.

Shromážděte částečně

Protokoly prostředků shromažďují jenom diagnostická klienti. Všechny zprávy se protokolují, včetně klientských zpráv a událostí připojení v diagnostických klientech.

Poznámka:

Limit počtu diagnostických klientů je 100. Pokud počet diagnostických klientů překročí 100, dojde u klientů diagnostiky k omezení služby SignalR. Nové, ale nečíslované klienty se nepodaří připojit ke službě SignalR a vyvolat System.Net.Http.HttpRequestException, který má zprávu Response status code does not indicate success: 429 (Too Many Requests). Už připojené klienty fungují, aniž by to mělo vliv na zásady omezování.

Diagnostický klient

Diagnostický klient je logický koncept. Každý klient může být diagnostický klient. Server řídí, který klient může být diagnostickým klientem. Jakmile je klient označený jako diagnostický klient, povolí se v tomto klientovi všechny protokoly prostředků. Pokud chcete nastavit klienta jako diagnostického klienta, přečtěte si průvodce konfigurací.

Průvodce konfigurací

Pokud chcete toto chování povolit, musíte nakonfigurovat službu, server a stranu klienta.

Strana služby

Pokud chcete toto chování povolit, zrušte zaškrtnutí políčka u konkrétního typu protokolu v části Typy v nastavení zdroje protokolu.

Na straně serveru

Nastavte ServiceOptions.DiagnosticClientFilter také definování filtru diagnostických klientů na základě kontextu HTTP od klientů. Nastavte například klienta s adresou URL <HUB_URL>?diag=yescentra a pak nastavte ServiceOptions.DiagnosticClientFilter filtrování diagnostického klienta. Pokud se klient vrátí true, označí se jako diagnostický klient. V opačném případě zůstane normálním klientem. Následující příklad ukazuje, jak používat ServiceOptions.DiagnosticClientFilter ve své startupové třídě.

Nezpracované připojovací řetězec se v tomto článku zobrazují jenom pro demonstrační účely. V produkčních prostředích vždy chraňte přístupové klíče. Pomocí služby Azure Key Vault můžete bezpečně spravovat a obměňovat klíče a zabezpečit připojovací řetězec pomocí ID Microsoft Entra a autorizovat přístup pomocí Microsoft Entra ID.

// 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();
}
Na straně klienta

Klienta označte jako diagnostického klienta konfigurací kontextu http. Klient je například označen jako diagnostický klient přidáním řetězce diag=yesdotazu .

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

Získání pomoci

Doporučujeme vám nejprve vyřešit potíže sami. Většina problémů je způsobená aplikačním serverem nebo sítí. Pokud chcete zjistit původní příčinu, postupujte podle průvodce odstraňováním potíží s protokolem prostředků a základním průvodcem odstraňováním potíží. Pokud problém stále nejde vyřešit, zvažte otevření problému na GitHubu nebo vytvoření lístku na webu Azure Portal. Poskytnout:

  1. Časový rozsah přibližně 30 minut, kdy k problému dochází
  2. ID prostředku služby Azure SignalR
  3. Podrobnosti o problému, co nejsměrnější: Například appserver neodesílá zprávy, zahodí připojení klienta atd.
  4. Protokoly shromážděné ze strany serveru nebo klienta a další materiály, které můžou být užitečné
  5. [Volitelné] Repro code

Poznámka:

Pokud otevřete problém na GitHubu, zachovejte citlivé informace (například ID prostředku, protokoly serveru nebo klienta). Posílat jenom členům v organizaci Microsoftu soukromě.