Partager via

Problèmes connus pour les opérations Azure IoT

Cet article répertorie les problèmes connus actuels que vous pouvez rencontrer lors de l’utilisation d’Azure IoT Operations. Les conseils vous aident à identifier ces problèmes et à fournir des solutions de contournement le cas échéant.

Pour obtenir des conseils généraux sur la résolution des problèmes, consultez Résoudre les problèmes liés aux opérations Azure IoT.

Problèmes liés au répartiteur MQTT

Cette section répertorie les problèmes connus actuels pour le répartiteur MQTT.

Les ressources du répartiteur MQTT ne sont pas visibles dans le portail Azure

ID du problème : 4257

Signature du journal : N/A

Les ressources broker MQTT créées dans votre cluster à l’aide de Kubernetes ne sont pas visibles dans le portail Azure. Ce résultat est attendu, car la gestion des composants Azure IoT Operations à l’aide de Kubernetes est en préversion et la synchronisation des ressources de la périphérie vers le cloud n’est actuellement pas prise en charge.

Il n’existe actuellement aucun moyen de contourner ce problème.

Problèmes généraux liés au connecteur

Cette section répertorie les problèmes connus actuels qui affectent tous les connecteurs.

Le connecteur ne détecte pas les mises à jour des informations d’identification de l’appareil dans Azure Key Vault

ID de problème : 6514

N/A

Le connecteur ne reçoit pas de notification lorsque les informations d’identification de l’appareil stockées dans Azure Key Vault sont mises à jour. Par conséquent, le connecteur continue d’utiliser les anciennes informations d’identification jusqu’à ce qu’il soit redémarré.

Solution de contournement : redémarrez le connecteur pour le forcer à récupérer les informations d’identification mises à jour à partir d’Azure Key Vault.

Pour les connecteurs Akri, le seul type d’authentification pris en charge pour les points de terminaison de Registre est artifact pull secrets

ID du problème : 4570

Signature du journal : N/A

Lorsque vous spécifiez la référence de point de terminaison de Registre dans un modèle de connecteur, il existe plusieurs méthodes d’authentification prises en charge. Les connecteurs Akri ne prennent en charge l'authentification que pour artifact pull secrets.

Les connecteurs Akri ne fonctionnent pas avec les ressources de point de terminaison de registre

ID du problème : 7710

Correction dans la version 1.2.154 (2512) et versions ultérieures

Signature du journal :

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

Lorsque vous créez une ressource RegistryEndpoint à l'aide de Bicep et que vous la référencez dans la ressource ConnectorTemplate, alors lorsque l'opérateur Akri tente de réconcilier ConnectorTemplate, il échoue avec l'erreur indiquée précédemment.

Contournement : ne pas utiliser les RegistryEndpoint ressources avec des connecteurs Akri. Au lieu de cela, spécifiez les informations de Registre dans les ContainerRegistry paramètres de la ConnectorTemplate ressource.

URL du connecteur OPC UA

Cette section répertorie les problèmes connus actuels du connecteur pour OPC UA.

Impossible d’utiliser des caractères spéciaux dans les noms d’événements

ID du problème : 1532

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

La génération de schéma échoue si les noms d’événements contiennent des caractères spéciaux tels que #, %ou &. Évitez d’utiliser ces caractères dans les noms d’événements pour empêcher les problèmes de génération de schéma.

Connecteur pour médias et connecteur pour les problèmes ONVIF

Cette section répertorie les problèmes connus actuels du connecteur pour le média et le connecteur pour ONVIF.

Conflit de synchronisation des secrets

ID de problème : 0606

Signature du journal : N/A

Lorsque vous utilisez la synchronisation des secrets, vérifiez que les noms de secrets sont globalement uniques. Si un secret local portant le même nom existe, les connecteurs peuvent ne pas récupérer le secret prévu.

La destination de l’événement d’événement de ressource ONVIF ne peut être configurée qu’au niveau du groupe ou de la ressource

ID de problème : 9545

Correction dans la version 1.2.154 (2512) et versions ultérieures

Signature de log semblable à :

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

Actuellement, les destinations d’événements de ressources ONVIF sont reconnues uniquement au niveau du groupe d’événements ou de la ressource. La configuration des destinations au niveau des événements individuels entraîne des entrées de journal similaires à l’exemple, et aucune donnée d’événement n’est publiée sur le répartiteur MQTT.

Pour contourner ce problème, configurez la destination d’événement au niveau du groupe d’événements ou de la ressource au lieu du niveau d’événement individuel. Par exemple, en utilisant defaultEventsDestinations au niveau du groupe d’événements :

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

Problèmes liés aux flux de données

Cette section répertorie les problèmes connus actuels pour les flux de données.

Les ressources de flux de données ne sont pas visibles dans l’interface utilisateur web de l’expérience des opérations

ID de problème : 8724

Signature du journal : N/A

Les ressources personnalisées de flux de données créées dans votre cluster à l’aide de Kubernetes ne sont pas visibles dans l’interface utilisateur web de l’expérience des opérations. Ce résultat est attendu, car la gestion des composants Azure IoT Operations à l’aide de Kubernetes est en préversion et la synchronisation des ressources de la périphérie vers le cloud n’est actuellement pas prise en charge.

Il n’existe actuellement aucun moyen de contourner ce problème.

Un profil de flux de données ne peut pas dépasser 70 flux de données

ID de problème : 1028

Signature du journal :

exec /bin/main: argument list too long

Si vous créez plus de 70 flux de données pour un profil de flux de données unique, les déploiements échouent avec l’erreur exec /bin/main: argument list too long.

Pour contourner ce problème, créez plusieurs profils de flux de données et distribuez les flux de données entre eux. Ne dépassez pas 70 flux de données par profil.

Les graphiques de flux de données prennent uniquement en charge des types de points de terminaison spécifiques

ID de problème : 5693

Signature du journal : N/A

Les graphiques de flux de données (WASM) prennent uniquement en charge les points de terminaison de flux de données MQTT, Kafka et OpenTelemetry (OTel). Les points de terminaison OpenTelemetry ne peuvent être utilisés que comme destinations dans les graphiques de flux de données. D’autres types de points de terminaison tels que Data Lake, Microsoft Fabric OneLake, Azure Data Explorer et Stockage local ne sont pas pris en charge pour les graphiques de flux de données.

Pour contourner ce problème, utilisez l’un des types de points de terminaison pris en charge :

Pour plus d’informations sur les graphiques de flux de données, consultez Utiliser WebAssembly (WASM) avec des graphiques de flux de données.

Impossible d’utiliser la même définition de graphe plusieurs fois dans un scénario de graphique chaîné

ID du problème : 1352

Échec de l’envoi de la configuration

Vous créez un scénario de graphique chaîné à l’aide de la sortie d’un graphique de flux de données comme entrée vers un autre graphique de flux de données. Toutefois, si vous essayez d’utiliser la même définition de graphique plusieurs fois dans ce scénario, elle ne fonctionne actuellement pas comme prévu. Par exemple, le code suivant échoue lors de l’utilisation de la même définition de graphe (graph-passthrough:1.3.6) pour les deux graph-1 et 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'}
      }
  ]

Pour résoudre cette erreur, poussez la définition du graphe vers l'ACR autant de fois que nécessaire, chaque fois avec un scénario portant un nom ou une balise différent. Par exemple, dans le scénario décrit, la définition de graphique doit être envoyée deux fois avec un nom différent ou une balise différente, comme graph-passthrough-one:1.3.6 et graph-passthrough-two:1.3.6.

  • Last updated on