Perguntas frequentes sobre os Hubs de Eventos

Um namespace é um contêiner de escopo para hubs de eventos ou tópicos do Apache Kafka. Ele fornece a você um FQDN único. Um namespace serve como um contêiner de aplicativo que pode hospedar vários hub de eventos ou tópicos do Kafka.

Não. Uma vez implantado, não é possível alterar (por exemplo) da camada padrão para a camada premium sem implantar um novo recurso.

As TUs (unidades de produtividade) ou PUs (unidades de processamento) de alocações de capacidade são cobradas no nível do namespace. Um namespace também está associado a uma região.

Talvez você queira criar um novo namespace em vez de usar um existente em um dos seguintes cenários:

• Você precisa de um hub de eventos associado a uma nova região.
• Você precisa de um hub de eventos associado a uma assinatura diferente.
• Você precisa de um hub de eventos com uma alocação de capacidade distinta (ou seja, a necessidade de capacidade para o namespace com o hub de eventos adicionado excederia o limite de 40 TU e você não deseja ir para o cluster dedicado).``

A camada Standard dos Hubs de Evento do Azure fornece recursos além daqueles disponíveis na camada Básica. Os recursos abaixo estão incluídos na camada Standard:

• Maior retenção de evento
• Conexões agenciadas adicionais, com uma taxa excedente para além do número incluído
• Mais de um único grupo de consumidores
• Captura
• Integração com Kafka

Para obter mais informações sobre tipos de preço, incluindo Hubs de Eventos Dedicados, veja os Detalhes de preços dos Hubs de Eventos.

Os Hubs de Eventos do Azure está disponível em todas as regiões do Azure com suporte. Para obter uma lista, visite a página Regiões do Azure.

Sim, contanto que todos os Hubs de Eventos estejam no mesmo namespace.

Atualmente, a camada Standard dos Hubs de Eventos dá suporte a um período máximo de retenção de sete dias, enquanto para a camada Premium e dedicada esse limite é de 90 dias. Os Hubs de Eventos não servem como um armazenamento de dados permanente. Períodos de retenção maiores que 24 horas são destinados a cenários em que é conveniente reproduzir um fluxo de eventos nos mesmos sistemas. Por exemplo, para treinar ou verificar um novo modelo de machine learning com base nos dados existentes. Se você precisar de retenção de mensagens por mais de sete dias, a habilitação da Captura de Hubs de Eventos efetuará pull dos dados do hub de eventos para a conta de armazenamento ou conta de serviço do Azure Data Lake de sua escolha. A habilitação da Captura acarretará uma cobrança com base nas unidades de produtividade compradas.

Você pode configurar o período de retenção para os dados capturados em sua conta de armazenamento. O recurso de gerenciamento do ciclo de vida do Armazenamento do Microsoft Azure oferece uma política avançada baseada em regras para contas de armazenamento de Blobs V2 e de uso geral. Use a política para fazer a transição de seus dados para as camadas de acesso apropriadas ou expirá-los ao final do ciclo de vida dos dados. Para obter mais informações, confira Gerenciar o ciclo de vida do armazenamento de Blobs do Azure.

Os Hubs de Eventos emitem métricas exaustivas que fornecem o estado de seus recursos ao Azure Monitor. Eles também permitem a avaliação da integridade geral do serviço do Hubs de Eventos, não apenas no nível do namespace, mas também no nível da entidade. Saiba qual monitoramento é oferecido para os Hubs de Eventos do Azure.

As camadas padrão, premium e dedicada dos Hubs de Eventos do Azure armazenam e processam dados publicados nele na região selecionada ao criar um espaço de nome dos Hubs de Eventos. Por padrão, os dados do cliente permanecem dentro dessa região. Quando a recuperação de desastre geográfico é configurada para um namespace de Hubs de Eventos do Azure, os metadados são copiados para a região secundária que você selecionar. Portanto, esse serviço atende automaticamente aos requisitos de residência de dados da região, incluindo os especificados na Central de Confiabilidade.

Quais protocolos posso usar para enviar e receber eventos?

Produtores ou remetentes podem usar protocolos Advanced Messaging Queuing Protocol (AMQP), Kafka ou HTTPS para enviar eventos para um hub de eventos.

Consumidores ou receptores usam AMQP ou Kafka para receber eventos de um hub de eventos. Os Hubs de Eventos são compatíveis apenas com o modelo de pull para que os consumidores recebam eventos dele. Mesmo quando você usa manipuladores de eventos para lidar com eventos de um hub de eventos, o processador de eventos usa internamente o modelo de pull para receber eventos do hub de eventos.

AMQP

Você pode usar o protocolo AMQP 1.0 para enviar eventos e receber eventos dos Hubs de Eventos do Azure. O AMQP fornece comunicação confiável, de desempenho e segura para enviar e receber eventos. Você pode usá-lo para streaming de alto desempenho e em tempo real e é compatível com a maioria dos SDKs dos Hubs de Eventos do Azure.

HTTPS/API REST

Você só pode enviar eventos para Hubs de Eventos usando solicitações HTTP POST. Os Hubs de Eventos não dão suporte ao recebimento de eventos via HTTPS. É adequado para clientes leves em que uma conexão TCP direta não é viável.

Apache Kafka

Os Hubs de Eventos do Azure têm um ponto de extremidade do Kafka interno que dá suporte a produtores e consumidores do Kafka. Os aplicativos criados por meio do Kafka podem usar o protocolo Kafka (versão 1.0 ou posterior) para enviar e receber eventos dos Hubs de Eventos sem alterações de código.

Os SDKs do Azure abstraem os protocolos de comunicação subjacentes e fornecem uma maneira simplificada de enviar e receber eventos de Hubs de Eventos usando linguagens como C#, Java, Python, JavaScript etc.

Quais portas preciso abrir no firewall?

É possível usar os seguintes protocolos com os Hubs de Eventos do Azure para enviar e receber eventos:

• Advanced Message Queuing Protocol 1.0 (AMQP)
• Protocolo de Transferência de Hipertexto individual com Segurança da Camada de Transporte (HTTPS)
• Apache Kafka

Consulte a tabela a seguir para as portas de saída que você precisa abrir para usar esses protocolos para se comunicar com os Hubs de Eventos do Azure.

A porta HTTPS também é necessária para a comunicação de saída quando o AMQP é usado pela porta 5671, pois várias operações de gerenciamento executadas pelos SDKs do cliente e pela aquisição de tokens de Microsoft Entra ID (quando usado) são executadas em HTTPS.

Geralmente, os SDKs oficiais do Azure usam o protocolo AMQP para enviar e receber eventos dos Hubs de eventos. A opção de protocolo AMQP-over-WebSockets é executada na porta TCP 443 da mesma forma que o API HTTP, mas sua funcionalidade é idêntica à do AMQP simples. Essa opção tem uma latência de conexão inicial maior devido às idas e voltas extras de handshake e um pouco mais de sobrecarga como compensação para o compartilhamento da porta HTTPS. Se esse modo estiver selecionado, a porta TCP 443 será suficiente para a comunicação. As opções a seguir permitem selecionar o modo AMQP simples ou AMQP WebSockets:

Quais endereços IP preciso permitir?

Quando você está trabalhando com o Azure, às vezes é preciso permitir intervalos de endereços IP específicos ou URLs em seu firewall corporativo ou proxy para acessar todos os serviços do Azure que você está usando ou tentando usar. Verifique se o tráfego é permitido em endereços IP usados pelos Hubs de Eventos. Para endereços IP usados pelos Hubs de Eventos do Azure: consulte Intervalos de IP e marcas de serviço do Azure – Nuvem pública.

Além disso, verifique se o endereço IP do seu namespace é permitido. Para localizar os endereços IP corretos a fim de permitir suas conexões, siga estas etapas:

1. Execute o seguinte comando de um prompt de comando:

   nslookup <YourNamespaceName>.servicebus.windows.net
   

2. Anote o endereço IP retornado em Non-authoritative answer.

Se você usar um namespace hospedado em um cluster mais antigo (baseado nos Serviços de Nuvem – CNAME terminando em *.cloudapp.net) e o namespace tiver redundância de zona, precisará seguir algumas etapas adicionais. Se o seu namespace está em um cluster mais recente (baseado em Conjunto de Dimensionamento de Máquinas Virtuais – CNAME terminando em *.cloudapp.azure.com) e é redundante em zonas, você pode pular as etapas abaixo.

1. Primeiro, execute nslookup no namespace.

   nslookup <yournamespace>.servicebus.windows.net
   

2. Anote o nome na seção resposta não autoritativa, que está em um dos seguintes formatos:

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

3. Execute nslookup para cada um com sufixos s1, s2 e s3 para obter os endereços IP de todas as três instâncias em execução em três zonas de disponibilidade,

   Observação

   O endereço IP retornado pelo comando nslookup não é um endereço IP estático. No entanto, ele permanece constante até que a implantação subjacente seja excluída ou movida para um cluster diferente.

Que IPs de cliente estão enviando ou recebendo eventos do meu namespace e para ele?

Primeiro, habilite a filtragem de IP no namespace.

Em seguida, habilite os logs de diagnóstico para Eventos de conexão de rede virtual dos Hubs de Eventos seguindo as instruções em Habilitar logs de diagnóstico. Você verá o endereço de IP para o qual a conexão é negada.

{
    "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"
}

Os Hubs de Eventos fornecem um ponto de extremidade Kafka que pode ser usado por seus aplicativos baseados em Apache Kafka existentes. Basta uma alteração de configuração para obter a experiência de PaaS Kafka. Ela fornece uma alternativa à execução de seu próprio cluster Kafka. Os Hubs de Eventos são compatíveis com o Apache Kafka 1.0 e com versões mais recentes do cliente e funcionam com seus aplicativos, ferramentas e estruturas existentes do Kafka. Para saber mais, confira Hubs de Eventos para repositório Kafka.

Para se conectar a um Hub de Eventos, você precisará atualizar as configurações de cliente do Kafka. Isso é feito por meio da criação de um namespace dos Hubs de Eventos e obtenção da cadeia de conexão. Altere o bootstrap.servers para apontar o FQDN de Hubs de Eventos e a porta para 9093. Atualize o sasl.jaas.config para direcionar o cliente do Kafka ao seu ponto de extremidade de Hubs de Eventos (que é a cadeia de conexão que você obteve), com a autenticação correta, conforme mostrado abaixo:

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}";

Exemplo:

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

O tamanho máximo de mensagem permitido para os Hubs de Eventos é de 1 MB.

A taxa de transferência nos Hubs de Eventos define a quantidade de dados em megabytes ou o número (em milhares) de eventos de 1 KB que entram e saem por meio dos Hubs de Eventos. Essa taxa de transferência é medida em unidades de produtividade (TUs). Compre TUs antes de começar a usar o serviço Hubs de Eventos. Seleciona explicitamente as TUs dos Hubs de Eventos usando o portal do Azure ou de modelos do Resource Manager dos Hubs de Eventos.

Sim, as TUs (unidades de produtividade) se aplicam a todos os hubs de eventos em um namespace dos Hubs de Eventos. Isso significa que você compra TUs no nível do namespace e elas são compartilhadas entre os hubs de eventos no namespace. Cada TU proporciona ao namespace os seguintes recursos:

• Até 1 MB por segundo de eventos de entrada (eventos enviados para um hub de eventos), mas não mais de 1.000 eventos de entrada, operações de gerenciamento ou chamadas à API de controle por segundo.
• Até 2 MB por segundo de eventos de saída (eventos consumidos de um Hub de Eventos), mas não mais do que 4,096 eventos de saída.
• Até 84 GB de armazenamento de eventos (suficiente para o período de retenção padrão de 1 hora).

As TUs (unidades de produtividade) são cobradas por hora. A cobrança é baseada no número máximo de unidades selecionado durante a hora determinada.

Você pode iniciar como TU (unidade de taxa de transferência) tão baixa quanto uma unidade de produtividade e ativar a inflação automática. O recurso de inflação automática permite aumentar suas TUs à medida que o tráfego/carga aumenta. Você também pode definir um limite superior de TUs.

O recurso de inflação automática permite escalar verticalmente suas TUs (unidades de produtividade). Isso significa que você pode começar comprando TUs baixas e aumentar automaticamente suas TUs à medida que a entrada aumenta. Isso proporciona uma opção econômica e controle total do número de TUs para gerenciamento. Esse recurso serve apenas para escalar verticalmente, e você pode controlar completamente a redução do número de TUs atualizando-o.

Talvez você queira começar com TUs (unidades de baixa produtividade), por exemplo, 2 TUs. Se você prever que o tráfego pode aumentar para 15 TUs, ative o recurso inflação automática em seu namespace e defina o limite máximo como 15 TUs. Agora, você pode aumentar suas TUs automaticamente conforme seu tráfego aumenta.

Não há custo associado a esse recurso.

No momento, isso não é possível porque os namespaces antigos dos Hubs de Eventos estão em clusters diferentes e não há como migrá-los para os novos clusters que habilitam automaticamente a redundância de zona quando novos namespaces do hub de eventos são criados.

Se a produtividade de entrada total ou a taxa de eventos de entrada total em todos os Hubs de Eventos em um namespace exceder os limites de unidades de produtividade totais agregados, os remetentes serão limitados e receberão erros indicando que a cota de entrada foi excedida.

Se a produtividade de saída total ou a taxa de eventos de saída total em todos os Hubs de Eventos em um namespace exceder os limites de unidades de produtividade agregados, os receptores serão limitados, mas nenhum erro de limitação será gerado.

As cotas de entrada e saída são aplicadas separadamente, para que nenhum remetente possa fazer com que o consumo de eventos se torne lento e para que um receptor não possa evitar que eventos sejam enviados para um Hub de Eventos.

Ao criar um namespace de camada básica ou standard no portal do Azure, você pode selecionar até 40 TUs para ele. Além dos 40 TUs, os Hubs de Eventos oferecem os modelos baseados em recursos/capacidade chamado de clusters de Hubs de Eventos Premium e Dedicados. Para obter mais informações, confira Hubs de Eventos Premium – visão geral e Hubs de Eventos Dedicados – visão geral.

Os clusters de Hubs de Eventos Dedicados oferecem implantações de locatário único para clientes com exigências mais rígidas. Essa oferta cria um cluster baseado em capacidade que não está associado por unidades de produtividade. Isso significa que você pode usar o cluster para ingerir e transmitir seus dados, conforme determinado pelo uso de CPU e memória do cluster. Para saber mais, confira Clusters dos Hubs de Eventos Dedicados.

Para ter um passo a passo e mais informações sobre como configurar um cluster de hubs de eventos dedicado, consulte o Início Rápido: Criar um cluster de Hubs de Eventos Dedicado usando o portal do Azure.

O que posso conseguir com um cluster?

Para um cluster de Hubs de Eventos, o quanto você pode ingerir e transmitir depende de fatores como seus produtores, consumidores e a taxa na qual você está ingerindo e processando.

A tabela a seguir mostra os resultados de parâmetro de comparação obtidos durante nossos testes com um cluster dedicado herdado.

Nos testes, foram usados os seguintes critérios:

• Um cluster de Hubs de Eventos de camada dedicada com quatro CUs foi usado.
• O hub de eventos usado para ingestão tinha 200 partições.
• Os dados ingeridos foram recebidos por dois aplicativos destinatários que recebem de todas as partições.

Posso escalar verticalmente ou reduzir verticalmente meu cluster?

Se você criar o cluster com a opção de dimensionamento de suporte definida, poderá usar a experiência de autoatendimento para escalar horizontalmente e dimensionar, conforme necessário. Você pode escalar verticalmente até dez CUs com clusters escalonáveis de autoatendimento. Os clusters dedicados escalonáveis de autoatendimento são baseados em uma nova infraestrutura, portanto, eles têm um desempenho melhor do que os clusters dedicados que não dão suporte ao dimensionamento de autoatendimento. O desempenho de clusters dedicados depende de fatores como alocação de recursos, número de partições e armazenamento. Recomendamos que você determine o número necessário de CUs depois de testar com uma carga de trabalho real.

Envie uma solicitação de suporte para escalar horizontalmente ou dimensionar em seu cluster dedicado nos seguintes cenários:

• Você precisa de mais de dez CUs para um cluster dedicado escalonável de autoatendimento (um cluster criado com o conjunto de opções de Dimensionamento de suporte).
• Você precisa escalar horizontalmente ou dimensionar em um cluster que foi criado sem selecionar a opção de dimensionamento de suporte.
• Você precisa escalar horizontalmente ou dimensionar em um cluster dedicado que foi criado antes do lançamento da experiência de autoatendimento.

Posso migrar de um cluster herdado para um cluster escalonável de autoatendimento?

Devido à diferença na infraestrutura de hardware e software subjacente, atualmente não oferecemos suporte à migração de clusters que não dão suporte ao dimensionamento de autoatendimento para autoatendimento de clusters dedicados escalonáveis. Se você quiser usar o dimensionamento de autoatendimento, será necessário recriar o cluster. Para saber como criar um cluster escalonável, consulte Criar um cluster dedicado dos Hubs de Eventos.

Quando devo dimensionar meu cluster dedicado?

O consumo de CPU é o principal indicador do consumo de recursos de seu cluster dedicado. Quando o consumo geral de CPU começa a atingir 70% (sem observar nenhuma condição anormal, como um alto número de erros de servidor ou um número baixo de solicitações bem-sucedidas), isso significa que o cluster está se movendo em direção à sua capacidade máxima. Você pode usar essas informações como um indicador para considerar se precisa escalar verticalmente o cluster dedicado ou não.

Para monitorar o uso da CPU do cluster dedicado, siga estas etapas:

1. Na página Métricas do cluster dedicado dos Hubs de Eventos, selecione Adicionar métrica.

2. Selecione CPU como a métrica e use Max como agregação.

   

3. Selecione Adicionar filtro e adicione um filtro para o tipo de Propriedade Função. Use o operador igual e selecione todos os valores (Back-end e Gateway) na lista suspensa.

   

   Em seguida, você pode monitorar essa métrica para determinar quando você deve escalar seu cluster dedicado. Você também pode configurar alertas contra essa métrica para ser notificado quando o uso da CPU atingir os limites definidos.

Como a recuperação de desastre geográfico funciona com meu cluster?

Você pode emparelhar geograficamente um namespace de um cluster de camada dedicada com outro namespace de cluster de camada dedicada. Não recomendamos emparelhar um namespace de camada dedicada com um namespace na oferta Standard porque o limite de taxa de transferência é incompatível e resulta em erros.

Posso migrar meus namespaces Standard ou Premium para um cluster de camada dedicada?

Atualmente, não há suporte para um processo de migração automatizado para migrar seus dados dos Hubs de Eventos de um namespace Standard ou Premium para um dedicado.

Por quê um cluster dedicado com redundância de zona tem no mínimo oito CUs?

Para fornecer redundância de zona para a oferta dedicada, todos os recursos de computação devem ter três réplicas em três datacenters na mesma região. Esse requisito mínimo dá suporte à redundância de zona (para que o serviço ainda possa funcionar quando duas zonas ou datacenters estão inativos) e resulta em uma capacidade de computação equivalente a oito CUs.

Não podemos alterar essa cota. É uma restrição da arquitetura atual com uma camada Dedicada.

Como a partição é um mecanismo de organização de dados que permite que você publique e consuma dados de maneira paralela. Recomendamos que você equilibre as unidades de dimensionamento (unidades de produtividade para a camada padrão, unidades de processamento para a camada Premium ou unidades de capacidade para a camada dedicada) e as partições para obter o dimensionamento ideal. Em geral, recomendamos uma taxa de transferência máxima de 1 MB/s por partição. Portanto, uma regra geral para calcular o número de partições seria dividir a taxa de transferência máxima esperada por 1 MB/s. Por exemplo, se o seu caso de uso exigir 20 MB/s, recomendamos que você escolha pelo menos 20 partições para obter a taxa de transferência ideal.

Contudo, se você tiver um modelo em que seu aplicativo tenha afinidade com uma partição específica, aumentar o número de partições não será benéfico. Para saber mais, confira disponibilidade e consistência.

Não, isso não é possível porque as partições são imutáveis na camada Standard. A adição dinâmica de partições está disponível somente nas camadas Premium e dedicada dos Hubs de Eventos.

Para obter todas as informações sobre os preços dos Hubs de Eventos, consulte os detalhes de preços dos Hubs de Eventos.

A camada Standard dos Hubs de Eventos permite a retenção de mensagens por períodos superiores a 24 horas, por um máximo de sete dias. Se o número total de eventos armazenados exceder o limite de armazenamento para o número de unidades de produtividade selecionadas (84 GB por unidade de produtividade), o tamanho que exceder o limite será cobrado com base na taxa de armazenamento de Blobs do Azure publicada. O limite de armazenamento em cada unidade de produtividade cobre todos os custos de armazenamento para períodos de retenção de 24 horas, mesmo que a unidade de produtividade seja usada até o limite máximo de entrada.

O tamanho total de todos os eventos armazenados, incluindo eventuais sobrecargas internas para cabeçalhos de eventos ou estruturas de armazenamento em disco em todos os Hubs de Eventos, é medido durante todo o dia. No final do dia, o tamanho do armazenamento de pico é calculado. O limite de armazenamento diário é calculado com base no número mínimo de unidades de produtividade que foram selecionadas durante o dia (cada unidade de produtividade fornece um limite de 84 GB). Se o tamanho total exceder o limite de armazenamento diário calculado, o armazenamento em excesso será cobrado usando as taxas de armazenamento de Blob do Azure (com base na taxa de armazenamento com redundância local ).

Cada evento enviado a um Hub de Eventos conta como uma mensagem faturável. Um evento de entrada é definido como uma unidade de dados menor ou igual a 64 KB. Qualquer evento menor ou igual a 64 KB de tamanho é considerado um evento faturável. Se o evento for maior que 64 KB, o número de eventos passíveis de cobrança será calculado de acordo com o tamanho do evento, em múltiplos de 64 KB. Por exemplo, um evento de 8 KB enviado ao Hub de Eventos é cobrado como um evento, mas uma mensagem de 96 KB enviada ao Hub de Eventos é cobrada como dois eventos.

Os eventos consumidos a partir de um hub de eventos, bem como as operações de gerenciamento e chamadas de controle (por exemplo, pontos de verificação), não são contados como eventos de entrada faturáveis, mas se acumulam até o limite da taxa da unidade de produtividade.

Cobranças de conexão são aplicadas somente quando o protocolo AMQP é usado. Não há cobranças de conexão para enviar eventos usando HTTP, independentemente do número de sistemas ou dispositivos remetentes. Se você pretende usar o AMQP (por exemplo, para obter transmissões de eventos mais eficientes ou para habilitar a comunicação bidirecional em cenários de comando e controle da IoT), consulte a página Informações sobre preços dos Hubs de Eventos para obter detalhes sobre quantas conexões estão incluídas em cada camada de serviço.

A Captura de Hubs de Eventos será habilitada quando qualquer Hub de Eventos no namespace tiver o recurso Captura habilitado. A Captura de Hubs de Eventos é cobrada mensalmente de acordo com a unidade de produtividade adquirida. À medida que a contagem das unidades de taxa de transferência aumentar ou diminuir, a cobrança da Captura de Hubs de Eventos refletirá essas mudanças em incrementos de hora cheia. Para obter mais informações sobre a cobrança da Captura de Hubs de Eventos, confira informações de preços de Hubs de Eventos.

A Captura usa uma conta de armazenamento fornecida quando habilitado em um Hub de Eventos. Como essa é sua conta de armazenamento, todas as alterações nessa configuração serão cobradas em sua assinatura do Azure.

Para obter uma lista de todas as cotas de Hubs de Eventos, consulte cotas.

Quando você exclui um namespace de uma assinatura, aguarde até 4 horas antes de recriá-lo com o mesmo nome em outra assinatura. Caso contrário, você poderá receber a seguinte mensagem de erro: Namespace already exists.

Para obter uma lista de exceções possíveis dos Hubs de Eventos, confira Visão geral das exceções.

Os Hubs de Eventos dão suporte a dois tipos de logs de diagnóstico – logs de erro de Captura e logs operacionais – ambos os quais são representados em json e podem ser ativados por meio do Portal do Azure.

O suporte técnico para Hubs de Eventos está disponível por meio da Página de perguntas e respostas da Microsoft para o Barramento de Serviço do Azure. O suporte para gerenciamento de assinaturas e cobranças é fornecido sem custo adicional.

Para saber mais sobre nosso SLA, veja a página Contratos de Nível de Serviço .

Se você executar esse código no Azure Stack Hub, haverá erros de runtime, a menos que você direcione uma versão específica da API de Armazenamento. Isso ocorre porque o SDK dos Hubs de Eventos usa a API de Armazenamento do Microsoft Azure disponível mais recente disponível no Azure que pode não estar disponível em sua plataforma do Azure Stack Hub. O Azure Stack Hub pode dar suporte a uma versão diferente do SDK do Blob de Armazenamento do que normalmente está disponível no Azure. Se estiver usando o Armazenamento de Blobs do Azure como um repositório de pontos de verificação, verifique a versão da API do Armazenamento do Microsoft Azure compatível com o compilado do Azure Stack Hub e tenha como destino essa versão no código.

Por exemplo, se a execução estiver sendo feita no Azure Stack Hub versão 2005, a versão mais recente disponível para o serviço de Armazenamento será a versão 2019-02-02. Por padrão, a biblioteca de clientes do SDK dos Hubs de Eventos usa a versão mais alta disponível no Azure (2019-07-07 no momento do lançamento do SDK). Nesse caso, além de seguir as etapas desta seção, você também precisará adicionar o código para ter como destino a versão de API 2019-02-02 do serviço de Armazenamento. Para obter um exemplo de como direcionar uma versão de API de armazenamento específica, confira os exemplos a seguir para C#, Java, Python e JavaScript/TypeScript.

Para obter um exemplo de como direcionar uma versão de API específica de armazenamento em seu código, confira estes exemplos no GitHub:

• .NET
• Java
• Python – Síncrono, Assíncrono
• JavaScript e TypeScript

Próximas etapas

Você pode saber mais sobre Hubs de Eventos visitando os links abaixo:

• Visão geral de Hubs de Eventos
• Criar um Hub de Eventos
• Inflar automaticamente de Hubs de Eventos