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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Протокол AMQP 1.0
• Протокол HTTP 1.1 с TLS (HTTPS)
• Apache Kafka

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

Если AMQP используется через порт 5671, то для исходящей связи требуется порт HTTPS, так как с использованием протокола HTTPS выполняются некоторые операции управления пакетами SDK клиентов, а также осуществляется получение токенов из службы Azure Active Directory (если они используются).

Официальный пакет 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.

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

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 час).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Выберите CPU в качестве метрики и используйте в Max качестве агрегата.

  

• Затем выберите Добавить фильтр и добавьте фильтр для типа Roleсвойства , используйте оператор equal и выберите все три значения(Backend, Gateway) из раскрывающегося списка.

  

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

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

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

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

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

Почему выделенный кластер с избыточностью между зонами имеет минимум 8 CU?

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

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

Так как секция — это механизм организации данных, позволяющий параллельно публиковать и использовать данные, рекомендуем сбалансировать единицы масштабирования (единицы пропускной способности, единицы обработки или единицы емкости) и секции для достижения оптимального масштаба. Как правило, рекомендуется использовать максимальную пропускную способность 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.

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

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

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