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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AMQP

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

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.

Если вы используете пространство имен, размещенное в более старом кластере (основанное на Cloud Services — 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. Для этого создайте пространство имен Центров событий и получите строку подключения. Измените bootstrap.servers, чтобы он содержало полное доменное имя (FQDN) Центров событий, и порт на 9093. Обновите sasl.jaas.config, чтобы направить клиент Kafka к конечной точке Event Hubs (которая является полученной строкой подключения) с корректной аутентификацией, как показано здесь:

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 КБ, которые могут проходить через Центр событий. Пропускная способность измеряется в единицах пропускной способности (TUs). Приобретите TUs перед началом использования службы Event Hubs. Единицы пропускной способности для Центров событий вы можете указать явным образом с помощью портала Azure или шаблонов Resource Manager для Центров событий.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   

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

   

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

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

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

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

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

Почему устаревший кластер выделенного типа с избыточностью между зонами имеет минимальное количество в восемь вычислительных единиц?

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

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

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

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

• Стандартный уровень: 1 МБ/с входящего трафика и около 2 МБ/с исходящего трафика на секцию.
• Уровни "Премиум" и "Выделенные": 1–2 МБ/с входящего трафика и 2–5 МБ/с исходящего трафика на раздел.

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

Разделы также задают потолок для параллелизма потребителей. Принцип работы потолка зависит от типа потребителя:

• Потребители эпохи (эксклюзивные) — используется EventProcessorClient (.NET, Java) и EventHubConsumerClient (Python, JavaScript), что является рекомендуемым шаблоном для рабочих нагрузок AMQP. Только один потребитель эпохи может принадлежать заданной секции в группе потребителей одновременно. Если развертывать больше экземпляров процессора, чем разделов, дополнительные экземпляры не назначаются ни одному разделу и бездействуют до тех пор, пока существующий владелец не освободит один из них. Если новый потребитель подключается к более высокому уровню владения, служба отключает текущего владельца с ошибкой ConsumerDisconnected, и новый потребитель становится владельцем.
• Потребители без эпохи — до 5 получателей без эпохи могут одновременно считывать один раздел в группе потребителей. Каждый получатель видит одни и те же события (размыкание), поэтому этот режим не увеличивает пропускную способность обработки на секцию. Подключение потребителя эпохи к секции отключает всех потребителей, не относящихся к эпохе, в этой секции.
• Потребители Kafka — потребители Kafka используют протокол координации группы (group.id) вместо эпох AMQP, но модель владения секциями эквивалентна: каждая секция назначается ровно одному члену потребителя в группе потребителей одновременно. Когда новый участник присоединяется или существующий участник выходит, группа балансирует заново и перераспределяет назначения разделов. Если участников больше, чем разделов, избыточные участники не получают назначений и остаются бездействовать до тех пор, пока будущая перебалансировка не освободит раздел. Чтобы уменьшить ненужное перебалансирование, вызванное временными отключениями, задайте уникальный group.instance.id для каждого экземпляра потребителя (статическое членство).

На практике число партиций равно максимальному количеству параллельных потребителей на каждую группу потребителей, независимо от того, используются ли epoch потребители AMQP или Kafka потребители. Учитывайте это число секций при планировании горизонтального масштабирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Запустив этот код в Azure Stack Hub, вы получите ошибки выполнения, если не укажете конкретную версию API службы хранилища. Это связано с тем, что пакет SDK для центров событий использует самую последнюю доступную версию API службы хранилища Azure в 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.

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

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

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