Руководство по устранению неполадок для Служебной шины Azure

В этой статье приведены советы по устранению неполадок и рекомендации по нескольким проблемам, которые возникают при использовании Служебная шина Azure.

Проблемы с подключением

Время ожидания при подключении к службе

В зависимости от среды узла и сети проблема с подключением может представляться приложениям как одно TimeoutExceptionили OperationCanceledExceptionто, или и ServiceBusException чаще ReasonServiceTimeout всего возникает, когда клиент не может найти сетевой путь к службе.

Устранение неполадок:

• Убедитесь, что строка подключения или полное доменное имя, указанное при создании клиента, правильно. Сведения о том, как получить строка подключения, см. в статье "Получение служебная шина строка подключения".
• Проверьте разрешения брандмауэра и порта в среде размещения. Убедитесь, что открыты порты расширенной очереди сообщений (AMQP) 5671 и 5672, а конечная точка разрешена через брандмауэр.
• Попробуйте использовать параметр транспорта веб-сокета, который подключается с помощью порта 443. Дополнительные сведения см. в разделе "Настройка транспорта".
• Проверьте, блокирует ли сеть определенные IP-адреса. Дополнительные сведения см. в статье о том, какие IP-адреса нужно разрешить?
• При необходимости проверьте конфигурацию прокси-сервера. Дополнительные сведения см. в статье "Настройка транспорта"
• Дополнительные сведения об устранении неполадок с сетевым подключением см. в статье [Подключение тивность, сертификат или время ожидания][#connectivity-certificate-or-timeout-issues].

Сбои подтверждения безопасного сокета (SSL)

Эта ошибка может возникать при использовании перехвата прокси-сервера. Чтобы проверить, рекомендуется протестировать приложение в среде узла с отключенным прокси-сервером.

Ошибки исчерпания сокета

Приложения должны предпочесть рассматривать типы служебная шина как одноэлементные, создавая и используя один экземпляр через время существования приложения. Каждый новый ServiceBusClient создал результаты в новом подключении AMQP, которое использует сокет. Тип ServiceBusClient управляет подключением для всех типов, созданных из этого экземпляра. Каждый ServiceBusReceiver, ServiceBusSessionReceiver, ServiceBusSender и ServiceBusProcessor управляет собственной ссылкой AMQP для связанной сущности служебная шина. При использовании ServiceBusSessionProcessor устанавливаются несколько ссылок AMQP в зависимости от количества сеансов, которые обрабатываются одновременно.

Клиенты безопасно кэшируются при простое; они обеспечивают эффективное управление сетью, ЦП и памятью, минимизируя их влияние в периоды бездействия. Также важно, чтобы CloseAsyncDisposeAsync клиент больше не нуждался в том, чтобы обеспечить правильную очистку сетевых ресурсов.

Добавление компонентов в строка подключения не работает

Текущее поколение клиентской библиотеки служебная шина поддерживает строка подключения только в форме, опубликованной портал Azure. Строка подключения предназначены только для предоставления основного расположения и общих сведений о ключе. Настройка поведения клиентов выполняется с помощью его параметров.

Предыдущие поколения клиентов служебная шина позволили настроить некоторое поведение путем добавления компонентов key/value в строка подключения. Эти компоненты больше не распознаются и не влияют на поведение клиента.

Альтернатива "TransportType=AmqpWebSockets"

Сведения о настройке веб-сокетов в качестве типа транспорта см. в разделе "Настройка транспорта".

Альтернатива "Authentication=Managed Identity" (Проверка подлинности=Управляемое удостоверение)

Сведения о проверке подлинности с помощью управляемого удостоверения см. в статье " Учетные данные для удостоверений и общего доступа". Дополнительные сведения о библиотеке Azure.Identity см. в статье "Проверка подлинности" и "Пакет SDK Azure".

Ведение журнала и диагностика

Клиентская библиотека служебная шина полностью инструментирована для ведения журнала на различных уровнях детализации с помощью .NET EventSource для выдачи информации. Ведение журнала выполняется для каждой операции и соответствует шаблону маркировки начальной точки операции, его завершения и любых исключений. Дополнительные сведения, которые могут предложить аналитические сведения, также регистрируются в контексте связанной операции.

Включение ведения журналов

Журналы клиентов служебная шина доступны для любогоEventListener, выбрав источники, начиная с Azure-Messaging-ServiceBus или выбрав все источники, имеющие признакAzureEventSource. Чтобы упростить запись журналов из клиентских библиотек Azure, библиотека, Azure.Core используемая служебная шина предлагает AzureEventSourceListener.

Дополнительные сведения см. в статье "Ведение журнала с помощью пакета SDK Azure для .NET".

Распределенная трассировка

Клиентская библиотека служебная шина поддерживает распределенную трассировку через интеграцию с пакетом SDK для приложений Аналитика. Она также поддерживает экспериментальную поддержку спецификации OpenTelemetry с помощью типа .NET ActivitySource , представленного в .NET 5. Чтобы включить ActivitySource поддержку использования с OpenTelemetry, см . раздел "Поддержка ActivitySource".

Чтобы использовать поддержку ga DiagnosticActivity, можно интегрировать с пакетом SDK для приложений Аналитика. Дополнительные сведения можно найти в приложении Аналитика с помощью Azure Monitor.

Библиотека создает следующие диапазоны:

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

Большинство диапазонов являются самообъяснительными и начинаются и остановлены во время операции, которая имеет свое имя. Диапазон, который связывает других между собой Message. Способ трассировки сообщения осуществляется через Diagnostic-Id свойство ServiceBusMessage.ApplicationProperties библиотеки во время операций отправки и расписания. В приложении Аналитика Message диапазоны отображаются как связывание с различными другими диапазонами, которые использовались для взаимодействия с сообщением, например ServiceBusReceiver.Receive диапазон, ServiceBusSender.Send диапазон и ServiceBusReceiver.Complete диапазон будет связан из Message диапазона. Ниже приведен пример того, как это выглядит в приложении Аналитика:

На приведенном выше снимке экрана вы увидите сквозную транзакцию, которую можно просмотреть в приложении Аналитика на портале. В этом сценарии приложение отправляет сообщения и использует ServiceBusSessionProcessor для их обработки. Действие Message связано с ServiceBusSender.Send, ServiceBusReceiver.Receiveи ServiceBusSessionProcessor.ProcessSessionMessageServiceBusReceiver.Complete.

Примечание.

Дополнительные сведения см. в статье "Распределенная трассировка и корреляция" с помощью служебная шина обмена сообщениями.

Устранение неполадок с отправителем

Не удается отправить пакет с несколькими ключами секции

Когда приложение отправляет пакет в сущность с поддержкой секционирования, все сообщения, включенные в одну операцию отправки, должны иметь одинаковое PartitionKeyзначение. Если сущность включена с поддержкой сеанса, то то же требование имеет значение true для SessionId свойства. Чтобы отправлять сообщения с разными PartitionKey значениями, группировать сообщения в отдельных ServiceBusMessageBatch экземплярах или SessionId включать их в отдельные вызовы перегрузки SendMessagesAsync, которая принимает набор ServiceBusMessage экземпляров.

Не удается отправить пакетную службу

Пакет сообщений содержит ServiceBusMessageBatch два или более сообщений, или вызов SendMessagesAsync , в котором передаются два или более сообщений. Служба не позволяет пакету сообщений превышать 1 МБ. Это поведение верно, включена ли функция поддержки больших сообщений класса Premium. Если вы планируете отправить сообщение больше 1 МБ, его необходимо отправить отдельно, а не сгруппировать с другими сообщениями. К сожалению, тип ServiceBusMessageBatch в настоящее время не поддерживает проверку того, что пакет не содержит сообщений больше 1 МБ, так как размер ограничен службой и может измениться. Таким образом, если вы планируете использовать функцию поддержки больших сообщений premium, убедитесь, что вы отправляете сообщения более 1 МБ по отдельности.

Устранение неполадок приемника

Количество возвращенных сообщений не соответствует номеру, запрошенном в пакетном получении

При попытке выполнить операцию пакетного получения, то есть передавая maxMessages значение двух или больше методу ReceiveMessagesAsync , вы не гарантируете получение количества запрошенных сообщений, даже если очередь или подписка имеет такое количество сообщений, доступных в то время, и даже если весь настроенный maxWaitTime параметр еще не истек. Чтобы максимально увеличить пропускную способность и избежать истечения срока действия блокировки, после того как первое сообщение поступает через провод, получатель ожидает дополнительно 20 миллисекунд для любых дополнительных сообщений перед отправкой сообщений для обработки. Определяет maxWaitTime , сколько времени получатель ожидает получения первого сообщения— последующие сообщения ожидают 20 миллисекунда. Поэтому приложение не должно предполагать, что все доступные сообщения получаются в одном вызове.

Сообщение или блокировка сеанса теряется до истечения срока действия блокировки

Служба служебная шина использует протокол AMQP, который является отслеживанием состояния. В связи с характером протокола, если ссылка, которая подключает клиента и службу отсоединяется после получения сообщения, но до того, как сообщение будет решено, сообщение не может быть решено при повторном подключении ссылки. Связи могут быть отсоединяться из-за кратковременного временного сбоя сети, сбоя сети или из-за принудительного времени ожидания простоя службы в течение 10 минут. Повторное подключение ссылки происходит автоматически в рамках любой операции, требующей ссылки, то есть урегулирования или получения сообщений. В этой ситуации вы получаете ServiceBusException или ReasonMessageLockLostSessionLockLost даже если время истечения срока действия блокировки еще не прошло.

Просмотр запланированных или отложенных сообщений

Запланированные и отложенные сообщения включаются при просмотре сообщений. Их можно определить с помощью свойства ServiceBusReceivedMessage.State . Получив значение SequenceNumber отложенного сообщения, его можно получить с помощью метода ReceiveDeferredMessagesAsync.

При работе с разделами вы не можете просматривать запланированные сообщения в подписке, так как сообщения остаются в разделе до запланированного времени запроса. В качестве обходного решения можно создать ServiceBusReceiver , передавая имя раздела, чтобы просмотреть такие сообщения. При использовании имени раздела другие операции с приемником не работают.

Просмотр сообщений сеанса во всех сеансах

Вы можете использовать обычный ServiceBusReceiver для просмотра во всех сеансах. Чтобы просмотреть определенный сеанс, можно использовать ServiceBusSessionReceiver, но необходимо получить блокировку сеанса.

NotSupportedException возникает при доступе к тексту сообщения

Эта проблема возникает чаще всего в сценариях взаимодействия при получении сообщения, отправленного из другой библиотеки, которая использует другой формат текста сообщения AMQP. Если вы взаимодействуете с этими типами сообщений, ознакомьтесь с примером текста сообщения AMQP, чтобы узнать, как получить доступ к тексту сообщения.

Устранение неполадок процессора

Автоматическое продление не работает

Автоматическое продление зависит от системного времени, чтобы определить, когда следует продлить блокировку для сообщения или сеанса. Если ваше системное время не является точным, например, ваши часы медленно, то обновление блокировки может не произойти до потери блокировки. Убедитесь, что системное время является точным, если автоматическое продление не работает.

Обработчик, как представляется, зависает или имеет проблемы с задержкой при использовании высокой параллелизма

Это поведение часто вызвано нехваткой потока, особенно при использовании процессора сеанса и использовании очень высокого значения для MaxConcurrentSessions, относительно количества ядер на компьютере. Первое, что необходимо проверка, чтобы убедиться, что вы не выполняете синхронизацию над асинхронным режимом ни в одном из обработчиков событий. Синхронизация по асинхронному режиму — это простой способ вызвать взаимоблокировку и нехватку потоков. Даже если вы не выполняете синхронизацию с асинхронной синхронизацией, любой чистый код синхронизации в обработчиках может способствовать нехватке потоков. Если вы определили, что это не проблема, например, так как у вас есть чистый асинхронный код, вы можете попробовать увеличить [TryTimeout][TryTimeout]. Это снижает давление на пул потоков, уменьшая количество переключений контекста и времени ожидания, возникающих при использовании процессора сеансов в частности. Значение по умолчанию для [TryTimeout][TryTimeout] составляет 60 секунд, но его можно задать до 1 часа. Мы рекомендуем тестировать с набором TryTimeout до 5 минут в качестве отправной точки и выполнять итерацию оттуда. Если ни одно из этих предложений не работает, вам просто нужно выполнить горизонтальное масштабирование до нескольких узлов, уменьшая параллелизм в приложении, но запуск приложения на нескольких узлах для достижения требуемой общей параллелизма.

Дополнительные материалы:

• Отладка нехватки пула потоков
• Диагностика нехватки пула потоков .NET Core с помощью PerfView (почему моя служба не насыщает все ядра или, кажется, остановлена)
• Диагностика проблем с исчерпанием пула потоков в приложениях .NET Core (видео)

Обработчик сеансов занимает слишком много времени для переключения сеансов

Это можно настроить с помощью [SessionIdleTimeout][SessionIdleTimeout], который сообщает обработчику, сколько времени нужно ждать получения сообщения из сеанса, прежде чем отказаться и перейти к другому. Полезно, если у вас много разреженных сеансов, где каждый сеанс содержит только несколько сообщений. Если вы ожидаете, что каждый сеанс будет иметь много сообщений, которые усложняются, установка слишком низкой может быть контрпродуктивной, так как это приводит к ненужному закрытию сеанса.

Обработчик останавливается немедленно

Это часто наблюдается для демонстрационных сценариев или сценариев тестирования. StartProcessingAsync возвращается сразу после запуска процессора. Вызов этого метода не блокирует и не сохраняет работоспособность приложения во время работы процессора, поэтому вам нужен другой механизм для этого. Для демонстраций или тестирования достаточно просто добавить Console.ReadKey() звонок после запуска процессора. В рабочих сценариях, скорее всего, потребуется использовать такую интеграцию платформы, как [BackgroundService][BackgroundService], чтобы обеспечить удобные перехватчики жизненного цикла приложений, которые можно использовать для запуска и удаления процессора.

Устранение неполадок транзакций

Общие сведения о транзакциях в служебная шина см. в статье [Обзор обработки транзакций служебная шина][Транзакции].

Поддерживаемые операции

Не все операции поддерживаются при использовании транзакций. Сведения о списке поддерживаемых транзакций см. в статье [Операции в область транзакций][TransactionOperations].

Время ожидания

Время ожидания транзакции истекает после [периода времени][TransactionTimeout], поэтому важно, чтобы обработка, которая происходит в рамках транзакции, область соответствует этому времени ожидания.

Операции в транзакции не извлекаются

Это сделано намеренно. Рассмотрим следующий сценарий: вы пытаетесь завершить сообщение в рамках транзакции, но существует некоторая временная ошибка, которая возникает, например ServiceBusException , с одним ReasonServiceCommunicationProblemиз них. Предположим, что запрос фактически делает его в службе. Если клиент попытался повторить попытку, служба увидит два полных запроса. Первое завершение не будет завершено, пока транзакция не будет зафиксирована. Второй завершенный процесс даже не может быть оценен до первого завершения. Транзакция на клиенте ожидает завершения. Это создает взаимоблокировку, в которой служба ожидает завершения транзакции, но клиент ожидает, чтобы служба признала вторую полную операцию. Транзакция в конечном итоге истекает через 2 минуты, но это плохое взаимодействие с пользователем. По этой причине мы не повторяем операции в рамках транзакции.

Транзакции между сущностями не работают

Для выполнения транзакций, включающих несколько сущностей, необходимо задать ServiceBusClientOptions.EnableCrossEntityTransactions для trueсвойства значение . Дополнительные сведения см. в примере [Транзакции между сущностями][CrossEntityTransactions].

Планы продаж

Сведения о квотах служебная шина можно найти [здесь][ServiceBusQuotas].

Проблемы с подключением, сертификатом или временем ожидания

Ниже приведены инструкции по устранению неполадок с подключением, сертификатом и временем ожидания для всех служб в *.servicebus.windows.net.

• Перейдите на страницу https://<yournamespace>.servicebus.windows.net/ или воспользуйтесь wget. Это поможет проверить наличие проблем с IP-фильтрацией, виртуальной сетью или цепочками сертификатов, которые являются типичными при использовании пакета SDK для Java.

  Пример сообщения об успешном выполнении:

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

  Пример сообщения об ошибке или сбое:

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

• Выполните следующую команду, чтобы проверить, не заблокирован ли какой-либо порт на брандмауэре. Используемые порты: 443 (HTTPS), 5671 и 5672 (AMQP) и 9354 (Net Messaging/SBMP). Также могут применятся другие порты. Это зависит от используемой библиотеки. Ниже приведен пример команды, проверка, заблокирован ли порт 5671. О

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

  В Linux:

  telnet <yournamespacename>.servicebus.windows.net 5671
  

• Если возникают периодические проблемы с подключением, выполните следующую команду, чтобы проверить наличие отброшенных пакетов. Эта команда пытается установить 25 разных TCP-подключений каждые 1 секунды со службой. Вы сможете увидеть, сколько попыток завершились успешно, а сколько — сбоем, а также увидеть задержку TCP-подключения. Средство psping можно скачать здесь.

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

  Также можно использовать аналогичные команды, если вы используете другие средства, такие как tnc, ping и прочие.

• Если предыдущие шаги не помогли в решении проблемы, получите трассировку сети и проанализируйте ее с помощью таких средств, как Wireshark. При необходимости обратитесь в службу поддержки Майкрософт.

• Чтобы узнать, как найти IP-адреса, которые нужно добавить в список разрешений для подключений, см. раздел IP-адреса, которые нужно добавить в список разрешений.

30 сентября 2026 года мы отставим от поддержки протокола SBMP для Служебная шина Azure, поэтому вы больше не сможете использовать этот протокол после 30 сентября 2026 года. Миграция на последние библиотеки пакета SDK Служебная шина Azure с помощью протокола AMQP, который предлагает критически важные обновления системы безопасности и улучшенные возможности до этой даты.

Дополнительные сведения см. в объявлении о выходе на пенсию в службу поддержки.

Проблемы, которые могут возникнуть при обновлении или перезапуске службы

Симптомы

• Запросы могут быть мгновенно регулироваться.
• Может возникнуть падение входящих сообщений и запросов.
• Файл журнала может содержать сообщения об ошибках.
• Приложения могут быть отключены от службы в течение нескольких секунд.

Причина

Обновления и перезапуски серверной службы могут вызвать эти проблемы в приложениях.

Разрешение

Если код приложения использует пакет SDK, политика повторных попыток уже встроена и активна. Приложение повторно подключается без значительного влияния на приложение или рабочий процесс.

Несанкционированный доступ: требуется отправка утверждений

Симптомы

Эта ошибка может возникнуть при попытке получить доступ к разделу служебная шина из Visual Studio на локальном компьютере с помощью управляемого удостоверения, назначаемого пользователем, с разрешениями на отправку.

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

Причина

Удостоверение не имеет разрешений на доступ к разделу Служебной шины.

Разрешение

Чтобы устранить эту ошибку, установите библиотеку Microsoft.Azure.Services.AppAuthentication. Дополнительные сведения см. в разделе Проверка подлинности локальной разработки.

Сведения о назначении разрешений ролям см. в статье "Проверка подлинности управляемого удостоверения с помощью идентификатора Записи Майкрософт" для доступа к ресурсам Служебная шина Azure.

Исключение Служебной шины: ошибка при размещении маркера

Симптомы

Отображается следующее сообщение об ошибке:

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

30 сентября 2026 г. мы удалим библиотеки пакета SDK Служебная шина Azure WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus и com.microsoft.azure.servicebus, которые не соответствуют рекомендациям по пакету SDK Azure. Мы также завершим поддержку протокола SBMP, поэтому вы больше не сможете использовать этот протокол после 30 сентября 2026 года. Перейдите в последние библиотеки пакета SDK Azure, которые предлагают критически важные обновления системы безопасности и улучшенные возможности до этой даты.

Хотя старые библиотеки по-прежнему могут использоваться после 30 сентября 2026 года, они больше не будут получать официальную поддержку и обновления от Майкрософт. Дополнительные сведения см. в объявлении о выходе на пенсию в службу поддержки.

Причина

Число токенов проверки подлинности для параллельных ссылок в одном подключении к пространству имен служебной шины превысило ограничение: 1000.

Разрешение

Выполните один из следующих шагов:

• Уменьшите количество параллельных ссылок в одном подключении или используйте новое подключение
• Используйте пакеты SDK для служебной шины Azure, чтобы убедиться, что вы не попадете в такую ситуацию (рекомендуется)

Блокировки ресурсов не работают при использовании пакета SDK плоскости данных

Симптомы

Вы настроили блокировку удаления для пространства имен служебная шина, но вы можете удалить ресурсы в пространстве имен (очереди, разделы и т. д.) с помощью служебная шина Обозреватель.

Причина

Блокировка ресурсов сохраняется в Azure Resource Manager (плоскости управления) и не предотвращает удаление ресурса непосредственно из пространства имен. Автономный служебная шина Обозреватель использует пакет SDK плоскости данных, поэтому удаление выполняется.

Разрешение

Рекомендуется использовать API на основе Azure Resource Manager с помощью портал Azure, PowerShell, CLI или шаблона Resource Manager, чтобы удалить сущности, чтобы блокировка ресурсов не позволяла случайно удалять ресурсы.

Сущность больше не доступна

Симптомы

Вы увидите сообщение об ошибке, что сущность больше не доступна.

Причина

Возможно, ресурс был удален. Выполните следующие действия, чтобы определить, почему сущность была удалена.

• Проверьте журнал действий, чтобы узнать, есть ли запрос Azure Resource Manager на удаление.
• Проверьте операционный журнал, чтобы узнать, был ли прямой вызов API для удаления. Сведения о сборе операционного журнала см. в статье "Сбор и маршрутизация". Схема и пример журнала операций см . в журналах операций.
• Проверьте журнал операций, чтобы узнать, произошло ли связанное autodeleteonidle удаление.

Дальнейшие действия

См. следующие статьи:

• Исключения Azure Resource Manager. В этой статье перечислены исключения, созданные при взаимодействии со Служебной шиной Azure с помощью Azure Resource Manager (используя шаблоны или прямые вызовы).
• Исключения в обмене сообщениями. В этой статье предоставлен список исключений, созданных .NET Framework для Служебной шины Azure.