Perguntas frequentes sobre Hubs de Eventos

Geral

O que é um namespace de Hubs de Eventos do Azure?

Um namespace é um contêiner de escopo para hubs de eventos ou tópicos do Kafka. Fornece-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.

É possível alterar o nível de preços após a implantação?

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.

Quando crio um novo namespace versus uso um namespace existente?

As alocações de capacidade, unidades de taxa de transferência (TUs) ou unidades de processamento (PUs), são cobradas ao 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).''

Qual é a diferença entre as camadas básica e padrão dos Hubs de Eventos?

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:

• Retenção de eventos por mais tempo
• Ligações intermediadas adicionais, com uma taxa adicional por exceder 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.

Onde os Hubs de Eventos do Azure estão disponíveis?

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 Azure.

Posso usar uma única conexão AMQP (Advanced Message Queuing Protocol) para enviar e receber de vários hubs de eventos?

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

Qual é o período máximo de retenção para eventos?

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. A ativação do Capture acarretará uma cobrança com base nas unidades de capacidade de processamento adquiridas.

Você pode configurar o período de retenção para os dados capturados em sua conta de armazenamento. A funcionalidade de gestão do ciclo de vida do Armazenamento do Azure oferece uma política avançada e baseada em regras para contas de armazenamento de v2 de uso geral e de blob. 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.

Como faço para monitorar meus hubs de eventos?

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.

Onde os Hubs de Eventos do Azure armazenam dados?

As camadas padrão, premium e dedicada dos Hubs de Eventos do Azure armazenam e processam dados enviados para eles na região que você seleciona quando cria 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

O Hub de Eventos do Azure tem 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.

Protocolo	Portas	Detalhes
AMQP	5671 e 5672	Consulte o guia de protocolo AMQP
HTTPS	443	Esta porta é usada para a API HTTP/REST e para AMQP-over-WebSockets.
Kafka	9093	Consulte a seção Usar Hubs de Eventos em aplicações Kafka

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 uma maior latência de conexão inicial devido a ciclos adicionais de handshake e um pouco mais de sobrecarga, como compromisso para permitir o uso compartilhado da 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:

Linguagem	Opção
.NET	EventHubConnectionOptions.TransportType propriedade com EventHubsTransportType.AmqpTcp ou EventHubsTransportType.AmqpWebSockets
Java	com.microsoft.azure.eventhubs.EventProcessorClientBuilder.transporttype com AmqpTransportType.AMQP ou AmqpTransportType.AMQP_WEB_SOCKETS
Node	EventHubConsumerClientOptions tem uma webSocketOptions propriedade.
Python	EventHubConsumerClient.transport_type com TransportType.Amqp ou TransportType.AmqpOverWebSocket

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 utilizar um namespace hospedado num 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, ative os logs de diagnóstico para eventos de conexão de rede virtual de Hubs de Eventos conforme 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"
}

Importante

Os logs de rede virtual são gerados somente se o namespace permitir acesso a partir de endereços IP específicos (regras de filtro IP). Se você não quiser restringir o acesso ao seu namespace usando esses recursos e ainda quiser obter logs de rede virtual para rastrear endereços IP de clientes que se conectam ao namespace Hubs de Eventos, você pode usar a seguinte solução alternativa: Habilite a filtragem IP e adicione o intervalo IPv4 endereçável total (0.0.0.0/1 - 128.0.0.0/1) e o intervalo IPv6 ().::/1 - 8000::/1

Nota

Atualmente, não é possível determinar o IP de origem de uma mensagem ou evento individual.

Integração com Apache Kafka

Como faço para integrar meu aplicativo Kafka existente com Hubs de Eventos?

O Hub de Eventos fornece um ponto de extremidade Kafka que pode ser usado pelos seus aplicativos existentes baseados no Apache Kafka. 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.

Que alterações de configuração precisam ser feitas para que meu aplicativo existente converse com Hubs de Eventos?

Para te ligares a um hub de eventos, precisas de 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 para o FQDN dos Hubs de Eventos e especifique a porta como 9093. Atualize o sasl.jaas.config para direcionar o cliente Kafka ao endpoint do seu Event Hubs (que é a cadeia de ligação que obteve), com autenticação correta como mostrado aqui:

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

Nota

Se sasl.jaas.config não for uma configuração suportada no seu framework, encontre as configurações usadas para definir o nome de utilizador e a palavra-passe da Camada Simples de Autenticação e Segurança (SASL) e use-as em vez disso. Defina o nome de usuário como $ConnectionString e a senha para a cadeia de conexão dos Hubs de Eventos.

Qual é o tamanho da mensagem/evento para Hubs de Eventos?

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

Unidades de processamento

O que são as unidades de taxa de transferência dos Hubs de Eventos? (Nível padrão)

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 o portal ou os modelos do Gestor de Recursos dos Hubs de Eventos.

As unidades de taxa de transferência se aplicam a todos os hubs de eventos em um namespace?

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 4096 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).

Como são faturadas as unidades de throughput?

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.

Como posso otimizar o uso em minhas unidades de rendimento?

Você pode começar com apenas uma unidade de taxa de transferência (TU) e ativar o autoinflate. A funcionalidade de expansão automática permite que aumente os seus TUs à medida que o seu tráfego ou volume de dados aumenta. Você também pode definir um limite máximo para o número de TUs.

Como funciona o recurso Autoinflate dos Hubs de Eventos?

O recurso de autoinflação permite aumentar a escala das suas unidades de rendimento (TUs). Isso significa que você pode começar comprando TUs baixos e aumentar automaticamente suas TUs à medida que sua entrada aumenta. Oferece-lhe uma opção econômica e controlo completo sobre o número de TUs a gerir. Este recurso é uma funcionalidade exclusiva de expansão, e pode controlar completamente a diminuição do número de TUs ao atualizá-lo.

Você pode querer começar com unidades de baixa largura de banda (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.

Existe algum custo associado quando eu ativo o recurso de insuflação automática?

Não há custo associado a esse recurso.

A Redundância de Zona pode ser ativada para um Namespace de Hubs de Eventos existente?

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.

Como são aplicados os limites de throughput?

Se a largura de banda de entrada total ou a taxa total de eventos de entrada em todos os hubs de eventos num namespace exceder as permissões agregadas de unidades de largura de banda, os emissores serão limitados e receberão erros indicando que as quotas de entrada foram excedidas.

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 são estrangulados, mas nenhum erro de estrangulamento é 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.

Existe um limite para o número de unidades de taxa de transferência que podem ser reservadas/selecionadas?

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 modelos baseados em recursos/capacidades, 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.

Clusters dedicados

O que é um cluster dedicado?

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.

Como faço para criar um cluster dedicado de Hubs de Eventos?

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.

Forma da carga útil	Destinatários	Largura de banda de entrada	Mensagens de entrada	Largura de banda de saída	Mensagens de saída	Total de UTs	TUs por UC
Lotes de 100x1KB	2	400 MB/seg	400 mil mensagens/seg	800 MB/seg	800 mil mensagens/seg	400 TUs	100 TUs
Lotes de 10x10KB	2	666 MB/seg	66,6 mil mensagens/seg	1,33 GB/seg	133k mensagens/seg	666 TUs	166 TUs
Lotes de 6x32KB	1	1,05 GB/seg	34k mensagens/seg	1,05 GB/seg	34k mensagens/seg	1.000 TUs	250 TUs

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 ingeridos foram recebidos por duas aplicações recetoras que recebem de todas as partições.

Posso aumentar ou reduzir a escala do meu agrupamento?

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 se determine o número necessário de CUs após 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ê necessita de mais de 10 CUs para um cluster dedicado escalável de autoatendimento (um cluster que foi criado com a opção de suporte a escalonamento ativada).
• Você precisa expandir ou dimensionar em um cluster que foi criado sem selecionar a opção Dimensionamento de suporte.
• Você precisa expandir ou reduzir o tamanho de um cluster dedicado que foi criado antes da funcionalidade de autoatendimento ser lançada.

Aviso

Não poderá eliminar o cluster durante, pelo menos, quatro horas depois de o criar. Você será cobrado por um mínimo de quatro horas de uso do cluster. Para obter mais informações sobre preços, consulte Preços dos Hubs de Eventos.

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 permitem o escalamento automático para clusters dedicados autoescaláveis. 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 PropriedadeFunçã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.

Partições

Quantas partições são necessárias?

Uma partição é um mecanismo de organização de dados que permite a publicação e o consumo paralelos. Embora suporte processamento paralelo e escalonamento, a capacidade total continua limitada pela alocação de escalabilidade do namespace. Balancear unidades de escalabilidade (unidades de throughput para o nível padrão, unidades de processamento para o nível premium ou unidades de capacidade para o nível dedicado) e partições para alcançar a escala ótima.

Comece pelo perfil da sua carga de trabalho: tamanho médio do payload, eventos por segundo e sensibilidade a quedas de taxa de transferência ou a picos de latência. Utilize a largura de banda por partição abaixo como ponto de partida, depois valide com testes de carga.

• Nível padrão: ~1 MB/s de entrada e ~2 MB/s de saída por partição.
• Níveis premium e dedicados: ~1-2 MB/s de entrada e ~2-5 MB/s de saída por partição.

Estima as partições dividindo a tua entrada e saída esperada pelas taxas aplicáveis por partição e tomando o resultado maior. Se o throughput ou latência observados não corresponder às expectativas, aumente as partições (apenas níveis Premium e Dedicado) e volte a testar.

As partições também definem o limite para o paralelismo dos consumidores. Como esse teto funciona depende do tipo de consumidor:

• Consumidores do Epoch (exclusivos) — Usado por EventProcessorClient (.NET, Java) e EventHubConsumerClient (Python, JavaScript), que é o padrão recomendado para cargas de trabalho AMQP de produção. Apenas um consumidor de epoch pode ter uma dada partição num grupo de consumidores ao mesmo tempo. Se implementares mais instâncias de processador do que partições, as instâncias extra não recebem nenhuma partição e ficam inativas até que um proprietário existente liberte uma. Se um novo consumidor da época se ligar a um proprietário de nível superior, o serviço desliga o proprietário atual com um ConsumerDisconnected erro, e o novo consumidor assume o controlo.
• Consumidores não-epoch — Até 5 recetores não-epoch podem ler a mesma partição em simultâneo dentro de um grupo de consumidores. Cada recetor vê os mesmos eventos (fan-out), por isso este modo não aumenta a taxa de processamento por partição. Ligar um consumidor de época a uma partição irá desconectar todos os consumidores não de época nessa mesma partição.
• Consumidores Kafka — Os consumidores Kafka usam o protocolo de coordenação de grupos (group.id) em vez das épocas AMQP, mas o modelo de propriedade de partição é equivalente: cada partição é atribuída exatamente a um membro consumidor dentro de um grupo de consumidores de cada vez. Quando um novo membro entra ou um membro existente sai, o grupo reequilibra e redistribui as atribuições de partições. Se houver mais consumidores do que partições, os membros excedentes não recebem atribuições e permanecem inativos até que um futuro rebalanceamento liberte uma partição. Para reduzir o reequilíbrio desnecessário devido a desconexões transitórias, configure uma instância única de group.instance.id por consumidor (membro estático).

Na prática, o número de partições é igual ao número máximo de consumidores paralelos por grupo de consumidores , independentemente de se usar consumidores da época AMQP ou de Kafka. Tenha isto em conta na contagem de partições ao planear um aumento de escala.

Se a sua aplicação tem 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.

Posso aumentar a contagem de partições no nível Standard dos Event Hubs?

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.

Preços

Onde posso encontrar mais informações sobre preços?

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

Existe alguma taxa para manter os eventos dos Hubs de Eventos por mais de 24 horas?

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 taxa de transferência 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 utilizada ao máximo da capacidade de entrada.

Como o tamanho de armazenamento dos Hubs de Eventos é calculado e cobrado?

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 capacidade de processamento que foram selecionadas durante o dia (cada unidade de capacidade de processamento proporciona 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).

Como são calculados os eventos de entrada?

Cada evento enviado para um hub de eventos conta como uma mensagem faturável. Um evento de entrada é definido como uma unidade de dados inferior ou igual a 64 KB. Qualquer evento com 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 gestão e chamadas de controlo, tais como pontos de verificação, não são contabilizados como eventos de entrada faturáveis, mas acumulam-se até ao limite da unidade de capacidade de transferência.

As taxas de conexão intermediada se aplicam aos Hubs de Eventos?

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.

Como é faturada a Captura dos Hubs de Eventos?

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 rendimento 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 do Evento Hubs, veja as informações de preços dos Hubs de Eventos.

Eu sou cobrado pela conta de armazenamento que selecionei para a Captura de 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.

Quotas

Existem cotas associadas aos Hubs de Eventos?

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

Resolução de Problemas

Por que não consigo criar um namespace depois de excluí-lo de outra assinatura?

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.

Quais são algumas das exceções geradas pelos Hubs de Eventos e suas ações sugeridas?

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

Logs de diagnóstico

Os Event Hubs dão suporte a dois tipos de logs de diagnóstico - logs de erros capturados e logs operacionais - ambos representados em JSON e podem ser ativados por meio do portal do Azure.

Suporte e SLA

O suporte técnico para Hubs de Eventos está disponível através da página de perguntas e respostas Microsoft Q&A 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 .

Azure Stack Hub

Como posso direcionar uma versão específica do SDK de Armazenamento do Azure ao usar o Armazenamento de Blobs do Azure como um armazenamento de ponto de verificaçã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
• Expansão Automática de Hubs de Eventos

Um namespace é um contêiner de escopo para hubs de eventos ou tópicos do Kafka. Fornece-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 alocações de capacidade, unidades de taxa de transferência (TUs) ou unidades de processamento (PUs), são cobradas ao 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:

• Retenção de eventos por mais tempo
• Ligações intermediadas adicionais, com uma taxa adicional por exceder 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 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. A ativação do Capture acarretará uma cobrança com base nas unidades de capacidade de processamento adquiridas.

Você pode configurar o período de retenção para os dados capturados em sua conta de armazenamento. A funcionalidade de gestão do ciclo de vida do Armazenamento do Azure oferece uma política avançada e baseada em regras para contas de armazenamento de v2 de uso geral e de blob. 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 enviados para eles na região que você seleciona quando cria 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

O Hub de Eventos do Azure tem 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.

Protocolo	Portas	Detalhes
AMQP	5671 e 5672	Consulte o guia de protocolo AMQP
HTTPS	443	Esta porta é usada para a API HTTP/REST e para AMQP-over-WebSockets.
Kafka	9093	Consulte a seção Usar Hubs de Eventos em aplicações Kafka

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 uma maior latência de conexão inicial devido a ciclos adicionais de handshake e um pouco mais de sobrecarga, como compromisso para permitir o uso compartilhado da 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:

Linguagem	Opção
.NET	EventHubConnectionOptions.TransportType propriedade com EventHubsTransportType.AmqpTcp ou EventHubsTransportType.AmqpWebSockets
Java	com.microsoft.azure.eventhubs.EventProcessorClientBuilder.transporttype com AmqpTransportType.AMQP ou AmqpTransportType.AMQP_WEB_SOCKETS
Node	EventHubConsumerClientOptions tem uma webSocketOptions propriedade.
Python	EventHubConsumerClient.transport_type com TransportType.Amqp ou TransportType.AmqpOverWebSocket

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 utilizar um namespace hospedado num 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, ative os logs de diagnóstico para eventos de conexão de rede virtual de Hubs de Eventos conforme 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"
}

Importante

Os logs de rede virtual são gerados somente se o namespace permitir acesso a partir de endereços IP específicos (regras de filtro IP). Se você não quiser restringir o acesso ao seu namespace usando esses recursos e ainda quiser obter logs de rede virtual para rastrear endereços IP de clientes que se conectam ao namespace Hubs de Eventos, você pode usar a seguinte solução alternativa: Habilite a filtragem IP e adicione o intervalo IPv4 endereçável total (0.0.0.0/1 - 128.0.0.0/1) e o intervalo IPv6 ().::/1 - 8000::/1

Nota

Atualmente, não é possível determinar o IP de origem de uma mensagem ou evento individual.

O Hub de Eventos fornece um ponto de extremidade Kafka que pode ser usado pelos seus aplicativos existentes baseados no Apache Kafka. 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 te ligares a um hub de eventos, precisas de 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 para o FQDN dos Hubs de Eventos e especifique a porta como 9093. Atualize o sasl.jaas.config para direcionar o cliente Kafka ao endpoint do seu Event Hubs (que é a cadeia de ligação que obteve), com autenticação correta como mostrado aqui:

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

Nota

Se sasl.jaas.config não for uma configuração suportada no seu framework, encontre as configurações usadas para definir o nome de utilizador e a palavra-passe da Camada Simples de Autenticação e Segurança (SASL) e use-as em vez disso. Defina o nome de usuário como $ConnectionString e a senha para a cadeia de conexão dos Hubs de Eventos.

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 o portal ou os modelos do Gestor 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 4096 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 começar com apenas uma unidade de taxa de transferência (TU) e ativar o autoinflate. A funcionalidade de expansão automática permite que aumente os seus TUs à medida que o seu tráfego ou volume de dados 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 das suas unidades de rendimento (TUs). Isso significa que você pode começar comprando TUs baixos e aumentar automaticamente suas TUs à medida que sua entrada aumenta. Oferece-lhe uma opção econômica e controlo completo sobre o número de TUs a gerir. Este recurso é uma funcionalidade exclusiva de expansão, e pode controlar completamente a diminuição do número de TUs ao atualizá-lo.

Você pode querer começar com unidades de baixa largura de banda (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 largura de banda de entrada total ou a taxa total de eventos de entrada em todos os hubs de eventos num namespace exceder as permissões agregadas de unidades de largura de banda, os emissores serão limitados e receberão erros indicando que as quotas de entrada foram excedidas.

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 são estrangulados, mas nenhum erro de estrangulamento é 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 modelos baseados em recursos/capacidades, 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.

Forma da carga útil	Destinatários	Largura de banda de entrada	Mensagens de entrada	Largura de banda de saída	Mensagens de saída	Total de UTs	TUs por UC
Lotes de 100x1KB	2	400 MB/seg	400 mil mensagens/seg	800 MB/seg	800 mil mensagens/seg	400 TUs	100 TUs
Lotes de 10x10KB	2	666 MB/seg	66,6 mil mensagens/seg	1,33 GB/seg	133k mensagens/seg	666 TUs	166 TUs
Lotes de 6x32KB	1	1,05 GB/seg	34k mensagens/seg	1,05 GB/seg	34k mensagens/seg	1.000 TUs	250 TUs

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 ingeridos foram recebidos por duas aplicações recetoras que recebem de todas as partições.

Posso aumentar ou reduzir a escala do meu agrupamento?

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 se determine o número necessário de CUs após 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ê necessita de mais de 10 CUs para um cluster dedicado escalável de autoatendimento (um cluster que foi criado com a opção de suporte a escalonamento ativada).
• Você precisa expandir ou dimensionar em um cluster que foi criado sem selecionar a opção Dimensionamento de suporte.
• Você precisa expandir ou reduzir o tamanho de um cluster dedicado que foi criado antes da funcionalidade de autoatendimento ser lançada.

Aviso

Não poderá eliminar o cluster durante, pelo menos, quatro horas depois de o criar. Você será cobrado por um mínimo de quatro horas de uso do cluster. Para obter mais informações sobre preços, consulte Preços dos Hubs de Eventos.

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 permitem o escalamento automático para clusters dedicados autoescaláveis. 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 PropriedadeFunçã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.

Uma partição é um mecanismo de organização de dados que permite a publicação e o consumo paralelos. Embora suporte processamento paralelo e escalonamento, a capacidade total continua limitada pela alocação de escalabilidade do namespace. Balancear unidades de escalabilidade (unidades de throughput para o nível padrão, unidades de processamento para o nível premium ou unidades de capacidade para o nível dedicado) e partições para alcançar a escala ótima.

Comece pelo perfil da sua carga de trabalho: tamanho médio do payload, eventos por segundo e sensibilidade a quedas de taxa de transferência ou a picos de latência. Utilize a largura de banda por partição abaixo como ponto de partida, depois valide com testes de carga.

• Nível padrão: ~1 MB/s de entrada e ~2 MB/s de saída por partição.
• Níveis premium e dedicados: ~1-2 MB/s de entrada e ~2-5 MB/s de saída por partição.

Estima as partições dividindo a tua entrada e saída esperada pelas taxas aplicáveis por partição e tomando o resultado maior. Se o throughput ou latência observados não corresponder às expectativas, aumente as partições (apenas níveis Premium e Dedicado) e volte a testar.

As partições também definem o limite para o paralelismo dos consumidores. Como esse teto funciona depende do tipo de consumidor:

• Consumidores do Epoch (exclusivos) — Usado por EventProcessorClient (.NET, Java) e EventHubConsumerClient (Python, JavaScript), que é o padrão recomendado para cargas de trabalho AMQP de produção. Apenas um consumidor de epoch pode ter uma dada partição num grupo de consumidores ao mesmo tempo. Se implementares mais instâncias de processador do que partições, as instâncias extra não recebem nenhuma partição e ficam inativas até que um proprietário existente liberte uma. Se um novo consumidor da época se ligar a um proprietário de nível superior, o serviço desliga o proprietário atual com um ConsumerDisconnected erro, e o novo consumidor assume o controlo.
• Consumidores não-epoch — Até 5 recetores não-epoch podem ler a mesma partição em simultâneo dentro de um grupo de consumidores. Cada recetor vê os mesmos eventos (fan-out), por isso este modo não aumenta a taxa de processamento por partição. Ligar um consumidor de época a uma partição irá desconectar todos os consumidores não de época nessa mesma partição.
• Consumidores Kafka — Os consumidores Kafka usam o protocolo de coordenação de grupos (group.id) em vez das épocas AMQP, mas o modelo de propriedade de partição é equivalente: cada partição é atribuída exatamente a um membro consumidor dentro de um grupo de consumidores de cada vez. Quando um novo membro entra ou um membro existente sai, o grupo reequilibra e redistribui as atribuições de partições. Se houver mais consumidores do que partições, os membros excedentes não recebem atribuições e permanecem inativos até que um futuro rebalanceamento liberte uma partição. Para reduzir o reequilíbrio desnecessário devido a desconexões transitórias, configure uma instância única de group.instance.id por consumidor (membro estático).

Na prática, o número de partições é igual ao número máximo de consumidores paralelos por grupo de consumidores , independentemente de se usar consumidores da época AMQP ou de Kafka. Tenha isto em conta na contagem de partições ao planear um aumento de escala.

Se a sua aplicação tem 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 taxa de transferência 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 utilizada ao máximo da capacidade 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 capacidade de processamento que foram selecionadas durante o dia (cada unidade de capacidade de processamento proporciona 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 inferior ou igual a 64 KB. Qualquer evento com 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 gestão e chamadas de controlo, tais como pontos de verificação, não são contabilizados como eventos de entrada faturáveis, mas acumulam-se até ao limite da unidade de capacidade 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 rendimento 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 do Evento Hubs, veja as 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 Event Hubs dão suporte a dois tipos de logs de diagnóstico - logs de erros capturados 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 Microsoft Q&A 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
• Expansão Automática de Hubs de Eventos