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

S'applique à : IoT Edge 1.5

Important

IoT Edge 1.5 LTS est la version prise en charge. IoT Edge 1,4 LTS a atteint la fin de vie le 12 novembre 2024. Si vous utilisez une version antérieure, consultez Update IoT Edge.

Utilisez cet article pour identifier et résoudre les problèmes courants lors de l’utilisation de solutions IoT Edge. Pour plus d'informations sur la manière de trouver les journaux et les erreurs de votre appareil IoT Edge, consultez Dépannage de votre appareil IoT Edge.

Approvisionnement et déploiement

IoT Edge module se déploie correctement, puis disparaît de l’appareil

Symptômes

Après avoir défini des modules pour un appareil IoT Edge, les modules se déploient correctement, mais après quelques minutes, ils disparaissent de l’appareil et des 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. Les fonctionnalités de définition de modules dans le portail Azure ou Créer un déploiement pour un seul appareil, fonctionnalité de Visual Studio Code, prend effet 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, soit un déploiement automatique, soit des 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 des appareils uniques ou à grande échelle.

IoT Edge runtime

IoT Edge agent 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 indiquent que l’agent IoT Edge tente de se connecter à IoT Hub par AMQP, puis essaie de se connecter en utilisant AMQP sur WebSocket. Lorsque cette connexion échoue, l’agent IoT Edge se ferme.

Exemples de logs 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 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 que chacun des modules communique. 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

Vérifiez qu’il existe un itinéraire vers Internet pour les adresses IP affectées à ce pont ou réseau 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 le edgeAgent est en cours d’exécution, mais signale un fichier de configuration vide....
Lorsque vous exécutez sudo iotedge check sur un appareil, il signale Le moteurContainer n’est pas configuré avec le paramètre de serveur DNS, ce qui peut avoir un impact sur la connectivité à IoT Hub. Consultez https://aka.ms/iotedge-prod-checklist-dns pour connaître les meilleures pratiques.

Cause

Par défaut, IoT Edge démarre les modules dans leur propre réseau de conteneurs isolé. L’appareil peut rencontrer des problèmes avec la résolution de noms DNS au sein de ce réseau privé.
Si vous utilisez une installation enfichable de IoT Edge, le fichier de configuration Docker se trouve à 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. Ces paramètres s’appliquent à tous les modules de conteneur démarrés par le moteur. Créez un fichier nommé daemon.jsonet 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 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 IoT Edge déploiement par module

Vous pouvez définir le serveur DNS pour la section 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 l'adresse DNS incorrecte, 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 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 vous installez IoT Edge en tant que composant logiciel enfichable, 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 d’apparaître dans la sortie de iotedge check, même après avoir défini l’emplacement du fichier de configuration. Le rapport signale une erreur, car le snap IoT Edge n'a pas de droit de lecture sur le 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 Edge Agent avec connexion LTE signale une « configuration de l’agent edge vide » et provoque une « erreur réseau intermittente »

Symptômes

Un appareil configuré avec une connexion LTE présente des problèmes de démarrage de modules définis dans le déploiement. Le edgeAgent ne peut pas se connecter au IoT Hub et signale « configuration de l'agent edge vide » et « 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. Cette fragmentation empêche 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 la carte 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. Définissez le MTU pour le réseau Docker 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

IoT Edge agent 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 n'a pas les autorisations nécessaires 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.

IoT Edge agent effectue des requêtes d’identité excessives

Symptômes

IoT Edge agent effectue des appels d’identité excessifs à 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 réessai de l'agent IoT Edge continue de réitérer 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 qui n'existe pas dans le registre de conteneurs ou est mal typé, l'agent IoT Edge retente le déploiement jusqu'à ce que le manifeste de déploiement soit corrigé.

Solution

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

IoT 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 l’ordinateur 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 parvient pas à démarrer si un autre processus a déjà lié l’un de ces ports.

Solution

Résolvez ce problème de l’une des deux manières suivantes :

Si l’appareil IoT Edge fonctionne comme un appareil de passerelle, recherchez et arrêtez le processus qui utilise 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 des options de création de module edgeHub. Vous pouvez modifier les options de création dans le portail Azure ou directement dans le fichier deployment.json.

Dans le portail Azure :

Accédez à votre ioT Hub et sélectionnez Appareils sous le menu Gestion des appareils .
Sélectionnez l’appareil IoT Edge que vous souhaitez mettre à jour.
Sélectionnez Définir modules.
Sélectionnez Paramètres du runtime.
Dans les paramètres du module Edge Hub, supprimez tout ce qui se trouve dans la zone de texte Container Create Options.
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 Create pour l’appliquer à nouveau à votre appareil IoT Edge.

IoT Edge module ne peut pas envoyer de message à edgeHub et retourne une erreur 404

Symptômes

Un module IoT Edge personnalisé ne peut pas envoyer de message au hub IoT Edge et retourne une erreur 404 Module not found. Le runtime IoT Edge imprime le message suivant dans les journaux :

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 pour tous les modules qui se connectent à edgeHub. Il vérifie que tous les messages qu’un module envoie proviennent de l’ID de processus principal du module. Si un module tente d’envoyer un message à partir d’un ID de processus différent, le runtime rejette le message et retourne un message d’erreur 404.

Solution

À compter de la version 1.0.7, tous les processus de module peuvent se connecter. Pour plus d’informations, consultez le journal des modifications de version 1.0.7.

Si vous ne pouvez pas effectuer la mise à niveau vers la version 1.0.7, procédez comme suit. Assurez-vous que le module IoT Edge personnalisé utilise toujours le même ID de processus pour envoyer des messages au edgeHub. Par exemple, utilisez la ENTRYPOINT commande au lieu de la CMD commande dans votre fichier Docker. La CMD commande génère un ID de processus pour le module et un autre ID de processus pour la commande Bash qui exécute le programme principal. La ENTRYPOINT commande génère un ID de processus unique.

Problèmes de stabilité sur les petits appareils

Symptômes

Vous pouvez rencontrer des problèmes de stabilité sur des appareils à contrainte de ressources comme Raspberry Pi, en particulier lorsqu’ils sont utilisés comme passerelle. Les symptômes incluent des exceptions de mémoire insuffisante dans le module hub IoT Edge, les appareils en aval qui ne parviennent pas à se connecter ou l’appareil qui ne parvient pas à envoyer des messages de télémétrie après 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 grands blocs 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, définissez une variable d’environnement OptimizeForPerformance sur false. Vous pouvez définir des variables d’environnement de l’une des deux manières suivantes :

Dans le portail Azure :

Dans votre IoT Hub, sélectionnez votre appareil IoT Edge. Dans la page détails de l’appareil, sélectionnez Définir les paramètres d’exécution des modules>.
Créez une variable d’environnement pour le module hub IoT Edge nommé OptimizeForPerformance avec le type True/False et définissez-le sur False.

Sélectionnez Appliquer pour enregistrer vos 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é ne peut pas démarrer

Symptômes

Le démon de sécurité ne peut pas démarrer et les conteneurs de modules ne sont pas créés. Le service IoT Edge ne démarre pas edgeAgent, edgeHub ou d'autres modules personnalisés. Dans les aziot-edged logs, vous voyez ce message d'erreur :

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, IoT Edge active les sockets par défaut avec systemd. Si vous modifiez le fichier de configuration pour désactiver l’activation du socket mais conservez les URL comme /var/run/iotedge/*.sock, vous obtenez une erreur de permission. L’utilisateur iotedge ne peut pas écrire dans /var/run/iotedge, de sorte qu’il ne peut pas déverrouiller et monter les sockets. CentOS a atteint sa fin de vie (EOL). Pour plus d’informations, consultez les conseils sur la fin de vie centOS.

Solution

Ne désactivez pas l’activation de socket sur une distribution qui prend en charge l’activation du socket. Toutefois, si vous ne souhaitez pas utiliser l’activation du 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 le système ne les démarre pas.
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 /var/run/iotedge/*.sock montages, donc exécutez-les docker rm -f pour les supprimer.

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

Symptômes

La file d’attente de messages ne nettoie pas une fois les messages traités. La file d’attente de messages augmente au fil du temps et entraîne l’exécution de IoT Edge à manquer de mémoire.

Cause

La durée de vie du message client (heure de vie) et la variable d’environnement EdgeHubMessageCleanupIntervalSecs contrôlent l’intervalle de nettoyage des messages. La valeur de durée de vie du message par défaut est de deux heures et la valeur par défaut 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 MessageCleanupIntervalSecs valeur, les messages expirés ne sont pas nettoyés jusqu’à l’intervalle de nettoyage suivant.

Solution

Si vous modifiez la valeur de durée de vie de votre application à une valeur plus courte que la valeur par défaut, ajustez également la valeur MessageCleanupIntervalSecs. La MessageCleanupIntervalSecs valeur doit être beaucoup plus petite que la plus petite valeur TTL 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 MessageCleanupIntervalSecs valeur sur une minute. Ces valeurs font que les messages sont nettoyés dans les 6 minutes (5 + 1).

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

IoT Edge Hub signale l’erreur System.FormatException lors de l’utilisation du protocole AMQP

Symptômes

Lorsque vous routez les messages d’un appareil IoT Edge vers un IoT Hub à l’aide du protocole AMQP et définissez la propriété iothub-creation-time-utc sur les messages d’appareil sortants, le IoT Edge Hub signale une erreur System.FormatException. Le message d’erreur est similaire au suivant :

System.FormatException: String '2024-12-01T00:00:0.000Z' was not recognized as a valid DateTime.

Cause

La valeur iot-hub-creation-time-utc ne répond pas aux critères de format stricts. Le format requis par le hub Edge est un sous-ensemble d’ISO 8601.

Solution

Ce problème est un problème connu dans IoT Edge Hub pour le protocole AMQP. Actuellement, l’équipe produit étudie un correctif. Le protocole MQTT n’a pas ce problème.

Mise en réseau

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

Symptômes

Si vous tentez de vérifier les journaux du gestionnaire de sécurité IoT Edge, cela échoue et imprime le message suivant :

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

Cause

Le runtime IoT Edge prend en charge les noms d’hôte dont la taille est inférieure à 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ôte générés automatiquement pour Windows machines virtuelles hébergées dans Azure, en particulier, ont tendance à être longs.

Solution

Lorsque vous voyez cette erreur, résolvez-la en configurant le nom DNS de votre machine virtuelle, puis en définissant le nom DNS comme nom d’hôte dans la commande d’installation.

Dans le portail Azure, accédez à la page 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) 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.
Entrez une valeur pour l’étiquette de nom DNS si vous n’en avez pas déjà 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 de configuration.
```
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
```

IoT Edge module signale des erreurs de connectivité

Symptômes

IoT Edge modules qui se connectent directement aux services cloud, y compris les modules d’exécution, arrêtent de fonctionner comme prévu et retournent des erreurs liées aux défaillances de connexion ou de mise en réseau.

Cause

Les conteneurs s’appuient sur le transfert de paquets IP pour se connecter à Internet afin qu’ils puissent communiquer avec les services cloud. Docker active le transfert de paquets IP par défaut, mais si vous le désactivez, les modules qui se connectent aux services cloud ne fonctionnent 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 appareil derrière une passerelle ne peut pas effectuer 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 Could not perform HTTP request dans les journaux.

Cause

Les appareils IoT Edge derrière une passerelle reçoivent leurs images de module de l’appareil IoT Edge parent spécifié dans le champ parent_hostname du fichier de configuration. L’erreur Could not perform HTTP request signifie que l’appareil en aval ne peut pas atteindre son appareil parent via HTTP.

Solution

Assurez-vous que l’appareil parent IoT Edge 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 se connecter lors de la migration d'un hub IoT vers un autre

Symptômes

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

Cause

La migration n’a pas correctement mis à jour les informations d’identification pour les appareils en aval. En raison de ce problème, les modules edgeAgent et edgeHub ont pour type d'authentification none (c'est la valeur par défaut si vous ne la définissez pas 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

Lorsque vous migrez vers le nouveau hub IoT (en supposant que vous n’utilisez pas DPS), procédez comme suit :

Suivez ce guide pour exporter puis importer les identités des appareils de l’ancien hub IoT vers le nouveau.
Reconfigurer tous les déploiements et configurations de 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 lorsqu’il est géographiquement distant de IoT Hub

Symptômes

Azure IoT Edge appareils qui sont géographiquement éloignés de Azure IoT Hub ont un débit de message inférieur.

Cause

Une latence élevée entre l’appareil et IoT Hub entraîne un débit de message inférieur. IoT Edge utilise une taille de lot de messages par défaut de 10. Cette taille de lot limite le nombre de messages envoyés dans un lot unique, 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. Cette modification envoie davantage de messages dans un lot unique, ce qui réduit le nombre d’allers-retours entre l’appareil et IoT Hub.

Pour définir les variables d’environnement d'Azure Edge Hub dans le portail Azure :

Accédez à votre IoT Hub et sélectionnez Devices sous le menu Device management.
Sélectionnez l’appareil IoT Edge que vous souhaitez mettre à jour.
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

Pensez-vous que vous avez trouvé un bogue dans la plateforme IoT Edge ? Submitez un problème afin que l’équipe produit puisse continuer à améliorer la plateforme.

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

Commentaires

Est-ce que cette page vous a été utile?

Last updated on 2026-03-11

Partage via

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

Approvisionnement et déploiement

IoT Edge module se déploie correctement, puis disparaît de l’appareil

Symptômes

Cause

Solution

IoT Edge runtime

IoT Edge agent 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 Edge Agent avec connexion LTE signale une « configuration de l’agent edge vide » et provoque une « erreur réseau intermittente »

Symptômes

Cause

Solution

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

Symptômes

Cause

Solution

IoT Edge agent effectue des requêtes d’identité excessives

Symptômes

Cause

Solution

IoT Edge hub ne parvient pas à démarrer

Symptômes

Cause

Solution

IoT Edge module ne peut pas envoyer de message à edgeHub et retourne une erreur 404

Symptômes

Cause

Solution

Problèmes de stabilité sur les petits appareils

Symptômes

Cause

Solution

Le démon de sécurité ne peut pas démarrer

Symptômes

Cause

Solution

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

Symptômes

Cause

Solution

IoT Edge Hub signale l’erreur System.FormatException lors de l’utilisation du protocole AMQP

Symptômes

Cause

Solution

Mise en réseau

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

Symptômes

Cause

Solution

IoT Edge module signale des erreurs de connectivité

Symptômes

Cause

Solution

IoT Edge appareil derrière une passerelle ne peut pas effectuer 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 lorsqu’il est géographiquement distant de IoT Hub

Symptômes

Cause

Solution

Étapes suivantes

Commentaires

Ressources supplémentaires