Azure Service Bus için sorun giderme kılavuzu

Bu makalede, Azure Service Bus kullanırken gördüğünüz birkaç sorun için sorun giderme ipuçları ve öneriler sağlanır.

Bağlantı sorunları

Hizmete bağlanırken zaman aşımı

Konak ortamına ve ağa bağlı olarak, istemci hizmete yönelik bir TimeoutExceptionağ yolu bulamadığında uygulamalara bir bağlantı sorunu , OperationCanceledExceptionveya ServiceBusException ile veya ile ReasonServiceTimeout olarak ortaya çıkabilir.

Sorunu gidermek için:

• İstemciyi oluştururken belirttiğiniz bağlantı dizesi veya tam etki alanı adının doğru olduğunu doğrulayın. bağlantı dizesi alma hakkında bilgi için bkz. Service Bus bağlantı dizesi alma.
• Barındırma ortamınızda güvenlik duvarı ve bağlantı noktası izinlerini denetleyin. Gelişmiş Message Queuing Protokolü (AMQP) 5671 ve 5672 bağlantı noktalarının açık olup olmadığını ve uç noktaya güvenlik duvarı üzerinden izin verilip verilmediğini denetleyin.
• 443 numaralı bağlantı noktasını kullanarak bağlanan Web Yuvası aktarım seçeneğini kullanmayı deneyin. Ayrıntılar için bkz . Taşımayı yapılandırma.
• Ağınızın belirli IP adreslerini engelleyip engellemediğini görün. Ayrıntılar için bkz. Hangi IP adreslerine izin vermeliyim?
• Varsa ara sunucu yapılandırmasını doğrulayın. Ayrıntılar için bkz. Taşımayı yapılandırma
• Ağ bağlantısı sorunlarını giderme hakkında daha fazla bilgi için bkz. [Bağlan ivity, certificate veya timeout issues][#connectivity-certificate-or-timeout-issues].

Güvenli yuva katmanı (SSL) el sıkışma hataları

Kesme ara sunucusu kullanıldığında bu hata oluşabilir. Doğrulamak için, uygulamayı ana bilgisayar ortamında ara sunucu devre dışı bırakılmış olarak test etmenizi öneririz.

Yuva tükenme hataları

Uygulamalar, Service Bus türlerini tekil olarak ele alıp uygulamanın ömrü boyunca tek bir örnek oluşturmayı ve kullanmayı tercih etmelidir. Oluşturulan her yeni ServiceBusClient , yuva kullanan yeni bir AMQP bağlantısına neden olur. ServiceBusClient türü, bu örnekten oluşturulan tüm türler için bağlantıyı yönetir. Her ServiceBusReceiver, ServiceBusSessionReceiver, ServiceBusSender ve ServiceBusProcessor ilişkili Service Bus varlığı için kendi AMQP bağlantısını yönetir. ServiceBusSessionProcessor kullandığınızda, eşzamanlı olarak işlenen oturum sayısına bağlı olarak birden çok AMQP bağlantısı oluşturulur.

İstemciler boştayken önbelleğe alınır; ağ, CPU ve bellek kullanımının verimli bir şekilde yönetilmesini sağlayarak etkinlik dışı dönemlerdeki etkilerini en aza indirir. Ağ kaynaklarının düzgün bir şekilde temizlendiğinden CloseAsync emin olmak için bir istemciye artık ihtiyaç duyulmadığında veya DisposeAsync çağrılması da önemlidir.

bağlantı dizesi bileşenleri ekleme çalışmıyor

Service Bus istemci kitaplığının geçerli nesli yalnızca Azure portalı tarafından yayımlanan formda bağlantı dizesi destekler. bağlantı dizesi yalnızca temel konum ve paylaşılan anahtar bilgilerini sağlamaya yöneliktir. İstemcilerin davranışını yapılandırma, seçenekleri aracılığıyla gerçekleştirilir.

Service Bus istemcilerinin önceki nesilleri, bir bağlantı dizesi anahtar/değer bileşenleri eklenerek bazı davranışların yapılandırılmasına izin verdi. Bu bileşenler artık tanınmıyor ve istemci davranışı üzerinde hiçbir etkisi yok.

"TransportType=AmqpWebSockets" alternatifi

Web Yuvalarını aktarım türü olarak yapılandırmak için bkz . Taşımayı yapılandırma.

"Authentication=Managed Identity" Alternatifi

Yönetilen Kimlik ile kimlik doğrulaması yapmak için bkz. Kimlik ve Paylaşılan Erişim Kimlik Bilgileri. Kitaplık hakkında Azure.Identity daha fazla bilgi için bkz . Kimlik doğrulaması ve Azure SDK.

Günlüğe kaydetme ve tanılama

Service Bus istemci kitaplığı, bilgileri yaymak için .NET EventSource kullanarak çeşitli ayrıntı düzeylerinde bilgileri günlüğe kaydetmek için tam olarak izlenmiştir. Günlük her işlem için gerçekleştirilir ve işlemin başlangıç noktasını, tamamlanmasını ve karşılaşılan özel durumları işaretleme desenini izler. İçgörü sunabilecek ek bilgiler de ilişkili işlem bağlamında günlüğe kaydedilir.

Günlü kaydını etkinleştir

Service Bus istemci günlükleri, ile Azure-Messaging-ServiceBus başlayan veya özelliğine AzureEventSourcesahip tüm kaynakları kabul ederek herhangi bir EventListener kaynak için kullanılabilir. Azure istemci kitaplıklarından günlükleri yakalamayı kolaylaştırmak için Service Azure.Core Bus tarafından kullanılan kitaplık bir AzureEventSourceListenersunar.

Daha fazla bilgi için bkz. .NET için Azure SDK ile günlüğe kaydetme.

Dağıtılmış izleme

Service Bus istemci kitaplığı, Application Analizler SDK ile tümleştirme aracılığıyla dağıtılmış izlemeyi destekler. Ayrıca.NET 5'te tanıtılan .NET ActivitySource türü aracılığıyla OpenTelemetry belirtimi için deneysel desteğe sahiptir. OpenTelemetry ile kullanım desteğini etkinleştirmek ActivitySource için bkz . ActivitySource desteği.

GA DiagnosticActivity desteğini kullanmak için Application Analizler SDK ile tümleştirebilirsiniz. Azure İzleyici ile Uygulama Analizler bölümünde daha fazla ayrıntı bulabilirsiniz.

Kitaplık aşağıdaki yayılma aralıklarını oluşturur:

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

Yayılma yerlerinin çoğu açıklayıcıdır ve adını taşıyan işlem sırasında başlatılır ve durdurulur. Diğerlerini birbirine bağlayan yayılma alanıdır Message. İletinin izlenme yolu, Diagnostic-Id gönderme ve zamanlama işlemleri sırasında kitaplık tarafından ServiceBusMessage.ApplicationProperties özelliğinde ayarlanan aracılığıyla yapılır. Uygulama Analizler'nde, Message span'lar iletiyle etkileşime geçmek için kullanılan diğer çeşitli yayılma alanlarıyla (örneğin, ServiceBusReceiver.Receive yayılma alanı, ServiceBusSender.Send yayılma alanı ve ServiceBusReceiver.Complete yayılma alanı) bağlantı Message olarak görüntülenir. Uygulama Analizler'nde bunun nasıl göründüğüne bir örnek aşağıda verilmişti:

Yukarıdaki ekran görüntüsünde portaldaki Uygulama Analizler uçtan uca işlemi görürsünüz. Bu senaryoda, uygulama iletileri gönderiyor ve bunları işlemek için ServiceBusSessionProcessor'ı kullanıyor. Etkinlik Message , , ServiceBusReceiver.ReceiveServiceBusSessionProcessor.ProcessSessionMessageve ServiceBusReceiver.Completeile bağlantılıdırServiceBusSender.Send.

Not

Daha fazla bilgi için bkz . Service Bus mesajlaşması aracılığıyla dağıtılmış izleme ve bağıntı.

Gönderen sorunlarını giderme

Birden çok bölüm anahtarıyla toplu iş gönderemiyorum

Uygulama bölüm etkinleştirilmiş bir varlığa toplu iş gönderdiğinde, tek bir gönderme işlemine dahil edilen tüm iletiler aynı PartitionKeyolmalıdır. Varlığınız oturum etkinse, özellik için SessionId aynı gereksinim geçerlidir. Farklı PartitionKey veya SessionId değerlere sahip iletiler göndermek için, iletileri ayrı ServiceBusMessageBatch örneklerde gruplandırın veya bir dizi ServiceBusMessage örneği alan SendMessagesAsync aşırı yüklemesine ayrı çağrılara ekleyin.

Batch gönderemiyor

İleti toplu işlemi ServiceBusMessageBatch iki veya daha fazla ileti içeriyor veya iki veya daha fazla iletinin geçirildiği SendMessagesAsync çağrısı. Hizmet, ileti toplu işleminin 1 MB'ı aşmasına izin vermez. Premium büyük ileti desteği özelliğinin etkinleştirilip etkinleştirilmediği bu davranış geçerlidir. 1 MB'tan büyük bir ileti göndermek istiyorsanız, iletinin diğer iletilerle gruplandırılmaması yerine tek tek gönderilmesi gerekir. Ne yazık ki ServiceBusMessageBatch türü şu anda boyutu hizmet tarafından kısıtlandığından ve değişebileceğinden toplu işlemde 1 MB'tan büyük ileti bulunmadığını doğrulamayı desteklemez. Bu nedenle, premium büyük ileti desteği özelliğini kullanmayı planlıyorsanız tek tek 1 MB'ın üzerinde ileti gönderdiğinizden emin olun.

Alıcı sorunlarını giderme

Döndürülen ileti sayısı toplu alma işleminde istenen sayıyla eşleşmiyor

Toplu alma işlemi gerçekleştirmeye çalışırken, yani ReceiveMessagesAsync yöntemine iki veya daha büyük bir maxMessages değer geçirildiğinde, kuyrukta veya abonelikte o anda kullanılabilir sayıda ileti olsa ve yapılandırılanın maxWaitTime tamamı henüz bitmemiş olsa bile istenen ileti sayısını almanız garanti değildir. Aktarım hızını en üst düzeye çıkarmak ve kilit süresinin dolmasını önlemek için, ilk ileti kablo üzerinden geldiğinde alıcı, iletileri işlenmek üzere göndermeden önce ek iletiler için 20 milisaniye daha bekler. Alıcı ilk maxWaitTime iletiyi almak için ne kadar süre bekler denetler; izleyen iletiler 20 milisaniye bekler. Bu nedenle, uygulamanız kullanılabilir tüm iletilerin tek bir çağrıda alındığını varsaymamalıdır.

İleti veya oturum kilidi, kilit sona erme zamanından önce kaybolur

Service Bus hizmeti durum bilgisi olan AMQP protokollerini kullanır. Protokolün doğası gereği, istemciyi ve hizmeti bağlayan bağlantı bir ileti alındıktan sonra ayrılırsa, ancak ileti tamamlanmadan önce, ileti bağlantıyı yeniden bağlamaya yerleşemez. Kısa süreli geçici ağ hatası, ağ kesintisi veya hizmetin 10 dakikalık boşta kalma zaman aşımına uğraması nedeniyle bağlantılar ayrılabilir. Bağlantının yeniden bağlanması, bağlantıyı gerektiren herhangi bir işlemin bir parçası olarak otomatik olarak gerçekleşir, yani iletilerin yerleşmesi veya alınması. Bu durumda, kilit süre sonu süresi henüz geçmemiş olsa bile ile veya ile alırsınız ServiceBusExceptionMessageLockLostReasonSessionLockLost.

Zamanlanmış veya ertelenen iletilere göz atma

zamanlanmış ve ertelenen iletiler, iletilere göz atılırken eklenir. Bunlar ServiceBusReceivedMessage.State özelliği tarafından tanımlanabilir. Ertelenen iletinin SequenceNumber değerini aldıktan sonra ReceiveDeferredMessagesAsync yöntemi aracılığıyla bir kilitle alabilirsiniz.

Konularla çalışırken, zamanlanmış iletiler zamanlanan sıraya alınana kadar konu başlığında kaldığından, abonelikte zamanlanmış iletilere göz atamazsınız. Geçici bir çözüm olarak, bu tür iletilere göz atmak için konu adını geçen bir ServiceBusReceiver oluşturabilirsiniz. Konu adı kullanılırken alıcıyla başka hiçbir işlem çalışmaz.

Tüm oturumlarda oturum iletilerine göz atma

Tüm oturumlara göz atmak için normal bir ServiceBusReceiver kullanabilirsiniz. Belirli bir oturuma göz atmak için ServiceBusSessionReceiver kullanabilirsiniz, ancak bir oturum kilidi almanız gerekir.

İleti gövdesine erişilirken NotSupportedException oluşturuldu

Bu sorun en sık birlikte çalışma senaryolarında, farklı bir AMQP ileti gövdesi biçimi kullanan farklı bir kitaplıktan gönderilen bir ileti alınırken oluşur. Bu tür iletilerle etkileşimdeyseniz ileti gövdesine nasıl erişeceğinizi öğrenmek için AMQP ileti gövdesi örneğine bakın.

İşlemci sorunlarını giderme

Otomatik kilitleme yenilemesi çalışmıyor

Otomatik kilitleme yenileme, bir ileti veya oturum için kilidin ne zaman yenileneceğini belirlemek için sistem süresine bağlıdır. Sistem süreniz doğru değilse, örneğin, saatiniz yavaşsa, kilit kaybolmadan önce kilit yenileme gerçekleşmeyebilir. Otomatik kilitleme yenilemesi çalışmıyorsa sistem sürenizin doğru olduğundan emin olun.

yüksek eşzamanlılık kullanılırken işlemci askıda kalıyor veya gecikme sorunları yaşıyor gibi görünüyor

Bu davranış genellikle, özellikle oturum işlemcisi kullanılırken ve makinedeki çekirdek sayısına göre MaxConcurrentSessions için çok yüksek bir değer kullanılırken iş parçacığı yetersizliğinden kaynaklanır. Denetlenecek ilk şey, olay işleyicilerinizin hiçbirinde eşitlemeyi zaman uyumsuz olarak gerçekleştirmediğinizden emin olmaktır. Zaman uyumsuz eşitleme, kilitlenmelere ve iş parçacığı açlığına neden olmak için kolay bir yoldur. Eşitlemeyi zaman uyumsuz olarak yapmasanız bile, işleyicilerinizdeki herhangi bir saf eşitleme kodu iş parçacığının aç kalmasına katkıda bulunabilir. Örneğin, saf zaman uyumsuz kodunuz olduğundan sorunun bu olmadığını belirlediyseniz [TryTimeout][TryTimeout] değerini artırmayı deneyebilirsiniz. Özellikle oturum işlemcisi kullanılırken oluşan bağlam anahtarlarının ve zaman aşımlarının sayısını azaltarak iş parçacığı havuzu üzerindeki baskıyı azaltır. [TryTimeout][TryTimeout] için varsayılan değer 60 saniyedir, ancak 1 saate kadar ayarlanabilir. Başlangıç noktası olarak 5 dakikaya ayarlanmış test yapmanızı ve oradan yinelemenizi öneririz TryTimeout . Bu önerilerin hiçbiri işe yaramazsa, ölçeği birden çok ana bilgisayar için genişletmeniz ve uygulamanızdaki eşzamanlılığı azaltmanız, ancak istenen genel eşzamanlılığı elde etmek için uygulamayı birden çok konakta çalıştırmanız yeterlidir.

Daha fazla okuma:

• İş parçacığı havuzu açlığında hata ayıklama
• PerfView ile .NET Core iş parçacığı havuzu aç kalma durumunu tanılama (Hizmetim neden tüm çekirdekleri doymuyor veya duraklıyor gibi görünüyor)
• .NET Core Uygulamalarında iş parçacığı havuzu tükenme sorunlarını tanılama (video)

Oturum işlemcinin oturumları değiştirmesi çok uzun sürüyor

Bu, işlemciye bir oturumdan ileti almak için ne kadar bekleyeceğini söyleyen [SessionIdleTimeout][SessionIdleTimeout] kullanılarak, vazgeçmeden ve başka bir oturuma geçmeden önce yapılandırılabilir. Her oturumun yalnızca birkaç iletiyi olduğu seyrek doldurulmuş çok sayıda oturum varsa kullanışlıdır. Her oturumun içinde karmaşık birçok ileti olmasını bekliyorsanız, oturumun gereksiz şekilde kapatılmasına neden olduğundan, çok düşük bir değerin ayarlanması üretkenliğe karşı olabilir.

İşlemci hemen durur

Bu durum genellikle tanıtım veya test senaryoları için gözlenir. StartProcessingAsync işlemci başlatıldıktan hemen sonra döndürür. Bu yöntemi çağırmak işlemci çalışırken uygulamanızı engellemez ve hayatta tutmaz, bu nedenle bunu yapmak için başka bir mekanizmaya ihtiyacınız vardır. Tanıtımlar veya test için, işlemciyi başlattıktan sonra yalnızca bir Console.ReadKey() çağrı eklemek yeterlidir. Üretim senaryolarında, işlemciyi başlatmak ve yok etmek için kullanılabilecek uygun uygulama yaşam döngüsü kancaları sağlamak için [BackgroundService][BackgroundService] gibi bir çerçeve tümleştirmesi kullanmak isteyebilirsiniz.

İşlemlerle ilgili sorunları giderme

Service Bus'taki işlemler hakkında genel bilgi için bkz. [Service Bus işlemi işlemeye genel bakış][İşlemler].

Desteklenen işlemler

İşlemler kullanılırken tüm işlemler desteklenmez. Desteklenen işlemlerin listesini görmek için bkz. [İşlem kapsamındaki işlemler][TransactionOperations].

Timeout

Bir işlem [zaman aralığı][TransactionTimeout] sonrasında zaman aşımına uğradı, bu nedenle bir işlem kapsamında gerçekleşen işlemenin bu zaman aşımına uyması önemlidir.

Bir işlemdeki işlemler yeniden denenmiyor

Bu tasarım gereğidir. Aşağıdaki senaryoyu göz önünde bulundurun: bir işlem içinde bir iletiyi tamamlamaya çalışıyorsunuz, ancak örneğin bir ile oluşan geçici bir ReasonServiceCommunicationProblemhata ServiceBusException var. İsteğin gerçekten hizmete yaptığını varsayalım. İstemci yeniden denerse, hizmet iki tam istek görür. İşlem tamamlanana kadar ilk tamamlama işlemi tamamlanmaz. İkinci tamamlanma, ilk tamamlanma tamamlanmadan önce bile değerlendirilemez. İstemcideki işlem, tamamlanma işleminin tamamlanmasını bekliyor. Bu, hizmetin istemcinin işlemi tamamlamasını beklediği, ancak istemcinin ikinci tam işlemi onaylamasını beklediği bir kilitlenme oluşturur. İşlem sonunda 2 dakika sonra zaman aşımına uğradı, ancak bu kötü bir kullanıcı deneyimi. Bu nedenle, bir işlem içindeki işlemleri yeniden denemeyiz.

Varlıklar arasında işlemler çalışmıyor

Birden çok varlık içeren işlemleri gerçekleştirmek için özelliğini olarak trueayarlamanız ServiceBusClientOptions.EnableCrossEntityTransactions gerekir. Ayrıntılar için [Varlıklar arasında işlemler][CrossEntityTransactions] örneğine bakın.

Kotalar

Service Bus kotaları hakkında bilgi bulunabilir [burada][ServiceBusQuotas].

Bağlan üretkenlik, sertifika veya zaman aşımı sorunları

Aşağıdaki adımlar *.servicebus.windows.net altındaki tüm hizmetler için bağlantı/sertifika/zaman aşımı sorunlarını gidermenize yardımcı olur.

• veya wgethttps://<yournamespace>.servicebus.windows.net/ konumuna gidin. Java SDK'sı kullanılırken yaygın olarak karşılaşılan IP filtreleme, sanal ağ veya sertifika zinciri sorunlarınız olup olmadığını denetlemenize yardımcı olur.

  Başarılı ileti örneği:

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

  Hata hata iletisi örneği:

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

• Güvenlik duvarında herhangi bir bağlantı noktasının engellenip engellenmediğini denetlemek için aşağıdaki komutu çalıştırın. Kullanılan bağlantı noktaları: 443 (HTTPS), 5671 ve 5672 (AMQP) ve 9354 (Net Messaging/SBMP). Kullandığınız kitaplığa bağlı olarak, diğer bağlantı noktaları da kullanılır. 5671 bağlantı noktasının engellenip engellenmediğini denetleye örnek komut aşağıda verilmiştir. C

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

  Linux'ta:

  telnet <yournamespacename>.servicebus.windows.net 5671
  

• Aralıklı bağlantı sorunları olduğunda, bırakılan paket olup olmadığını denetlemek için aşağıdaki komutu çalıştırın. Bu komut, hizmetle her 1 saniyede bir 25 farklı TCP bağlantısı kurmaya çalışır. Ardından bunların kaç tanesinin başarılı/başarısız olduğunu denetleyebilir ve TCP bağlantısı gecikme süresini görebilirsiniz. Aracı buradan indirebilirsinizpsping.

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

  , pinggibi tncbaşka araçlar kullanıyorsanız eşdeğer komutları kullanabilirsiniz.

• Önceki adımlar wireshark gibi araçları kullanarak yardımcı olmazsa ve çözümlemiyorsa bir ağ izlemesi alın. Gerekirse Microsoft Desteği ile iletişime geçin.

• Bağlantılarınız için izin verilenler listesine eklenecek doğru IP adreslerini bulmak için bkz . İzin verilenler listesine hangi IP adreslerini eklemem gerekiyor?

30 Eylül 2026'da Azure Service Bus için SBMP protokolü desteğini devre dışı bırakacağız, böylece 30 Eylül 2026'da bu protokolü artık kullanamayacaksınız. Bu tarihten önce kritik güvenlik güncelleştirmeleri ve gelişmiş özellikler sunan AMQP protokolunu kullanarak en son Azure Service Bus SDK kitaplıklarına geçiş yapın.

Daha fazla bilgi için bkz . destek kullanımdan kaldırma duyurusu.

Hizmet yükseltmelerinde/yeniden başlatmalarında oluşabilecek sorunlar

Belirtiler

• İstekler kısa süre kısıtlanabilir.
• Gelen iletilerde/isteklerde bir düşüş olabilir.
• Günlük dosyası hata iletileri içerebilir.
• Uygulamaların hizmetle bağlantısı birkaç saniyeliğine kesilebilir.

Neden

Arka uç hizmeti yükseltmeleri ve yeniden başlatmaları uygulamalarınızda bu sorunlara neden olabilir.

Çözüm

Uygulama kodu SDK kullanıyorsa, yeniden deneme ilkesi zaten yerleşik ve etkindir. Uygulama/iş akışı üzerinde önemli bir etki olmadan yeniden bağlanır.

Yetkisiz erişim: Talep gönderme gereklidir

Belirtiler

Gönderme izinlerine sahip kullanıcı tarafından atanan yönetilen kimliği kullanarak şirket içi bir bilgisayarda Visual Studio'dan Service Bus konusuna erişmeye çalışırken bu hatayı görebilirsiniz.

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

Neden

Kimliğin Service Bus konusuna erişme izinleri yok.

Çözüm

Bu hatayı çözmek için Microsoft.Azure.Services.AppAuthentication kitaplığını yükleyin. Daha fazla bilgi için bkz . Yerel geliştirme kimlik doğrulaması.

Rollere izin atamayı öğrenmek için bkz . Azure Service Bus kaynaklarına erişmek için Microsoft Entra Id ile yönetilen kimliğin kimliğini doğrulama.

Service Bus Özel Durumu: Belirteci yerleştirme başarısız oldu

Belirtiler

Aşağıdaki hata iletisini alırsınız:

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

30 Eylül 2026'da Azure SDK yönergelerine uymayan WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus ve com.microsoft.azure.servicebus Azure Service Bus SDK kitaplıklarını kullanımdan kaldıracağız. Ayrıca SBMP protokolünün desteğini de sonlandıracağız, bu nedenle 30 Eylül 2026'da bu protokolü artık kullanamayacaksınız. Bu tarihten önce kritik güvenlik güncelleştirmeleri ve geliştirilmiş özellikler sunan en son Azure SDK kitaplıklarına geçiş yapın.

Eski kitaplıklar 30 Eylül 2026'dan sonra da kullanılabilir olsa da artık Microsoft'tan resmi destek ve güncelleştirmeler almayacaktır. Daha fazla bilgi için bkz . destek kullanımdan kaldırma duyurusu.

Neden

Service Bus ad alanına tek bir bağlantıda eş zamanlı bağlantılar için kimlik doğrulama belirteci sayısı sınırı aştı: 1000.

Çözüm

Aşağıdaki adımlardan birini yapın:

• Tek bir bağlantıdaki eş zamanlı bağlantı sayısını azaltın veya yeni bir bağlantı kullanın
• Bu duruma girmemenizi sağlayan Azure Service Bus için SDK'ları kullanın (önerilir)

Veri düzlemi SDK'sı kullanılırken kaynak kilitleri çalışmıyor

Belirtiler

Service Bus ad alanında silme kilidi yapılandırdıysanız ancak Service Bus Gezgini'ni kullanarak ad alanı içindeki kaynakları (kuyruklar, konular vb.) silebilirsiniz.

Neden

Kaynak kilidi Azure Resource Manager'da (denetim düzlemi) korunur ve veri düzlemi SDK çağrısının kaynağı doğrudan ad alanından silmesini engellemez. Tek başına Service Bus Gezgini veri düzlemi SDK'sını kullandığından silme işlemi gerçekleştirilir.

Çözüm

Kaynak kilidinin kaynakların yanlışlıkla silinmesini önlemek için varlıkları silmek için Azure portal, PowerShell, CLI veya Resource Manager şablonu aracılığıyla Azure Resource Manager tabanlı API'yi kullanmanızı öneririz.

Varlık artık kullanılamıyor

Belirtiler

Varlığın artık kullanılamadığını belirten bir hata görürsünüz.

Neden

Kaynak silinmiş olabilir. Varlığın neden silindiğini belirlemek için bu adımları izleyin.

• Silme için Azure Resource Manager isteği olup olmadığını görmek için etkinlik günlüğünü denetleyin.
• Silme için doğrudan API çağrısı olup olmadığını görmek için işlem günlüğünü denetleyin. İşlem günlüğü toplamayı öğrenmek için bkz . Toplama ve yönlendirme. Şema ve işlem günlüğü örneği için bkz . İşlem günlükleri
• İlgili silme autodeleteonidle işlemi olup olmadığını görmek için işlem günlüğünü denetleyin.

Sonraki adımlar

Aşağıdaki makalelere bakın:

• Azure Resource Manager özel durumları. Azure Resource Manager kullanarak Azure Service Bus ile etkileşim kurarken oluşturulan özel durumları listeler (şablonlar veya doğrudan çağrılar aracılığıyla).
• Mesajlaşma özel durumları. Azure Service Bus için .NET Framework tarafından oluşturulan özel durumların listesini sağlar.