Felsökningsguide för Azure Service Bus

Den här artikeln innehåller felsökningstips och rekommendationer för några problem som du ser när du använder Azure Service Bus.

Anslutningsproblem

Tidsgräns vid anslutning till tjänsten

Beroende på värdmiljö och nätverk kan ett anslutningsproblem uppstå för program som antingen en TimeoutException, OperationCanceledExceptioneller en ServiceBusException med ReasonServiceTimeout och inträffar oftast när klienten inte kan hitta en nätverkssökväg till tjänsten.

För att felsöka:

• Kontrollera att det anslutningssträng eller fullständigt kvalificerade domännamnet som du angav när du skapade klienten är korrekt. Information om hur du hämtar en anslutningssträng finns i Hämta en Service Bus-anslutningssträng.
• Kontrollera brandväggs- och portbehörigheterna i värdmiljön. Kontrollera att AMQP-portarna (Advanced Message Queuing Protocol) 5671 och 5672 är öppna och att slutpunkten tillåts via brandväggen.
• Prova att använda transportalternativet Web Socket, som ansluter med port 443. Mer information finns i konfigurera transporten.
• Se om nätverket blockerar specifika IP-adresser. Mer information finns i Vilka IP-adresser behöver jag tillåta?
• Om tillämpligt kontrollerar du proxykonfigurationen. Mer information finns i: Konfigurera transporten
• Mer information om hur du felsöker nätverksanslutningar finns i: Anslutning, certifikat eller tidsgränsproblem.

SSL-handskakningsfel (Secure Socket Layer)

Det här felet kan inträffa när en avlyssningsproxy används. För att verifiera rekommenderar vi att du testar programmet i värdmiljön med proxyn inaktiverad.

Socket-överbelastningsfel

Program bör föredra att behandla Service Bus-typerna som singletons, skapa och använda en enda instans under programmets livslängd. Varje ny ServiceBusClient som skapas resulterar i en ny AMQP-anslutning, som använder en socket. Typen ServiceBusClient hanterar anslutningen för alla typer som skapats från den instansen. Varje ServiceBusReceiver, ServiceBusSessionReceiver, ServiceBusSender och ServiceBusProcessor hanterar sin egen AMQP-länk för den associerade Service Bus-entiteten. När du använder ServiceBusSessionProcessor upprättas flera AMQP-länkar beroende på antalet sessioner som bearbetas samtidigt.

Klienterna är säkra att cachelagrade när de är inaktiva. de säkerställer effektiv hantering av nätverks-, CPU- och minnesanvändning, vilket minimerar deras påverkan under perioder av inaktivitet. Det är också viktigt att antingen CloseAsync eller DisposeAsync anropas när en klient inte längre behövs för att säkerställa att nätverksresurserna rensas korrekt.

Att lägga till komponenter i anslutningssträng fungerar inte

Den aktuella generationen av Service Bus-klientbiblioteket stöder endast anslutningssträng i formuläret som publiceras av Azure Portal. De anslutningssträng är avsedda att endast tillhandahålla grundläggande plats och delad nyckelinformation. Konfigurering av klienternas beteende sker genom dess alternativ.

Tidigare generationer av Service Bus-klienterna tillät att vissa beteenden konfigurerades genom att nyckel-/värdekomponenter skulle läggas till i en anslutningssträng. Dessa komponenter identifieras inte längre och påverkar inte klientbeteendet.

Alternativ för "TransportType=AmqpWebSockets"

Information om hur du konfigurerar Web Sockets som transporttyp finns i Konfigurera transporten.

Alternativ för "Authentication=Managed Identity"

Information om hur du autentiserar med hanterad identitet finns i: Identitet och autentiseringsuppgifter för delad åtkomst. Mer information om biblioteket finns i Azure.Identity Autentisering och Azure SDK.

Loggning och diagnostik

Service Bus-klientbiblioteket är helt instrumenterat för loggningsinformation på olika detaljnivåer med hjälp av .NET EventSource för att generera information. Loggning utförs för varje åtgärd och följer mönstret för att markera startpunkten för åtgärden, dess slutförande och eventuella undantag som påträffas. Ytterligare information som kan ge insikter loggas också i kontexten för den associerade åtgärden.

Aktivera loggning

Service Bus-klientloggarna är tillgängliga för alla EventListener genom att välja källor som börjar med Azure-Messaging-ServiceBus eller genom att välja alla källor som har egenskapen AzureEventSource. För att göra det enklare att samla in loggar från Azure-klientbiblioteken Azure.Core erbjuder biblioteket som används av Service Bus en AzureEventSourceListener.

Mer information finns i: Loggning med Azure SDK för .NET.

Distribuerad spårning

Service Bus-klientbiblioteket stöder distribuerad spårning via integrering med Application Insights SDK. Den har också experimentellt stöd för OpenTelemetry-specifikationen via .NET ActivitySource-typen som introducerades i .NET 5. Information om hur du aktiverar ActivitySource stöd för användning med OpenTelemetry finns i Stöd för ActivitySource.

För att kunna använda GA DiagnosticActivity-stöd kan du integrera med Application Insights SDK. Mer information finns i ApplicationInsights med Azure Monitor.

Biblioteket skapar följande intervall:

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

De flesta spann är självförklarande och startas och stoppas under den operation som bär dess namn. Det spann som binder ihop de andra är Message. Det sätt som meddelandet spåras på är via Diagnostic-Id det som anges i egenskapen ServiceBusMessage.ApplicationProperties av biblioteket under sändnings- och schemaåtgärder. I Application Insights Message visas intervall som länkning till de olika andra intervall som användes för att interagera med meddelandet, ServiceBusReceiver.Receive till exempel spannet, ServiceBusSender.Send spannet och spannet ServiceBusReceiver.Complete skulle alla länkas från Message spannet. Här är ett exempel på hur detta ser ut i Application Insights:

I skärmbilden ovan ser du den transaktion från slutpunkt till slutpunkt som kan visas i Application Insights i portalen. I det här scenariot skickar programmet meddelanden och använder ServiceBusSessionProcessor för att bearbeta dem. Aktiviteten Message är länkad till ServiceBusSender.Send, ServiceBusReceiver.Receive, ServiceBusSessionProcessor.ProcessSessionMessageoch ServiceBusReceiver.Complete.

Kommentar

Mer information finns i Distribuerad spårning och korrelation via Service Bus-meddelanden.

Felsöka avsändarproblem

Det går inte att skicka en batch med flera partitionsnycklar

När en app skickar en batch till en partitionsaktiverad entitet måste alla meddelanden som ingår i en enda sändningsåtgärd ha samma PartitionKey. Om entiteten är sessionsaktiverad gäller samma krav för SessionId egenskapen. Om du vill skicka meddelanden med olika PartitionKey värden eller SessionId gruppera meddelandena i separata ServiceBusMessageBatch instanser eller inkludera dem i separata anrop till överlagringen SendMessagesAsync som tar en uppsättning ServiceBusMessage instanser.

Batch kan inte skicka

En meddelandebatch innehåller antingen ServiceBusMessageBatch två eller flera meddelanden eller ett anrop till SendMessagesAsync där två eller flera meddelanden skickas. Tjänsten tillåter inte att en meddelandebatch överskrider 1 MB. Det här beteendet gäller oavsett om funktionen för premiumsupport för stora meddelanden är aktiverad eller inte. Om du tänker skicka ett meddelande som är större än 1 MB måste det skickas individuellt i stället för grupperade med andra meddelanden. Tyvärr stöder inte ServiceBusMessageBatch-typen för närvarande validering av att en batch inte innehåller några meddelanden som är större än 1 MB eftersom storleken begränsas av tjänsten och kan ändras. Om du tänker använda funktionen för premiumsupport för stora meddelanden ska du därför se till att du skickar meddelanden över 1 MB individuellt.

Felsöka problem med mottagare

Antal meddelanden som returneras matchar inte det begärda numret i batch-mottagningen

När du försöker utföra en batch-mottagningsåtgärd, d.v.s. att skicka ett maxMessages värde på två eller fler till metoden ReceiveMessagesAsync , är du inte garanterad att ta emot antalet begärda meddelanden, även om kön eller prenumerationen har så många meddelanden tillgängliga vid den tidpunkten, och även om hela konfigurerade maxWaitTime ännu inte har förflutit. För att maximera dataflödet och undvika låsets förfallotid väntar mottagaren ytterligare 20 millisekunder på ytterligare meddelanden innan meddelandena skickas för bearbetning när det första meddelandet kommer över kabeln. Styr maxWaitTime hur länge mottagaren väntar på att få det första meddelandet – efterföljande meddelanden väntar i 20 millisekunder. Därför bör programmet inte förutsätta att alla tillgängliga meddelanden tas emot i ett anrop.

Meddelande- eller sessionslåset går förlorat innan låset upphör att gälla

Service Bus-tjänsten använder AMQP-protokollet, som är tillståndskänsligt. Om länken som ansluter klienten och tjänsten kopplas från efter att ett meddelande har tagits emot på grund av protokollets natur, men innan meddelandet har lösts, kan meddelandet inte lösas när länken återansluts. Länkar kan kopplas från på grund av ett kortvarigt tillfälligt nätverksfel, ett nätverksavbrott eller på grund av att tjänsten framtvingade tidsgränsen på 10 minuter för inaktivitet. Återanslutningen av länken sker automatiskt som en del av alla åtgärder som kräver länken, dvs. att lösa eller ta emot meddelanden. I den här situationen får du ett ServiceBusException med Reason eller MessageLockLostSessionLockLost även om låsets förfallotid ännu inte har passerat.

Bläddra bland schemalagda eller uppskjutna meddelanden

Schemalagda och uppskjutna meddelanden ingår när du tittar på meddelanden. De kan identifieras av egenskapen ServiceBusReceivedMessage.State . När du har sekvensnumret för ett uppskjutet meddelande kan du ta emot det med ett lås via metoden ReceiveDeferredMessagesAsync .

När du arbetar med ämnen kan du inte titta på schemalagda meddelanden i prenumerationen, eftersom meddelandena finns kvar i ämnet förrän den schemalagda kötiden. Som en lösning kan du skapa en ServiceBusReceiver som skickar in ämnesnamnet för att granska sådana meddelanden. Inga andra åtgärder med mottagaren fungerar när du använder ett ämnesnamn.

Bläddra bland sessionsmeddelanden i alla sessioner

Du kan använda en vanlig ServiceBusReceiver för att granska alla sessioner. Om du vill titta efter en specifik session kan du använda ServiceBusSessionReceiver, men du måste skaffa ett sessionslås.

NotSupportedException genereras vid åtkomst till meddelandetexten

Det här problemet uppstår oftast i interop-scenarier när du tar emot ett meddelande som skickas från ett annat bibliotek som använder ett annat AMQP-meddelandetextformat. Om du interagerar med dessa typer av meddelanden kan du läsa exempel på AMQP-meddelandetext för att lära dig hur du kommer åt meddelandetexten.

Felsöka processorproblem

Automatisk inlåsningsförnyelse fungerar inte

Automatisk inlåsningsförnyelse förlitar sig på systemtiden för att avgöra när ett lås ska förnyas för ett meddelande eller en session. Om systemtiden till exempel inte är korrekt är klockan långsam och låsförnyelsen kanske inte inträffar innan låset går förlorat. Se till att systemtiden är korrekt om automatisk inlåsningsförnyelse inte fungerar.

Processorn verkar hänga sig eller har problem med svarstid vid användning av hög samtidighet

Det här beteendet orsakas ofta av trådsvält, särskilt när du använder sessionsprocessorn och använder ett mycket högt värde för MaxConcurrentSessions, i förhållande till antalet kärnor på datorn. Det första du bör kontrollera är att se till att du inte gör synkronisering över asynkronisering i någon av dina händelsehanterare. Sync-over-async är ett enkelt sätt att orsaka dödlägen och trådsvältning. Även om du inte synkroniserar över asynkronisering kan all ren synkroniseringskod i dina hanterare bidra till trådsvältning. Om du har fastställt att det inte är problemet, till exempel eftersom du har ren asynkron kod, kan du försöka öka TryTimeout. Det minskar trycket på trådpoolen genom att minska antalet kontextväxlar och timeouter som inträffar när du använder sessionsprocessorn i synnerhet. Standardvärdet för TryTimeout är 60 sekunder, men det kan ställas in hela vägen upp till 1 timme. Vi rekommenderar att du testar med TryTimeout inställningen 5 minuter som utgångspunkt och itererar därifrån. Om inget av dessa förslag fungerar behöver du helt enkelt skala ut till flera värdar, vilket minskar samtidigheten i ditt program, men kör programmet på flera värdar för att uppnå önskad övergripande samtidighet.

Ytterligare läsning:

• Felsöka utsvulten trådpool
• Diagnostisera .NET Core-trådpoolssvält med PerfView (varför min tjänst inte mättar alla kärnor eller verkar stanna upp)
• Diagnostisera problem med överbelastning av trådpooler i .NET Core Apps(video)

Sessionsprocessorn tar för lång tid att växla sessioner

Detta kan konfigureras med hjälp av SessionIdleTimeout, som talar om för processorn hur lång tid det tar att vänta med att ta emot ett meddelande från en session, innan du ger upp och flyttar till en annan. Det är användbart om du har många glesa sessioner, där varje session bara har några få meddelanden. Om du förväntar dig att varje session kommer att ha många meddelanden som sipprar in kan det vara kontraproduktivt att ställa in den för lågt, eftersom det resulterar i onödig stängning av sessionen.

Processorn stoppas omedelbart

Detta observeras ofta för demo- eller testscenarier. StartProcessingAsync returnerar omedelbart efter att processorn har startats. Att anropa den här metoden blockerar inte och håller programmet vid liv medan processorn körs, så du behöver någon annan mekanism för att göra det. För demonstrationer eller testning räcker det att bara lägga till ett Console.ReadKey() anrop när du har startat processorn. För produktionsscenarier vill du förmodligen använda någon form av ramverksintegrering som BackgroundService för att tillhandahålla praktiska programlivscykelkrokar som kan användas för att starta och ta bort processorn.

Felsöka transaktioner

Allmän information om transaktioner i Service Bus finns i Översikt över Service Bus-transaktionsbearbetning.

Åtgärder som stöds

Alla åtgärder stöds inte när du använder transaktioner. En lista över transaktioner som stöds finns i Åtgärder inom ett transaktionsomfång.

Timeout

En transaktion överskrider tidsgränsen efter en viss tidsperiod, så det är viktigt att bearbetning som sker inom ett transaktionsomfång följer den här tidsgränsen.

Åtgärder i en transaktion görs inte på nytt

Det här är avsiktligt. Tänk på följande scenario – du försöker slutföra ett meddelande i en transaktion, men det finns ett tillfälligt fel som inträffar, till exempel ServiceBusException med en Reason av ServiceCommunicationProblem. Anta att begäran faktiskt gör det till tjänsten. Om klienten skulle försöka igen skulle tjänsten se två fullständiga begäranden. Det första slutförda slutförs inte förrän transaktionen har checkats in. Det andra slutfört kan inte ens utvärderas innan det första slutförts. Transaktionen på klienten väntar på att slutföras. Detta skapar ett dödläge där tjänsten väntar på att klienten ska slutföra transaktionen, men klienten väntar på att tjänsten ska bekräfta den andra fullständiga åtgärden. Transaktionen kommer så småningom att överskrida tidsgränsen efter 2 minuter, men det här är en dålig användarupplevelse. Därför försöker vi inte utföra åtgärder igen i en transaktion.

Transaktioner mellan entiteter fungerar inte

För att kunna utföra transaktioner som involverar flera entiteter måste du ange ServiceBusClientOptions.EnableCrossEntityTransactions egenskapen till true. Mer information finns i exemplet Transaktioner mellan entiteter .

Kvoter

Information om Service Bus-kvoter finns här.

Problem med anslutning, certifikat eller timeout

Följande steg hjälper dig att felsöka problem med anslutning/certifikat/timeout för alla tjänster under *.servicebus.windows.net.

• Bläddra till eller wgethttps://<yournamespace>.servicebus.windows.net/. Det hjälper dig att kontrollera om du har problem med IP-filtrering eller virtuellt nätverk eller certifikatkedja, vilket är vanligt när du använder Java SDK.

  Ett exempel på lyckat meddelande:

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

  Ett exempel på felmeddelande:

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

• Kör följande kommando för att kontrollera om någon port är blockerad i brandväggen. Portar som används är 443 (HTTPS), 5671 och 5672 (AMQP) och 9354 (Net Messaging/SBMP). Beroende på vilket bibliotek du använder används även andra portar. Här är exempelkommandot som kontrollerar om 5671-porten är blockerad. C

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

  I Linux:

  telnet <yournamespacename>.servicebus.windows.net 5671
  

• När det uppstår tillfälliga anslutningsproblem kör du följande kommando för att kontrollera om det finns några borttagna paket. Det här kommandot försöker upprätta 25 olika TCP-anslutningar var 1 sekund med tjänsten. Sedan kan du kontrollera hur många av dem som lyckades/misslyckades och även se TCP-anslutningsfördröjningen. Du kan ladda ned psping verktyget härifrån.

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

  Du kan använda motsvarande kommandon om du använder andra verktyg som tnc, pingoch så vidare.

• Hämta en nätverksspårning om föregående steg inte hjälper och analyserar den med hjälp av verktyg som Wireshark. Kontakta Microsoft Support om det behövs.

• Information om hur du hittar rätt IP-adresser att lägga till i listan över tillåtna anslutningar finns i Vad IP-adresser behöver jag lägga till i listan över tillåtna adresser.

Den 30 september 2026 drar vi tillbaka stödet för SBMP-protokollet för Azure Service Bus, så att du inte längre kan använda det här protokollet efter den 30 september 2026. Migrera till de senaste Azure Service Bus SDK-biblioteken med hjälp av AMQP-protokollet, som erbjuder kritiska säkerhetsuppdateringar och förbättrade funktioner, före det datumet.

Mer information finns i meddelandet om supportavgång.

Problem som kan uppstå med tjänstuppgraderingar/omstarter

Symtom

• Begäranden kan tillfälligt begränsas.
• Det kan finnas en minskning av inkommande meddelanden/begäranden.
• Loggfilen kan innehålla felmeddelanden.
• Programmen kan vara frånkopplade från tjänsten i några sekunder.

Orsak

Uppgraderingar och omstarter av serverdelstjänsten kan orsaka dessa problem i dina program.

Åtgärd

Om programkoden använder SDK är återförsöksprincipen redan inbyggd och aktiv. Programmet återansluter utan betydande påverkan på programmet/arbetsflödet.

Obehörig åtkomst: Skicka anspråk krävs

Symtom

Du kan se det här felet när du försöker komma åt ett Service Bus-ämne från Visual Studio på en lokal dator med hjälp av en användartilldelad hanterad identitet med sändningsbehörigheter.

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

Orsak

Identiteten har inte behörighet att komma åt Service Bus-ämnet.

Åtgärd

Lös det här felet genom att installera biblioteket Microsoft.Azure.Services.AppAuthentication . Mer information finns i autentisering för lokal utveckling.

Information om hur du tilldelar behörigheter till roller finns i Autentisera en hanterad identitet med Microsoft Entra-ID för åtkomst till Azure Service Bus-resurser.

Service Bus-undantag: Det gick inte att placera token

Symtom

Du får följande felmeddelande:

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

Den 30 september 2026 drar vi tillbaka Azure Service Bus SDK-biblioteken WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus och com.microsoft.azure.servicebus, som inte följer Riktlinjerna för Azure SDK. Vi kommer också att avsluta stödet för SBMP-protokollet, så du kommer inte längre att kunna använda det här protokollet efter den 30 september 2026. Migrera till de senaste Azure SDK-biblioteken, som erbjuder kritiska säkerhetsuppdateringar och förbättrade funktioner, före det datumet.

Även om de äldre biblioteken fortfarande kan användas efter den 30 september 2026 får de inte längre officiell support och uppdateringar från Microsoft. Mer information finns i meddelandet om supportavgång.

Orsak

Antalet autentiseringstoken för samtidiga länkar i en enda anslutning till ett Service Bus-namnområde har överskridit gränsen: 1 000.

Åtgärd

Gör något av följande:

• Minska antalet samtidiga länkar i en enda anslutning eller använd en ny anslutning
• Använd SDK:er för Azure Service Bus, vilket säkerställer att du inte hamnar i den här situationen (rekommenderas)

Resurslås fungerar inte när du använder dataplanets SDK

Symtom

Du har konfigurerat ett borttagningslås på ett Service Bus-namnområde, men du kan ta bort resurser i namnområdet (köer, ämnen osv.) med hjälp av Service Bus Explorer.

Orsak

Resurslåset bevaras i Azure Resource Manager (kontrollplan) och förhindrar inte att SDK-anropet för dataplanet tar bort resursen direkt från namnområdet. Den fristående Service Bus Explorer använder dataplanets SDK, så borttagningen går igenom.

Åtgärd

Vi rekommenderar att du använder det Azure Resource Manager-baserade API:et via mallen Azure Portal, PowerShell, CLI eller Resource Manager för att ta bort entiteter så att resurslåset förhindrar att resurserna tas bort av misstag.

Entiteten är inte längre tillgänglig

Symtom

Du ser ett fel om att entiteten inte längre är tillgänglig.

Orsak

Resursen kan ha tagits bort. Följ de här stegen för att identifiera varför entiteten togs bort.

• Kontrollera aktivitetsloggen för att se om det finns en Azure Resource Manager-begäran om borttagning.
• Kontrollera driftloggen för att se om det fanns ett direkt API-anrop för borttagning. Information om hur du samlar in en driftlogg finns i Övervaka Azure Service Bus. Schemat och ett exempel på en åtgärdslogg finns i Åtgärdsloggar
• Kontrollera åtgärdsloggen för att se om det fanns en autodeleteonidle relaterad borttagning.

Nästa steg

Mer information finns i följande artiklar:

• Azure Resource Manager-undantag. Den visar undantag som genereras när du interagerar med Azure Service Bus med Hjälp av Azure Resource Manager (via mallar eller direktanrop).
• Meddelandefel. Den innehåller en lista över undantag som genereras av .NET Framework för Azure Service Bus.