Przewodnik rozwiązywania problemów z usługą Azure Service Bus

Ten artykuł zawiera porady dotyczące rozwiązywania problemów i zalecenia dotyczące kilku problemów, które są widoczne podczas korzystania z usługi Azure Service Bus.

Problemy z połączeniem

Przekroczenie limitu czasu podczas nawiązywania połączenia z usługą

W zależności od środowiska hosta i sieci problem z łącznością może występować w aplikacjach jako TimeoutExceptionelement , OperationCanceledExceptionlub ServiceBusException z wartością ServiceTimeout Reason i najczęściej występuje, gdy klient nie może znaleźć ścieżki sieciowej do usługi.

W celu rozwiązania problemu:

• Sprawdź, czy parametry połączenia lub w pełni kwalifikowana nazwa domeny określona podczas tworzenia klienta jest poprawna. Aby uzyskać informacje na temat uzyskiwania parametry połączenia, zobacz Pobieranie parametry połączenia usługi Service Bus.
• Sprawdź uprawnienia zapory i portu w środowisku hostingu. Sprawdź, czy porty 5671 i 5672 protokołu Advanced Message Queuing Protocol (AMQP) są otwarte i czy punkt końcowy jest dozwolony przez zaporę.
• Spróbuj użyć opcji transportu web socket, która nawiązuje połączenie przy użyciu portu 443. Aby uzyskać szczegółowe informacje, zobacz konfigurowanie transportu.
• Sprawdź, czy sieć blokuje określone adresy IP. Aby uzyskać szczegółowe informacje, zobacz Jakie adresy IP muszę zezwolić?
• Jeśli ma to zastosowanie, sprawdź konfigurację serwera proxy. Aby uzyskać szczegółowe informacje, zobacz: Konfigurowanie transportu
• Aby uzyskać więcej informacji na temat rozwiązywania problemów z łącznością sieciową, zobacz: Łączność, certyfikat lub problemy z przekroczeniem limitu czasu.

Błędy uzgadniania protokołu SSL (Secure Socket Layer)

Ten błąd może wystąpić, gdy jest używany przechwytujący serwer proxy. Aby to sprawdzić, zalecamy przetestowanie aplikacji w środowisku hosta z wyłączonym serwerem proxy.

Błędy wyczerpania gniazd

Aplikacje powinny preferować traktowanie typów usługi Service Bus jako pojedynczychtonów, tworzenie i używanie pojedynczego wystąpienia przez okres istnienia aplikacji. Każda nowa usługa ServiceBusClient utworzyła wyniki w nowym połączeniu amQP, które używa gniazda. Typ ServiceBusClient zarządza połączeniem dla wszystkich typów utworzonych na podstawie tego wystąpienia. Każdy element ServiceBusReceiver, ServiceBusSessionReceiver, ServiceBusSender i ServiceBusProcessor zarządza własnym linkiem AMQP dla skojarzonej jednostki usługi Service Bus. W przypadku korzystania z klasy ServiceBusSessionProcessor wiele łączy AMQP jest ustanawianych w zależności od liczby sesji, które są przetwarzane współbieżnie.

Klienci są bezpieczni do buforowania w przypadku bezczynności; zapewniają wydajne zarządzanie siecią, procesorem CPU i użyciem pamięci, minimalizując ich wpływ w okresach braku aktywności. Ważne jest również, aby wywołać elementy CloseAsync lub DisposeAsync gdy klient nie jest już potrzebny, aby upewnić się, że zasoby sieciowe są prawidłowo czyszczone.

Dodawanie składników do parametry połączenia nie działa

Bieżąca generacja biblioteki klienta usługi Service Bus obsługuje parametry połączenia tylko w postaci opublikowanej przez witrynę Azure Portal. Parametry połączenia mają na celu podanie tylko podstawowych informacji o lokalizacji i kluczach udostępnionych. Konfigurowanie zachowania klientów odbywa się za pomocą jego opcji.

Poprzednie generacje klientów usługi Service Bus zezwalały na skonfigurowanie niektórych zachowań przez dodanie składników klucza/wartości do parametry połączenia. Te składniki nie są już rozpoznawane i nie mają wpływu na zachowanie klienta.

Alternatywa "TransportType=AmqpWebSockets"

Aby skonfigurować gniazda sieci Web jako typ transportu, zobacz Konfigurowanie transportu.

Alternatywna opcja "Authentication=Managed Identity"

Aby uwierzytelnić się przy użyciu tożsamości zarządzanej, zobacz: Identity and Shared Access Credentials (Poświadczenia tożsamości i dostępu współdzielonego). Aby uzyskać więcej informacji na temat Azure.Identity biblioteki, zobacz Authentication and the Azure SDK (Uwierzytelnianie i zestaw Azure SDK).

Rejestrowanie i diagnostyka

Biblioteka klienta usługi Service Bus jest w pełni instrumentowana do rejestrowania informacji na różnych poziomach szczegółów przy użyciu platformy .NET EventSource w celu emitowania informacji. Rejestrowanie jest wykonywane dla każdej operacji i jest zgodne ze wzorcem oznaczania punktu początkowego operacji, jego ukończenia i napotkanych wyjątków. Dodatkowe informacje, które mogą oferować szczegółowe informacje, są również rejestrowane w kontekście skojarzonej operacji.

Włącz rejestrowanie

Dzienniki klienta usługi Service Bus są dostępne dla wszystkich EventListener źródeł, decydując się na źródła rozpoczynające się Azure-Messaging-ServiceBus od lub wybierając wszystkie źródła, które mają cechę AzureEventSource. Aby ułatwić przechwytywanie dzienników z bibliotek klienckich platformy Azure, Azure.Core biblioteka używana przez usługę Service Bus oferuje element AzureEventSourceListener.

Aby uzyskać więcej informacji, zobacz Rejestrowanie przy użyciu zestawu Azure SDK dla platformy .NET.

Śledzenie rozproszone

Biblioteka klienta usługi Service Bus obsługuje śledzenie rozproszone za pośrednictwem integracji z zestawem SDK usługi Application Insights. Ma również eksperymentalną obsługę specyfikacji OpenTelemetry za pośrednictwem typu .NET ActivitySource wprowadzonego na platformie .NET 5. Aby włączyć ActivitySource obsługę funkcji OpenTelemetry, zobacz Obsługa elementu ActivitySource.

Aby korzystać z obsługi ga DiagnosticActivity, można zintegrować z zestawem SDK usługi Application Insights. Więcej szczegółów można znaleźć w temacie ApplicationInsights with Azure Monitor (Usługa ApplicationInsights w usłudze Azure Monitor).

Biblioteka tworzy następujące zakresy:

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

Większość rozpiętości jest objaśniająca i jest uruchamiana i zatrzymywana podczas operacji, która nosi jego nazwę. Rozpiętość, która łączy inne ze sobą, to Message. Sposób śledzenia komunikatu odbywa się za pośrednictwem Diagnostic-Id właściwości ServiceBusMessage.ApplicationProperties ustawionej przez bibliotekę podczas operacji wysyłania i planowania. W usłudze Application Insights Message zakresy są wyświetlane jako łączenie z różnymi innymi zakresami, które zostały użyte do interakcji z komunikatem, na przykład ServiceBusReceiver.Receive zakres, ServiceBusSender.Send zakres i ServiceBusReceiver.Complete zakres będą połączone z Message zakresu. Oto przykład tego, jak wygląda to w usłudze Application Insights:

Na powyższym zrzucie ekranu widać kompleksową transakcję, którą można wyświetlić w usłudze Application Insights w portalu. W tym scenariuszu aplikacja wysyła komunikaty i przetwarza je przy użyciu klasy ServiceBusSessionProcessor . Działanie Message jest połączone z elementami ServiceBusSender.Send, ServiceBusReceiver.Receive, ServiceBusSessionProcessor.ProcessSessionMessagei ServiceBusReceiver.Complete.

Uwaga

Aby uzyskać więcej informacji, zobacz Rozproszone śledzenie i korelacja za pośrednictwem komunikatów usługi Service Bus.

Rozwiązywanie problemów z nadawcą

Nie można wysłać partii z wieloma kluczami partycji

Gdy aplikacja wysyła partię do jednostki z włączoną obsługą partycji, wszystkie komunikaty zawarte w jednej operacji wysyłania muszą mieć taką samą wartość PartitionKey. Jeśli jednostka jest włączona w sesji, to samo wymaganie ma wartość true dla SessionId właściwości . Aby wysyłać komunikaty z różnymi PartitionKey lub SessionId wartościami, pogrupuj komunikaty w osobnych wystąpieniach lub dołącz je do oddzielnych ServiceBusMessageBatch wywołań przeciążenia SendMessagesAsync , które pobiera zestaw ServiceBusMessage wystąpień.

Usługa Batch nie może wysłać

Partia komunikatów zawiera ServiceBusMessageBatch co najmniej dwa komunikaty lub wywołanie metody SendMessagesAsync , w której przekazywane są co najmniej dwa komunikaty. Usługa nie zezwala partii komunikatów na przekroczenie 1 MB. To zachowanie ma wartość true, czy funkcja obsługi dużych komunikatów w warstwie Premium jest włączona. Jeśli zamierzasz wysłać komunikat większy niż 1 MB, musi być wysyłany indywidualnie, a nie grupowany z innymi komunikatami. Niestety typ ServiceBusMessageBatch nie obsługuje obecnie sprawdzania poprawności, że partia nie zawiera żadnych komunikatów większych niż 1 MB, ponieważ rozmiar jest ograniczony przez usługę i może ulec zmianie. Dlatego jeśli zamierzasz korzystać z funkcji obsługi dużych komunikatów w warstwie Premium, upewnij się, że komunikaty są wysyłane pojedynczo przez 1 MB.

Rozwiązywanie problemów z odbiornikiem

Liczba zwróconych komunikatów nie jest zgodna z liczbą żądaną w odbieraniu wsadowym

Podczas próby wykonania operacji odbierania wsadowego, czyli przekazania maxMessages wartości dwóch lub większych do metody ReceiveMessagesAsync , nie masz gwarancji, że otrzymasz liczbę żądanych komunikatów, nawet jeśli kolejka lub subskrypcja ma tyle komunikatów dostępnych w tym czasie, a nawet jeśli cała skonfigurowana maxWaitTime jeszcze nie upłynął. Aby zmaksymalizować przepływność i uniknąć wygaśnięcia blokady, po przejściu pierwszego komunikatu przez przewód odbiornik czeka dodatkowe 20 milisekund dla dodatkowych komunikatów przed wysłaniem komunikatów do przetworzenia. OkreślamaxWaitTime, jak długo odbiorca czeka na odebranie pierwszego komunikatu — kolejne komunikaty będą czekać na 20 milisekund. W związku z tym aplikacja nie powinna zakładać, że wszystkie dostępne komunikaty są odbierane w jednym wywołaniu.

Blokada komunikatu lub sesji zostanie utracona przed upływem czasu wygaśnięcia blokady

Usługa Service Bus używa protokołu AMQP, który jest stanowy. Ze względu na charakter protokołu, jeśli link łączący klienta i usługę jest odłączony po odebraniu komunikatu, ale zanim komunikat zostanie rozstrzygnięty, komunikat nie będzie mógł zostać rozstrzygnięty po ponownym połączeniu linku. Łącza mogą być odłączone z powodu krótkotrwałego przejściowego błędu sieci, awarii sieci lub z powodu wymuszonego 10-minutowego limitu czasu bezczynności usługi. Ponowne połączenie linku odbywa się automatycznie w ramach dowolnej operacji wymagającej linku, czyli rozliczania lub odbierania komunikatów. W takiej sytuacji otrzymasz ServiceBusException wartość z wartością MessageLockLost Reason lub SessionLockLost nawet wtedy, gdy nie upłynął jeszcze czas wygaśnięcia blokady.

Jak przeglądać zaplanowane lub odroczone komunikaty

Zaplanowane i odroczone komunikaty są uwzględniane podczas podglądu komunikatów. Można je zidentyfikować za pomocą właściwości ServiceBusReceivedMessage.State . Po utworzeniu ciągu SequenceNumber odroczonego komunikatu można go odebrać za pomocą blokady za pośrednictwem metody ReceiveDeferredMessagesAsync .

Podczas pracy z tematami nie można zajrzeć do zaplanowanych komunikatów w subskrypcji, ponieważ komunikaty pozostają w temacie do czasu zaplanowanego kolejki. Aby zajrzeć do takich komunikatów, możesz utworzyć element ServiceBusReceiver przekazujący nazwę tematu. Żadne inne operacje z odbiornikiem nie działają podczas używania nazwy tematu.

Jak przeglądać komunikaty sesji we wszystkich sesjach

Możesz użyć zwykłego elementu ServiceBusReceiver , aby zajrzeć do wszystkich sesji. Aby zapoznać się z określoną sesją, możesz użyć elementu ServiceBusSessionReceiver, ale musisz uzyskać blokadę sesji.

Wyjątek NotSupportedException zgłaszany podczas uzyskiwania dostępu do treści komunikatu

Ten problem występuje najczęściej w scenariuszach międzyoperacyjności podczas odbierania komunikatu wysyłanego z innej biblioteki, która używa innego formatu treści komunikatu AMQP. Jeśli korzystasz z tego typu komunikatów, zobacz przykład treści komunikatów protokołu AMQP, aby dowiedzieć się, jak uzyskać dostęp do treści komunikatu.

Rozwiązywanie problemów z procesorem

Odnawianie automatycznego zakleszczenia nie działa

Automatyczne odnawianie blokady opiera się na czasie systemowym, aby określić, kiedy należy odnowić blokadę komunikatu lub sesji. Jeśli czas systemowy nie jest dokładny, na przykład zegar działa wolno, odnawianie blokady może nie nastąpić przed utratą blokady. Upewnij się, że czas systemowy jest dokładny, jeśli odnawianie autolocka nie działa.

Procesor wydaje się zawieszać lub mieć problemy z opóźnieniami podczas korzystania z wysokiej współbieżności

To zachowanie jest często spowodowane głodem wątku, szczególnie w przypadku korzystania z procesora sesji i korzystania z bardzo wysokiej wartości dla maxConcurrentSessions względem liczby rdzeni na maszynie. Pierwszą rzeczą do sprawdzenia jest upewnienie się, że nie wykonujesz synchronizacji za pośrednictwem asynchronicznego w żadnym z programów obsługi zdarzeń. Synchronizacja za pośrednictwem asynchronicznego to prosty sposób na spowodowanie zakleszczenia i głodu wątku. Nawet jeśli nie przeprowadzasz synchronizacji za pośrednictwem asynchronicznego, każdy czysty kod synchronizacji w programach obsługi może przyczynić się do głodu wątku. Jeśli ustalono, że nie jest to problem, na przykład ponieważ masz czysty kod asynchroniczny, możesz spróbować zwiększyć limit tryTimeout. Zmniejsza to obciążenie puli wątków, zmniejszając liczbę przełączników kontekstu i limitów czasu występujących w przypadku korzystania z procesora sesji w szczególności. Wartość domyślna tryTimeout wynosi 60 sekund, ale można ją ustawić przez maksymalnie 1 godzinę. Zalecamy przetestowanie z zestawem TryTimeout do 5 minut jako punktu początkowego i iterowanie stamtąd. Jeśli żadna z tych sugestii nie działa, wystarczy przeprowadzić skalowanie w poziomie do wielu hostów, zmniejszając współbieżność w aplikacji, ale uruchamiając aplikację na wielu hostach, aby osiągnąć żądaną ogólną współbieżność.

Linki zewnętrzne:

• Debugowanie zagęszczenie puli wątków
• Diagnozowanie głodu puli wątków platformy .NET Core za pomocą narzędzia PerfView (Dlaczego moja usługa nie saturuje wszystkich rdzeni lub wydaje się zatrzymać)
• Diagnozowanie problemów z wyczerpaniem puli wątków w aplikacjach .NET Core (wideo)

Procesor sesji trwa zbyt długo, aby przełączyć sesje

Można to skonfigurować przy użyciu sessionIdleTimeout, który informuje procesor, jak długo czekać na odebranie komunikatu z sesji, przed rezygnacją i przejściem do innego. Jest to przydatne, jeśli masz wiele rozrzedzonych sesji, w których każda sesja ma tylko kilka komunikatów. Jeśli spodziewasz się, że każda sesja będzie zawierać wiele komunikatów, w których występuje błąd, ustawienie zbyt małej wartości może być sprzeczne z wydajnością, ponieważ powoduje niepotrzebne zamknięcie sesji.

Procesor zatrzymuje się natychmiast

Jest to często obserwowane w scenariuszach demonstracyjnych lub testowych. StartProcessingAsync zwraca natychmiast po uruchomieniu procesora. Wywołanie tej metody nie spowoduje zablokowania i utrzymania aktywności aplikacji podczas działania procesora, więc potrzebny jest inny mechanizm, aby to zrobić. W przypadku pokazów lub testów wystarczy dodać Console.ReadKey() wywołanie po uruchomieniu procesora. W przypadku scenariuszy produkcyjnych prawdopodobnie warto użyć jakiejś integracji struktury, takiej jak BackgroundService , aby zapewnić wygodne punkty zaczepienia cyklu życia aplikacji, których można użyć do uruchamiania i dysponowania procesora.

Rozwiązywanie problemów z transakcjami

Aby uzyskać ogólne informacje na temat transakcji w usłudze Service Bus, zobacz Omówienie przetwarzania transakcji usługi Service Bus.

Obsługiwane operacje

Nie wszystkie operacje są obsługiwane podczas korzystania z transakcji. Aby wyświetlić listę obsługiwanych transakcji, zobacz Operacje w zakresie transakcji.

Timeout

Limit czasu transakcji jest przekroczony po upływie określonego czasu, dlatego ważne jest, aby przetwarzanie, które występuje w zakresie transakcji, jest zgodne z tym limitem czasu.

Operacje w transakcji nie są ponawiane

Jest to celowe. Rozważmy następujący scenariusz — próbujesz ukończyć komunikat w ramach transakcji, ale występuje błąd przejściowy, na przykład ServiceBusException z wartością Reason ServiceCommunicationProblem. Załóżmy, że żądanie rzeczywiście wysyła je do usługi. Jeśli klient miał ponowić próbę, usługa będzie widzieć dwa kompletne żądania. Pierwsze ukończenie nie zostanie sfinalizowane, dopóki transakcja nie zostanie zatwierdzona. Drugie ukończenie nie jest w stanie nawet zostać ocenione przed zakończeniem pierwszego ukończenia. Transakcja na kliencie czeka na zakończenie. Powoduje to zakleszczenie, w którym usługa oczekuje na ukończenie transakcji przez klienta, ale klient czeka na usługę, aby potwierdzić drugą operację ukończenia. Transakcja ostatecznie upłynął po upływie 2 minut, ale jest to złe środowisko użytkownika. Z tego powodu nie ponawiamy prób w ramach transakcji.

Transakcje między jednostkami nie działają

Aby wykonać transakcje obejmujące wiele jednostek, należy ustawić ServiceBusClientOptions.EnableCrossEntityTransactions właściwość na true. Aby uzyskać szczegółowe informacje, zobacz przykład Transakcje między jednostkami .

Normy sprzedaży

Informacje o limitach przydziałów usługi Service Bus można znaleźć tutaj.

Problemy z łącznością, certyfikatem lub przekroczeniem limitu czasu

Poniższe kroki ułatwiają rozwiązywanie problemów z łącznością/certyfikatem/limitem czasu dla wszystkich usług w obszarze *.servicebus.windows.net.

• Przejdź do lub wget https://<yournamespace>.servicebus.windows.net/. Ułatwia to sprawdzenie, czy występują problemy z filtrowaniem adresów IP, siecią wirtualną lub łańcuchem certyfikatów, które są typowe podczas korzystania z zestawu Java SDK.

  Przykład pomyślnego komunikatu:

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

  Przykład komunikatu o błędzie niepowodzenia:

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

• Uruchom następujące polecenie, aby sprawdzić, czy jakikolwiek port jest zablokowany w zaporze. Używane porty to 443 (HTTPS), 5671 i 5672 (AMQP) i 9354 (Net Messaging/SBMP). W zależności od używanej biblioteki używane są również inne porty. Oto przykładowe polecenie, które sprawdza, czy port 5671 jest zablokowany. C

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

  W systemie Linux:

  telnet <yournamespacename>.servicebus.windows.net 5671
  

• Jeśli występują sporadyczne problemy z łącznością, uruchom następujące polecenie, aby sprawdzić, czy istnieją jakiekolwiek porzucone pakiety. To polecenie próbuje ustanowić 25 różnych połączeń TCP co 1 sekundę z usługą. Następnie możesz sprawdzić, ile z nich się, ile zakończyło niepowodzeniem, a także zobaczyć opóźnienie połączenia TCP. Narzędzie można pobrać psping z tego miejsca.

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

  Możesz użyć równoważnych poleceń, jeśli używasz innych narzędzi, takich jak tnc, pingi tak dalej.

• Uzyskaj ślad sieci, jeśli poprzednie kroki nie pomogą i przeanalizują je przy użyciu narzędzi, takich jak Wireshark. W razie potrzeby skontaktuj się z pomoc techniczna firmy Microsoft.

• Aby znaleźć odpowiednie adresy IP, które mają zostać dodane do listy dozwolonych dla połączeń, zobacz Jakie adresy IP muszę dodać do listy dozwolonych.

30 września 2026 r. wycofamy obsługę protokołu SBMP dla usługi Azure Service Bus, więc nie będzie można już używać tego protokołu po 30 września 2026 r. Przeprowadź migrację do najnowszych bibliotek zestawu SDK usługi Azure Service Bus przy użyciu protokołu AMQP, który oferuje krytyczne aktualizacje zabezpieczeń i ulepszone możliwości przed tą datą.

Aby uzyskać więcej informacji, zobacz ogłoszenie o wycofaniu pomocy technicznej.

Problemy, które mogą wystąpić podczas uaktualniania/ponownego uruchamiania usługi

Objawy

• Żądania mogą być chwilowo ograniczane.
• Może wystąpić spadek przychodzących komunikatów/żądań.
• Plik dziennika może zawierać komunikaty o błędach.
• Aplikacje mogą zostać odłączone od usługi przez kilka sekund.

Przyczyna

Uaktualnienia i ponowne uruchomienia usługi zaplecza mogą powodować te problemy w aplikacjach.

Rozwiązanie

Jeśli kod aplikacji używa zestawu SDK, zasady ponawiania są już wbudowane i aktywne. Aplikacja ponownie łączy się bez znaczącego wpływu na aplikację/przepływ pracy.

Nieautoryzowany dostęp: wymagane są oświadczenia wysyłania

Objawy

Ten błąd może wystąpić podczas próby uzyskania dostępu do tematu usługi Service Bus z programu Visual Studio na komputerze lokalnym przy użyciu tożsamości zarządzanej przypisanej przez użytkownika z uprawnieniami wysyłania.

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

Przyczyna

Tożsamość nie ma uprawnień dostępu do tematu usługi Service Bus.

Rozwiązanie

Aby rozwiązać ten błąd, zainstaluj bibliotekę Microsoft.Azure.Services.AppAuthentication . Aby uzyskać więcej informacji, zobacz Lokalne uwierzytelnianie programistyczne.

Aby dowiedzieć się, jak przypisywać uprawnienia do ról, zobacz Uwierzytelnianie tożsamości zarządzanej za pomocą identyfikatora Entra firmy Microsoft w celu uzyskania dostępu do zasobów usługi Azure Service Bus.

Wyjątek usługi Service Bus: Nie można umieścić tokenu

Objawy

Zostanie wyświetlony następujący komunikat o błędzie:

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

30 września 2026 r. wycofamy biblioteki zestawu SDK usługi Azure Service Bus WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus i com.microsoft.azure.servicebus, które nie są zgodne z wytycznymi dotyczącymi zestawu Azure SDK. Zakończymy również obsługę protokołu SBMP, więc nie będzie można już używać tego protokołu po 30 września 2026 r. Przeprowadź migrację do najnowszych bibliotek zestawu Azure SDK, które oferują krytyczne aktualizacje zabezpieczeń i ulepszone możliwości przed tą datą.

Mimo że starsze biblioteki mogą być nadal używane poza 30 września 2026 r., nie będą już otrzymywać oficjalnej pomocy technicznej i aktualizacji od firmy Microsoft. Aby uzyskać więcej informacji, zobacz ogłoszenie o wycofaniu pomocy technicznej.

Przyczyna

Liczba tokenów uwierzytelniania dla łączy współbieżnych w jednym połączeniu z przestrzenią nazw usługi Service Bus przekroczyła limit: 1000.

Rozwiązanie

Wykonaj jeden z następujących kroków:

• Zmniejsz liczbę współbieżnych łączy w jednym połączeniu lub użyj nowego połączenia
• Użyj zestawów SDK dla usługi Azure Service Bus, co gwarantuje, że nie dostaniesz się do tej sytuacji (zalecane)

Blokady zasobów nie działają podczas korzystania z zestawu SDK płaszczyzny danych

Objawy

Skonfigurowano blokadę usuwania w przestrzeni nazw usługi Service Bus, ale możesz usunąć zasoby w przestrzeni nazw (kolejki, tematy itp.) przy użyciu Eksploratora usługi Service Bus.

Przyczyna

Blokada zasobów jest zachowywana w usłudze Azure Resource Manager (płaszczyźnie sterowania) i nie uniemożliwia wywołania zestawu SDK płaszczyzny danych usunięcia zasobu bezpośrednio z przestrzeni nazw. Autonomiczny Eksplorator usługi Service Bus używa zestawu SDK płaszczyzny danych, więc usuwanie odbywa się.

Rozwiązanie

Zalecamy używanie interfejsu API opartego na usłudze Azure Resource Manager za pośrednictwem witryny Azure Portal, programu PowerShell, interfejsu wiersza polecenia lub szablonu usługi Resource Manager w celu usunięcia jednostek, aby blokada zasobu uniemożliwiła przypadkowe usunięcie zasobów.

Jednostka nie jest już dostępna

Objawy

Zostanie wyświetlony błąd, że jednostka nie jest już dostępna.

Przyczyna

Zasób mógł zostać usunięty. Wykonaj następujące kroki, aby określić, dlaczego jednostka została usunięta.

• Sprawdź dziennik aktywności, aby sprawdzić, czy istnieje żądanie usunięcia usługi Azure Resource Manager.
• Sprawdź dziennik operacyjny, aby sprawdzić, czy było bezpośrednie wywołanie interfejsu API w celu usunięcia. Aby dowiedzieć się, jak zbierać dziennik operacyjny, zobacz Monitorowanie usługi Azure Service Bus. Aby zapoznać się ze schematem i przykładem dziennika operacji, zobacz Dzienniki operacji
• Sprawdź dziennik operacji, aby sprawdzić, czy wystąpiło autodeleteonidle powiązane usunięcie.

Następne kroki

Odwiedź następujące artykuły:

• Wyjątki usługi Azure Resource Manager. Wyświetla on listę wyjątków generowanych podczas interakcji z usługą Azure Service Bus przy użyciu usługi Azure Resource Manager (za pośrednictwem szablonów lub wywołań bezpośrednich).
• Wyjątki obsługi komunikatów. Zawiera listę wyjątków generowanych przez program .NET Framework dla usługi Azure Service Bus.