Problemi noti per Operazioni di Azure IoT

Questo articolo elenca i problemi noti correnti che possono verificarsi quando si usa Operazioni di Azure IoT. Le indicazioni consentono di identificare questi problemi e di fornire soluzioni alternative, se disponibili.

Per indicazioni generali sulla risoluzione dei problemi, vedere Troubleshoot Operazioni di Azure IoT.

Problemi di distribuzione e aggiornamento

Questa sezione elenca i problemi noti correnti relativi alla distribuzione e all'aggiornamento di Operazioni di Azure IoT.

L'aggiornamento a Operazioni di Azure IoT 2603 può fallire in modo silente.

Firma del log: N/A

Quando si esegue az iot ops upgrade per eseguire l'aggiornamento a Operazioni di Azure IoT 2603, l'aggiornamento non riesce a raggiungere automaticamente il cluster. Si osservano quindi i sintomi seguenti:

  • provisioningState: Failed nell'estensione Operazioni di Azure IoT.
  • Tutti i carichi di lavoro nel cluster rimangono integri (non si verifica alcuna attività di aggiornamento).
  • az iot ops upgrade potrebbe non segnalare alcun elemento da aggiornare ai tentativi successivi.

Causa principale

  Durante l'aggiornamento, se un'estensione di sistema da cui dipende, ad esempio microsoft.extensiondiagnostics, riscontra un timeout Helm temporaneo, Azure Resource Manager lo contrassegna come Failed. Anche se l'estensione ha esito positivo nel cluster, lo stato nel cloud rimane Errore. In questo modo si blocca la catena di dipendenze, Azure Resource Manager non recapita mai la configurazione aggiornata dell'estensione Operazioni di Azure IoT o dell'archivio segreto all'agente di configurazione del cluster.   I sintomi includono:

  • La funzionalità PostStatus restituita dall'agente di configurazione 400: "Configuration spec has been modified"
  • getPendingConfigs restituisce risultati vuoti
  • Il gestore delle estensioni non riceve mai le istruzioni di aggiornamento per Helm.

Soluzione

  La soluzione alternativa consiste nel forzare Azure Resource Manager a inviare nuovamente le specifiche di estensione eseguendo un aggiornamento no-op nelle estensioni Operazioni di Azure IoT e secret store, quindi ritentando l'aggiornamento:

az k8s-extension update --name <aio-extension-name> \
    --cluster-name <cluster-name> \
    --resource-group <resource-group> \
    --cluster-type connectedClusters \
    --configuration-settings AgentOperationTimeoutInMinutes=120

az k8s-extension update --name azure-secret-store \
    --cluster-name <cluster-name> \
    --resource-group <resource-group> \
    --cluster-type connectedClusters \
    --configuration-settings AgentOperationTimeoutInMinutes=120

az iot ops upgrade

Per identificare il nome dell'estensione Operazioni di Azure IoT, che include un suffisso casuale (ad esempio, azure-iot-operations-cym7h), trovare il nome dell'estensione specifico eseguendo:

az k8s-extension list \
    --cluster-name <cluster-name> \
    --resource-group <resource-group> \
    --cluster-type connectedClusters \
    --query "[?extensionType=='microsoft.iotoperations'].name" -o tsv

Importante

Al termine dell'aggiornamento, ripristinare AgentOperationTimeoutInMinutes un valore inferiore, ad esempio cinque minuti, per evitare tempi di attesa lunghi nelle operazioni future in caso di errore di altro tipo.

Problemi del Registro dei dispositivi di Azure

Questa sezione elenca i problemi noti correnti per il registro dei dispositivi di Azure.

Le risorse degli asset ADR non vengono sincronizzate

ID problema: 1235

Firma del log: N/A

Le risorse Registro Dispositivi Azure non vengono sincronizzate se sono state create con una versione precedente dell'API.

Problemi del broker MQTT

Questa sezione elenca i problemi noti correnti per il broker MQTT.

Le risorse broker MQTT non sono visibili nel portale di Azure

ID problema: 4257

Firma del log: N/A

Le risorse broker MQTT create nel cluster con Kubernetes non sono visibili nel portale di Azure. Questo risultato è previsto perché la gestione dei componenti Operazioni di Azure IoT con Kubernetes è destinata solo per il debug e i test e sincronizzare le risorse dal perimetro al cloud non è attualmente supportato.

Attualmente non è disponibile alcuna soluzione alternativa per questo problema.

Problemi generali del connettore

Questa sezione elenca i problemi noti correnti che interessano tutti i connettori.

Il connettore non rileva gli aggiornamenti delle credenziali del dispositivo in Azure Key Vault

ID problema: 6514

N/A

Il connettore non riceve una notifica quando le credenziali del dispositivo archiviate in Azure Key Vault vengono aggiornate. Di conseguenza, il connettore continua a usare le credenziali precedenti finché non viene riavviato.

Soluzione alternativa: riavviare il connettore per forzare il recupero delle credenziali aggiornate da Azure Key Vault.

Per i connettori Akri, l'unico tipo di autenticazione supportato per gli endpoint del Registro di sistema è artifact pull secrets

ID problema: 4570

Firma del log: N/A

Quando si specifica il riferimento all'endpoint del Registro di sistema in un modello di connettore, sono disponibili più metodi di autenticazione supportati. I connettori Akri supportano solo l'autenticazione artifact pull secrets.

I connettori Akri non funzionano con le risorse dell'endpoint del Registro di sistema

ID problema: 7710

Correzione nella versione 1.2.154 (2512) e successive

Firma del 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 si crea una risorsa RegistryEndpoint con Bicep e vi si fa riferimento nella risorsa ConnectorTemplate, l'operatore Akri non riesce a completare l'operazione quando tenta di riconciliare ConnectorTemplate, restituendo l'errore mostrato in precedenza.

Soluzione alternativa: non usare le RegistryEndpoint risorse con i connettori Akri. Specificare invece le informazioni del registro nelle ContainerRegistry impostazioni della ConnectorTemplate risorsa.

Errore di Akri durante l'aggiornamento o l'eliminazione di un'istanza di Operazioni di Azure IoT

ID problema: 9347

Correzione nella versione 1.2.154 (2512) e successive

Gli utenti possono riscontrare un errore relativo ai certificati webhook scaduti con Akri durante l'eliminazione o l'aggiornamento di istanze di Operazioni di Azure IoT o l'esecuzione di operazioni CRUD su risorse Akri, ad esempio Connector e ConnectorTemplates.

Soluzione alternativa: eseguire kubectl delete pod -n azure-iot-operations aio-akri-webhook-0 --ignore-not-found per eliminare e riavviare i pod webhook per consentire al pod di raccogliere il nuovo certificato.

Problemi del connettore per OPC UA

Questa sezione elenca i problemi noti correnti per il connettore per OPC UA.

Non è possibile usare caratteri speciali nei nomi degli eventi

ID problema: 1532

Correzione nella versione 1.3.36 (2603) e successive

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

La generazione dello schema ha esito negativo se i nomi degli eventi contengono caratteri speciali, ad #esempio , %o &. Evitare di usare questi caratteri nei nomi degli eventi per evitare problemi di generazione dello schema.

Connettore per supporti e connettori per problemi ONVIF

Questa sezione elenca i problemi noti attuali per il connettore per i contenuti multimediali e il connettore per ONVIF.

Conflitto di sincronizzazione dei segreti

ID problema: 0606

Firma del log: N/A

Quando si usa la sincronizzazione dei segreti, assicurarsi che i nomi dei segreti siano univoci a livello globale. Se esiste un segreto locale con lo stesso nome, i connettori potrebbero non riuscire a recuperare il segreto previsto.

La destinazione evento dell'asset ONVIF può essere configurata solo a livello di gruppo o asset

ID problema: 9545

Correzione nella versione 1.2.154 (2512) e successive

Firma del log simile a:

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

Attualmente, le destinazioni degli eventi degli asset ONVIF vengono riconosciute solo a livello di gruppo di evento o di asset. La configurazione delle destinazioni a livello di singolo evento comporta voci di log simili all'esempio e nessun dato dell'evento viene pubblicato nel broker MQTT.

Come soluzione alternativa, configurare la destinazione dell'evento a livello di gruppo di eventi o asset anziché a livello di singolo evento. Ad esempio, usando defaultEventsDestinations a livello di gruppo di eventi:

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

Problemi relativi ai flussi di dati

Questa sezione elenca i problemi noti correnti per i flussi di dati.

Le risorse del flusso di dati non sono visibili nell'interfaccia utente Web dell'esperienza operativa

ID problema: 8724

Firma del log: N/A

Le risorse personalizzate del flusso di dati create nel cluster con Kubernetes non sono visibili nell'interfaccia utente Web dell'esperienza operativa. Questo risultato è previsto perché la gestione dei componenti Operazioni di Azure IoT con Kubernetes è destinata solo per il debug e i test e sincronizzare le risorse dal perimetro al cloud non è attualmente supportato.

Attualmente non è disponibile alcuna soluzione alternativa per questo problema.

Un profilo flusso di dati non può superare i 70 flussi di dati

ID problema: 1028

Firma del log:

exec /bin/main: argument list too long

Se si creano più di 70 flussi di dati per un singolo profilo del flusso di dati, le distribuzioni hanno esito negativo con l'errore exec /bin/main: argument list too long.

Per risolvere questo problema, creare più profili del flusso di dati e distribuire i flussi di dati tra di essi. Non superare i 70 flussi di dati per profilo.

I grafici del flusso di dati supportano solo tipi di endpoint specifici

ID problema: 5693

Firma del log: N/A

I grafici del flusso di dati (WASM) supportano attualmente solo gli endpoint del flusso di dati MQTT, Kafka e OpenTelemetry (OTel). Gli endpoint OpenTelemetry possono essere usati solo come destinazioni nei grafici del flusso di dati. Altri tipi di endpoint, ad esempio Data Lake, Microsoft Fabric OneLake, Esplora dati di Azure e Archiviazione locale non sono supportati per i grafici del flusso di dati.

Per risolvere questo problema, usare uno dei tipi di endpoint supportati:

  • Endpoint MQTT per la messaggistica bidirezionale con broker MQTT
  • Endpoint Kafka per la messaggistica bidirezionale con broker Kafka, tra cui Hub eventi di Azure
  • Endpoint OpenTelemetry per l'invio di metriche e log alle piattaforme di osservabilità (solo destinazione)

Per altre informazioni sui grafici del flusso di dati, vedere Usare WebAssembly (WASM) con grafici del flusso di dati.

Non è possibile usare più volte la stessa definizione del grafo in uno scenario a grafo concatenato

ID problema: 1352

Correzione nella versione 1.3.36 (2603) e successive

Impossibile inviare la configurazione

Si crea uno scenario a grafo concatenato usando l'output di un grafico del flusso di dati come input per un altro grafico del flusso di dati. Tuttavia, se si tenta di usare più volte la stessa definizione del grafo in questo scenario, attualmente non funziona come previsto. Ad esempio, il codice seguente ha esito negativo quando si usa la stessa definizione del grafo (graph-passthrough:1.3.6) sia per graph-1 che per 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'}
      }
  ]

Per risolvere questo errore, eseguire il push della definizione del grafo in Registro Azure Container tutte le volte necessarie, usando ogni volta uno scenario con un nome o un tag diverso. Nello scenario descritto, ad esempio, la definizione del grafo deve essere inserita due volte con un nome diverso o un tag diverso, ad esempio graph-passthrough-one:1.3.6 e graph-passthrough-two:1.3.6.

Problemi di listener broker

Questa sezione elenca i problemi noti correnti per i listener broker.

Azure portale non riesce a recuperare le autenticazioni broker

ID problema: 3072

Firma del log: messaggio portale Azure Fetch broker authentications: Failed to fetch broker authentications

Quando si configura un listener broker nel portale di Azure e si seleziona un valore nell'elenco a discesa "Autenticazione", il portale tenta di recuperare l'elenco di autenticazioni broker. Nel portale viene visualizzato il messaggio di Fetch broker authentications: Failed to fetch broker authenticationserrore .

Per risolvere questo problema, eseguire l'aggiornamento alla versione 2603.

  • Last updated on