Problèmes connus pour Opérations Azure IoT

Cet article répertorie les problèmes connus actuels que vous pouvez rencontrer lors de l’utilisation de Opérations Azure IoT. 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 Troubleshoot Opérations Azure IoT.

problèmes liés au Registre d’appareils Azure

Cette section répertorie les problèmes connus actuels pour le Registre d’appareils Azure.

Les ressources de l'état d'intégrité de l'espace de noms ADR ne se synchronisent pas de la périphérie vers le cloud.

ID de problème : 1235

Signature du journal : N/A

Les ressources d’état de santé des actifs de l’espace de noms Registre de Dispositifs Azure ne se synchronisent pas vers le cloud si elles ont été créées avec une version d’API antérieure à 2026-04-01. Cet échec se produit parce qu’une annotation de ressource Kubernetes requise est manquante.

Solution de contournement : utilisez le proxy arc pour vous connecter à votre cluster Kubernetes, puis exécutez le script remediation pour l'interpréteur de commandes que vous utilisez (PowerShell ou bash). Les scripts répertorient toutes les ressources d’espace de noms obsolètes et demandent la confirmation avant d’ajouter les annotations manquantes.

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 Opérations Azure IoT à l'aide de Kubernetes est uniquement destinée au débogage et au test, et la synchronisation des ressources de la périphérie vers le cloud n'est pas prise en charge actuellement.

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

Correction dans la version 2605 et ultérieure

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

Erreur Akri lors de la mise à jour ou de la suppression d’une instance de Opérations Azure IoT

ID de problème : 9347

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

Les utilisateurs peuvent rencontrer une erreur concernant les certificats webhook expirés avec Akri lors de la suppression/mise à niveau d’instances de Opérations Azure IoT ou d’opérations CRUD sur des ressources Akri telles que Connector et ConnectorTemplates.

Solution de contournement : Exécutez kubectl delete pod -n azure-iot-operations aio-akri-webhook-0 --ignore-not-found pour supprimer et redémarrer les pods webhook afin que le pod puisse récupérer le nouveau certificat.

Les points de terminaison entrants de l’appareil n’appliquent pas l’authentification lorsqu’aucun n’est spécifié

ID du problème : 7337

Signature du journal : N/A

Le schéma de ressource de l’appareil Azure Device Registry répertorie l’authentification basée sur des certificats (X.509) comme méthode d’authentification par défaut pour un point de terminaison entrant. Toutefois, la propriété d’authentification elle-même est nullable. Il est donc possible de créer un point de terminaison entrant d’appareil sans spécifier de méthode d’authentification.

Lorsque l’authentification est omise, la valeur par défaut implicite des certificats X.509 n’est pas appliquée au moment de l’exécution. Le point de terminaison entrant de l’appareil est créé sans authentification appliquée.

Recommandations:

• Communiquez toujours avec les points de terminaison entrants de l’appareil via un protocole authentifié.
• Configurez explicitement l’authentification basée sur un certificat, ou une autre méthode d’authentification prise en charge, dans la propriété d’authentification de chaque point de terminaison entrant. Ne vous fiez pas à la valeur par défaut du schéma : elle n’est pas appliquée implicitement.

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

Correction dans la version 1.3.36 (2603) et versions ultérieures

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.

Modèle de connecteur OPC manquant

ID du problème : 1330

Signature du journal : N/A

Le déploiement d’instance Opérations Azure IoT devrait installer par défaut un OPC ConnectorTemplate. Après le déploiement, le modèle de connecteur manque sur le portail Azure et la ConnectorTemplate ressource n'est pas présente dans le cluster.

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.

Solution de contournement : Configurez la destination de l’événement au niveau du groupe d’événements ou de l’actif plutôt qu’au niveau de l’événement individuel. Par exemple, utilisez 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 au connecteur pour MQTT

Incompatibilité de version du modèle de connecteur MQTT pendant la mise à jour

ID de problème : 1533

Signature du journal : N/A

Corrigé dans la version 2606 et ultérieure

Lors de la mise à jour vers la version 2605, les modèles de connecteur MQTT existants peuvent afficher des versions de métadonnées incompatibles dans le portail. Pour résoudre, supprimer et recréer le modèle de connecteur. Vous pouvez également utiliser le Azure CLI pour mettre à jour le connecteur.

Le connecteur MQTT ne peut pas se connecter à des répartiteurs MQTT externes qui ont des adresses IP privées

ID de problème : 7791

Signature du journal : N/A

Corrigé dans la version 2607 et ultérieure

À partir de la version 2605, le connecteur MQTT ne peut plus se connecter aux courtiers MQTT externes qui utilisent des adresses IP privées.

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

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

L’interface utilisateur web d’Operations Experience affiche uniquement les artefacts du graphe de flux de données issus d’Azure Container Registry (ACR) et de mcr.microsoft.com

ID de numéro : 8895

Signature du journal : N/A

Même si vous configurez un point de terminaison de registre conteneur pour un registre de conteneurs non-ACR, comme GHCR :

• Les artefacts des graphes de flux de données provenant du registre non-ACR n’apparaissent pas dans l’interface web de l’expérience d’opérations, donc vous ne pouvez pas créer un graphe de flux de données qui les utilise.

• Sélectionner un graphe de flux de données dans la liste des flux de données dans l’interface web d’expérience d’opérations qui contient des éléments provenant d’un registre non-ACR produit une erreur similaire à : Can't load data flow graph. The contents of this data flow graph are unavailable. Please ensure that it still exists, then work with your administrator to get 'AcrPull' access to required registry endpoints.

Solution de contournement : Vous avez deux options :

• Si vous n’avez pas besoin d’utiliser l’interface utilisateur de l’expérience des opérations, utilisez Azure CLI pour effectuer des opérations CRUD sur des graphes de flux de données définis dans des fichiers JSON ou Bicep contenant des artefacts provenant de registres non ACR.

• Si vous souhaitez utiliser l’interface web d’expérience des opérations, importez des artefacts de flux de données et des graphes provenant de registres non-ACR dans un registre ACR. Pour en savoir plus, consultez Transférer des modules vers votre registre.

Les ressources de flux de données créées avec Kubernetes ne sont pas visibles dans l’interface web de l’expérience d’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 Opérations Azure IoT à l'aide de Kubernetes est uniquement destinée au débogage et au test, et la synchronisation des ressources de la périphérie vers le cloud n'est pas prise en charge actuellement.

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.

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

Correction dans la version 1.3.36 (2603) et versions ultérieures

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

Questions d’identité fédérée

Cette section énumère les problèmes actuels connus concernant l’identité fédérée.

Le désaccord entre les émetteurs d’identifiants d’identité fédérés peut provoquer des échecs d’authentification par synchronisation secrète

ID du problème : 1190

Corrigé dans la version 2607 et ultérieure

Signature de journal : similaire à AADSTS700211: No matching federated identity record found for presented assertion issuer 'https://northamerica.oic.prod-arc.azure.com/1f5f7baf-633d-4eb5-9be1-8cf1e9c6fcc9/f512e8f6-0c47-48a1-91f3-aeb5422dd766'. Please check your federated identity credential Subject, Audience and Issuer against the presented assertion.

Opérations Azure IoT rencontre 401 erreurs non autorisées lors de la récupération de secrets depuis Azure Key Vault.

Cause principale : L’erreur survient parce que l’URL émetteur fédérée de l’identifiant d’identité ne correspond pas à la revendication de l’émetteur (iss) dans le jeton de compte de service Kubernetes.

Lorsque la az iot ops secretsync enable commande crée une identifiante fédérée (FIC) sur l'identité managée attribuée par l'utilisateur que Opérations Azure IoT utilise pour accéder à Azure Key Vault, elle règle l'URL de l'émetteur FIC à celle de l'émetteur OIDC du cluster. Dans certains déploiements, cette URL comporte une barre oblique finale (« / ») qui ne figure pas dans la revendication iss (émetteur) du jeton de compte de service émis par le cluster.

Comme le problème affecte l’échange de jetons lors de la récupération du secret, l’échec ne se produit généralement pas lorsque vous exécutez az iot ops secretsync enable. Au lieu de cela, il refait surface plus tard lorsque Opérations Azure IoT tente d’accéder à un secret, ce qui peut rendre difficile l’identification de la cause profonde.

Solution de contournement : Vérifiez que l’URL de l’émetteur configurée dans les informations d’identification d’identité fédérée ne se termine pas par une barre oblique. Le cas échéant, mettez à jour les informations d’identification d’identité fédérée pour supprimer la barre oblique finale.

Vous pouvez utiliser les commandes Azure CLI az identity federated-credential pour afficher et, si nécessaire, mettre à jour la valeur de l’émetteur des informations d’identification d’identité fédérée, par exemple :

az identity federated-credential show --name <fic-name> --identity-name <managed-identity-name> --resource-group <resource-group-name>

az identity federated-credential update --name <fic-name> --identity-name <managed-identity-name> --resource-group <resource-group> --issuer <new-issuer-url-without-trailing-slash>

En guise de bonne pratique, effectuez cette validation lors de la configuration après avoir lancé la az iot ops secretsync enable commande afin d’éviter des échecs d’authentification potentiellement difficiles à diagnostiquer ultérieurement.