Perguntas frequentes sobre Hubs de Eventos

Um namespace é um contêiner de escopo para hubs de eventos ou tópicos do Kafka. Dá-lhe um FQDN único. Um namespace serve como um contêiner de aplicativo que pode abrigar vários hubs de eventos ou tópicos do Kafka.

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

As unidades de taxa de transferência (TUs) ou unidades de processamento (PUs) 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 Eventos do Azure fornece recursos além do que está disponível na camada Básica. Os seguintes recursos estão incluídos no Standard:

• Maior retenção de eventos
• Ligações intermediadas adicionais, com uma taxa de excesso de idade para mais do que o número incluído
• Mais do que um único grupo de consumidores
• Captura
• Integração Kafka

Para obter mais informações sobre níveis de preços, incluindo Hubs de Eventos Dedicados, consulte os detalhes de preços dos Hubs de Eventos.

Os Hubs de Eventos do Azure estão disponíveis em todas as regiões do Azure suportadas. Para obter uma lista, visite a página de regiões do Azure.

Sim, desde que todos os hubs de eventos estejam no mesmo namespace.

Atualmente, a camada padrão dos Hubs de Eventos oferece suporte a um período máximo de retenção de sete dias, enquanto para as camadas premium e dedicada, esse limite é de 90 dias. Os hubs de eventos não se destinam a ser um armazenamento de dados permanente. Períodos de retenção superiores a 24 horas destinam-se a cenários em que é conveniente reproduzir um fluxo de eventos nos mesmos sistemas. Por exemplo, para treinar ou verificar um novo modelo de aprendizado de máquina em dados existentes. Se você precisar de retenção de mensagens além de sete dias, habilitar a Captura de Hubs de Eventos no hub de eventos extrai os dados do hub de eventos para a conta de Armazenamento ou para a conta do Serviço Azure Data Lake de sua escolha. Ativar o Capture incorre em uma cobrança com base nas unidades de taxa de transferência 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 Azure oferece uma política avançada e baseada em regras para contas de armazenamento de blob e v2 de uso geral. Use a política para fazer a transição de seus dados para as camadas de acesso apropriadas ou expirar no final do ciclo de vida dos dados. Para obter mais informações, consulte Gerenciar o ciclo de vida do armazenamento de Blob do Azure.

Os Hubs de Eventos emitem métricas exaustivas que fornecem o estado dos seus recursos ao Azure Monitor. Eles também permitem avaliar a integridade geral do serviço Hubs de Eventos não apenas no nível do namespace, mas também no nível da entidade. Saiba mais sobre o 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 nela na região selecionada ao criar um espaço de nome de Hubs de Eventos. Por padrão, os dados do cliente permanecem nessa região. Quando a recuperação de desastres geográficos é configurada para um namespace de Hubs de Eventos do Azure, os metadados são copiados para a região secundária selecionada. Portanto, esse serviço satisfaz automaticamente os requisitos de residência de dados da região, incluindo os especificados na Central de Confiabilidade.

Que protocolos posso usar para enviar e receber eventos?

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

Os consumidores ou recetores usam AMQP ou Kafka para receber eventos de um hub de eventos. Os Hubs de Eventos suportam apenas o modelo pull para que os consumidores recebam eventos dele. Mesmo quando você usa manipuladores de eventos para manipular eventos de um hub de eventos, o processador de eventos usa internamente o modelo pull para receber eventos do hub de eventos.

AMQP

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

HTTPS/REST API

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

Apache Kafka

Os Hubs de Eventos do Azure têm um ponto de extremidade Kafka incorporado que suporta produtores e consumidores Kafka. Os aplicativos criados usando Kafka podem usar o protocolo Kafka (versão 1.0 ou posterior) para enviar e receber eventos de 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.

Que portas preciso abrir no firewall?

Você pode usar os seguintes protocolos com os Hubs de Eventos do Azure para enviar e receber eventos:

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

Consulte a tabela a seguir para obter 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 é necessária para comunicação de saída também quando o AMQP é usado pela porta 5671, porque várias operações de gerenciamento executadas pelos SDKs do cliente e a aquisição de tokens do Microsoft Entra ID (quando usado) são executadas por HTTPS.

Os SDKs oficiais do Azure geralmente usam o protocolo AMQP para enviar e receber eventos de Hubs de Eventos. A opção de protocolo AMQP-over-WebSockets é executada pela porta TCP 443 tal como a API HTTP, mas é funcionalmente idêntica à AMQP simples. Esta opção tem maior latência de conexão inicial devido a viagens de ida e volta extras de handshake e um pouco mais de sobrecarga como compensação para compartilhar a porta HTTPS. Se este modo estiver selecionado, a porta TCP 443 é suficiente para comunicação. As opções a seguir permitem selecionar o modo AMQP ou AMQP WebSockets simples:

Que endereços IP devo permitir?

Quando você está trabalhando com o Azure, às vezes você precisa 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 por Hubs de Eventos. Para endereços IP usados pelos Hubs de Eventos do Azure: consulte Intervalos de IP do Azure e Tags de Serviço - Nuvem Pública.

Além disso, verifique se o endereço IP do seu namespace é permitido. Para encontrar os endereços IP certos para permitir suas conexões, siga estas etapas:

1. Execute o seguinte comando a partir de uma linha de comandos:

   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 em Serviços de Nuvem - CNAME terminando em *.cloudapp.net) e o namespace for redundante de zona, será necessário seguir algumas etapas extras. Se o namespace estiver em um cluster mais recente (baseado no Conjunto de Escala de Máquina Virtual - CNAME terminando em *.cloudapp.azure.com) e zona redundante, você poderá ignorar as etapas abaixo.

1. Primeiro, você executa nslookup no namespace.

   nslookup <yournamespace>.servicebus.windows.net
   

2. Anote o nome na seção de resposta não autorizada, 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 os 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,

   Nota

   O endereço IP retornado pelo nslookup comando 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.

Quais IPs de cliente estão enviando ou recebendo eventos do meu namespace?

Primeiro, habilite a filtragem de IP no namespace.

Em seguida, habilite os logs de diagnóstico para eventos de conexão de rede virtual de Hubs de Eventos seguindo as instruções em Habilitar logs de diagnóstico. Você vê o endereço 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 no Apache Kafka existentes. Uma alteração de configuração é tudo o que é necessário para ter a experiência PaaS Kafka. Ele fornece uma alternativa para executar seu próprio cluster Kafka. Os Hubs de Eventos suportam Apache Kafka 1.0 e versões de cliente mais recentes e funcionam com seus aplicativos, ferramentas e estruturas Kafka existentes. Para obter mais informações, consulte Hubs de eventos para Kafka repo.

Para se conectar a um hub de eventos, você precisará atualizar as configurações do cliente Kafka. Isso é feito criando um namespace de Hubs de Eventos e obtendo a cadeia de conexão. Altere o bootstrap.servers para apontar o FQDN dos Hubs de Eventos e a porta para 9093. Atualize o sasl.jaas.config para direcionar o cliente Kafka para o ponto de extremidade dos Hubs de Eventos (que é a cadeia de conexão que você obteve), com 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 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 através dos Hubs de Eventos. Essa taxa de transferência é medida em unidades de taxa de transferência (TUs). Compre TUs antes de começar a usar o serviço Hubs de Eventos. Você pode selecionar explicitamente os TUs dos Hubs de Eventos usando os modelos do Portal ou do Gerenciador de Recursos dos Hubs de Eventos.

Sim, as unidades de taxa de transferência (TUs) se aplicam a todos os hubs de eventos em um namespace de Hubs de Eventos. Isso significa que você compra TUs no nível de namespace e são compartilhados entre os hubs de eventos sob esse namespace. Cada TU dá direito ao namespace aos 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 de 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 de 4.096 eventos de saída.
• Até 84 GB de armazenamento de eventos (o suficiente para o período de retenção padrão de 1 hora).

As unidades de taxa de transferência (TUs) são cobradas por hora. A faturação baseia-se no número máximo de unidades selecionadas durante uma determinada hora.

Você pode iniciar tão baixo quanto uma unidade de taxa de transferência (TU) e ativar a autoinsuflação. A funcionalidade de insuflação automática permite-lhe aumentar os seus TUs à medida que o seu tráfego/carga útil aumenta. Você também pode definir um limite máximo para o número de TUs.

O recurso de autoinflação permite aumentar a escala de suas unidades de taxa de transferência (TUs). Isso significa que você pode começar comprando TUs baixos e aumentar automaticamente suas TUs à medida que sua entrada aumenta. Ele oferece uma opção econômica e controle completo do número de TUs para gerenciar. Esse recurso é um recurso somente de expansão, e você pode controlar completamente a redução do número de TUs atualizando-o.

Você pode querer começar com unidades de baixa taxa de transferência (TUs), por exemplo, 2 TUs. Se você prevê que seu tráfego pode crescer para 15 TUs, habilite o recurso de inflação automática em seu namespace e defina o limite máximo para 15 TUs. Agora você pode aumentar seus TUs automaticamente à medida que seu tráfego cresce.

Não há custo associado a esse recurso.

Atualmente, 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 de hub de eventos são criados.

Se a taxa de transferência de entrada total ou a taxa de eventos de entrada total em todos os hubs de eventos em um namespace exceder as permissões de unidade de taxa de transferência agregada, os remetentes serão limitados e receberão erros indicando que a cota de entrada foi excedida.

Se a taxa de transferência total de saída ou a taxa de saída total de eventos em todos os hubs de eventos em um namespace exceder as permissões de unidade de taxa de transferência agregada, os recetores 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 diminua, nem um recetor possa impedir que eventos sejam enviados para um hub de eventos.

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

Hubs de Eventos Os clusters dedicados oferecem implantações de locatário único para clientes com requisitos mais exigentes. Essa oferta cria um cluster baseado em capacidade que não está vinculado por unidades de taxa de transferência. Isso significa que você pode usar o cluster para ingerir e transmitir seus dados conforme ditado pela CPU e pelo uso de memória do cluster. Para obter mais informações, consulte Hubs de eventos Clusters dedicados.

Para obter instruções passo a passo e mais informações sobre como configurar um cluster dedicado de Hubs de Eventos, consulte Guia de início rápido: criar um cluster de Hubs de Eventos dedicado usando o portal do Azure.

O que posso alcançar 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 benchmark que obtivemos durante nossos testes com um cluster dedicado legado.

Nos testes, foram utilizados os seguintes critérios:

• Foi utilizado um cluster de Hubs de Eventos de camada dedicada com quatro UCs.
• O hub de eventos usado para ingestão tinha 200 partições.
• Os dados que foram ingeridos foram recebidos por dois aplicativos recetores recebendo de todas as partições.

Posso aumentar ou reduzir a escala do meu cluster?

Se você criar o cluster com o conjunto de opções de dimensionamento de suporte, poderá usar a experiência de autoatendimento para expandir e dimensionar, conforme necessário. Você pode escalar até 10 CUs com clusters escaláveis de autoatendimento. Os clusters dedicados escaláveis de autoatendimento são baseados em uma nova infraestrutura, portanto, têm um desempenho melhor do que os clusters dedicados que não oferecem 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 UCs depois de testar com uma carga de trabalho real.

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

• Você precisa de mais de 10 CUs para um cluster dedicado escalável de autoatendimento (um cluster que foi criado com o conjunto de opções de dimensionamento de suporte).
• Você precisa expandir ou dimensionar em um cluster que foi criado sem selecionar a opção Dimensionamento de suporte.
• Você precisa expandir ou dimensionar em um cluster dedicado que foi criado antes da experiência de autoatendimento ser lançada.

Posso migrar de um cluster herdado para um cluster escalá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 oferecem suporte ao dimensionamento de autoatendimento para clusters dedicados escaláveis de autoatendimento. Se quiser usar o dimensionamento de autoatendimento, você deve recriar o cluster. Para saber como criar um cluster escalável, consulte Criar um cluster dedicado de Hubs de Eventos.

Quando devo dimensionar meu cluster dedicado?

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

Para monitorizar a utilização da CPU do cluster dedicado, siga estes passos:

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 a agregação.

   

3. Selecione Adicionar filtro e adicione um filtro para o Tipo de propriedade Função. Use o operador equal e selecione todos os valores (Backend e Gateway) na lista suspensa.

   

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

Como funciona a recuperação de desastres geográficos com meu cluster?

Você pode emparelhar geograficamente um namespace em um cluster de camada dedicada com outro namespace em um cluster de camada dedicada. Não incentivamos o emparelhamento de 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 oferecemos suporte a um processo de migração automatizado para migrar seus dados de Hubs de Eventos de um namespace Standard ou Premium para um namespace dedicado.

Por que um cluster dedicado com redundância de zona herdada tem um mínimo de 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 suporta 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 esta quota. É uma restrição da arquitetura atual com uma camada dedicada.

Como partição é um mecanismo de organização de dados que permite publicar e consumir dados de forma paralela. Recomendamos que você equilibre unidades de dimensionamento (unidades de taxa de transferência para a camada padrão, unidades de processamento para a camada premium ou unidades de capacidade para a camada dedicada) e partições para obter a escala ideal. Em geral, recomendamos uma taxa de transferência máxima de 1 MB/s por partição. Portanto, uma regra prática 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 requer 20 MB/s, recomendamos que você escolha pelo menos 20 partições para alcançar a taxa de transferência ideal.

No entanto, se você tiver um modelo no qual seu aplicativo tenha afinidade com uma partição específica, aumentar o número de partições não é benéfico. Para obter mais informações, consulte disponibilidade e consistência.

Não, 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 apenas em camadas premium e dedicadas de Hubs de Eventos.

Para obter informações completas 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 períodos de retenção de mensagens superiores a 24 horas, por um máximo de sete dias. Se o tamanho do número total de eventos armazenados exceder a permissão de armazenamento para o número de unidades de taxa de transferência selecionadas (84 GB por unidade de taxa de transferência), o tamanho que exceder a permissão será cobrado pela taxa de armazenamento de Blob do Azure publicada. A franquia de armazenamento em cada unidade de rendimento cobre todos os custos de armazenamento para períodos de retenção de 24 horas, mesmo que a unidade de taxa de transferência seja usada até a permissão máxima de entrada.

O tamanho total de todos os eventos armazenados, incluindo qualquer sobrecarga interna para cabeçalhos de eventos ou em estruturas de armazenamento em disco em todos os hubs de eventos, é medido ao longo do dia. No final do dia, é calculado o tamanho de armazenamento máximo. A concessão de armazenamento diário é calculada com base no número mínimo de unidades de débito que foram selecionadas durante o dia (cada unidade de débito fornece uma concessão de 84 GB). Se o tamanho total exceder a franquia de armazenamento diária calculada, o armazenamento excedente será cobrado usando as taxas de armazenamento de Blob do Azure (na taxa de Armazenamento Localmente Redundante).

Cada evento enviado para 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 com tamanho menor ou igual a 64 KB é considerado um evento faturável. Se o evento for maior que 64 KB, o número de eventos faturáveis é calculado de acordo com o tamanho do evento, em múltiplos de 64 KB. Por exemplo, um evento de 8 KB enviado para o hub de eventos é cobrado como um evento, mas uma mensagem de 96 KB enviada para o hub de eventos é cobrada como dois eventos.

Os eventos consumidos de um hub de eventos e as operações de gerenciamento e chamadas de controle, como pontos de verificação, não são contados como eventos de entrada faturáveis, mas acumulados até a franquia de unidade de taxa de transferência.

As taxas de conexão aplicam-se somente quando o protocolo AMQP é usado. Não há custos de ligação para o envio de eventos por HTTP, independentemente do número de sistemas ou dispositivos de envio. Se você planeja usar o AMQP (por exemplo, para obter streaming de eventos mais eficiente ou para habilitar a comunicação bidirecional em cenários de comando e controle de IoT), consulte a página de informações de 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 é habilitada quando qualquer hub de eventos no namespace tem a opção Capturar habilitada. A Captura de Hubs de Eventos é cobrada mensalmente por unidade de taxa de transferência comprada. À medida que a contagem de unidades de taxa de transferência é aumentada ou diminuída, o faturamento da Captura de Hubs de Eventos reflete essas alterações em incrementos de horas inteiras. Para obter mais informações sobre o faturamento da Captura de Hubs de Eventos, consulte Informações de preços dos Hubs de Eventos.

O Capture usa uma conta de armazenamento fornecida quando habilitada em um hub de eventos. Como é sua conta de armazenamento, todas as alterações para essa configuração são cobradas em sua assinatura do Azure.

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

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

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

Os Hubs de Eventos dão suporte a dois tipos de logs de diagnóstico - Capturar logs de erro e logs operacionais - ambos representados em json e podem ser ativados por meio do portal do Azure.

O suporte técnico para Hubs de Eventos está disponível através da página de perguntas e respostas da Microsoft para o Barramento de Serviço do Azure. O suporte de gestão da faturação e subscrição é fornecido sem custos.

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

Se você executar esse código no Azure Stack Hub, enfrentará erros de tempo de execução, a menos que tenha como alvo uma versão específica da API de Armazenamento. Isso ocorre porque o SDK de Hubs de Eventos usa a API de Armazenamento do Azure mais recente disponível no Azure que pode não estar disponível em sua plataforma Azure Stack Hub. O Azure Stack Hub pode dar suporte a uma versão diferente do SDK de Blob de Armazenamento do que normalmente está disponível no Azure. Se você estiver usando o Armazenamento de Blog do Azure como um armazenamento de ponto de verificação, verifique a versão da API de Armazenamento do Azure com suporte para sua compilação do Azure Stack Hub e direcione essa versão em seu código.

Por exemplo, se você estiver executando no Azure Stack Hub versão 2005, a versão mais alta disponível para o serviço de Armazenamento é a versão 2019-02-02. Por padrão, a biblioteca de cliente 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 nesta seção, você também precisará adicionar código para direcionar a API do serviço de armazenamento versão 2019-02-02. Para obter um exemplo de como direcionar uma versão específica da API de armazenamento, consulte os exemplos a seguir para C#, Java, Python e JavaScript/TypeScript.

Para obter um exemplo de como direcionar uma versão específica da API de armazenamento do seu código, consulte os seguintes exemplos no GitHub:

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

Próximos passos

Pode saber mais sobre os Hubs de Eventos ao aceder às seguintes ligações:

• Descrição geral dos Hubs de Eventos
• Criar um Hub de Eventos
• Hubs de Eventos Inflar automaticamente