Часто задаваемые вопросы о Центрах событий

Пространство имен — это контейнер области для центров событий или разделов Kafka. Оно предоставляет уникальное полное доменное имя (FQDN). Пространство имен служит контейнером приложения, который может размещать несколько центров событий или разделов Kafka.

№ После развертывания невозможно изменить (например, с уровня "Стандартный" на уровень "Премиум" без развертывания нового ресурса.

Используемые для оценки распределение мощностей единицы пропускной способности (TU) или единицы обработки (PU) оплачиваются на уровне пространства имен. Пространство имен также связано с регионом.

Можно создать новое пространство имен вместо использования существующего в одном из следующих сценариев:

• Вам нужен концентратор событий, связанный с новым регионом.
• Вам нужен концентратор событий, связанный с другой подпиской.
• Вам нужен концентратор событий с отдельным выделением емкости (т. е. емкость пространства имен с добавленным концентратором событий превысит пороговое значение 40 ТУ, и вы не хотите использовать выделенный кластер).'

Центры событий ценовой категории "Стандартный" предоставляют функции, недоступные для категории "Базовый". Ценовая категория "Стандартный" включает в себя следующие функции:

• более длительное хранение событий;
• дополнительные подключения через брокер с оплатой избыточных событий в случае превышения установленного количества;
• возможность использования нескольких групп объектов-получателей;
• возможность использования функции записи.
• Интеграция с Kafka

Дополнительные сведения о ценовых категориях, включая Центры событий ценовой категории "Выделенный", см. на странице цен на Центры событий.

Центры событий Azure доступны во всех поддерживаемых регионах Azure. Список см. на странице регионов Azure.

Да, при условии, что все концентраторы событий находятся в одном пространстве имен.

Стандартный уровень Центров событий в настоящее время поддерживает максимальный срок хранения в семь дней, а для уровня "Премиум" и "Выделенный" это ограничение составляет 90 дней. Концентраторы событий не предназначены для постоянного хранения данных. Периоды хранения, превышающие 24 часа, предназначены для сценариев, в которых удобно воспроизводить поток событий в одних и тех же системах. Например, для обучения или проверки новой модели машинного обучения на основе существующих данных. Если требуется хранить сообщения дольше семи дней, включите функцию Сбор в Центрах событий, чтобы извлекать из концентратора событий данные в учетную запись хранения или учетную запись службы Azure Data Lake по своему выбору. Включение записи повлечет за собой затраты в соответствии с приобретенной единицей пропускной способности.

Вы можете настроить срок хранения для захваченных данных в учетной записи хранения. Управление жизненным циклом службы хранилища Azure предлагает многофункциональные политики на основе правил для учетных записей v2 общего назначения и хранилищ BLOB-объектов. Эти политики позволяют переводить данные на новые уровни доступа и удалять их по завершении жизненного цикла. Дополнительные сведения см. в статье Управление жизненным циклом хранилища BLOB-объектов Azure.

Концентраторы событий создают метрики, которые предоставляют в Azure Monitor полные данные о состоянии ресурсов. Они позволяют оценить общую работоспособность службы Центров событий не только на уровне пространства имен, но также и на уровне сущностей. Узнайте, какие возможности мониторинга поддерживаются для Центров событий Azure.

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

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

Производители или отправители могут использовать протоколы advanced Messaging Queuing (AMQP), Kafka или HTTPS для отправки событий в концентратор событий.

Потребители или получатели используют AMQP или Kafka для получения событий из концентратора событий. Центры событий поддерживают только модель извлечения для потребителей, получая от нее события. Даже если обработчики событий используются для обработки событий из концентратора событий, обработчик событий внутренне использует модель извлечения для получения событий из концентратора событий.

AMQP

Протокол AMQP 1.0 можно использовать для отправки событий в Центры событий Azure и получения событий. AMQP обеспечивает надежную, исполнительную и безопасную связь как для отправки, так и для получения событий. Его можно использовать для высокопроизводительной и потоковой передачи в режиме реального времени и поддерживается большинством Центры событий Azure пакетов SDK.

HTTPS/REST API

События можно отправлять только в Центры событий с помощью HTTP-запросов POST. Центры событий не поддерживают получение событий по протоколу HTTPS. Он подходит для упрощенных клиентов, где прямое TCP-подключение невозможно.

Apache Kafka

Центры событий Azure имеет встроенную конечную точку Kafka, которая поддерживает производителей и потребителей Kafka. Приложения, созданные с помощью Kafka, могут использовать протокол Kafka (версия 1.0 или более поздней версии) для отправки и получения событий из Центров событий без каких-либо изменений кода.

Пакеты SDK Azure абстрагируют базовые протоколы связи и предоставляют упрощенный способ отправки и получения событий из Центров событий с помощью таких языков, как C#, Java, Python, JavaScript и т. д.

Какие порты нужно открыть в брандмауэре?

Для отправки и получения событий можно использовать следующие протоколы с Центрами событий Azure:

• Протокол AMQP 1.0
• Протокол гипертекстовой передачи 1.1 с безопасностью транспортного уровня (HTTPS)
• Apache Kafka

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

Порт HTTPS требуется для исходящего взаимодействия также при использовании AMQP через порт 5671, так как несколько операций управления, выполняемых клиентскими пакетами SDK, и приобретение маркеров из идентификатора Microsoft Entra (при использовании) выполняется по протоколу HTTPS.

Официальный пакет SDK для Azure обычно использует протокол AMQP для отправки и получения событий от Центров событий. Вариант протокола AMQP через WebSockets работает через порт TCP 443, как и API HTTP. В остальном с точки зрения функциональности он полностью идентичен обычному протоколу AMQP. Этот вариант протокола имеет более высокую начальную задержку при подключении из-за дополнительных циклов подтверждения соединения, а также требует несколько больших дополнительных расходов для совместного использования порта HTTPS. Если выбран этот режим, для обмена данными достаточно TCP-порта 443. Для выбора между обычным протоколом AMQP и режимом AMQP через WebSockets используются следующие параметры.

Какие IP-адреса нужно внести в список разрешений?

При работе с Azure иногда необходимо разрешать определенные диапазоны IP-адресов или URL-адреса на корпоративном брандмауэре или прокси-сервере, чтобы получить доступ ко всем службам Azure, которые вы используете или пытаетесь использовать. Убедитесь, что разрешен трафик на IP-адреса, используемые Центрами событий. IP-адреса, используемые Центрами событий Azure, см. в разделе Диапазоны IP-адресов и теги служб Azure — общедоступное облако.

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

1. В командной строке выполните следующую команду:

   nslookup <YourNamespaceName>.servicebus.windows.net
   

2. Запишите IP-адрес, возвращенный в Non-authoritative answer.

Если вы используете пространство имен, размещенное в более старом кластере (на основе Облачные службы — CNAME, заканчивающееся *.cloudapp.net), а пространство имен является избыточным по зонам, необходимо выполнить несколько дополнительных действий. Если пространство имен находится в новом кластере (на основе масштабируемого набора виртуальных машин — CNAME, заканчивающееся *.cloudapp.azure.com) и избыточности зоны, можно пропустить следующие действия.

1. Сначала следует запустить nslookup в пространстве имен.

   nslookup <yournamespace>.servicebus.windows.net
   

2. Запишите имя в разделе не заслуживающий доверия ответ, который имеет один из следующих форматов:

   <name>-s1.cloudapp.net
   <name>-s2.cloudapp.net
   <name>-s3.cloudapp.net
   

3. Выполните команду nslookup для каждого из них с суффиксами s1, s2 и s3, чтобы получить IP-адреса всех трех экземпляров, работающих в трех зонах доступности.

   Примечание.

   IP-адрес, возвращенный командой nslookup, не является статическим. Однако он остается постоянным до тех пор, пока базовое развертывание не будет удалено или перемещено в другой кластер.

Какие IP-адреса клиента отправляют события в мое пространство имен или получают события из него?

Сначала включите фильтрацию IP-адресов в пространстве имен.

Затем включите журналы диагностики для событий подключения виртуальной сети Центров событий, следуя инструкциям в разделе Включение журналов диагностики. Вы увидите IP-адрес, для которого запрещено подключение.

{
    "SubscriptionId": "0000000-0000-0000-0000-000000000000",
    "NamespaceName": "namespace-name",
    "IPAddress": "1.2.3.4",
    "Action": "Deny Connection",
    "Reason": "IPAddress doesn't belong to a subnet with Service Endpoint enabled.",
    "Count": "65",
    "ResourceId": "/subscriptions/0000000-0000-0000-0000-000000000000/resourcegroups/testrg/providers/microsoft.eventhub/namespaces/namespace-name",
    "Category": "EventHubVNetConnectionEvent"
}

Центры событий предоставляют конечную точку Kafka, которую могут использовать существующие приложения на основе Kafka. Чтобы настроить Kafka в режиме PaaS (платформа как услуга), достаточно лишь изменить конфигурацию. Так вы сможете обойтись без создания собственного кластера Kafka. Центры событий поддерживают Apache Kafka 1.0 и более новые версии клиента, а также работают с существующими приложениями, средствами и платформами Kafka. Дополнительные сведения см. в репозитории Центров событий для Kafka.

Чтобы подключиться к концентратору событий с поддержкой Kafka, следует обновить конфигурации клиентов Kafka. Для этого создайте пространство имен Центров событий и получите строку подключения. Измените bootstrap.servers, чтобы он содержат полное доменное имя Центров событий и порт 9093. Обновите файл sasl.jaas.config, чтобы направлять клиент Kafka к конечной точке Центров событий (которая является полученной строкой подключения) и использовать правильную проверку подлинности, как показано ниже:

bootstrap.servers={YOUR.EVENTHUBS.FQDN}:9093
request.timeout.ms=60000
security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="$ConnectionString" password="{YOUR.EVENTHUBS.CONNECTION.STRING}";

Пример:

bootstrap.servers=dummynamespace.servicebus.windows.net:9093
request.timeout.ms=60000
security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="$ConnectionString" password="Endpoint=sb://dummynamespace.servicebus.windows.net/;SharedAccessKeyName=DummyAccessKeyName;SharedAccessKey=XXXXXXXXXXXXXXXXXXXXX";

Для Центров событий допускается максимальный размер сообщения 1 МБ.

Пропускная способность Центров событий определяет объем данных (в мегабайтах) или число событий (в тысячах) размером 1 КБ, которые могут проходить через Центр событий. Пропускная способность измеряется в единицах пропускной способности. Единицы пропускной способности следует приобретать заранее до начала работы со службой Центров событий. Единицы пропускной способности для Центров событий вы можете указать явным образом с помощью портала Azure или шаблонов Resource Manager для Центров событий.

Да, единицы пропускной способности применяются для всех Центров событий в пространстве имен. Это означает, что единицы пропускной способности приобретаются на уровне пространства имен и совместно используются всеми Центрами событий в этом пространстве имен. Каждая единица пропускной способности предоставляет следующие возможности для пространства имен:

• До 1 МБ в секунду событий входящего трафика (события, отправленные в концентратор событий), но не более 1000 событий входящего трафика, операций управления или вызовов API управления в секунду.
• До 2 МБ в секунду событий исходящего трафика (события, потребляемые из концентратора событий), но не более 4096 событий исходящего трафика.
• До 84 ГБ хранилища событий (достаточно для периода хранения по умолчанию 1 час).

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

Вы можете запустить как минимум одну единицу пропускной способности (TU) и включить автоматическое заполнение. Функция автоинфляции позволяет увеличивать количество единиц по мере увеличения трафика или полезных данных. Можно также задать верхний предел количества для единиц пропускной способности.

Функция автоинфляции позволяет масштабировать единицы пропускной способности (TUS). Это означает, что вы можете начать с приобретения низких единиц TUS и автоинфляции масштабирует ваши TUS по мере увеличения входящего трафика. Так вы сэкономите средства, сохраняя полный контроль над количеством используемых единиц пропускной способности. Эта функция выполняет только увеличение масштаба, а обратное снижение масштаба вы контролируете самостоятельно, изменяя количество используемых единиц пропускной способности.

Возможно, вам потребуется начать с единиц пропускной способности (TUS), например 2 единица измерения пропускной способности. Если вы прогнозируете, что трафик может увеличиться до 15 единиц, включите функцию автоматического раздувания в пространстве имен и установите максимальное ограничение на 15 единиц. Теперь количество единиц пропускной способности будет увеличиваться автоматически по мере роста трафика.

Эта функция предоставляется без дополнительных затрат.

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

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

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

Квоты на входящие и исходящие сообщения применяются независимо, поэтому отправитель не может стать причиной замедления получения событий, а получатель — причиной прекращения отправки событий в концентратор событий.

На портале Azure можно выбрать до 40 единиц пропускной способности при создании пространства имен базового или стандартного уровня. При объемах более 40 единиц пропускной способности Центры событий предлагают специальную модель на основе ресурсов и емкости, например кластеры Центров событий ценовой категории "Премиум" или "Выделенный". Дополнительные сведения см. в разделах Центры событий (цен. категория "Премиум") — обзор и Центры событий (цен. категория "Выделенный") — обзор.

Ценовая категория "Выделенный" для Центров событий позволяет создавать развертывания с одним клиентом для самых требовательных пользователей. Это предложение создает кластер на основе емкости, который не привязан к единицам пропускной способности. Это означает, что вы можете использовать такой кластер для приема и потоковой передачи данных в любых объемах, которые смогут поддерживать ЦП и память кластера. Дополнительные сведения см. в статье Обзор Центров событий ценовой категории "Выделенный".

Пошаговые инструкции и дополнительные сведения о настройке выделенного кластера Центра событий см. в статье Краткое руководство. Создание выделенного кластера Центров событий с помощью портала Azure.

Чего я могу достичь с помощью кластера?

Для кластера Центров событий количество приема и потоков зависит от таких факторов, как ваши производители, потребители и скорость приема и обработки.

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

В тестировании использовались следующие критерии:

• Использовался кластер Центров событий выделенного уровня с четырьмя единицами ЦС.
• Для Центра событий, который использовался для приема сообщений, было выделено 200 разделов.
• Принимаемые данные распределялись между двумя приложениями-получателями, каждый из которых работал со всеми разделами.

Можно ли увеличить или уменьшить масштаб кластера?

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

Отправьте запрос на поддержку для горизонтального масштабирования или масштабирования в выделенном кластере в следующих сценариях:

• Вам требуется более 10 единиц емкости для масштабируемого в формате самообслуживания кластера (при создании которого был включен параметр Поддержка масштабирования).
• Необходимо масштабировать или масштабировать в кластере, который был создан без выбора параметра масштабирования поддержки .
• Перед выпуском самообслуживания необходимо масштабировать или масштабировать в выделенном кластере.

Можно ли перейти из устаревшего кластера в масштабируемый кластер самостоятельно?

Из-за разницы в базовой аппаратной и программной инфраструктуре мы в настоящее время не поддерживаем миграцию кластеров, которые не поддерживают самостоятельное масштабирование для самостоятельного обслуживания масштабируемых выделенных кластеров. Если вы хотите использовать самостоятельное масштабирование, необходимо повторно создать кластер. Сведения о создании масштабируемого кластера см. в статье "Создание выделенного кластера Центров событий".

Когда следует масштабировать выделенный кластер?

Использование ЦП является ключевым показателем потребления ресурсов выделенного кластера. Когда общее потребление ЦП начинает достигать 70 % (не наблюдая каких-либо ненормальных условий, таких как большое количество ошибок сервера или небольшое количество успешных запросов), это означает, что кластер движется к максимальной емкости. Эти сведения можно использовать в качестве индикатора, чтобы определить, нужно ли масштабировать выделенный кластер или нет.

Чтобы отслеживать использование ЦП выделенного кластера, выполните следующие действия.

1. На странице метрик выделенного кластера Центров событий выберите "Добавить метрику".

2. Выберите ЦП в качестве метрики и используйте Max в качестве агрегирования.

   

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

   

   Затем вы можете отслеживать эту метрику, чтобы определить, когда следует масштабировать выделенный кластер. Кроме того, можно настроить оповещения для этой метрики, чтобы получать уведомления о достижении установленного порогового значения загрузки ЦП.

Как геоизбыточное восстановление работает с моим кластером?

Вы можете географически связать пространство имен в кластере выделенного уровня с другим пространством имен в кластере выделенного уровня. Мы не рекомендуем связать пространство имен "Выделенный уровень" с пространством имен в стандартном предложении, так как ограничение пропускной способности несовместимо и приводит к ошибкам.

Можно ли перенести пространства имен Уровня "Стандартный" или "Премиум" в выделенный кластер?

В настоящее время мы не поддерживаем автоматизированный процесс миграции для переноса данных Центров событий из пространства имен "Стандартный" или "Премиум" в выделенный.

Почему устаревший выделенный кластер, избыточный между зонами, имеет не менее восьми ЦС?

Чтобы обеспечить избыточность зоны для выделенного предложения, все вычислительные ресурсы должны иметь три реплики в трех центрах обработки данных в одном регионе. Это минимальное требование поддерживает избыточность зоны (чтобы служба по-прежнему функционировала при отключении двух зон или центров обработки данных) и приводит к вычислению емкости, эквивалентной восьми единицам обслуживания.

Мы не можем изменить эту квоту. Это ограничение текущей архитектуры с выделенным уровнем.

Как секционирование — это механизм организации данных, позволяющий публиковать и использовать данные параллельно. Рекомендуется сбалансировать единицы масштабирования (единицы пропускной способности для стандартного уровня, единицы обработки для уровня "Премиум" или единицы емкости для выделенного уровня) и секции для достижения оптимального масштабирования. Как правило, рекомендуется использовать максимальную пропускную способность в 1 МБ/с на секцию. Таким образом, правило большого пальца для вычисления количества секций будет делить максимальную ожидаемую пропускную способность на 1 МБ/с. Например, если для вашего варианта использования требуется 20 МБ/с, рекомендуется выбрать по крайней мере 20 секций для достижения оптимальной пропускной способности.

Однако если у вас есть модель, в которой приложение имеет сходство с определенной секцией, увеличение числа секций не является полезным. Дополнительные сведения см. в статье Доступность и согласованность в Центрах событий.

Нет, невозможно, так как секции неизменяемы на уровне "Стандартный". Динамическое добавление секций доступно только на уровнях "Премиум" и "Выделенные" центров событий.

Полные сведения о ценах на Центры событий см. в разделе со сведениями о ценах на Центры событий.

Центры событий ценовой категории "Стандартный" разрешают хранение сообщений более 24 часов, но не более 7 дней. Если общий объем всех хранимых событий превышает лимит хранения для выбранного количества единиц пропускной способности (84 ГБ для каждой единицы), то за избыточный объем взимается плата согласно опубликованным ценам на хранилище BLOB-объектов Azure. Квота на хранение в каждой единице пропускной способности охватывает все затраты на хранение в течение 24 часов, даже если единица пропускной способности используется до максимальной квоты на вход.

Общий размер всех хранимых событий, включая внутреннюю дополнительную память для заголовков событий или дисковые накопительные структуры во всех концентраторах событий, измеряется в течение дня. В конце дня рассчитывается пиковый объем хранения. Суточная квота на хранение рассчитывается на основе минимального количества единиц пропускной способности, которые были выбраны в течение дня (каждая единица пропускной способности обеспечивает квоту в размере 84 ГБ). Если общий размер превышает рассчитанный ежедневный лимит хранения, избыточный объем оплачивается согласно ценам на хранилище BLOB-объектов Azure (по цене локально избыточного хранилища ).

Каждое событие, отправленное в концентратор событий, считается оплачиваемым сообщением. Входящее событие определяется как единица данных, размер которой меньше или равен 64 КБ. Любое событие, размер которого меньше или равен 64 КБ, считается одним оплачиваемым событием. Если размер события превышает 64 КБ, то количество оплачиваемых сообщений вычисляется исходя из размера, кратного 64 КБ. Например, событие размером 8 КБ, отправленное концентратору событий, оплачивается как одно событие, а сообщение размером 96 КБ, отправленное концентратору событий, оплачивается как два события.

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

Плата за подключение взимается только при использовании протокола AMQP. Плата за подключение при отправке событий с помощью HTTP не взимается независимо от числа отправляющих систем или устройств. Если планируется использовать AMQP (например, для достижения более эффективной потоковой передачи событий или включения двусторонней связи в сценариях управления Интернетом вещей), то ознакомьтесь со сведениями о ценах на Центры событий, чтобы узнать, сколько подключений доступно на каждом уровне служб.

Функция записи активируется, когда ее включают в любом концентраторе событий пространства имен. Сбор центров событий взимается ежемесячно за единицу приобретенной пропускной способности. Так как количество единиц пропускной способности может увеличиваться или уменьшаться, стоимость каждого часа использования функции записи в службе "Центры событий" рассчитывается отдельно. Дополнительные сведения о выставлении счетов за использование функции "Сбор" в Центрах событий см. на этой странице.

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

Список всех квот для Центров событий см. в статье Квоты для Центров событий.

При удалении пространства имен из подписки подождите 4 часа, прежде чем создать его заново с тем же именем в другой подписке. В противном случае может появиться следующее сообщение об ошибке: Namespace already exists

Список возможных исключений Центров событий приведен в статье Исключения обмена сообщениями Центров событий.

Центры событий поддерживают два типа журналов диагностики — журналы ошибок функции "Сбор" и операционные журналы. Оба типа представлены в формате JSON и могут быть включены на портале Azure.

Техническая поддержка для концентраторов событий доступна на Странице Майкрософт с вопросами и ответами для Служебной шины Azure. Поддержка по вопросам выставления счетов и управления подписками предоставляется бесплатно.

Дополнительные сведения о соглашении об уровне обслуживания см. на странице Соглашения об уровне обслуживания.

Запустив этот код в Azure Stack Hub, вы получите ошибки выполнения, если не укажете конкретную версию API службы хранилища. Это связано с тем, что пакет SDK центров событий использует последние доступные служба хранилища Azure API, доступные в Azure, которые могут быть недоступны на платформе Azure Stack Hub. Azure Stack Hub может поддерживать другую версию пакета SDK для BLOB-объектов хранилища, чем обычно доступно в Azure. Если вы используете Хранилище BLOB-объектов Azure в качестве хранилища контрольных точек, проверьте поддерживаемую версию API службы хранилища Azure для сборки Azure Stack Hub и включите эту версию в код.

Например, если вы используете Azure Stack Hub версии 2005, последней доступной версией для службы хранилища будет версия 2019-02-02. По умолчанию клиентская библиотека пакета SDK для Центров событий использует последнюю доступную версию в Azure (2019-07-07 на момент выпуска пакета SDK). В таком случае, кроме действий, описанных в этом разделе, вам нужно добавить код для указания API службы хранилища версии 2019-02-02. Сведения о включении поддержки определенной версии API службы хранилища см. в следующих примерах для C#, Java, Python и JavaScript/TypeScript.

Сведения о включении поддержки определенной версии API службы хранилища с помощью кода см. в следующих примерах на GitHub:

• .NET
• Java
• Python — синхронный, асинхронный.
• JavaScript и TypeScript.

Следующие шаги

Дополнительные сведения о Центрах событий см. в следующих источниках:

• Общие сведения о Центрах событий
• Создание концентратора событий
• Автоматическое расширение Центров событий