Leitfaden zur Problembehandlung für Azure Service Bus

In diesem Artikel finden Sie Tipps zur Problembehandlung und Empfehlungen für einige Probleme, die bei der Verwendung von Azure Service Bus auftreten können.

Verbindungsprobleme

Timeout beim Herstellen einer Verbindung mit dem Dienst

Je nach Hostumgebung und Netzwerk kann ein Verbindungsproblem Anwendungen entweder als TimeoutException, OperationCanceledException oder eine ServiceBusException mit Reason von ServiceTimeout und am häufigsten auftreten, wenn der Client keinen Netzwerkpfad zum Dienst finden kann.

Problembehandlung:

• Stellen Sie sicher, dass die Verbindungszeichenfolge oder der vollqualifizierte Domänenname, den Sie beim Erstellen des Clients angegeben haben, korrekt ist. Informationen zum Abrufen einer Verbindungszeichenfolge finden Sie unter Abrufen einer Service Bus-Verbindungszeichenfolge.
• Überprüfen Sie die Firewall- und Portberechtigungen in Ihrer Hostingumgebung. Vergewissern Sie sich, dass die AMQP-Ports 5671 und 5672 (Advanced Message Queuing Protocol) geöffnet sind und dass der Endpunkt über die Firewall zugelassen wird.
• Versuchen Sie, die Web Socket-Transportoption zu verwenden, die eine Verbindung mit Port 443 herstellt. Ausführliche Informationen finden Sie unter Konfigurieren des Transports.
• Überprüfen Sie, ob Ihr Netzwerk bestimmte IP-Adressen blockiert. Ausführliche Informationen finden Sie unter Welche IP-Adressen muss ich zulassen?
• Überprüfen Sie ggf. die Proxykonfiguration. Ausführliche Informationen finden Sie unter Konfigurieren des Transports
• Weitere Informationen zur Problembehandlung bei der Netzwerkkonnektivität finden Sie unter: [Konnektivitäts-, Zertifikat- oder Timeoutprobleme][#connectivity-certificate-or-timeout-issues].

SSL-Handshakefehler (Secure Socket Layer)

Dieser Fehler kann auftreten, wenn ein abfangender Proxy verwendet wird. Um das zu überprüfen, empfehlen wir, die Anwendung in der Hostumgebung mit deaktivierten Proxys zu testen.

Fehler bei der Socketauslastung

Anwendungen sollten die Service Bus-Typen lieber als Singletons behandeln, also eine einzelne Instanz über die Lebensdauer der Anwendung erstellen und verwenden. Jeder neue ServiceBusClient hat Ergebnisse in einer neuen AMQP-Verbindung erstellt, wozu ein Socket verwendet wird. Der ServiceBusClient-Typ verwaltet die Verbindung für alle Typen, die aus dieser Instanz erstellt wurden. Jeder ServiceBusReceiver, ServiceBusSessionReceiver, ServiceBusSender und ServiceBusProcessor verwaltet einen eigenen AMQP-Link für die zugeordnete Service Bus-Entität. Wenn Sie ServiceBusSessionProcessor verwenden, werden abhängig von der Anzahl der gleichzeitig verarbeiteten Sitzungen mehrere AMQP-Verknüpfungen eingerichtet.

Die Clients können im Leerlauf sicher zwischengespeichert werden. Sie stellen eine effiziente Verwaltung der Netzwerk-, CPU- und Speichernutzung sicher, wodurch ihre Auswirkungen während Inaktivitätszeiträumen minimiert werden. Es ist auch wichtig, entweder CloseAsync oder DisposeAsync aufzurufen, wenn ein Client nicht mehr benötigt wird, um sicherzustellen, dass Netzwerkressourcen ordnungsgemäß bereinigt werden.

Das Hinzufügen von Komponenten zur Verbindungszeichenfolge funktioniert nicht.

Die aktuelle Generation der Service Bus-Clientbibliothek unterstützt Verbindungszeichenfolgen nur in dem Formular, das vom Azure-Portal veröffentlicht wird. Die Verbindungszeichenfolgen sollen nur grundlegende Informationen zu Standorten und freigegebenen Schlüsseln bereitstellen. Das Konfigurieren des Verhaltens der Clients erfolgt über deren jeweilige Optionen.

In früheren Generationen der Service Bus-Clients konnten einige Verhaltensweisen konfiguriert werden, indem Schlüssel-/Wertkomponenten zu einer Verbindungszeichenfolge hinzugefügt werden. Diese Komponenten werden nicht mehr erkannt und haben keine Auswirkungen auf das Clientverhalten.

„TransportType=AmqpWebSockets“-Alternative

Informationen zum Konfigurieren von Websockets als Transporttyp finden Sie unter Konfigurieren des Transports.

„Authentication=Managed Identity“-Alternative

Informationen zur Authentifizierung mit verwalteter Identität finden Sie unter Identität und Shared Access-Anmeldeinformationen. Weitere Informationen zur Azure.Identity-Bibliothek finden Sie unter Authentifizierung und Azure SDK.

Protokollierung und Diagnose

Die Service Bus-Clientbibliothek wird vollständig für die Protokollierung von Informationen auf verschiedenen Detailebenen mithilfe von .NET EventSource zum Ausgeben von Informationen instrumentiert. Die Protokollierung wird für jeden Vorgang ausgeführt und folgt dem Muster, den Startpunkt des Vorgangs, dessen Abschluss und alle aufgetretenen Ausnahmen zu markieren. Zusätzliche Informationen, die Einblicke bieten könnten, werden auch im Kontext des zugeordneten Vorgangs protokolliert.

Aktivieren der Protokollierung

Die Service Bus-Clientprotokolle sind für alle EventListener verfügbar, indem man sich für die Quellen entscheidet, die mit Azure-Messaging-ServiceBus beginnen, oder durch die Auswahl aller Quellen, die über das Merkmal AzureEventSourceverfügen. Um das Erfassen von Protokollen aus den Azure-Clientbibliotheken zu vereinfachen, bietet die von Service Bus verwendete Azure.Core-Bibliothek eine AzureEventSourceListener.

Weitere Informationen finden Sie unter Protokollierung mit dem Azure SDK für .NET.

Verteilte Ablaufverfolgung

Die Service Bus-Clientbibliothek unterstützt die verteilte Ablaufverfolgung durch Integration in das Application Insights SDK. Sie verfügt außerdem über experimentelle Unterstützung für die OpenTelemetry-Spezifikation über den .NET ActivitySource-Typ, der in .NET 5 eingeführt wurde. Informationen zum Aktivieren der ActivitySource-Unterstützung für die Verwendung mit OpenTelemetry finden Sie unter ActivitySource-Unterstützung.

Um die GA DiagnosticActivity-Unterstützung zu verwenden, können Sie es in das Application Insights SDK integrieren. Weitere Details finden Sie in ApplicationInsights mit Azure Monitor.

Die Bibliothek erstellt die folgenden span-Elemente:

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

Die meisten span-Elemente sind selbsterklärend und werden während des Vorgangs gestartet und beendet, der dessen Namen trägt. Das span-Element, das die anderen miteinander verbindet, ist Message. Die Art und Weise, wie die Nachricht nachverfolgt wird, erfolgt über die Diagnostic-Id in der Eigenschaft ServiceBusMessage.ApplicationProperties durch die Bibliothek während des Sende- und Zeitplanvorgangs. In Application Insights werden Message-span-Elemente als Verknüpfung mit den verschiedenen anderen span-Elementen angezeigt, die für die Interaktion mit der Nachricht verwendet wurden, z. B. das ServiceBusSender.Send-span-Element, das ServiceBusReceiver.Receive-span-Element und das ServiceBusReceiver.Complete-span-Element, die alle aus dem Message-span-Element verknüpft werden. Hier ist ein Beispiel dafür, wie dies in Application Insights aussieht:

Im obigen Screenshot sehen Sie die End-to-End-Transaktion, die im Portal in Application Insights angezeigt werden kann. In diesem Szenario sendet die Anwendung Nachrichten und verwendet den ServiceBusSessionProcessor, um sie zu verarbeiten. Die Message-Aktivität ist mit ServiceBusSender.Send, ServiceBusReceiver.Receive, ServiceBusSessionProcessor.ProcessSessionMessage und ServiceBusReceiver.Complete verknüpft.

Hinweis

Weitere Informationen finden Sie unter Verteilte Ablaufverfolgung und Korrelation über Service Bus-Messaging.

Behandeln von Absenderproblemen

Ein Batch mit mehreren Partitionsschlüsseln kann nicht gesendet werden.

Wenn eine App einen Batch an eine partitionsfähige Entität sendet, müssen alle Nachrichten, die in einem einzelnen Sendevorgang enthalten sind, denselben PartitionKeyaufweisen. Wenn Ihre Entität sitzungsfähig ist, gilt die gleiche Anforderung für die SessionId-Eigenschaft. Um Nachrichten mit unterschiedlichen PartitionKey- oder SessionId-Werten zu senden, gruppieren Sie die Nachrichten in separaten ServiceBusMessageBatch-Instanzen, oder fügen Sie sie in separate Aufrufe der SendMessagesAsync-Überladung ein, die eine Reihe von ServiceBusMessage-Instanzen verwendet.

Ein Batch kann nicht gesendet werden.

Ein Nachrichtenbatch ist entweder ServiceBusMessageBatch und enthält zwei oder mehr Nachrichten oder einen Aufruf von SendMessagesAsync, in dem zwei oder mehr Nachrichten übergeben werden. Der Dienst lässt nicht zu, dass ein Nachrichtenbatch 1 MB überschreitet. Dieses Verhalten gilt unabhängig davon, ob das Premium-Feature Unterstützung großer Nachrichten aktiviert ist. Wenn Sie beabsichtigen, eine Nachricht mit mehr als 1 MB zu senden, muss sie einzeln gesendet werden und darf nicht mit anderen Nachrichten gruppiert werden. Leider unterstützt der ServiceBusMessageBatch-Typ derzeit keine Überprüfung, dass ein Batch keine Nachrichten enthält, die größer als 1 MB sind, da die Größe durch den Dienst eingeschränkt wird und sich ändern kann. Wenn Sie daher beabsichtigen, das Premium-Feature zur Unterstützung großer Nachrichten zu verwenden, müssen Sie sicherstellen, dass Sie Nachrichten über 1 MB einzeln senden.

Behandeln von Empfängerproblemen

Die Anzahl der zurückgegebenen Nachrichten stimmt nicht mit der Anzahl überein, die im Batch-Empfang angefordert wurde.

Wenn Sie versuchen, einen Batch-Empfangsvorgang auszuführen, d. h. ein maxMessages-Wert von zwei oder mehr an die ReceiveMessagesAsync-Methode übergeben wird, ist es nicht garantiert, die Anzahl der angeforderten Nachrichten zu empfangen, auch wenn die Warteschlange oder das Abonnement zu diesem Zeitpunkt über so viele Nachrichten verfügt, und auch dann nicht, wenn die gesamte konfigurierte maxWaitTime noch nicht abgelaufen ist. Um den Durchsatz zu maximieren und den Sperrablauf zu vermeiden, wartet der Empfänger, sobald die erste Nachricht über das Netzwerk eingeht, weitere 20 Millisekunden auf weitere Nachrichten, bevor die Nachrichten zur Verarbeitung verteilt werden. maxWaitTime steuert, wie lange der Empfänger auf den Empfang der ersten Nachricht wartet – auf nachfolgende Nachrichten wird 20 Millisekunden gewartet. Daher sollte Ihre Anwendung nicht davon ausgehen, dass alle verfügbaren Nachrichten in einem Aufruf empfangen werden.

Die Nachrichten- oder Sitzungssperre geht vor der Ablaufzeit der Sperre.

Der Service Bus-Dienst verwendet das AMQP-Protokoll, das zustandsbehaftet ist. Es liegt in der Natur des Protokolls, dass die Nachricht bei Wiederherstellung der Verbindung nicht abgerechnet werden kann, wenn die Verbindung zwischen dem Client und dem Dienst nach dem Empfang einer Nachricht, aber vor der Abrechnung der Nachricht getrennt wird. Verbindungen können aufgrund eines kurzfristigen vorübergehenden Netzwerkfehlers, eines Netzwerkausfalls oder aufgrund des vom Dienst erzwungenen Leerlauftimeouts von 10 Minuten getrennt werden. Die Wiederherstellung der Verbindung erfolgt automatisch bei jedem Vorgang, für den die Verbindung benötigt wird, d. h. beim Abrechnen oder Empfangen von Nachrichten. In diesem Fall erhalten Sie eine ServiceBusException mit Reason von MessageLockLost oder SessionLockLost sogar dann, wenn die Ablaufzeit der Sperre noch nicht vergangen ist.

So durchsuchen Sie geplante oder verzögerte Nachrichten

Geplante und verzögerte Nachrichten werden beim Einsehen von Nachrichten eingeschlossen. Sie können durch die ServiceBusReceivedMessage.State-Eigenschaft identifiziert werden. Sobald Sie die SequenceNumber einer verzögerten Nachricht haben, können Sie sie mit einer Sperre über die ReceiveDeferredMessagesAsync-Methode empfangen.

Wenn Sie mit Themen arbeiten, können Sie keine geplanten Nachrichten im Abonnement anzeigen, da die Nachrichten bis zur geplanten Zeit in der Warteschlange im Thema verbleiben. Als Problemumgehung können Sie einen ServiceBusReceiver erstellen, der den Themennamen übergibt, um solche Nachrichten einsehen zu können. Bei Verwendung eines Themennamens funktionieren keine anderen Vorgänge mit dem Empfänger.

So durchsuchen Sie Sitzungsnachrichten in allen Sitzungen

Sie können einen regulären ServiceBusReceiver verwenden, um alle Sitzungen zu durchsuchen. Um eine bestimmte Sitzung anzuzeigen, können Sie den ServiceBusSessionReceiver verwenden, aber Sie müssen eine Sitzungssperre abrufen.

NotSupportedException wird ausgelöst, wenn auf den Nachrichtentext zugegriffen wird.

Dieses Problem tritt am häufigsten in Interop-Szenarien auf, wenn eine von einer anderen Bibliothek gesendete Nachricht empfangen wird, die ein anderes AMQP-Nachrichtentextformat verwendet. Wenn Sie mit diesen Nachrichtentypen interagieren, können Sie im AMQP-Nachrichtentextbeispiel erfahren, wie Sie auf den Nachrichtentext zugreifen können.

Behandeln von Prozessorproblemen

Die Verlängerung der automatischen Sperre funktioniert nicht.

Die Verlängerung der automatischen Sperre hängt von der Systemzeit ab, um zu bestimmen, wann eine Sperre für eine Nachricht oder Sitzung verlängert werden soll. Wenn ihre Systemzeit beispielsweise nicht korrekt ist, etwa wenn Ihre Uhr nachgeht, dann erfolgt die Sperrverlängerung möglicherweise nicht, bevor die Sperre verloren geht. Stellen Sie sicher, dass die Systemzeit korrekt ist, wenn die Verlängerung der automatische Sperre nicht funktioniert.

Der Prozessor scheint zu hängen oder hat Latenzprobleme, wenn hohe Parallelität verwendet wird.

Dieses Verhalten wird häufig durch Threadmangel verursacht, insbesondere bei Verwendung des Sitzungsprozessors und eines sehr hohen Werts für MaxConcurrentSessions im Verhältnis zur Anzahl der Kerne auf dem Computer. Als Erstes sollten Sie sicherstellen, dass in keinem Ihrer Ereignishandler Sync-over-Async ausgeführt wird. Sync-over-Async ist eine einfache Möglichkeit, Deadlocks und Threadmangel zu verursachen. Selbst wenn kein Sync-over-Async ausgeführt wird, kann jeder reine Sync-Code in Ihren Handlern zum Threadmangel beitragen. Wenn Sie festgestellt haben, dass dies nicht das Problem ist, z. B. weil Sie über reinen asynchronen Code verfügen, können Sie versuchen, Ihr [TryTimeout][TryTimeout] zu erhöhen. Dadurch wird der Druck auf den Threadpool verringert, indem die Anzahl der Kontextwechsel und Timeouts reduziert wird, die insbesondere bei Verwendung des Sitzungsprozessors auftreten. Der Standardwert für [TryTimeout][TryTimeout] beträgt 60 Sekunden, kann jedoch auf bis zu 1 Stunde festgelegt werden. Es wird empfohlen, das Testen mit der Einstellung von TryTimeout auf 5 Minuten als Ausgangspunkt zu testen und ausgehend davon mehrere Einstellungen zu durchlaufen. Wenn keine dieser Vorschläge funktioniert, müssen Sie einfach auf mehrere Hosts skalieren, wodurch die Parallelität in Ihrer Anwendung reduziert wird, die Anwendung jedoch auf mehreren Hosts ausgeführt wird, um die gewünschte allgemeine Parallelität zu erzielen.

Weitere nützliche Informationen:

• Blockierung des Threadpools beheben
• Diagnostizieren der .NET Core-Threadpool-Blockierung mit PerfView (Warum mein Dienst nicht alle Kerne sättigt oder zu stagnieren scheint)
• Diagnostizieren von Threadpool-Erschöpfungsproblemen in .NET Core-Apps (Video)

Der Sitzungsprozessor benötigt zu lange, um zwischen Sitzungen zu wechseln.

Dies kann mithilfe von [SessionIdleTimeout][SessionIdleTimeout] konfiguriert werden. Dieser Wert instruiert den Prozessor, wie lange er warten soll, bis eine Nachricht von einer Sitzung empfangen wird, bevor er aufgeben und zu einer anderen wechseln soll. Dies ist nützlich, wenn Sie viele wenig ausgelastete Sitzungen haben und jede Sitzung nur wenige Nachrichten enthält. Wenn Sie damit rechnen, dass bei jeder Sitzung viele Nachrichten eingehen, kann eine zu niedrige Einstellung kontraproduktiv sein, da dies zu einem unnötigen Schließen der Sitzung führt.

Der Prozessor stoppt sofort.

Dies wird häufig in Demo- oder Testszenarien beobachtet. StartProcessingAsync gibt unmittelbar nach dem Start des Prozessors zurück. Wenn Sie diese Methode aufrufen, wird Ihre Anwendung nicht blockiert und am Leben gehalten, während der Prozessor läuft. Sie benötigen dafür also einen anderen Mechanismus. Für Demos oder Tests reicht es aus, nur einen Console.ReadKey()-Aufruf hinzuzufügen, nachdem Sie den Prozessor gestartet haben. Für Produktionsszenarien sollten Sie wahrscheinlich eine Art Frameworkintegration wie [BackgroundService][BackgroundService] verwenden, um praktische Anwendungslebenszyklus-Hooks bereitzustellen, die zum Starten und Freigeben des Prozessors verwendet werden können.

Problembehandlung bei Transaktionen

Allgemeine Informationen zu Transaktionen in Service Bus finden Sie unter [Übersicht über die Service Bus-Transaktionsverarbeitung][Transaktionen].

Unterstützte Vorgänge

Bei der Verwendung von Transaktionen werden nicht alle Vorgänge unterstützt. Informationen zur Liste der unterstützten Transaktionen finden Sie unter [Vorgänge innerhalb eines Transaktionsbereichs][TransactionOperations].

Timeout

Eine Transaktion läuft nach einem [Zeitraum][TransactionTimeout] aus. Es ist also wichtig, dass die Verarbeitung innerhalb eines Transaktionsbereichs diesen Zeitraum einhält.

Die Vorgänge in einer Transaktion werden nicht wiederholt.

Es handelt sich hierbei um ein beabsichtigtes Verhalten. Betrachten Sie das folgende Szenario: Sie versuchen, eine Nachricht in einer Transaktion abzuschließen, aber es gibt einen vorübergehenden Fehler, der z. B. ServiceBusException mit einer Reason von ServiceCommunicationProblem auftritt. Angenommen, die Anfrage wird tatsächlich an den Dienst weitergeleitet. Wenn der Client es erneut versuchen würde, würde der Dienst zwei vollständige Anfragen sehen. Die erste vollständige Bearbeitung wird erst abgeschlossen, wenn die Transaktion bestätigt wurde. Die zweite vollständige Bearbeitung kann nicht einmal ausgewertet werden, bevor die erste vollständige Bearbeitung abgeschlossen ist. Die Transaktion auf dem Client wartet auf den Abschluss der Bearbeitung. Dadurch entsteht ein Deadlock, bei dem der Dienst wartet, bis der Client die Transaktion abgeschlossen hat, aber der Client wartet darauf, dass der Dienst den zweiten Abschlussvorgang bestätigt. Die Transaktion wird schließlich nach 2 Minuten abgebrochen, aber das ist eine schlechte Benutzererfahrung. Aus diesem Grund wiederholen wir keine Vorgänge innerhalb einer Transaktion.

Entitätsübergreifende Transaktionen funktionieren nicht.

Um Transaktionen auszuführen, die mehrere Entitäten umfassen, müssen Sie die Eigenschaft ServiceBusClientOptions.EnableCrossEntityTransactionsauf true festlegen. Ausführliche Informationen finden Sie im Beispiel [Transaktionen zwischen Entitäten][CrossEntityTransactions]

Vorgaben

Informationen zu Service Bus-Kontingenten finden Sie [hier][ServiceBusQuotas].

Konnektivitäts-, Zertifikat- oder Timeoutprobleme

Die folgenden Schritte unterstützen Sie bei der Problembehandlung von Konnektivitäts-/Zertifikat-/Timeoutproblemen für alle Dienste unter *.servicebus.windows.net.

• Navigieren Sie zu https://<yournamespace>.servicebus.windows.net/, oder verwenden Sie wget. Dies hilft bei der Überprüfung, ob Probleme mit der IP-Filterung oder dem virtuellen Netzwerk bzw. der Zertifikatkette vorliegen – diese treten bei Verwendung des Java SDK nicht selten auf.

  Beispiel für eine erfolgreiche Meldung:

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

  Beispiel für eine Fehlermeldung:

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

• Führen Sie den folgenden Befehl aus, um zu überprüfen, ob ein Port auf der Firewall blockiert ist. Die verwendeten Ports lauten 443 (HTTPS), 5671 und 5672 (AMQP) und 9354 (.NET-Messaging/SBMP). Abhängig von der verwendeten Bibliothek werden auch andere Ports verwendet. Hier ist der Beispielbefehl, mit dem überprüft wird, ob Port 5671 blockiert ist. C

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

  Unter Linux:

  telnet <yournamespacename>.servicebus.windows.net 5671
  

• Führen Sie bei zeitweiligen Konnektivitätsproblemen den folgenden Befehl aus, um zu überprüfen, ob gelöschte Pakete vorhanden sind. Dieser Befehl versucht, jede Sekunde 25 verschiedene TCP-Verbindungen mit dem Dienst herzustellen. Anschließend können Sie überprüfen, wie viele davon erfolgreich/fehlerhaft waren, und außerdem die Latenz der TCP-Verbindung anzeigen. Sie können das psping-Tool psping herunterladen.

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

  Sie können äquivalente Befehle verwenden, wenn Sie andere Tools wie tnc, ping usw. nutzen.

• Rufen Sie eine Netzwerkablaufverfolgung ab, wenn die vorherigen Schritte nicht hilfreich sind, und analysieren Sie diese mit Tools wie Wireshark. Wenden Sie sich bei Bedarf an den Microsoft-Support.

• Informationen zum Ermitteln der IP-Adressen, die der Positivliste für Ihre Verbindungen hinzugefügt werden müssen, finden Sie unter Welche IP-Adressen muss ich in die Zulassungsliste aufnehmen?.

Am 30. September 2026 wird die Unterstützung des SBMP-Protokolls für Azure Service Bus eingestellt, sodass Sie dieses Protokoll nach dem 30. September 2026 nicht mehr verwenden können. Migrieren Sie vor diesem Datum mithilfe des AMQP-Protokolls zu den neuesten Azure Service Bus SDK-Bibliotheken, die wichtige Sicherheitsupdates und verbesserte Funktionen bieten.

Weitere Informationen finden Sie in der Ankündigung der Supporteinstellung.

Mögliche Probleme im Zusammenhang mit Dienstupgrades/-neustarts

Problembeschreibung

• Anforderungen werden ggf. vorübergehend gedrosselt.
• Es gehen möglicherweise weniger Nachrichten/Anforderungen ein.
• Die Protokolldatei enthält unter Umständen Fehlermeldungen.
• Die Verbindung zwischen Anwendungen und dem Dienst wird möglicherweise für einige Sekunden getrennt.

Ursache

Upgrades und Neustarts des Back-End-Diensts können folgende Probleme in Ihren Anwendungen verursachen.

Lösung

Wenn der Anwendungscode das SDK verwendet, ist die Wiederholungsrichtlinie bereits integriert und aktiv. Die Verbindung stellt ohne nennenswerte Auswirkungen auf die Anwendung/den Workflow die Verbindung wieder her.

Nicht autorisierter Zugriff: Sendeansprüche sind erforderlich

Problembeschreibung

Dieser Fehler tritt möglicherweise auf, wenn Sie mit einer vom Benutzer zugewiesenen Identität mit Sendeberechtigungen versuchen, über Visual Studio auf ein Service Bus-Thema auf einem lokalen Computer zuzugreifen.

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

Ursache

Die Identität verfügt nicht über die erforderlichen Zugriffsberechtigungen für das Service Bus-Thema.

Lösung

Installieren Sie die Bibliothek Microsoft.Azure.Services.AppAuthentication, um das Problem zu lösen. Weitere Informationen finden Sie unter Authentifizierung für die lokale Entwicklung.

Informationen zum Zuweisen von Berechtigungen zu Rollen finden Sie unter Authentifizieren einer verwalteten Identität mit Microsoft Entra ID für den Zugriff auf Azure Service Bus-Ressourcen.

Service Bus-Ausnahme: Fehler beim Put-Token.

Symptome

Sie erhalten die folgende Fehlermeldung:

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

Am 30. September 2026 werden die Azure Service Bus SDK-Bibliotheken „WindowsAzure.ServiceBus“, „Microsoft.Azure.ServiceBus“ und „com.microsoft.azure.servicebus“ eingestellt, da sie nicht den Azure SDK-Richtlinien entsprechen. Außerdem wird die Unterstützung des SBMP-Protokolls beendet, sodass Sie dieses Protokoll nach dem 30. September 2026 nicht mehr verwenden können. Migrieren Sie vor diesem Datum zu den neuesten Azure SDK-Bibliotheken, die wichtige Sicherheitsupdates und verbesserte Funktionen bieten.

Obwohl die älteren Bibliotheken noch über den 30. September 2026 hinaus verwendet werden können, erhalten sie keinen offiziellen Support und keine Updates mehr von Microsoft. Weitere Informationen finden Sie in der Ankündigung der Supporteinstellung.

Ursache

Die Anzahl der Authentifizierungstoken für gleichzeitige Links in einer einzelnen Verbindung mit einem Service Bus-Namespace hat den Grenzwert überschritten: 1000.

Lösung

Führen Sie einen der folgenden Schritte aus:

• Reduzieren der Anzahl gleichzeitiger Links in einer einzelnen Verbindung oder Verwenden einer neuen Verbindung
• Verwenden von SDKs für Azure Service Bus, um sicherzustellen, dass diese Situation nicht eintritt (empfohlen)

Ressourcensperren funktionieren nicht, wenn das SDK für die Datenebene verwendet wird

Symptome

Sie haben eine Löschsperre für einen Service Bus-Namespace konfiguriert, aber Sie können Ressourcen im Namespace (Warteschlangen, Themen usw.) mithilfe des Service Bus Explorer löschen.

Ursache

Die Ressourcensperre wird in Azure Resource Manager (Steuerungsebene) beibehalten, und die verhindert nicht, dass der SDK-Aufruf der Datenebene die Ressource direkt aus dem Namespace löscht. Der eigenständige Service Bus Explorer verwendet das SDK auf Datenebene, sodass der Löschvorgang ausgeführt werden kann.

Lösung

Wir empfehlen, dass Sie die Azure Resource Manager-basierte API über das Azure-Portal, PowerShell, die CLI oder die Resource Manager-Vorlage verwenden, um Entitäten zu löschen, damit die Ressourcensperre verhindert, dass die Ressourcen versehentlich gelöscht werden.

Die Entität ist nicht mehr verfügbar.

Symptome

Sie erhalten die Fehlermeldung, dass die Entität nicht mehr verfügbar ist.

Ursache

Die Ressource wurde möglicherweise gelöscht. Führen Sie die folgenden Schritte aus, um zu ermitteln, warum die Entität gelöscht wurde.

• Überprüfen Sie das Aktivitätsprotokoll, um festzustellen, ob eine Azure Resource Manager-Löschanforderung vorliegt.
• Überprüfen Sie das Betriebsprotokoll, um festzustellen, ob ein direkter API-Aufruf zum Löschen vorhanden ist. Informationen zum Sammeln eines Betriebsprotokolls finden Sie unter Überwachen von Azure Service Bus. Das Schema und ein Beispiel für ein Betriebsprotokoll finden Sie unter Betriebsprotokolle.
• Überprüfen Sie im Betriebsprotokoll, ob es einen autodeleteonidle-bezogenen Löschvorgang gab.

Nächste Schritte

Weitere Informationen finden Sie in folgenden Artikeln:

• Azure Resource Manager-Ausnahmen: In diesem Artikel werden die Ausnahmen aufgelistet, die bei der Interaktion mit Azure Service Bus über Azure Resource Manager (über Vorlagen oder direkte Aufrufe) generiert werden.
• Messagingausnahmen: In diesem Artikel finden Sie eine Liste der Ausnahmen, die .NET Framework für Azure Service Bus generiert.