Průvodce odstraňováním potíží se službou Azure Service Bus

  • Článek

Tento článek obsahuje tipy a doporučení pro řešení potíží s několika problémy, které se zobrazí při používání služby Azure Service Bus.

Problémy s připojením

Vypršení časového limitu při připojování ke službě

V závislosti na hostitelském prostředí a síti může být problém s připojením k aplikacím přítomen buď jako TimeoutException, OperationCanceledExceptionnebo s , nebo ServiceBusException s ServiceTimeout Reason a nejčastěji k tomu dochází, když klient nemůže najít síťovou cestu ke službě.

Řešení potíží:

  • Ověřte správnost připojovací řetězec nebo plně kvalifikovaného názvu domény, který jste zadali při vytváření klienta. Informace o získání připojovací řetězec najdete v tématu Získání připojovací řetězec služby Service Bus.
  • Zkontrolujte oprávnění brány firewall a portu ve vašem hostitelském prostředí. Zkontrolujte, jestli jsou otevřené porty protokolu AMQP (Advanced Message Queuing Protocol) 5671 a 5672 a že koncový bod je povolený přes bránu firewall.
  • Zkuste použít možnost přenosu webového soketu, která se připojuje pomocí portu 443. Podrobnosti najdete v tématu konfigurace přenosu.
  • Zkontrolujte, jestli vaše síť neblokuje konkrétní IP adresy. Podrobnosti najdete v tématu Jaké IP adresy je potřeba povolit?
  • Pokud je to možné, ověřte konfiguraci proxy serveru. Podrobnosti najdete v tématu: Konfigurace přenosu
  • Další informace o řešení potíží se síťovým připojením najdete v tématu [Problémy s připojením, certifikátem nebo vypršením časového limitu][#connectivity-certificate-or-timeout-issues].

Selhání handshake ssl (Secure Socket Layer)

K této chybě může dojít při použití zachytávání proxy serveru. K ověření doporučujeme otestovat aplikaci v hostitelském prostředí se zakázaným proxy serverem.

Chyby vyčerpání soketů

Aplikace by měly preferovat zacházení s typy Service Bus jako s singletony, vytvářením a používáním jedné instance po celou dobu životnosti aplikace. Každá nová služba ServiceBusClient vytvořila výsledky v novém připojení AMQP, které používá soket. Typ ServiceBusClient spravuje připojení pro všechny typy vytvořené z této instance. Každý ServiceBusReceiver, ServiceBusSessionReceiver, ServiceBusSender a ServiceBusProcessor spravuje svůj vlastní odkaz AMQP pro přidruženou entitu Service Bus. Při použití ServiceBusSessionProcessor se vytvoří několik propojení AMQP v závislosti na počtu relací, které se zpracovávají souběžně.

Klienti jsou v bezpečí pro ukládání do mezipaměti při nečinnosti; zajišťují efektivní správu sítě, procesoru a využití paměti, což minimalizuje jejich dopad během období nečinnosti. Je také důležité, aby se buď CloseAsync volala, DisposeAsync když už klient není potřeba, aby se zajistilo správné vyčištění síťových prostředků.

Přidání komponent do připojovací řetězec nefunguje

Aktuální generace klientské knihovny služby Service Bus podporuje připojovací řetězec pouze ve formuláři publikovaném na webu Azure Portal. Účelem připojovací řetězec je poskytnout pouze základní informace o umístění a sdíleném klíči. Konfigurace chování klientů se provádí prostřednictvím svých možností.

Předchozí generace klientů služby Service Bus umožňovaly nakonfigurovat určité chování přidáním komponent klíč/hodnota do připojovací řetězec. Tyto komponenty se už nerozpoznají a nemají žádný vliv na chování klienta.

Alternativa TransportType=AmqpWebSockets

Informace o konfiguraci webových soketů jako typu přenosu najdete v tématu Konfigurace přenosu.

Alternativní řešení "Authentication=Managed Identity"

Pokud se chcete ověřit pomocí spravované identity, přečtěte si téma: Identita a sdílené přístupové přihlašovací údaje. Další informace o knihovně Azure.Identity najdete v tématu Ověřování a sada Azure SDK.

Protokolování a diagnostika

Klientská knihovna Service Bus je plně instrumentovaná pro protokolování informací na různých úrovních podrobností pomocí rozhraní .NET EventSource k vygenerování informací. Protokolování se provádí pro každou operaci a řídí se vzorem označení výchozího bodu operace, jeho dokončení a všech zjištěných výjimek. Další informace, které můžou nabídnout přehled, se zaprotokolují také v kontextu přidružené operace.

Povolit protokolování

Protokoly klienta služby Service Bus jsou k dispozici pro všechny EventListener tím, že se přihlásíte ke zdrojům počínaje Azure-Messaging-ServiceBus nebo se přihlásíte ke všem zdrojům, které mají vlastnost AzureEventSource. Aby bylo zachytávání protokolů z klientských knihoven Azure jednodušší, Azure.Core nabízí knihovna používaná službou AzureEventSourceListenerService Bus .

Další informace najdete v tématu: Protokolování pomocí sady Azure SDK pro .NET.

Distribuované trasování

Klientská knihovna Service Bus podporuje distribuované trasování prostřednictvím integrace se sadou Application Insights SDK. Má také experimentální podporu specifikace OpenTelemetry prostřednictvím typu ActivitySource .NET zavedeného v .NET 5. Pokud chcete povolit ActivitySource podporu pro použití s OpenTelemetry, podívejte se na podporu ActivitySource.

Pokud chcete použít podporu GA DiagnosticActivity, můžete ji integrovat se sadou Application Insights SDK. Další podrobnosti najdete ve službě ApplicationInsights se službou Azure Monitor.

Knihovna vytvoří následující rozsahy:

Message
ServiceBusSender.Send
ServiceBusSender.Schedule
ServiceBusSender.Cancel
ServiceBusReceiver.Receive
ServiceBusReceiver.ReceiveDeferred
ServiceBusReceiver.Peek
ServiceBusReceiver.Abandon
ServiceBusReceiver.Complete
ServiceBusReceiver.DeadLetter
ServiceBusReceiver.Defer
ServiceBusReceiver.RenewMessageLock
ServiceBusSessionReceiver.RenewSessionLock
ServiceBusSessionReceiver.GetSessionState
ServiceBusSessionReceiver.SetSessionState
ServiceBusProcessor.ProcessMessage
ServiceBusSessionProcessor.ProcessSessionMessage
ServiceBusRuleManager.CreateRule
ServiceBusRuleManager.DeleteRule
ServiceBusRuleManager.GetRules

Většina rozsahů je vysvětlovaná a během operace, která nese název, se spustí a zastaví. Rozpětí, které spojuje ostatní dohromady, je Message. Způsob, jakým je zpráva trasována, je prostřednictvím Diagnostic-Id toho, který je nastaven v ServiceBusMessage.ApplicationProperties vlastnost knihovny během operací odesílání a plánu. V Application Insights Message se rozsahy zobrazují jako propojení s různými dalšími rozsahy, které byly použity k interakci se zprávou, ServiceBusReceiver.Receive například rozsah, ServiceBusSender.Send rozsah a ServiceBusReceiver.Complete rozsah by byly propojené z rozsahu Message . Tady je příklad toho, jak to vypadá v Application Insights:

Obrázek znázorňující ukázkové distribuované trasování

Na předchozím snímku obrazovky vidíte komplexní transakci, kterou můžete zobrazit v Application Insights na portálu. V tomto scénáři aplikace odesílá zprávy a ke zpracování zpráv používá ServiceBusSessionProcessor . Aktivita je propojena Message s ServiceBusSender.Send, ServiceBusReceiver.Receive, ServiceBusSessionProcessor.ProcessSessionMessagea ServiceBusReceiver.Complete.

Poznámka:

Další informace najdete v tématu Distribuované trasování a korelace prostřednictvím zasílání zpráv služby Service Bus.

Řešení potíží s odesílatelem

Nejde odeslat dávku s více klíči oddílu

Když aplikace odešle dávku do entity s povoleným oddílem, musí mít všechny zprávy zahrnuté v jedné operaci odeslání stejné PartitionKey. Pokud je vaše entita povolená relace, platí pro tuto vlastnost stejný požadavek SessionId . Chcete-li odesílat zprávy s různými PartitionKey nebo SessionId hodnotami, seskupte zprávy v samostatných ServiceBusMessageBatch instancích nebo je zahrňte do samostatných ServiceBusMessage volání sendMessagesAsync přetížení, které přebírá sadu instancí.

Batch se nepovedlo odeslat

Dávka zprávy buď obsahuje ServiceBusMessageBatch dvě nebo více zpráv, nebo volání SendMessagesAsync , kde se předávají dvě nebo více zpráv. Služba neumožňuje dávku zpráv překročit 1 MB. Toto chování platí bez ohledu na to, jestli je povolená funkce podpory velkých zpráv Premium. Pokud máte v úmyslu odeslat zprávu větší než 1 MB, je nutné ji odeslat jednotlivě, nikoli seskupit s jinými zprávami. Typ ServiceBusMessageBatch bohužel nepodporuje ověřování, že dávka neobsahuje žádné zprávy větší než 1 MB, protože služba omezuje velikost a může se změnit. Pokud tedy máte v úmyslu používat funkci podpory velkých zpráv úrovně Premium, ujistěte se, že odesíláte zprávy přes 1 MB jednotlivě.

Řešení potíží s příjemcem

Počet vrácených zpráv neodpovídá číslu požadovanému v dávkovém příjmu

Při pokusu o dávkovou operaci příjmu, tj. předání maxMessages hodnoty dvou nebo větších do metody ReceiveMessagesAsync , není zaručeno, že obdržíte počet požadovaných zpráv, i když fronta nebo odběr obsahuje tolik zpráv, které jsou v té době k dispozici, a to i v případě, že ještě uplynulo celé nakonfigurované maxWaitTime . Aby se maximalizovala propustnost a zabránilo vypršení platnosti zámku, příjemce po předání první zprávy před odesláním zpráv ke zpracování počká dalších 20 milisekund. Určuje maxWaitTime , jak dlouho příjemce čeká na přijetí první zprávy – další zprávy se počkají na 20 milisekund. Proto by vaše aplikace neměla předpokládat, že všechny zprávy, které jsou k dispozici, budou přijaty v jednom volání.

Zpráva nebo zámek relace se ztratí před vypršením platnosti zámku.

Služba Service Bus používá protokol AMQP, který je stavový. Vzhledem k povaze protokolu platí, že pokud je propojení, které připojuje klienta a službu, odpojeno po přijetí zprávy, ale před vyrovnáním zprávy se zpráva nedá vyřešit při opětovném připojení odkazu. Propojení je možné odpojit kvůli krátkodobému přechodnému selhání sítě, výpadku sítě nebo kvůli vypršení 10minutového časového limitu nečinnosti služby. Opětovné připojení odkazu se automaticky provede jako součást jakékoli operace, která vyžaduje propojení, tj. vyrovnání nebo příjem zpráv. V takovém případě obdržíte s Reason koncem ServiceBusException MessageLockLost platnosti zámku nebo SessionLockLost i v případě, že čas vypršení platnosti zámku ještě neproběhl.

Procházení naplánovaných nebo odložených zpráv

Při náhledu zpráv jsou zahrnuté naplánované a odložené zprávy. Mohou být identifikovány ServiceBusReceivedMessage.State vlastnost. Jakmile budete mít SequenceNumber odložené zprávy, můžete ji přijmout se zámkem prostřednictvím ReceiveDeferredMessagesAsync metoda.

Při práci s tématy nemůžete zobrazit naplánované zprávy v odběru, protože zprávy zůstanou v tématu, dokud naplánovaný čas nezačnete frontu. Jako alternativní řešení můžete vytvořit ServiceBusReceiver předávající název tématu, abyste si mohli tyto zprávy prohlédnout. Při použití názvu tématu nefungují žádné jiné operace s příjemcem.

Procházení zpráv relací napříč všemi relacemi

K zobrazení všech relací můžete použít běžný ServiceBusReceiver . Pokud chcete zobrazit náhled konkrétní relace, můžete použít ServiceBusSessionReceiver, ale potřebujete získat zámek relace.

Při přístupu k textu zprávy se vyvolá výjimka NotSupportedException

K tomuto problému nejčastěji dochází ve scénářích spolupráce při příjmu zprávy odeslané z jiné knihovny, která používá jiný základní formát zprávy AMQP. Pokud s těmito typy zpráv pracujete, přečtěte si ukázku textu zprávy AMQP a zjistěte, jak získat přístup k textu zprávy.

Řešení potíží s procesorem

Automatické uzamčení nefunguje

Automatické uzamčení závisí na systémovém čase a určuje, kdy se má zámek pro zprávu nebo relaci obnovit. Pokud váš systémový čas není přesný, například hodiny jsou pomalé, může se stát, že se obnovení zámku neprodlouží, než se zámek ztratí. Pokud obnovení automatického zámku nefunguje, ujistěte se, že systémový čas je přesný.

Zdá se, že procesor přestane reagovat nebo má problémy s latencí při použití vysoké souběžnosti

Toto chování je často způsobeno hladovým vláknem, zejména při použití procesoru relace a použití velmi vysoké hodnoty pro MaxConcurrentSessions vzhledem k počtu jader na počítači. První věcí, kterou je potřeba zkontrolovat, je zajistit, abyste v žádném z obslužných rutin událostí neprovádí synchronizaci async. Sync-over-async je snadný způsob, jak způsobit zablokování a hladovění vláken. I když nesynchronizujete, může jakýkoli čistý synchronizační kód v obslužných rutinách přispět k hladovění vlákna. Pokud jste zjistili, že problém není, například proto, že máte čistý asynchronní kód, můžete zkusit zvýšit hodnotu [TryTimeout][TryTimeout]. Snižuje tlak na fond vláken snížením počtu kontextových přepínačů a časových limitů, ke kterým dochází při použití procesoru relace. Výchozí hodnota pro [TryTimeout][TryTimeout] je 60 sekund, ale dá se nastavit až 1 hodinu. Doporučujeme testovat s nastaveným TryTimeout na 5 minut jako výchozí bod a iterovat odsud. Pokud žádný z těchto návrhů nefunguje, stačí jednoduše škálovat na více hostitelů a snížit souběžnost ve vaší aplikaci, ale spuštění aplikace na více hostitelích, abyste dosáhli požadované celkové souběžnosti.

Další čtení:

Přepnutí relací procesorem relací trvá příliš dlouho.

To je možné nakonfigurovat pomocí relace [SessionIdleTimeout][SessionIdleTimeout], která procesoru říká, jak dlouho má čekat na přijetí zprávy z relace, a teprve potom se vzdát a přesunout do jiné. Je užitečné, pokud máte mnoho řídkých naplněných relací, kde každá relace obsahuje jenom několik zpráv. Pokud očekáváte, že každá relace bude mít mnoho zpráv, které se zpochybní, může být nastavení příliš nízké, protože výsledkem je zbytečné zavření relace.

Procesor se okamžitě zastaví

To se často pozoruje u ukázkových nebo testovacích scénářů. StartProcessingAsync vrátí okamžitě po spuštění procesoru. Volání této metody nezablokuje a udržuje vaši aplikaci naživu, když je procesor spuštěný, takže k tomu potřebujete nějaký jiný mechanismus. Pro ukázky nebo testování stačí, když po spuštění procesoru přidáte Console.ReadKey() volání. V produkčních scénářích budete pravděpodobně chtít použít nějaký druh integrace architektury, jako je [BackgroundService][BackgroundService] a poskytnout pohodlné háčky životního cyklu aplikace, které je možné použít ke spuštění a vyřazení procesoru.

Řešení potíží s transakcemi

Obecné informace o transakcích ve službě Service Bus najdete v tématu [Přehled zpracování transakcí služby Service Bus][Transakce].

Podporované operace

Při použití transakcí se nepodporují všechny operace. Seznam podporovaných transakcí najdete v tématu [Operace v rámci oboru transakce][TransactionOperations].

Timeout

Transakce vyprší po [časovém období][TransactionTimeout], takže je důležité, aby zpracování, ke kterému dochází v rámci oboru transakce, dodržovalo tento časový limit.

Operace v transakci se neopakují.

Toto chování je úmyslné. Představte si následující scénář – pokoušíte se dokončit zprávu v rámci transakce, ale dojde k nějaké přechodné chybě, například ServiceBusException s chybou Reason ServiceCommunicationProblem. Předpokládejme, že požadavek ve skutečnosti provede službu. Pokud by se klient chtěl opakovat, služba by viděla dvě úplné žádosti. První dokončení nebude dokončeno, dokud transakce nebude potvrzena. Druhý dokončený proces není možné vyhodnotit ani před dokončením prvního dokončení. Transakce na klientovi čeká na dokončení dokončení. Tím se vytvoří vzájemné zablokování, kdy služba čeká na dokončení transakce klientem, ale klient čeká na potvrzení druhé operace dokončení. Transakce nakonec vyprší po 2 minutách, ale jedná se o špatné uživatelské prostředí. Z tohoto důvodu neopakujeme operace v rámci transakce.

Transakce napříč entitami nefungují

Chcete-li provádět transakce, které zahrnují více entit, je nutné nastavit ServiceBusClientOptions.EnableCrossEntityTransactions vlastnost na true. Podrobnosti najdete v ukázce [Transakce napříč entitami][CrossEntityTransactions].

Kvóty

Informace o kvótách služby Service Bus najdete [zde][ServiceBusQuotas].

Problémy s připojením, certifikátem nebo vypršením časového limitu

Následující kroky vám pomůžou při řešení potíží s připojením, certifikátem nebo vypršením časového limitu pro všechny služby v části *.servicebus.windows.net.

  • Přejděte na nebo wget https://<yournamespace>.servicebus.windows.net/. Pomáhá s kontrolou, jestli máte problémy s filtrováním IP adres nebo virtuální sítí nebo řetězem certifikátů, které jsou běžné při použití sady Java SDK.

    Příklad úspěšné zprávy:

    <feed xmlns="http://www.w3.org/2005/Atom"><title type="text">Publicly Listed Services</title><subtitle type="text">This is the list of publicly-listed services currently available.</subtitle><id>uuid:27fcd1e2-3a99-44b1-8f1e-3e92b52f0171;id=30</id><updated>2019-12-27T13:11:47Z</updated><generator>Service Bus 1.1</generator></feed>

    Příklad chybové zprávy o selhání:

    <Error>
    <Code>400</Code>
    <Detail>
        Bad Request. To know more visit https://aka.ms/sbResourceMgrExceptions. . TrackingId:b786d4d1-cbaf-47a8-a3d1-be689cda2a98_G22, SystemTracker:NoSystemTracker, Timestamp:2019-12-27T13:12:40
    </Detail>
</Error>

  • Spuštěním následujícího příkazu zkontrolujte, jestli je v bráně firewall blokovaný nějaký port. Používané porty jsou 443 (HTTPS), 5671 a 5672 (AMQP) a 9354 (Net Messaging/SBMP). V závislosti na používané knihovně se používají i další porty. Tady je ukázkový příkaz, který zkontroluje, jestli je blokovaný port 5671. C

    tnc <yournamespacename>.servicebus.windows.net -port 5671

    V Linuxu:

    telnet <yournamespacename>.servicebus.windows.net 5671

  • Pokud dojde k přerušovaným problémům s připojením, spusťte následující příkaz a zkontrolujte, jestli nedošlo k zahozeným paketům. Tento příkaz se pokusí vytvořit 25 různých připojení TCP každých 1 sekundu se službou. Pak se můžete podívat, kolik jich bylo úspěšných/neúspěšných a můžete se také podívat na latenci připojení TCP. Nástroj si můžete stáhnout odsud psping .

    .\psping.exe -n 25 -i 1 -q <yournamespace>.servicebus.windows.net:5671 -nobanner

    Ekvivalentní příkazy můžete použít, pokud používáte jiné nástroje, například tnc, pingatd.

  • Získejte trasování sítě, pokud předchozí kroky nepomáhají a analyzují ho pomocí nástrojů, jako je Wireshark. V případě potřeby kontaktujte podpora Microsoftu.

  • Pokud chcete najít správné IP adresy, které chcete přidat do seznamu povolených připojení, přečtěte si, jaké IP adresy je potřeba přidat do seznamu povolených.

Dne 30. září 2026 vyřadíme podporu protokolu SBMP pro Azure Service Bus, takže tento protokol už nebudete moct používat po 30. září 2026. Migrujte na nejnovější knihovny sady SDK služby Azure Service Bus pomocí protokolu AMQP, který nabízí důležité aktualizace zabezpečení a vylepšené funkce před tímto datem.

Další informace najdete v oznámení o vyřazení podpory.

Problémy, ke kterým může dojít u upgradů nebo restartování služeb

Příznaky

  • Žádosti můžou být momentálně omezené.
  • Může dojít k poklesu příchozích zpráv nebo požadavků.
  • Soubor protokolu může obsahovat chybové zprávy.
  • Aplikace se můžou po dobu několika sekund odpojit od služby.

Příčina

Upgrady a restartování back-endových služeb můžou způsobit tyto problémy ve vašich aplikacích.

Rozlišení

Pokud kód aplikace používá sadu SDK, zásady opakování jsou už integrované a aktivní. Aplikace se znovu připojí bez významného dopadu na aplikaci nebo pracovní postup.

Neoprávněný přístup: Vyžaduje se odesílání deklarací identity.

Příznaky

Tato chyba se může zobrazit při pokusu o přístup k tématu služby Service Bus ze sady Visual Studio na místním počítači pomocí spravované identity přiřazené uživatelem s oprávněními k odeslání.

Service Bus Error: Unauthorized access. 'Send' claim\(s\) are required to perform this operation.

Příčina

Identita nemá oprávnění pro přístup k tématu služby Service Bus.

Rozlišení

Pokud chcete tuto chybu vyřešit, nainstalujte knihovnu Microsoft.Azure.Services.AppAuthentication . Další informace najdete v tématu Místní ověřování vývoje.

Informace o přiřazování oprávnění k rolím najdete v tématu Ověření spravované identity pomocí ID Microsoft Entra pro přístup k prostředkům služby Azure Service Bus.

Výjimka služby Service Bus: Selhání tokenu put

Příznaky

Zobrazí se tato chybová zpráva:

Microsoft.Azure.ServiceBus.ServiceBusException: Put token failed. status-code: 403, status-description: The maximum number of '1000' tokens per connection has been reached.

30. září 2026 vyřadíme knihovny sady SDK služby Azure Service Bus pro WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus a com.microsoft.azure.servicebus, které nevyhovují pokynům sady Azure SDK. Také ukončíme podporu protokolu SBMP, takže tento protokol už nebudete moct používat po 30. září 2026. Před tímto datem migrujte na nejnovější knihovny sady Azure SDK, které nabízejí důležité aktualizace zabezpečení a vylepšené funkce.

I když starší knihovny je možné používat i po 30. září 2026, nebudou už od Microsoftu dostávat oficiální podporu a aktualizace. Další informace najdete v oznámení o vyřazení podpory.

Příčina

Počet ověřovacích tokenů pro souběžné propojení v jednom připojení k oboru názvů služby Service Bus překročil limit: 1000.

Rozlišení

Proveďte jeden z následujících kroků:

  • Snížení počtu souběžných propojení v jednom připojení nebo použití nového připojení
  • Použití sad SDK pro Azure Service Bus, které zajistí, že se do této situace nedostanete (doporučeno)

Zámky prostředků nefungují při použití sady SDK roviny dat

Příznaky

Nakonfigurovali jste zámek odstranění v oboru názvů služby Service Bus, ale pomocí Service Bus Exploreru můžete odstranit prostředky v oboru názvů (fronty, témata atd.).

Příčina

Zámek prostředků se zachová v Azure Resource Manageru (řídicí rovině) a nezabrání volání sady SDK roviny dat v odstranění prostředku přímo z oboru názvů. Samostatný Průzkumník služby Service Bus používá sadu SDK roviny dat, takže odstranění prochází.

Rozlišení

Doporučujeme použít rozhraní API založené na Azure Resource Manageru prostřednictvím webu Azure Portal, PowerShellu, rozhraní příkazového řádku nebo šablony Resource Manageru k odstranění entit, aby zámek prostředku zabránil náhodnému odstranění prostředků.

Entita už není k dispozici.

Příznaky

Zobrazí se chyba, že entita už není dostupná.

Příčina

Prostředek byl pravděpodobně odstraněn. Podle těchto kroků určete, proč byla entita odstraněna.

  • Zkontrolujte protokol aktivit, abyste zjistili, jestli se jedná o žádost Azure Resource Manageru o odstranění.
  • Zkontrolujte provozní protokol a zjistěte, jestli nedošlo k přímému volání rozhraní API k odstranění. Informace o tom, jak shromažďovat provozní protokol, najdete v tématu Monitorování služby Azure Service Bus. Schéma a příklad protokolu operací najdete v části Protokoly operací.
  • V protokolu operací zkontrolujte, jestli nedošlo k souvisejícímu autodeleteonidle odstranění.

Další kroky

Podívejte se na následující články:

  • Výjimky Azure Resource Manageru Vypíše výjimky vygenerované při interakci se službou Azure Service Bus pomocí Azure Resource Manageru (prostřednictvím šablon nebo přímých volání).
  • Výjimky zasílání zpráv Poskytuje seznam výjimek generovaných rozhraním .NET Framework pro Azure Service Bus.