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

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

Состояние ресурса

Неработоспособный период, отмеченный на странице работоспособности ресурсов пространства имен служебной шины на портале Azure, возможно, будет дольше на несколько минут, чем фактический период. Например, на странице может быть указано, что пространство имен неработоспособно в течение 5–6 минут, в то время как фактический неработоспособный период составил всего 1–2 минуты.

Это связано с механизмом оценки системы оповещений, который использует 3-минутный интервал оценки в сочетании с 5-минутным окном обратного просмотра. Окно обратного просмотра используется для обеспечения отсутствия ошибок по крайней мере через 5 минут, прежде чем рассматривать пространство имен работоспособным. В приведенном выше примере пространство имен стало работоспособным через минуту или две, но следующая оценка произошла по крайней мере через 5 минут (окно ретроспективы) после того, как пространство имен стало работоспособным.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы использовать поддержку DiagnosticActivity в версии GA, можно интегрироваться с SDK Application Insights. Дополнительные сведения см. в Application Insights в 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 при операциях отправки и планирования. В Application Insights интервалы трассировки Message отображаются как связанные с различными другими интервалами трассировки, которые использовались для взаимодействия с сообщением; например, на интервалы трассировки ServiceBusReceiver.Receive, ServiceBusSender.Send и ServiceBusReceiver.Complete будут вести ссылки из интервала трассировки Message. Ниже приведен пример того, как это выглядит в Application Insights:

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

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

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

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

Не удалось отправить пакет

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

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

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

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

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

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

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

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

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

Как просматривать сообщения сеансов сразу во всех сеансах

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

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

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

Ошибки «Сервер занят», когда открыто много ресиверов

Если вы открываете большое количество получателей в одной очереди, топике или подписке и держите их активными одновременно, может появиться ServiceBusException со значением ReasonServiceBusy. служебная шина поддерживает до 5000 одновременных запросов на получение сообщений для одного объекта в совокупности по всем подпискам темы. Каждый открытый получатель предоставляет кредит и постоянно запрашивает сообщения, даже когда сущность пуста, поэтому большое количество неактивных получателей может привести к тому, что общее число запросов на получение превысит этот предел, и дополнительные запросы будут отклонены.

Пакеты SDK для служебная шина автоматически выполняют повторные попытки при ответах сервера о занятости с экспоненциальной задержкой, поэтому кратковременные сбои обрабатываются автоматически. Чтобы не достигать предельного значения, держите число одновременных приёмников для одной сущности значительно ниже 5 000, закрывайте приёмники, которые вам больше не нужны, вместо того чтобы оставлять их простаивать, и распределяйте нагрузку между несколькими сущностями, если вам требуется очень большое число потребителей. Дополнительные сведения см. в статье Ограничение пропускной способности операций в Служебная шина Azure.

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

Не работает продление автоблокировки

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

Процессор, по-видимому, зависает или возникают проблемы с задержкой при использовании высокой степени параллелизма

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

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

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

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

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

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

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

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

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

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

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

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

Транзакция завершается по тайм-ауту через определённое время, поэтому важно, чтобы обработка, выполняемая в рамках транзакции, укладывалась в этот тайм-аут.

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

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

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

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

Квоты

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

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

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

• Перейдите или воспользуйтесь wgethttps://<yournamespace>.servicebus.windows.net/. Это поможет проверить наличие проблем с 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-адреса, которые нужно добавить в список разрешений.

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

Симптомы

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

Причина

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

Разрешение

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

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

Симптомы

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

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

Причина

У этого субъекта нет разрешений на доступ к теме служебная шина.

Разрешение

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

Сведения о назначении разрешений ролям см. в статье Проверка подлинности управляемого удостоверения с помощью Microsoft Entra ID для доступа к ресурсам Служебной шины 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, — которые не соответствуют рекомендациям Azure SDK. Мы также завершим поддержку протокола SBMP, поэтому вы больше не сможете использовать этот протокол после 30 сентября 2026 года. Перейдите в последние библиотеки пакета SDK Azure, которые предлагают критически важные обновления системы безопасности и улучшенные возможности до этой даты.

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

Причина

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

Разрешение

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

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

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

Симптомы

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

Причина

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

Разрешение

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

Объект больше недоступен

Симптомы

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

Причина

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

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

Имена сущностей показывают тильду (~) вместо косой черты (/)

Симптомы

Имена сущностей на портале Azure, интерфейсе командной строки или ответах API ARM отображают символы ~, например orders~us~west вместо orders/us/west.

Причина

служебная шина поддерживает иерархические имена сущностей с / в качестве разделителя путей, но Azure Resource Manager не разрешает / в именах ресурсов. служебная шина преобразует ~ в / на границе ARM.

Разрешение

Это ожидаемое поведение. Имя базовой сущности использует /. Отображается ~ только в средствах на основе ARM (портал, CLI, PowerShell, шаблоны ARM). Пакеты SDK служебная шина и клиенты AMQP видят реальное имя /. Дополнительные сведения см. в разделе «Названия сущностей с прямой косой чертой».

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

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

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