Partager via

Problèmes connus : 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 de déploiement, de mise à jour et de désinstallation

Cette section répertorie les problèmes connus actuels qui peuvent se produire lorsque vous déployez, mettez à jour ou désinstallez les opérations Azure IoT.

Erreur lors de la création de ressources personnalisées

ID du problème : 9091

Signature du journal : "code": "ExtensionOperationFailed", "message": "The extension operation failed with the following error: Error occurred while creating custom resources needed by system extensions"

Le message Error occurred while creating custom resources needed by system extensions indique que votre déploiement a échoué en raison d’un problème sporadique connu.

Pour contourner ce problème, utilisez la az iot ops delete commande avec l’indicateur --include-deps pour supprimer les opérations Azure IoT de votre cluster. Une fois Opérations Azure IoT et ses dépendances supprimées de votre cluster, réessayez le déploiement.

Erreur de redémarrage de Codespaces

ID de problème : 9941

Signature du journal : "This codespace is currently running in recovery mode due to a configuration error."

Si vous déployez Opérations Azure IoT dans GitHub Codespaces, l’arrêt et le redémarrage de Codespace provoque un problème This codespace is currently running in recovery mode due to a configuration error.

Il n’existe aucune solution de contournement pour ce problème. Si vous avez besoin d’un cluster qui prend en charge l’arrêt et le redémarrage, sélectionnez l’une des options de préparation de votre cluster Kubernetes avec Azure Arc.

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 de gestion de réseau à couches Azure IoT (aperçu)

Cette section répertorie les problèmes connus actuels liés à la gestion du réseau en couches Azure IoT.

Le service de gestion réseau en couches n’obtient pas d’adresse IP

ID de problème : 7864

Signature du journal : N/A

Le service de gestion réseau en couches n’obtient pas d’adresse IP lorsqu’il s’exécute sur K3S sur un hôte Ubuntu.

Pour contourner ce problème, vous réinstallez K3S sans le contrôleur d’entrée traefik :

curl -sfL https://get.k3s.io | sh -s - --disable=traefik --write-kubeconfig-mode 644

Pour en savoir plus, consultez Mise en réseau | K3s.

Le service CoreDNS ne résout pas correctement les requêtes DNS

ID de problème : 7955

Signature du journal : N/A

Les requêtes DNS ne sont pas résolues à l’adresse IP attendue lors de l’utilisation du service CoreDNS s’exécutant au niveau du réseau enfant.

Pour contourner ce problème, effectuez une mise à niveau vers Ubuntu 22.04 et réinstallez K3S.

URL du connecteur OPC UA

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

Le pod de connecteur ne redémarre pas après la modification de la configuration

ID du problème : 7518

Signature du journal : N/A

Quand vous ajoutez un nouvel actif avec un nouveau profil de point de terminaison d'actif au répartiteur OPC UA et que vous engagez une reconfiguration, le déploiement des pods opc.tcp change pour prendre en charge les nouveaux montages sécurisés pour le nom d’utilisateur et le mot de passe. Si le nouveau montage échoue pour une raison quelconque, le pod ne redémarre pas et, par conséquent, l’ancien flux pour les ressources correctement configurées s’arrête également.

Pic de données toutes les 2,5 heures avec certains simulateurs OPC UA

ID de problème : 6513

Signature du journal : Augmentation du volume des messages toutes les 2,5 heures

Les valeurs de données augmentent toutes les 2,5 heures lors de l’utilisation de simulateurs OPC UA particuliers provoquant des pics d’UC et de mémoire. Ce problème n’est pas vu avec le simulateur OPC PLC utilisé dans les démarrages rapides. Aucune donnée n’est perdue, mais vous pouvez voir une augmentation du volume de données publiées du serveur vers le répartiteur MQTT.

Aucun schéma de message généré si les nœuds sélectionnés dans un jeu de données référencent la même définition de type de données complexe

ID de problème : 7369

Signature du journal : An item with the same key has already been added. Key: <element name of the data type>

Aucun schéma de message n’est généré si les nœuds sélectionnés dans un jeu de données font référence à la même définition de type de données complexe (un UDT de type struct ou enum).

Si vous sélectionnez des points de données (ID de nœud) pour un ensemble de données utilisant des définitions de types complexes dans un espace de noms qui n'est pas OPC UA (structure ou énumération), le schéma JSON n'est pas généré. Le schéma ouvert par défaut s’affiche lorsque vous créez un flux de données à la place. Par exemple, si le jeu de données contient trois valeurs d’un type de données, alors qu'il fonctionne ou non est indiqué dans le tableau suivant. Vous pouvez remplacer int par n’importe quel type OPC UA intégré ou type primitif tel que string, double, float, ou long:

Type de valeur 1 Type de valeur 2 Type de valeur 3 Génère correctement le schéma
int int int Oui
int int int Oui
int int struct A Oui
int enum A struct A Oui
enum A enum B enum C Oui
struct A struct B struct C Oui
int struct A struct A Non
int enum A enum A Non

Pour contourner ce problème, vous pouvez :

  • Fractionnez le jeu de données sur deux ressources ou plus.
  • Chargez manuellement un schéma.
  • Utilisez l’expérience non-schema par défaut dans le concepteur de flux de données.

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.

Le processus de suppression CRD AssetType ne se termine pas

ID de problème : 6065

Signature du journal : "Error HelmUninstallUnknown: Helm encountered an error while attempting to uninstall the release aio-118117837-connectors in the namespace azure-iot-operations. (caused by: Unknown: 1 error occurred: * timed out waiting for the condition"

Parfois, lorsque vous tentez de désinstaller Azure IoT Operations à partir du cluster, le système peut accéder à un état où le travail de suppression CRD est bloqué dans un état en attente et qui bloque le nettoyage des opérations Azure IoT.

Pour contourner ce problème, procédez comme suit pour supprimer manuellement le CRD et terminer la désinstallation :

  1. Supprimez manuellement le CRD AssetType : kubectl delete crd assettypes.opcuabroker.iotoperations.azure.com --ignore-not-found=true

  2. Supprimez la définition du travail : kubectl delete job aio-opc-delete-crds-job-<version> -n azure-iot-operations

  3. Recherchez la mise en production Helm pour les connecteurs ; il s’agit de celle avec le suffixe -connectors : helm ls -a -n azure-iot-operations

  4. Désinstallez la mise en production Helm sans exécuter le hook : helm uninstall aio-<id>-connectors -n azure-iot-operations --no-hooks

Découverte de ressources avec des problèmes liés aux services Akri

Cette section répertorie les problèmes connus actuels liés à la découverte de ressources avec les services Akri.

La découverte des ressources ne fonctionne pas pendant une heure après la mise à niveau

ID du problème : 0407

Signature du journal : N/A

Lorsque vous mettez à niveau les services Akri, vous risquez de perdre des messages et des ressources pendant une heure après la mise à niveau.

Pour contourner ce problème, attendez une heure après la mise à niveau et réexécutez le scénario de détection des ressources.

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.

Impossible de configurer l’authentification X.509 pour les points de terminaison Kafka personnalisés

ID de problème : 8750

Signature du journal : N/A

L’authentification X.509 pour les points de terminaison Kafka personnalisés n’est actuellement pas prise en charge.

Échecs de connexion avec Azure Event Grid

ID de problème : 8891

Signature du journal : N/A

Lorsque vous connectez plusieurs instances d’opérations IoT au même espace de noms MQTT Event Grid, les échecs de connexion peuvent se produire en raison de conflits d’ID client. Les ID client sont actuellement dérivés des noms de ressources de flux de données et, lors de l’utilisation de l’infrastructure en tant que modèles de code pour le déploiement, les ID client générés peuvent être identiques.

Pour contourner ce problème, ajoutez un caractère aléatoire aux noms de flux de données dans vos modèles de déploiement.

Le déploiement de flux de données ne se termine pas

ID du problème : 9411

Signature du journal :

"Dataflow pod had error: Bad pod condition: Pod 'aio-dataflow-operator-0' container 'aio-dataflow-operator' stuck in a bad state due to 'CrashLoopBackOff'"

"Failed to create webhook cert resources: Failed to update ApiError: Internal error occurred: failed calling webhook "webhook.cert-manager.io" [...]"

Lorsque vous créez un flux de données, il se peut qu’il ne termine pas le déploiement. La cause est que le cert-manager n’était pas prêt ou ne fonctionne pas.

Pour contourner ce problème, effectuez ces étapes afin de supprimer manuellement le pod d’opérateur de flux de données pour effacer l’état d’incident :

  1. Exécutez kubectl get pods -n azure-iot-operations. Dans la sortie, vérifiez qu’aio-dataflow-operator-0 est le seul pod d’opérateur de flux de données en cours d’exécution.

  2. Exécutez kubectl logs --namespace azure-iot-operations aio-dataflow-operator-0 pour vérifier les journaux du pod d’opérateur de flux de données.

    Dans la sortie, recherchez la dernière entrée du journal :

    Dataflow pod had error: Bad pod condition: Pod 'aio-dataflow-operator-0' container 'aio-dataflow-operator' stuck in a bad state due to 'CrashLoopBackOff'

  3. Réexécutez la commande kubectl logs avec l’option--previous.

    kubectl logs --namespace azure-iot-operations --previous aio-dataflow-operator-0

    Dans la sortie, recherchez la dernière entrée du journal :

    Failed to create webhook cert resources: Failed to update ApiError: Internal error occurred: failed calling webhook "webhook.cert-manager.io" [...]. ID de problème :2382 Si vous voyez les deux entrées de journal à partir des deux commandes kubectl log, le gestionnaire de certificats n'était pas prêt ou en train de s'exécuter.

  4. Exécutez kubectl delete pod aio-dataflow-operator-0 -n azure-iot-operations pour supprimer le pod d’opérateur de flux de données. La suppression du pod efface l’état d’incident et redémarre le pod.

  5. Attendez que le pod d’opérateur redémarre et déploie le flux de données.

Métriques d’erreur des flux de données

ID de problème : 2382

Signature du journal : N/A

Les flux de données marquent les réessais de message et les reconnexions en tant qu’erreurs et, par conséquent, les flux de données peuvent sembler non sains. Ce comportement n’est vu que dans les versions précédentes des flux de données. Passez en revue les journaux pour déterminer si le flux de données est sain.