Enviar e receber mensagens entre o Azure IoT MQ Preview e o Azure Event Hubs ou Kafka

Artigo
04/22/2024

Importante

O recurso Pré-visualização de Operações do Azure IoT — habilitado pelo Azure Arc — está atualmente em VERSÃO PRÉVIA. Você não deve usar esse software em versão prévia em ambientes de produção.

Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para obter termos legais que se aplicam aos recursos do Azure que estão em versão beta, versão prévia ou que, de outra forma, ainda não foram lançados em disponibilidade geral.

O conector Kafka envia mensagens do corretor MQTT do Azure IoT MQ Preview para um ponto de extremidade Kafka e, da mesma forma, extrai mensagens na outra direção. Como os Hubs de Eventos do Azure dão suporte à API do Kafka, o conector funciona imediatamente com os Hubs de Eventos.

Configurar o conector dos Hubs de Eventos via ponto de extremidade Kafka

Por padrão, o conector não é instalado com a Internet das Coisas do Azure MQ. Ele deve ser explicitamente habilitado com mapeamento de tópico e credenciais de autenticação especificadas. Siga estas etapas para habilitar a comunicação bidirecional entre o IoT MQ e os Hubs de Eventos do Azure por meio de seu ponto de extremidade Kafka.

Criar um namespace dos Hubs de Eventos.
Crie um hub de eventos para cada tópico do Kafka.

Conceder ao conector acesso ao namespace Hubs de Eventos

Conceder acesso à extensão IoT MQ Arc a um namespace de Hubs de Eventos é a maneira mais conveniente de estabelecer uma conexão segura do conector Kakfa do IoT MQ para Hubs de Eventos.

Salve o seguinte modelo Bicep em um arquivo e aplique-o com a CLI do Azure depois de definir os parâmetros válidos para seu ambiente:

Observação

O modelo Bicep pressupõe que o cluster com arco e o namespace Hubs de Eventos estejam no mesmo grupo de recursos, ajuste o modelo se seu ambiente for diferente.

@description('Location for cloud resources')
param mqExtensionName string = 'mq'
param clusterName string = 'clusterName'
param eventHubNamespaceName string = 'default'

resource connectedCluster 'Microsoft.Kubernetes/connectedClusters@2021-10-01' existing = {
  name: clusterName
}

resource mqExtension 'Microsoft.KubernetesConfiguration/extensions@2022-11-01' existing = {
  name: mqExtensionName
  scope: connectedCluster
}

resource ehNamespace 'Microsoft.EventHub/namespaces@2021-11-01' existing = {
  name: eventHubNamespaceName
}

// Role assignment for Event Hubs Data Receiver role
resource roleAssignmentDataReceiver 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(ehNamespace.id, mqExtension.id, '7f951dda-4ed3-4680-a7ca-43fe172d538d')
  scope: ehNamespace
  properties: {
     // ID for Event Hubs Data Receiver role is a638d3c7-ab3a-418d-83e6-5f17a39d4fde
    roleDefinitionId: resourceId('Microsoft.Authorization/roleDefinitions', 'a638d3c7-ab3a-418d-83e6-5f17a39d4fde') 
    principalId: mqExtension.identity.principalId
    principalType: 'ServicePrincipal'
  }
}

// Role assignment for Event Hubs Data Sender role
resource roleAssignmentDataSender 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(ehNamespace.id, mqExtension.id, '69b88ce2-a752-421f-bd8b-e230189e1d63')
  scope: ehNamespace
  properties: {
    // ID for Event Hubs Data Sender role is 2b629674-e913-4c01-ae53-ef4638d8f975
    roleDefinitionId: resourceId('Microsoft.Authorization/roleDefinitions', '2b629674-e913-4c01-ae53-ef4638d8f975') 
    principalId: mqExtension.identity.principalId
    principalType: 'ServicePrincipal'
  }
}

# Set the required environment variables

# Resource group for resources
RESOURCE_GROUP=xxx

# Bicep template files name
TEMPLATE_FILE_NAME=xxx

# MQ Arc extension name
MQ_EXTENSION_NAME=xxx

# Arc connected cluster name
CLUSTER_NAME=xxx

# Event Hubs namespace name
EVENTHUB_NAMESPACE=xxx


az deployment group create \
      --name assign-RBAC-roles \
      --resource-group $RESOURCE_GROUP \
      --template-file $TEMPLATE_FILE_NAME \
      --parameters mqExtensionName=$MQ_EXTENSION_NAME \
      --parameters clusterName=$CLUSTER_NAME \
      --parameters eventHubNamespaceName=$EVENTHUB_NAMESPACE

KafkaConnector

O recurso personalizado (CR) KafkaConnector permite configurar um conector Kafka que pode comunicar um host Kafka e Hubs de Eventos. O conector Kafka pode transferir dados entre tópicos MQTT e tópicos Kafka, usando os Hubs de Eventos como um ponto de extremidade compatível com Kafka.

O exemplo a seguir mostra uma CR KafkaConnector que se conecta a um ponto de extremidade dos Hubs de Eventos usando a identidade do Azure do IoT MQ, ele pressupõe que outros recursos do MQ foram instalados usando o início rápido:

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: KafkaConnector
metadata:
  name: my-eh-connector
  namespace: azure-iot-operations # same as one used for other MQ resources
spec:
  image:
    pullPolicy: IfNotPresent
    repository: mcr.microsoft.com/azureiotoperations/kafka
    tag: 0.4.0-preview
  instances: 2
  clientIdPrefix: my-prefix
  kafkaConnection:
    # Port 9093 is Event Hubs' Kakfa endpoint
    # Plug in your Event Hubs namespace name
    endpoint: <NAMESPACE>.servicebus.windows.net:9093
    tls:
      tlsEnabled: true
    authentication:
      enabled: true
      authType:
        systemAssignedManagedIdentity:
          # plugin in your Event Hubs namespace name
          audience: "https://<NAMESPACE>.servicebus.windows.net" 
  localBrokerConnection:
    endpoint: "aio-mq-dmqtt-frontend:8883"
    tls:
      tlsEnabled: true
      trustedCaCertificateConfigMap: "aio-ca-trust-bundle-test-only"
    authentication:
      kubernetes: {}

A tabela a seguir descreve os campos no KafkaConnector CR:

Campo	Descrição	Necessário
imagem	A imagem do conector de Kafka. Você pode especificar o `pullPolicy`, o `repository` e o `tag` da imagem. Os valores padrão são mostrados no exemplo anterior.	Sim
instances	O número de instâncias do conector Kafka a serem executadas.	Sim
clientIdPrefix	A cadeia de caracteres a ser anexada a uma ID de cliente usada pelo conector.	Não
kafkaConnection	Os detalhes de conexão do ponto de extremidade dos Hubs de Eventos. Veja Conexão Kafka.	Sim
localBrokerConnection	Os detalhes da conexão do agente local que substitui a conexão do agente padrão. Consulte Gerenciar conexão de agente local.	Não
logLevel	O nível de log do conector Kafka. Os valores possíveis são: trace, debug, info, warn, error ou fatal. O padrão é avisar.	Não

Conexão Kafka

O campo kafkaConnection define os detalhes de conexão do ponto de extremidade Kafka.

Campo	Descrição	Necessário
endpoint	O host e a porta do ponto de extremidade dos Hubs de Eventos. A porta é tipicamente 9093. Você pode especificar vários pontos de extremidade separados por vírgulas para usar a sintaxe dos servidores de inicialização.	Sim
tls	A configuração para criptografia TLS. Consulte TLS.	Sim
autenticação	A configuração para autenticação. Consulte Autenticação.	Não

TLS

O campo tls habilita a criptografia TLS para a conexão e, opcionalmente, especifica um mapa de configuração da autoridade de certificação.

Campo	Descrição	Necessário
tlsEnabled	Um valor booleano que indica se a criptografia TLS está habilitada ou não. Ele deve ser definido como true para comunicação com Hubs de Eventos.	Yes
trustedCaCertificateConfigMap	O nome do mapa de configuração que contém o certificado de autoridade de certificação para verificar a identidade do servidor. Esse campo não é necessário para a comunicação dos Hubs de Eventos, pois os Hubs de Eventos usam CAs conhecidas que são confiáveis por padrão. No entanto, você pode usar esse campo se quiser usar um certificado de autoridade de certificação personalizado.	Não

Ao especificar uma autoridade de certificação confiável, crie um ConfigMap contendo a poção pública da autoridade de certificação no formato PEM e especifique o nome na propriedade trustedCaCertificateConfigMap.

kubectl create configmap ca-pem --from-file path/to/ca.pem

Autenticação

O campo de autenticação oferece suporte a diferentes tipos de métodos de autenticação, como SASL, X509 ou identidade gerenciada.

Campo	Descrição	Necessário
Habilitado	Um valor booleano que indica se a autenticação está habilitada ou não.	Sim
authType	Um campo que contém o tipo de autenticação usado. Consulte Tipo de autenticação

Tipo de Autenticação

Campo	Descrição	Necessário
sasl	A configuração para autenticação SASL. Especifique o `saslType`, que pode ser simples, scramSha256, ou scramSha512 e `token` para fazer referência ao segredo do Kubernetes `secretName` ou do Azure Key Vault `keyVault` que contém a senha.	Sim, se estiver usando autenticação SASL
systemAssignedManagedIdentity	A configuração para autenticação de identidade gerenciada. Especifique a audiência para a solicitação de token, que deve corresponder ao namespace (`https://<NAMESPACE>.servicebus.windows.net`) dos Hubs de Eventos porque o conector é um cliente Kafka. Uma identidade gerenciada atribuída pelo sistema é criada automaticamente e atribuída ao conector quando ele é habilitado.	Sim, se estiver usando autenticação de identidade gerenciada
x509	A configuração para autenticação X509. Especifique o campo `secretName` ou `keyVault`. O campo `secretName` é o nome do segredo que contém o certificado do cliente e a chave do cliente no formato PEM, armazenados como um segredo TLS.	Sim, se estiver usando a autenticação X509

Para saber como usar o Azure Key Vault e o keyVault para gerenciar segredos do Azure IoT MQ em vez de segredos do Kubernetes, veja Gerenciar segredos usando o Azure Key Vault ou segredos do Kubernetes.

Autenticar no Hubs de Eventos

Para se conectar aos Hubs de Eventos usando uma cadeia de conexão e um segredo do Kubernetes, use plain tipo SASL e $ConnectionString como nome de usuário e a cadeia de conexão completa como senha. Primeiro crie o segredo do Kubernetes:

kubectl create secret generic cs-secret -n azure-iot-operations \
  --from-literal=username='$ConnectionString' \
  --from-literal=password='Endpoint=sb://<NAMESPACE>.servicebus.windows.net/;SharedAccessKeyName=<KEY_NAME>;SharedAccessKey=<KEY>'

Em seguida, faça referência ao segredo na configuração:

authentication:
  enabled: true
  authType:
    sasl:
      saslType: plain
      token:
        secretName: cs-secret

Para usar o Azure Key Vault em vez dos segredos do Kubernetes, crie um segredo do Azure Key Vault com a cadeia de conexão Endpoint=sb://.., referencie-o com vaultSecret e especifique o nome de usuário como "$ConnectionString" na configuração.

authentication:
  enabled: true
  authType:
    sasl:
      saslType: plain
      token:
        keyVault:
          username: "$ConnectionString"
          vault:
            name: my-key-vault
            directoryId: <AKV directory ID>
            credentials:
              servicePrincipalLocalSecretName: aio-akv-sp
          vaultSecret:
            name: my-cs # Endpoint=sb://..
            # version: 939ecc2...

Para usar a identidade gerenciada, especifique-a como o único método sob autenticação. Você também precisa atribuir uma função à identidade gerenciada que concede permissão para enviar e receber mensagens de Hubs de Eventos, como Proprietário de Dados dos Hubs de Eventos do Azure ou Remetente/Receptor de Dados dos Hubs de Eventos do Azure. Para saber mais, consulte Autenticar um aplicativo com o Microsoft Entra ID para acessar recursos dos Hubs de Eventos.

authentication:
  enabled: true
  authType:
    systemAssignedManagedIdentity:
      audience: https://<NAMESPACE>.servicebus.windows.net

X.509

Para X.509, use o segredo TLS do Kubernetes que contém o certificado público e a chave privada.

kubectl create secret tls my-tls-secret -n azure-iot-operations \
  --cert=path/to/cert/file \
  --key=path/to/key/file

Em seguida, especifique o secretName na configuração.

authentication:
  enabled: true
  authType:
    x509:
      secretName: my-tls-secret

Em vez disso, para usar o Azure Key Vault, certifique-se de que o certificado e a chave privada sejam importados corretamente e, em seguida, especifique a referência com vaultCert.

authentication:
  enabled: true
  authType:
    x509:
      keyVault:
        vault:
          name: my-key-vault
          directoryId: <AKV directory ID>
          credentials:
            servicePrincipalLocalSecretName: aio-akv-sp
        vaultCert:
          name: my-cert
          # version: 939ecc2...
        ## If presenting full chain also  
        # vaultCaChainSecret:
        #   name: my-chain

Ou, se for necessário apresentar a cadeia completa, carregue o certificado e a chave da cadeia completa para AKV como um arquivo PFX e use o campo vaultCaChainSecret.

# ...
keyVault:
  vaultCaChainSecret:
    name: my-cert
    # version: 939ecc2...

Gerenciar conexão de agente local

Como a ponte MQTT, o conector dos Hubs de Eventos atua como um cliente para o agente IoT MQ MQTT. Se você personalizou a porta de ouvinte e/ou a autenticação do seu agente IoT MQ MQTT, substitua a configuração de conexão MQTT local para o conector dos Hubs de Eventos também. Para saber mais, consulte Conexão do agente local da ponte MQTT.

KafkaConnectorTopicMap

O recurso personalizado (CR) KafkaConnectorTopicMap permite definir o mapeamento entre tópicos MQTT e tópicos Kafka para transferência de dados bidirecional. Especifique uma referência a um KafkaConnector CR e uma lista de rotas. Cada rota pode ser uma rota MQTT para Kafka ou uma rota Kafka para MQTT. Por exemplo:

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: KafkaConnectorTopicMap
metadata:
  name: my-eh-topic-map
  namespace: <SAME NAMESPACE AS BROKER> # For example "default"
spec:
  kafkaConnectorRef: my-eh-connector
  compression: snappy
  batching:
    enabled: true
    latencyMs: 1000
    maxMessages: 100
    maxBytes: 1024
  partitionStrategy: property
  partitionKeyProperty: device-id
  copyMqttProperties: true
  routes:
    # Subscribe from MQTT topic "temperature-alerts/#" and send to Kafka topic "receiving-event-hub"
    - mqttToKafka:
        name: "route1"
        mqttTopic: temperature-alerts/#
        kafkaTopic: receiving-event-hub
        kafkaAcks: one
        qos: 1
        sharedSubscription:
          groupName: group1
          groupMinimumShareNumber: 3
    # Pull from kafka topic "sending-event-hub" and publish to MQTT topic "heater-commands"
    - kafkaToMqtt:
        name: "route2"
        consumerGroupId: mqConnector
        kafkaTopic: sending-event-hub
        mqttTopic: heater-commands
        qos: 0

A tabela a seguir descreve os campos no KafkaConnectorTopicMap CR:

Campo	Descrição	Necessário
kafkaConnectorRef	O nome do KafkaConnector CR ao qual este mapa de tópico pertence.	Sim
compactação	A configuração para compactação para as mensagens enviadas para tópicos de Kafka. Consulte Compressão.	Não
lote	A configuração para envio em lote para as mensagens enviadas aos tópicos de Kafka. Consulte Lote.	Não
partitionStrategy	A estratégia para lidar com partições Kafka ao enviar mensagens para tópicos Kafka. Consulte Estratégia de manipulação de partições.	Não
copyMqttProperties	Valor booleano para controlar se as propriedades do sistema MQTT e do usuário são copiadas para o cabeçalho da mensagem Kafka. As propriedades do usuário são copiadas no estado em que se encontram. Algumas transformações são feitas com as propriedades do sistema. O padrão é false.	Não
rotas	Uma lista de rotas para transferência de dados entre tópicos MQTT e tópicos Kafka. Cada rota pode ter um campo `mqttToKafka` ou `kafkaToMqtt`, dependendo da direção da transferência de dados. Veja Rotas.	Sim

Compactação

O campo de compactação permite a compactação para as mensagens enviadas aos tópicos de Kafka. A compactação ajuda a reduzir a largura de banda da rede e o espaço de armazenamento necessários para a transferência de dados. No entanto, a compactação também adiciona alguma sobrecarga e latência ao processo. Os tipos de compactação com suporte estão listados na tabela a seguir.

Valor	Descrição
nenhum	Nenhuma compactação ou lote é aplicada. nenhum é o valor padrão se nenhuma compactação for especificada.
gzip	A compactação GZIP e o processamento em lote são aplicados. GZIP é um algoritmo de compressão de uso geral que oferece um bom equilíbrio entre taxa de compressão e velocidade.
snappy	A compactação rápida e o processamento em lote são aplicados. Snappy é um algoritmo de compressão rápida que oferece taxa de compressão moderada e velocidade.
lz4	A compactação LZ4 e o processamento em lote são aplicados. LZ4 é um algoritmo de compressão rápida que oferece baixa taxa de compressão e alta velocidade.

Envio em lote

Além da compactação, você também pode configurar o envio em lote de mensagens antes de enviá-las para os tópicos do Kafka. O envio em lote permite agrupar várias mensagens e compactá-las como uma única unidade, o que pode melhorar a eficiência da compactação e reduzir a sobrecarga de rede.

Campo	Descrição	Necessário
Habilitado	Um valor booleano que indica se o processamento em lote está habilitado ou não. Se não for definida, o valor padrão será falso.	Sim
latencyMs	O intervalo de tempo máximo em milissegundos em que as mensagens podem ser armazenadas em buffer antes de serem enviadas. Se esse intervalo for atingido, todas as mensagens em buffer serão enviadas como um lote, independentemente de quantas ou quão grandes elas sejam. Se não for definido, o valor padrão será 5.	Não
maxMessages	O número máximo de mensagens que podem ser armazenadas em buffer antes de serem enviadas. Se esse número for atingido, todas as mensagens armazenadas em buffer serão enviadas como um lote, independentemente de quão grandes elas sejam ou por quanto tempo sejam armazenadas em buffer. Se não for definido, o valor padrão será 100000.	Não
maxBytes	O tamanho máximo em bytes que pode ser armazenado em buffer antes de ser enviado. Se esse tamanho for atingido, todas as mensagens armazenadas em buffer serão enviadas como um lote, independentemente de quantas sejam ou por quanto tempo sejam armazenadas em buffer. O valor padrão é 1000000 (1 MB).	Não

Um exemplo de uso em lote é:

batching:
  enabled: true
  latencyMs: 1000
  maxMessages: 100
  maxBytes: 1024

Isso significa que as mensagens são enviadas quando há 100 mensagens no buffer, ou quando há 1024 bytes no buffer, ou quando 1000 milissegundos decorrem desde o último envio, o que ocorrer primeiro.

Estratégia de manipulação de partições

A estratégia de manipulação de partições é um recurso que permite controlar como as mensagens são atribuídas às partições Kafka ao enviá-las para tópicos Kafka. As partições Kafka são segmentos lógicos de um tópico Kafka que permitem processamento paralelo e tolerância a falhas. Cada mensagem em um tópico Kafka tem uma partição e um deslocamento que são usados para identificar e ordenar as mensagens.

Por padrão, o conector Kafka atribui mensagens a partições aleatórias, usando um algoritmo round-robin. No entanto, você pode usar estratégias diferentes para atribuir mensagens a partições com base em alguns critérios, como o nome do tópico MQTT ou uma propriedade de mensagem MQTT. Isso pode ajudá-lo a obter melhor balanceamento de carga, localidade de dados ou ordenação de mensagens.

Valor	Descrição
default	Atribui mensagens a partições aleatórias, usando um algoritmo round-robin. É o valor padrão se nenhuma estratégia for especificada.
static	Atribui mensagens a um número de partição fixo derivado do ID da instância do conector. Isso significa que cada instância do conector envia mensagens para uma partição diferente. Isso pode ajudar a obter melhor balanceamento de carga e localidade de dados.
tópico	Usa o nome do tópico MQTT como a chave para particionamento. Isso significa que as mensagens com o mesmo nome de tópico MQTT são enviadas para a mesma partição. Isso pode ajudar a obter uma melhor ordenação de mensagens e localidade de dados.
property	Usa uma propriedade de mensagem MQTT como a chave para particionamento. Especifique o nome da propriedade no campo `partitionKeyProperty`. Isso significa que as mensagens com o mesmo valor de propriedade são enviadas para a mesma partição. Isso pode ajudar a obter uma melhor ordenação de mensagens e localidade de dados com base em um critério personalizado.

Um exemplo de uso da estratégia de manipulação de partição é:

partitionStrategy: property
partitionKeyProperty: device-id

Isso significa que as mensagens com a mesma propriedade device-id são enviadas para a mesma partição.

Rotas

O campo rotas define uma lista de rotas para transferência de dados entre tópicos MQTT e tópicos Kafka. Cada rota pode ter um campo mqttToKafka ou kafkaToMqtt, dependendo da direção da transferência de dados.

MQTT para Kafka

O campo mqttToKafka define uma rota que transfere dados de um tópico MQTT para um tópico Kafka.

Campo	Descrição	Obrigatório
name	Nome exclusivo para a rota.	Sim
mqttTopic	O tópico MQTT do qual se inscrever. Você pode usar caracteres curinga (`#` e `+`) para corresponder a vários tópicos.	Sim
kafkaTopic	O tópico Kafka para enviar.	Sim
kafkaAcks	O número de confirmações que o conector requer do ponto de extremidade Kafka. Os valores possíveis são: `zero`, `one` ou `all`.	Não
qos	O nível de qualidade de serviço (QoS) para a assinatura de tópico MQTT. Os valores possíveis são: 0 ou 1 (padrão). QoS 2 não é suportado no momento.	Sim
sharedSubscription	A configuração para usar assinaturas compartilhadas para tópicos MQTT. Especifique o `groupName`, que é um identificador exclusivo para um grupo de assinantes, e o `groupMinimumShareNumber`, que é o número de assinantes em um grupo que recebem mensagens de um tópico. Por exemplo, se groupName for "group1" e groupMinimumShareNumber for 3, o conector criará três assinantes com o mesmo nome de grupo para receber mensagens de um tópico. Esse recurso permite que você distribua mensagens entre vários assinantes sem perder nenhuma mensagem ou criar duplicatas.	Não

Um exemplo de uso mqttToKafka rota:

mqttToKafka:
  mqttTopic: temperature-alerts/#
  kafkaTopic: receiving-event-hub
  kafkaAcks: one
  qos: 1
  sharedSubscription:
    groupName: group1
    groupMinimumShareNumber: 3

Neste exemplo, as mensagens de tópicos MQTT que correspondem a temperature-alerts/# são enviadas para o tópico Kafka receiving-event-hub com QoS equivalente 1 e grupo de assinatura compartilhada "group1" com número de compartilhamento 3.

Kafka para MQTT

O campo kafkaToMqtt define uma rota que transfere dados de um tópico Kafka para um tópico MQTT.

Campo	Descrição	Obrigatório
name	Nome exclusivo para a rota.	Sim
kafkaTopic	O tema Kafka para puxar.	Sim
mqttTopic	O tópico MQTT para publicar.	Sim
consumerGroupId	O prefixo do ID do grupo de consumidores para cada rota Kafka para MQTT. Se não estiver definido, o ID do grupo de consumidores será definido como o mesmo que o nome da rota.	Não
qos	O nível de qualidade de serviço (QoS) para as mensagens publicadas no tópico MQTT. Os valores possíveis são 0 ou 1 (padrão). QoS 2 não é suportado no momento. Se QoS estiver definido como 1, o conector publicará a mensagem no tópico MQTT e, em seguida, aguardará o ack antes de confirmar a mensagem de volta para Kafka. Para QoS 0, o conector volta imediatamente sem MQTT ack.	Não

Um exemplo de uso da rota kafkaToMqtt:

kafkaToMqtt:
  kafkaTopic: sending-event-hub
  mqttTopic: heater-commands
  qos: 0

Neste exemplo, as mensagens do tópico Kafka sending-event-hub* são publicadas no tópico MQTT heater-commands com QoS nível 0.

O nome do hub de eventos deve corresponder ao tópico Kafka

Cada hub de evento individual, não o namespace, deve ser nomeado exatamente da mesma forma que o tópico Kafka pretendido especificado nas rotas. Além disso, a cadeia de conexão EntityPath deve corresponder se a cadeia de conexão tiver como escopo um hub de eventos. Esse requisito ocorre porque o namespace Hubs de Eventos é análogo ao cluster Kafka e o nome do hub de eventos é análogo a um tópico Kafka, portanto, o nome do tópico Kafka deve corresponder ao nome do hub de eventos.

Deslocamentos do grupo de consumidores do Kafka

Se o conector se desconectar ou for removido e reinstalado com a mesma ID do grupo de consumidores do Kafka, o deslocamento do grupo de consumidores (a última posição de onde o consumidor do Kafka lê mensagens) será armazenado nos Hubs de Eventos do Azure. Para saber mais, consulte Grupo de consumidores dos Hubs de Eventos vs. Grupo de consumidores Kafka.

Versão MQTT

Este conector usa apenas MQTT v5.

Publique e assine mensagens MQTT usando o Azure IoT MQ Preview