Solutions aux problèmes courants liés à Azure IoT Edge

Article
07/17/2024

Attention

Cet article fait référence à CentOS, une distribution Linux ayant atteint l’état EOL (fin du service). Veuillez considérer votre utilisation et votre planification en conséquence. Pour plus d’informations, consultez l’aide relative à la fin de vie de CentOS.

S’applique à : IoT Edge 1.5 IoT Edge 1.4

Important

IoT Edge 1.5 LTS et IoT Edge 1.4 LTS sont des versions prises en charge. IoT Edge 1.4 LTS sera en fin de vie le 12 novembre 2024. Si vous utilisez une version antérieure, consultez l’article Mettre à jour IoT Edge.

Utilisez cet article pour identifier et résoudre les problèmes courants lors de l’utilisation de solutions IoT Edge. Si vous souhaitez savoir comment trouver les journaux et les erreurs sur votre appareil IoT Edge, consultez Problèmes courants et résolutions pour Azure IoT Edge.

Provisionnement et déploiement

Après son déploiement, le module IoT Edge n’est plus visible sur l’appareil

Symptômes

Une fois que les modules d’un appareil IoT Edge ont été définis, ils sont déployés, mais au bout de quelques minutes, ils ne sont plus visibles sur l’appareil et ils n’apparaissent plus dans les détails de l’appareil dans le Portail Azure. D’autres modules que ceux définis peuvent également apparaître sur l’appareil.

Cause

Si un déploiement automatique cible un appareil, il est prioritaire sur la définition manuelle des modules pour un seul appareil. La fonctionnalité Définir des modules dans le Portail Azure ou la fonctionnalité Créer un déploiement pour un seul appareil dans Visual Studio Code s’applique pendant un moment. Vous voyez les modules que vous avez définis démarrer sur l’appareil. Ensuite, la priorité du déploiement automatique s’applique et remplace les propriétés souhaitées de l’appareil.

Solution

Utilisez un seul type de mécanisme de déploiement par appareil, qu’il s’agisse d’un déploiement automatique ou de déploiements d’appareils individuels. Si vous avez plusieurs déploiements automatiques ciblant un appareil, vous pouvez changer la priorité ou les descriptions des cibles pour être sûr que le déploiement approprié est effectué sur l’appareil. Vous pouvez également mettre à jour le jumeau d’appareil pour qu’il ne corresponde plus à la description de la cible du déploiement automatique.

Pour plus d’informations, consultez Comprendre les déploiements automatiques IoT Edge pour un seul ou de nombreux appareils.

Runtime IoT Edge

L’agent IoT Edge s’arrête après une minute

Symptômes

Le module edgeAgent démarre et s’exécute avec succès pendant environ une minute, puis s’arrête. Les journaux d’activité indiquent que l’agent IoT Edge tente de se connecter à IoT Hub via AMQP, puis essaie de se connecter à l’aide d’AMQP sur WebSocket. Lorsque cette tentative échoue, l’agent IoT Edge se ferme.

Exemples de journaux d’activité edgeAgent :

2017-11-28 18:46:19 [INF] - Starting module management agent.
2017-11-28 18:46:19 [INF] - Version - 1.0.7516610 (03c94f85d0833a861a43c669842f0817924911d5)
2017-11-28 18:46:19 [INF] - Edge agent attempting to connect to IoT Hub via AMQP...
2017-11-28 18:46:49 [INF] - Edge agent attempting to connect to IoT Hub via AMQP over WebSocket...

Cause

Une configuration de mise en réseau sur le réseau hôte empêche l’agent IoT Edge d’atteindre le réseau. L’agent tente de se connecter via AMQP (port 5671) en premier. Si la connexion échoue, il essaie via les WebSockets (port 443).

Le runtime IoT Edge configure un réseau pour chacun des modules sur lesquels communiquer. Sur Linux, ce réseau est un réseau de pont. Sur Windows, il utilise NAT. Ce problème est plus courant sur les appareils Windows utilisant des conteneurs Windows qui utilisent le réseau NAT.

Solution

Assurez-vous qu’il existe un itinéraire vers Internet pour les adresses IP affectées à ce réseau pont/NAT. Parfois, une configuration VPN sur l’hôte remplace le réseau IoT Edge.

Le module Edge Agent rapporte le message « fichier config vide » et aucun module ne démarre sur l’appareil

Symptômes

L’appareil rencontre des difficultés pour démarrer les modules définis dans le déploiement. Seul edgeAgent est en cours d’exécution, mais il signale fichier de configuration vide....
Lorsque vous exécutez sudo iotedge check sur un appareil, il signale Le moteur de conteneur n’est pas configuré avec le paramètre de serveur DNS, ce qui peut avoir un impact sur la connectivité à IoT Hub. Pour connaître les meilleures pratiques, veuillez consulter https://aka.ms/iotedge-prod-checklist-dns.

Cause

Par défaut, IoT Edge démarre les modules dans leur réseau de conteneur isolé. L’appareil peut rencontrer des difficultés avec la résolution de noms DNS au sein de ce réseau privé.
Si vous utilisez une installation de snap pour IoT Edge, le fichier de configuration Docker se trouve dans un autre emplacement. Consultez l’option 3 de la solution.

Solution

Option 1 : Définir le serveur DNS dans les paramètres du moteur de conteneur

Spécifiez le serveur DNS de votre environnement dans les paramètres du moteur de conteneur qui s’appliquent à tous les modules de conteneur démarrés par le moteur. Créez un fichier nommé daemon.json, puis spécifiez le serveur DNS à utiliser. Par exemple :

{
    "dns": ["1.1.1.1"]
}

Ce serveur DNS est défini sur un service DNS accessible publiquement. Toutefois, certains réseaux, tels que les réseaux d’entreprise, ont leurs propres serveurs DNS installés et n’autorisent pas l’accès aux serveurs DNS publics. Par conséquent, si votre périphérique ne peut pas accéder à un serveur DNS public, remplacez-le par une adresse de serveur DNS accessible.

Placez daemon.json dans le répertoire /etc/docker de votre appareil.

Si l’emplacement contient déjà un fichier daemon.json, ajoutez-lui la clé dns et enregistrez-le.

Redémarrez le moteur de conteneur pour que les mises à jour prennent effet.

sudo systemctl restart docker

Option 2 : Définir le serveur DNS dans le déploiement IoT Edge par module

Vous pouvez définir le serveur DNS pour createOptions de chaque module dans le déploiement IoT Edge. Par exemple :

"createOptions": {
  "HostConfig": {
    "Dns": [
      "x.x.x.x"
    ]
  }
}

Avertissement

Si vous utilisez cette méthode et spécifiez la mauvaise adresse DNS, edgeAgent perd la connexion avec IoT Hub et ne peut pas recevoir de nouveaux déploiements pour résoudre le problème. Pour résoudre ce problème, vous pouvez réinstaller le runtime IoT Edge. Avant d’installer une nouvelle instance de IoT Edge, veillez à supprimer tous les conteneurs edgeAgent de l’installation précédente.

Veillez à définir cette configuration également pour les modules edgeAgent et edgeHub.

Option 3 : Passer l’emplacement du fichier de configuration Docker à la commande check

Si IoT Edge est installé sous forme de snap, utilisez le paramètre --container-engine-config-file pour spécifier l’emplacement du fichier de configuration Docker. Par exemple, si le fichier de configuration Docker se trouve sur /var/snap/docker/current/config/daemon.json, exécutez la commande suivante : iotedge check --container-engine-config-file '/var/snap/docker/current/config/daemon.json'.

Actuellement, le message d’avertissement continue de s’afficher dans la sortie de iotedge check même après avoir défini l’emplacement du fichier de configuration. La commande check signale l’erreur, car le snap IoT Edge n’a pas d’accès en lecture au snap Docker. Si vous utilisez iotedge check dans votre processus de mise en production, vous pouvez supprimer le message d’avertissement en utilisant le paramètre --ignore container-engine-dns container-engine-logrotate.

Le module Agent Edge avec les rapports de connexion LTE « la configuration de l’agent edge est vide » et provoque une « erreur réseau temporaire »

Symptômes

Un appareil configuré avec la connexion LTE rencontre des problèmes de démarrage des modules définis dans le déploiement. edgeAgent n’est pas en mesure de se connecter à IoT Hub et signale la configuration de l’agent edge est vide et une erreur réseau temporaire s’est produite.

Cause

Certains réseaux ont une surcharge de paquets, ce qui rend le MTU de réseau Docker par défaut (1500) trop élevé et provoque la fragmentation des paquets empêchant l’accès aux ressources externes.

Solution

Vérifiez le paramètre MTU de votre réseau Docker.

docker network inspect <network name>
Vérifiez le paramètre MTU pour l’adaptateur réseau physique sur votre appareil.

ip addr show eth0

Remarque

Le MTU du réseau Docker ne peut pas être supérieur à celui de votre appareil. Pour plus d’informations, contactez votre fournisseur d’accès à Internet.

Si vous constatez que la taille du MTU est différente pour votre réseau Docker et pour le périphérique, essayez la solution de contournement suivante :

Créez un autre réseau. Par exemple,

docker network create --opt com.docker.network.driver.mtu=1430 test-mtu

Dans l’exemple, le paramètre MTU de l’appareil est 1430. Ainsi, le MTU du réseau Docker est défini sur 1430.
Arrêtez et supprimez le réseau Azure.

docker network rm azure-iot-edge
Recréez le réseau Azure.

docker network create --opt com.docker.network.driver.mtu=1430 azure-iot-edge
Supprimez tous les conteneurs et redémarrez le service aziot-edged.

sudo iotedge system stop && sudo docker rm -f $(docker ps -aq -f "label=net.azure-devices.edge.owner=Microsoft.Azure.Devices.Edge.Agent") && sudo iotedge config apply

L’agent IoT Edge ne peut pas accéder à l’image d’un module (403)

Symptômes

Un conteneur ne s’exécute pas et les journaux d’activité edgeAgent comportent une erreur 403.

Cause

Le module de l’agent IoT Edge ne possède pas les autorisations pour accéder à l’image d’un module.

Solution

Vérifiez que les informations d’identification du registre de conteneurs sont correctes dans le manifeste de déploiement de votre appareil.

L’agent IoT Edge effectue des appels d’identité excessifs

Symptômes

L’agent IoT Edge effectue des appels d’identité excessifs vers Azure IoT Hub.

Cause

La configuration incorrecte du manifeste de déploiement de l’appareil provoque un échec du déploiement sur l’appareil. La logique de nouvelle tentative de l’agent IoT Edge continue de relancer le déploiement. Chaque nouvelle tentative effectue des appels d’identité jusqu’à la réussite du déploiement. Par exemple, si le manifeste de déploiement spécifie un URI de module n’existant pas dans le registre de conteneurs ou mal typé, l’agent IoT Edge retente le déploiement jusqu’à la correction du manifeste de déploiement.

Solution

Vérifiez le manifeste de déploiement dans le Portail Azure. Corrigez les erreurs et redéployez le manifeste sur l’appareil.

Edge Hub ne parvient pas à démarrer

Symptômes

Le module edgeHub ne démarre pas. Vous pouvez voir un message semblable à l’une des erreurs suivantes dans les journaux :

One or more errors occurred.
(Docker API responded with status code=InternalServerError, response=
{\"message\":\"driver failed programming external connectivity on endpoint edgeHub (6a82e5e994bab5187939049684fb64efe07606d2bb8a4cc5655b2a9bad5f8c80):
Error starting userland proxy: Bind for 0.0.0.0:443 failed: port is already allocated\"}\n)

info: edgelet_docker::runtime -- Starting module edgeHub...
warn: edgelet_utils::logging -- Could not start module edgeHub
warn: edgelet_utils::logging --     caused by: failed to create endpoint edgeHub on network nat: hnsCall failed in Win32:
        The process cannot access the file because it is being used by another process. (0x20)

Cause

Un autre processus sur la machine hôte a lié un port que le module edgeHub tente de lier. Le hub IoT Edge mappe les ports 443, 5671 et 8883 pour une utilisation dans les scénarios de passerelle. Le module ne démarre pas si un autre processus a déjà lié l’un de ces ports.

Solution

Vous pouvez résoudre ce problème de deux manières :

Si l’appareil IoT Edge fonctionne en tant qu’appareil de passerelle, vous devez rechercher et arrêter le processus qui utilise actuellement le port 443, 5671 ou 8883. Une erreur sur le port 443 signifie généralement que l’autre processus est un serveur web.

Si vous n’avez pas besoin d’utiliser l’appareil IoT Edge en tant que passerelle, supprimez les liaisons de port dans les options de création de module edgeHub. Vous pouvez modifier ces options de création dans le Portail Azure, ou directement dans le fichier deployment.json.

Dans le portail Azure :

Accédez à votre hub IoT et sélectionnez Appareils sous le menu Gestion des périphériques.
Sélectionnez l’appareil IoT Edge que vous souhaitez modifier.
Sélectionnez Définir modules.
Sélectionnez Paramètres du runtime.
Dans les paramètres du module Hub Edge, supprimez tout ce qui se trouve dans la zone de texte Options de création.
Sélectionnez Appliquer pour enregistrer vos modifications et créer le déploiement.

Dans le fichier deployment.json :

Ouvrez le fichier deployment.json que vous avez appliqué à votre appareil IoT Edge.

Recherchez les paramètres edgeHub dans la section des propriétés souhaitées pour edgeAgent :

  "edgeHub": {
      "restartPolicy": "always",
      "settings": {
         "image": "mcr.microsoft.com/azureiotedge-hub:1.5",
         "createOptions": "{\"HostConfig\":{\"PortBindings\":{\"443/tcp\":[{\"HostPort\":\"443\"}],\"5671/tcp\":[{\"HostPort\":\"5671\"}],\"8883/tcp\":[{\"HostPort\":\"8883\"}]}}}"
      },
      "status": "running",
      "type": "docker"
   }

Supprimez la ligne createOptions ainsi que la virgule à la fin de la ligne image au-dessus :

  "edgeHub": {
      "restartPolicy": "always",
      "settings": {
      "image": "mcr.microsoft.com/azureiotedge-hub:1.5",
      "status": "running",
      "type": "docker"
}

Sélectionnez Créer pour l’appliquer à nouveau à votre appareil IoT Edge.

Le module IoT Edge ne parvient pas à envoyer de message à edgeHub et retourne l’erreur 404

Symptômes

Un module IoT Edge personnalisé ne parvient pas à envoyer de message au hub IoT Edge et retourne l’erreur Module not found 404. Le runtime IoT Edge imprime le message suivant dans les journaux d’activité :

Error: Time:Thu Jun  4 19:44:58 2018 File:/usr/sdk/src/c/provisioning_client/adapters/hsm_client_http_edge.c Func:on_edge_hsm_http_recv Line:364 executing HTTP request fails, status=404, response_buffer={"message":"Module not found"}u, 04 )

Cause

Pour des raisons de sécurité, le runtime IoT Edge applique l’identification du processus à tous les modules se connectant à l’edgeHub. Il vérifie que tous les messages envoyés par un module proviennent de l’ID de processus principal du module. Si un message est envoyé par un module à partir d’un autre ID de processus que celui qui a été établi initialement, il rejette le message avec un message d’erreur 404.

Solution

Depuis la version 1.0.7, tous les processus de module sont autorisés à se connecter. Pour plus d’informations, consultez les Notes de version pour la version 1.0.7.

Si la mise à niveau vers la version 1.0.7 n’est pas possible, procédez comme suit. Assurez-vous que le même ID de processus est bien toujours utilisé par le module IoT Edge personnalisé pour envoyer des messages au hub de périphérie. Par exemple, utilisez la commande ENTRYPOINT au lieu de CMD dans votre fichier Docker. La commande CMD crée un ID de processus pour le module et un autre ID de processus pour la commande bash exécutant le programme principal, alors que la commande ENTRYPOINT créé un ID de processus unique.

Problèmes de stabilité sur les petits appareils

Symptômes

Vous rencontrez parfois des problèmes de stabilité sur les appareils avec contraintes de ressources, comme le Raspberry Pi, en particulier quand ils sont utilisés comme passerelles. Les symptômes incluent des exceptions de mémoire insuffisante dans le module hub IoT Edge, l’échec de la connexion d’appareils en aval ou l’échec de l’envoi des messages de télémétrie d’un appareil au bout de quelques heures.

Cause

Le hub IoT Edge, qui fait partie du runtime IoT Edge, est optimisé pour les performances par défaut et tente d’allouer de grandes quantités de mémoire. Cette optimisation n’est pas idéale pour les appareils de périphérie limités et peut entraîner des problèmes de stabilité.

Solution

Pour le hub IoT Edge, affectez la valeur false à une variable d’environnement OptimizeForPerformance. Il existe deux façons de définir des variables d’environnement :

Dans le portail Azure :

Dans votre hub IoT, sélectionnez votre appareil IoT Edge puis, à partir de la page de détails de l’appareil, sélectionnez Définir des modules>Paramètres du runtime.
Créez une variable d’environnement pour le module hub IoT Edge appelé OptimizeForPerformance avec le type True/False défini sur False.

Sélectionnez Appliquer pour enregistrer les modifications, puis sélectionnez Vérifier + créer.

La variable d’environnement se trouve désormais dans la propriété edgeHub du manifeste de déploiement :

   "edgeHub": {
      "env": {
            "OptimizeForPerformance": {
               "value": false
            }
      },
      "restartPolicy": "always",
      "settings": {
            "image": "mcr.microsoft.com/azureiotedge-hub:1.5",
            "createOptions": "{\"HostConfig\":{\"PortBindings\":{\"443/tcp\":[{\"HostPort\":\"443\"}],\"5671/tcp\":[{\"HostPort\":\"5671\"}],\"8883/tcp\":[{\"HostPort\":\"8883\"}]}}}"
      },
      "status": "running",
      "type": "docker"
   }

Sélectionnez Créer pour enregistrer vos modifications et déployer le module.

Le démon de sécurité n’a pas pu démarrer correctement

Symptômes

Le démon de sécurité ne parvient pas à démarrer et les conteneurs de module ne sont pas créés. edgeAgent, edgeHub et d’autres modules personnalisés ne sont pas démarrés par le service IoT Edge. Dans les journaux de aziot-edged, le message d’erreur suivant s’affiche :

Le démon n’a pas pu démarrer correctement : Impossible de démarrer le service de gestion

provoqué par : Une erreur s’est produite pour le chemin d’accès /var/run/iotedge/mgmt.sock

provoqué par : Autorisation refusée (erreur du système d’exploitation 13)

Cause

Pour toutes les distributions Linux, à l’exception de CentOS 7, la configuration par défaut d’IoT Edge utilise l’activation de socket systemd. Une erreur d’autorisation se produit si vous modifiez le fichier de configuration pour qu’il n’utilise pas l’activation de socket, mais que vous laissez les URL sous la forme /var/run/iotedge/*.sock, car l’utilisateur iotedge ne peut pas écrire sur /var/run/iotedge, ce qui signifie qu’il ne peut pas déverrouiller et monter les sockets lui-même.

Solution

Vous n’avez pas besoin de désactiver l’activation de socket sur une distribution où l’activation de socket est prise en charge. Toutefois, si vous préférez ne pas utiliser l’activation de socket, placez les sockets dans /var/lib/iotedge/.

Exécutez systemctl disable iotedge.socket iotedge.mgmt.socket pour désactiver les unités de socket afin que systemd ne les démarre pas inutilement
Modifiez la configuration d’iotedge pour utiliser /var/lib/iotedge/*.sock dans les sections connect et listen
Si vous avez déjà des modules, ils ont les anciens montages /var/run/iotedge/*.sock, donc appliquez-leur docker rm -f.

Le nettoyage de la file d’attente des messages est lent

Symptômes

La file d’attente des messages n’est pas nettoyée une fois les messages traités. La file d’attente des messages augmente au fil du temps et le runtime IoT Edge finit par manquer de mémoire.

Cause

L’intervalle de nettoyage des messages est contrôlé par la durée de vie des messages clients et par la variable d’environnement MessageCleanupIntervalSecs de EdgeHub. La valeur par défaut de la durée de vie des messages est de deux heures et la valeur par défaut de MessageCleanupIntervalSecs est de 30 minutes. Si votre application utilise une valeur de durée de vie plus courte que la valeur par défaut et que vous n’ajustez pas la valeur de MessageCleanupIntervalSecs, les messages expirés ne seront pas nettoyés avant l’intervalle de nettoyage suivant.

Solution

Si vous changez la valeur de la durée de vie pour votre application en une valeur inférieure à la valeur par défaut, ajustez également la valeur de MessageCleanupIntervalSecs. La valeur de MessageCleanupIntervalSecs doit être significativement inférieure à la plus petite valeur de durée de vie utilisée par le client. Par exemple, si l’application cliente définit une durée de vie de cinq minutes dans l’en-tête de message, définissez la valeur de MessageCleanupIntervalSecs sur 1 minute. Ces valeurs font que les messages sont nettoyés dans les 6 minutes (5 + 1).

Pour configurer la valeur de MessageCleanupIntervalSecs, définissez la variable d’environnement dans le manifeste de déploiement du module du hub IoT Edge. Pour plus d’informations sur la définition des variables d’environnement d’exécution, consultez Variables d’environnement de l’agent Edge et du hub Edge.

Mise en réseau

Le démon de sécurité IoT Edge échoue avec un nom d’hôte non valide

Symptômes

La tentative de vérification des journaux du gestionnaire de sécurité IoT Edge échoue, avec le message suivant :

Error parsing user input data: invalid hostname. Hostname cannot be empty or greater than 64 characters

Cause

Le runtime IoT Edge peut prendre uniquement en charge les noms d’hôte avec moins de 64 caractères. Les machines physiques n’ont généralement pas de noms d’hôte longs, mais le problème est plus courant sur une machine virtuelle. Les noms d’hôtes générés automatiquement pour les machines virtuelles Windows hébergées dans Azure, en particulier, sont généralement longs.

Solution

Lorsque vous voyez cette erreur, vous pouvez la résoudre par la configuration du nom DNS de votre machine virtuelle, puis en définissant le nom DNS en tant que nom d’hôte dans la commande d’installation.

Dans le Portail Azure, accédez au panneau Vue d’ensemble de votre machine virtuelle.
Ouvrez le panneau de configuration en sélectionnant le lien Non configuré (si votre machine virtuelle est nouvelle) sous le nom DNS existant ou sélectionnez votre nom DNS existant sous Essentials>Nom DNS. Si votre machine virtuelle a déjà un nom DNS configuré, vous n’avez pas besoin d’en configurer un nouveau.
Fournissez une valeur pour Étiquette de nom DNS si vous n’en avez pas déjà un et sélectionnez Enregistrer.
Copiez le nouveau nom DNS, qui doit être au format suivant :
<>DNSnamelabel .<vmlocation>.cloudapp.azure.com.
Sur l’appareil IoT Edge, ouvrez le fichier config.
```
sudo nano /etc/aziot/config.toml
```
Remplacez la valeur hostname par votre nom DNS.
Enregistrez et fermez le fichier, puis appliquez les modifications à IoT Edge.
```
sudo iotedge config apply
```

Le module IoT Edge signale des erreurs de connectivité

Symptômes

Les modules IoT Edge qui se connectent directement aux services cloud, y compris les modules de runtime, cessent de fonctionner comme prévu et retournent des erreurs concernant les échecs de connexion ou de mise en réseau.

Cause

Les conteneurs s’appuient sur le transfert de paquets IP pour se connecter à Internet afin de pouvoir communiquer avec les services cloud. Le transfert de paquets IP est activé par défaut dans Docker, mais s’il est désactivé, tous les modules qui se connectent aux services cloud ne fonctionneront pas comme prévu. Pour plus d’informations, consultez Comprendre la communication avec les conteneurs dans la documentation Docker.

Solution

Pour activer le transfert de paquets IP, procédez comme suit.

Ouvrez le fichier sysctl.conf.
```
sudo nano /etc/sysctl.conf
```
Ajoutez la ligne suivante au fichier.
```
net.ipv4.ip_forward=1
```
Enregistrez le fichier et fermez-le.
Redémarrez le service réseau et le service Docker pour appliquer les modifications.

IoT Edge derrière une passerelle ne peut pas exécuter de requêtes HTTP ni démarrer le module edgeAgent

Symptômes

Le runtime IoT Edge est actif avec un fichier de configuration valide, mais il ne peut pas démarrer le module edgeAgent. La commande iotedge list retourne une liste vide. Le runtime IoT Edge signale une erreur Could not perform HTTP request dans les journaux.

Cause

Des appareils IoT Edge derrière une passerelle obtiennent leurs images de module à partir de l’appareil IoT Edge parent spécifié dans le champ parent_hostname du fichier config. L’erreur Could not perform HTTP request signifie que l’appareil en aval n’est pas en mesure d’atteindre son appareil parent via HTTP.

Solution

Assurez-vous que l’appareil de IoT Edge parent peut recevoir des demandes entrantes de l’appareil IoT Edge en aval. Ouvrez le trafic réseau sur les ports 443 et 6617 pour les requêtes provenant de l’appareil en aval.

IoT Edge derrière une passerelle ne peut pas exécuter de requêtes HTTP ni démarrer le module edgeAgent

Symptômes

Le démon IoT Edge est actif avec un fichier de configuration valide, mais il ne peut pas démarrer le module edgeAgent. La commande iotedge list retourne une liste vide. Le démon IoT Edge enregistre le rapport Could not perform HTTP request.

Cause

Solution

IoT Edge derrière une passerelle ne peut pas se connecter lors de la migration d’un hub IoT vers un autre

Symptômes

Lorsque vous tentez de migrer une hiérarchie d’appareils IoT Edge d’un hub IoT vers un autre, l’appareil IoT Edge parent de niveau supérieur peut se connecter à IoT Hub, mais les appareils IoT Edge en aval ne le peuvent pas. Les journaux indiquent Unable to authenticate client downstream-device/$edgeAgent with module credentials.

Cause

Les informations d’identification des appareils en aval n’ont pas été mises à jour correctement lors de la migration vers le nouveau hub IoT. Pour cette raison, les modules edgeAgent et edgeHub ont été définis pour avoir le type d’authentification none (valeur par défaut s’il n’est pas défini explicitement). Lors de la connexion, les modules des appareils en aval utilisent les anciennes informations d’identification, ce qui entraîne l’échec de l’authentification.

Solution

Lors de la migration vers le nouveau hub IoT (en supposant que vous n’utilisez pas DPS), suivez ces étapes dans l’ordre :

Suivez ce guide pour exporter puis importer les identités des appareils de l’ancien hub IoT vers le nouveau.
Reconfigurez tous les déploiements et configurations d’IoT Edge dans le nouveau hub IoT.
Reconfigurez toutes les relations parent-enfant des appareils dans le nouveau hub IoT.
Mettez à jour chaque appareil pour qu’il pointe vers le nom d’hôte du nouveau hub IoT (iothub_hostname sous [provisioning] dans config.toml).
Si vous avez choisi d’exclure les clés d’authentification pendant l’exportation des appareils, reconfigurez chaque appareil avec les nouvelles clés fournies par le nouveau hub IoT (device_id_pk sous [provisioning.authentication] dans config.toml).
Redémarrez d’abord l’appareil Edge parent de niveau supérieur pour vous assurer qu’il est opérationnel.
Redémarrez chaque appareil de la hiérarchie, niveau par niveau, du haut vers le bas.

IoT Edge a un débit de messages faible quand il est géographiquement distant d’IoT Hub

Symptômes

Les appareils Azure IoT Edge qui sont géographiquement éloignés d’Azure IoT Hub ont un débit de messages plus faible que prévu.

Cause

Une latence élevée entre l’appareil et IoT Hub peut entraîner un débit de message inférieur aux prévisions. Par défaut, la taille des lots de messages utilisés par IoT Edge est de 10. Cela limite le nombre de messages envoyés dans un seul lot, ce qui augmente le nombre d’allers-retours entre l’appareil et IoT Hub.

Solution

Essayez d’augmenter la variable d’environnement IoT Edge Hub MaxUpstreamBatchSize. Cela permet d’envoyer davantage de messages dans un seul lot, ce qui réduit le nombre d’allers-retours entre l’appareil et IoT Hub.

Pour définir des variables d’environnement Azure Edge Hub dans le Portail Azure :

Accédez à votre IoT Hub et sous le menu Gestion des périphériques, sélectionnez Appareils.
Sélectionnez l’appareil IoT Edge que vous souhaitez modifier.
Sélectionnez Définir modules.
Sélectionnez Paramètres du runtime.
Sous l’onglet paramètres du module Hub Edge, ajoutez la variable d’environnement MaxUpstreamBatchSize comme type Number avec une valeur de 20.
Sélectionnez Appliquer.

Étapes suivantes

Vous pensez que vous avez trouvé un bogue dans la plateforme IoT Edge ? Soumettez un problème afin que nous puissions poursuivre les améliorations.

Si vous avez d'autres questions, créez une Support request pour obtenir de l'aide.

Partage via

Solutions aux problèmes courants liés à Azure IoT Edge

Provisionnement et déploiement

Après son déploiement, le module IoT Edge n’est plus visible sur l’appareil

Symptômes

Cause

Solution

Runtime IoT Edge

L’agent IoT Edge s’arrête après une minute

Symptômes

Cause

Solution

Le module Edge Agent rapporte le message « fichier config vide » et aucun module ne démarre sur l’appareil

Symptômes

Cause

Solution

Le module Agent Edge avec les rapports de connexion LTE « la configuration de l’agent edge est vide » et provoque une « erreur réseau temporaire »

Symptômes

Cause

Solution

L’agent IoT Edge ne peut pas accéder à l’image d’un module (403)

Symptômes

Cause

Solution

L’agent IoT Edge effectue des appels d’identité excessifs

Symptômes

Cause

Solution

Edge Hub ne parvient pas à démarrer

Symptômes

Cause

Solution

Le module IoT Edge ne parvient pas à envoyer de message à edgeHub et retourne l’erreur 404

Symptômes

Cause

Solution

Problèmes de stabilité sur les petits appareils

Symptômes

Cause

Solution

Le démon de sécurité n’a pas pu démarrer correctement

Symptômes

Cause

Solution

Le nettoyage de la file d’attente des messages est lent

Symptômes

Cause

Solution

Mise en réseau

Le démon de sécurité IoT Edge échoue avec un nom d’hôte non valide

Symptômes

Cause

Solution

Le module IoT Edge signale des erreurs de connectivité

Symptômes

Cause

Solution

IoT Edge derrière une passerelle ne peut pas exécuter de requêtes HTTP ni démarrer le module edgeAgent

Symptômes

Cause

Solution

IoT Edge derrière une passerelle ne peut pas exécuter de requêtes HTTP ni démarrer le module edgeAgent

Symptômes

Cause

Solution

IoT Edge derrière une passerelle ne peut pas se connecter lors de la migration d’un hub IoT vers un autre

Symptômes

Cause

Solution

IoT Edge a un débit de messages faible quand il est géographiquement distant d’IoT Hub

Symptômes

Cause

Solution

Étapes suivantes

Commentaires

Ressources supplémentaires