Compartilhar via

Problemas conhecidos para operações de IoT do Azure

Este artigo lista os problemas conhecidos atuais que você pode encontrar ao usar operações de IoT do Azure. As diretrizes ajudam você a identificar esses problemas e fornece soluções alternativas quando disponíveis.

Para obter diretrizes gerais de solução de problemas, consulte Solucionar problemas de operações de IoT do Azure.

Problemas com o corretor MQTT

Esta seção lista os problemas conhecidos atuais para o agente MQTT.

Os recursos do agente MQTT não estão visíveis no portal do Azure

ID do problema: 4257

Assinatura de log: N/A

Os recursos do agente MQTT criados em seu cluster usando o Kubernetes não estão visíveis no portal do Azure. Esse resultado é esperado porque o gerenciamento de componentes do Azure IoT Operations usando o Kubernetes está em versão prévia e não há suporte para sincronizar recursos da borda para a nuvem no momento.

Atualmente, não há nenhuma solução alternativa para esse problema.

Problemas gerais do conector

Esta seção lista os problemas conhecidos atuais que afetam todos os conectores.

O conector não detecta atualizações nas credenciais do dispositivo no Azure Key Vault

ID do problema: 6514

N/A

O conector não recebe uma notificação quando as credenciais do dispositivo armazenadas no Azure Key Vault são atualizadas. Como resultado, o conector continua a usar as credenciais antigas até que seja reiniciado.

Solução alternativa: reinicie o conector para forçá-lo a recuperar as credenciais atualizadas do Azure Key Vault.

Para conectores Akri, o único tipo de autenticação com suporte para pontos de extremidade do Registro é artifact pull secrets

ID do problema: 4570

Assinatura de log: N/A

Quando você especifica a referência de ponto de extremidade do Registro em um modelo de conector, há vários métodos de autenticação com suporte. Os conectores Akri só dão suporte à artifact pull secrets autenticação.

Conectores Akri não funcionam com recursos de endpoint de registro

ID do problema: 7710

Corrigido na versão 1.2.154 (2512) e posterior

Assinatura de log:

[aio_akri_logs@311 tid="7"] - failed to generate StatefulSet payload for instance rest-connector-template-...
[aio_akri_logs@311 tid="7"] - reconciliation error for Connector resource... 
[aio_akri_logs@311 tid="7"] - reconciliation of Connector resource failed...

Se você criar um recurso RegistryEndpoint usando o bicep e referenciá-lo no recurso ConnectorTemplate, quando o operador Akri tentar reconciliar o ConnectorTemplate ele falhará com o erro mostrado anteriormente.

Solução alternativa: não utilize RegistryEndpoint recursos com conectores Akri. Em vez disso, especifique as informações do Registro nas configurações ContainerRegistry no recurso ConnectorTemplate.

Problemas do conector para OPC UA

Esta seção lista os problemas conhecidos atuais do conector para OPC UA.

Não é possível usar caracteres especiais em nomes de eventos

ID do problema: 1532

Assinatura de log: 2025-10-22T14:51:59.338Z aio-opc-opc.tcp-1-68ff6d4c59-nj2s4 - Updated schema information for Boiler#1Notifier skipped!

A geração de esquema falhará se os nomes de eventos contiverem caracteres especiais, como #, %ou &. Evite usar esses caracteres em nomes de eventos para evitar problemas de geração de esquema.

Conector para mídia e conector para problemas de ONVIF

Esta seção lista os problemas conhecidos atuais para o conector para mídia e o conector para ONVIF.

Conflito de sincronização de segredo

ID do problema: 0606

Assinatura de log: N/A

Ao usar a sincronização secreta, verifique se os nomes de segredo são globalmente exclusivos. Se existir um segredo local com o mesmo nome, os conectores poderão não recuperar o segredo pretendido.

O destino do evento de ativo ONVIF só pode ser configurado no nível do grupo ou do ativo

ID do problema: 9545

Corrigido na versão 1.2.154 (2512) e posterior

Assinatura de log semelhante a:

No matching event subscription for topic: "tns1:RuleEngine/CellMotionDetector/Motion"

Atualmente, os destinos de eventos do ativo ONVIF são reconhecidos apenas no nível do grupo de eventos ou do ativo. Configurar destinos no nível de evento individual resulta em entradas de log semelhantes ao exemplo e nenhum dado de evento é publicado no agente MQTT.

Como solução alternativa, configure o destino do evento no nível do grupo de eventos ou do ativo em vez do nível de evento individual. Por exemplo, usando defaultEventsDestinations no nível do grupo de eventos:

eventGroups:
  - dataSource: ""
    events:
    - dataSource: tns1:RuleEngine/CellMotionDetector/Motion
      destinations:
      - configuration:
          qos: Qos1
          retain: Never
          topic: azure-iot-operations/data/motion
          ttl: 5
        target: Mqtt
      name: Motion
    name: Default
    defaultEventsDestinations:
    - configuration:
        qos: Qos1
        retain: Never
        topic: azure-iot-operations/data/motion
        ttl: 5
      target: Mqtt

Problemas de fluxos de dados

Esta seção lista os problemas conhecidos atuais para fluxos de dados.

Os recursos de fluxo de dados não estão visíveis na interface web da experiência operacional

ID do problema: 8724

Assinatura de log: N/A

Os recursos personalizados de fluxo de dados criados no seu cluster usando o Kubernetes não ficam visíveis na interface do usuário da Web da experiência de operações. Esse resultado é esperado porque o gerenciamento de componentes do Azure IoT Operations usando o Kubernetes está em versão prévia e não há suporte para sincronizar recursos da borda para a nuvem no momento.

Atualmente, não há nenhuma solução alternativa para esse problema.

Um perfil de fluxo de dados não pode exceder 70 fluxos de dados

ID do problema: 1028

Assinatura de log:

exec /bin/main: argument list too long

Se você criar mais de 70 fluxos de dados para um único perfil de fluxo de dados, as implantações falharão com o erro exec /bin/main: argument list too long.

Para contornar esse problema, crie vários perfis de fluxo de dados e distribua os fluxos de dados entre eles. Não exceda 70 fluxos de dados por perfil.

Os grafos de fluxo de dados só dão suporte a tipos de ponto de extremidade específicos

ID do problema: 5693

Assinatura de log: N/A

Atualmente, os grafos de fluxo de dados (WASM) dão suporte apenas a pontos de extremidade de fluxo de dados MQTT, Kafka e OpenTelemetry (OTel). Os pontos de extremidade OpenTelemetry só podem ser usados como destinos em grafos de fluxo de dados. Outros tipos de ponto de extremidade, como Data Lake, Microsoft Fabric OneLake, Azure Data Explorer e Armazenamento Local, não são compatíveis com grafos de fluxo de dados.

Para contornar esse problema, use um dos tipos de ponto de extremidade com suporte:

Para obter mais informações sobre grafos de fluxo de dados, confira Use WebAssembly (WASM) com grafos de fluxo de dados.

Não é possível usar a mesma definição de grafo várias vezes em um cenário de grafo encadeado

ID do problema: 1352

Falha ao enviar a configuração

Você cria um cenário de grafo encadeado usando a saída de um grafo de fluxo de dados como a entrada para outro grafo de fluxo de dados. No entanto, se você tentar usar a mesma definição de grafo várias vezes nesse cenário, ela atualmente não funcionará conforme o esperado. Por exemplo, o código a seguir falha ao usar a mesma definição de grafo (graph-passthrough:1.3.6) para ambos graph-1 e graph-2.

      {
          nodeType: 'Graph'
          name: 'graph-1'
          graphSettings: {
            registryEndpointRef: dataflowRegistryEndpoint.name
            artifact: 'graph-passthrough:1.3.6'
            configuration: []
            }
      }
      {
          nodeType: 'Graph'
          name: 'graph-2'
          graphSettings: {
            registryEndpointRef: dataflowRegistryEndpoint.name
            artifact: 'graph-passthrough:1.3.6'
            configuration: graphConfiguration
            }
      }
  nodeConnections: [
      {
          from: {name: 'source'}
          to: {name: 'graph-1'}
      }
      {
          from: {name: 'graph-1'}
          to: {name: 'graph-2'}
      }
      {
          from: {name: 'graph-2'}
          to: {name: 'destination'}
      }
  ]

Para resolver esse erro, envie a definição do grafo para o ACR quantas vezes forem necessárias, atribuindo um nome ou tag diferente ao cenário a cada vez. Por exemplo, no cenário descrito, a definição do grafo precisa ser transferida duas vezes com um nome diferente ou uma tag diferente, como graph-passthrough-one:1.3.6 e graph-passthrough-two:1.3.6.

  • Last updated on