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

Article
11/17/2022

S’applique à : IoT Edge 1.1

Important

IoT Edge la date de fin du support 1.1 était le 13 décembre 2022. Consultez la page Politique de support Microsoft pour plus d’informations sur la prise en charge de ce produit, de ce service, de cette technologie ou de cette API. Pour plus d’informations sur la mise à jour vers la dernière version de IoT Edge, consultez 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.

Impossible d’obtenir les journaux d’activité du runtime IoT Edge sur Windows

Symptômes

Vous obtenez une exception EventLogException quand vous utilisez Get-WinEvent sur Windows.

Cause

La commande PowerShell Get-WinEvent repose sur la présence d’une entrée de Registre pour trouver les journaux d’activité d’après un ProviderName spécifique.

Solution

Définissez une entrée de Registre pour le démon IoT Edge. Créez un fichier iotedge.reg avec le contenu suivant, puis importez-le dans le Registre Windows en double-cliquant dessus ou en utilisant la commande reg import iotedge.reg :

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\iotedged]
"CustomSource"=dword:00000001
"EventMessageFile"="C:\\ProgramData\\iotedge\\iotedged.exe"
"TypesSupported"=dword:00000007

Erreur du client DPM

Symptômes

Échec du démarrage d’IoT Edge avec un message d’erreurfailed to provision with IoT Hub, and no valid device backup was found dps client error.

Cause

Une inscription de groupe est utilisée pour provisionner un appareil IoT Edge sur un IoT Hub. L’appareil IoT Edge est déplacé vers un autre hub. L’inscription est supprimée dans DPS. Une nouvelle inscription est créée dans DPS pour le nouveau hub. L’appareil n’est pas reprovisionné.

Solution

Vérifiez que vos informations d’identification DPS sont correctes.
Appliquez votre configuration à l’aide de sudo iotedge apply config.
Si l’appareil n’est pas reprovisionné, redémarrez l’appareil à l’aide de sudo iotedge system restart.
Si l’appareil n’est pas reprovisionné, forcez le reprovisionnement à l’aide de sudo iotedge system reprovision.

Pour reprovisionner automatiquement, définissez dynamic_reprovisioning: true dans le fichier config de l’appareil. En définissant cet indicateur sur true, vous acceptez la fonctionnalité de reprovisionnement dynamique. IoT Edge détecte les situations où l’appareil semble avoir été reprovisionné dans le cloud en supervisant sa propre connexion IoT Hub à la recherche de certaines erreurs. IoT Edge répond en arrêtant tous les modules Edge et lui-même. La prochaine fois que le démon démarre, il tente de reprovisionner cet appareil avec Azure pour recevoir les nouvelles informations de provisionnement IoT Hub.

Lors de l’utilisation du provisionnement externe, le démon informe également le point de terminaison de provisionnement externe de l’événement de reprovisionnement avant de s’arrêter. Pour plus d’informations, consultez Concepts du reprovisionnement d’appareils IoT Hub.

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 s’exécute mais rapporte en continu le message « fichier config vide ».

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

Solution

Option n°1 : Définissez 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 au bon emplacement de votre plateforme :

Plateforme	Emplacement
Linux	`/etc/docker`
Hôte Windows avec des conteneurs Windows	`C:\ProgramData\iotedge-moby\config`

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

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

Plateforme	Commande
Linux	`sudo systemctl restart docker`
Windows (Admin PowerShell)	`Restart-Service iotedge-moby -Force`

Option n°2 : Définissez 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.

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.

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 Edge Hub, supprimez tout le contenu de la zone de texte Options de création.
Enregistrez vos modifications et créez 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": {
    "settings": {
        "image": "mcr.microsoft.com/azureiotedge-hub:1.1",
        "createOptions": "{\"HostConfig\":{\"PortBindings\":{\"8883/tcp\":[{\"HostPort\":\"8883\"}],\"443/tcp\":[{\"HostPort\":\"443\"}]}}}"
    },
    "type": "docker",
    "status": "running",
    "restartPolicy": "always"
}

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

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

Enregistrez le fichier et réappliquez-le à 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 depuis un ID de processus différent de 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 en la définissant sur false.

OptimizeForPerformance défini sur false

Dans le manifeste de déploiement :

"edgeHub": {
  "type": "docker",
  "settings": {
    "image": "mcr.microsoft.com/azureiotedge-hub:1.1",
    "createOptions": <snipped>
  },
  "env": {
    "OptimizeForPerformance": {
      "value": "false"
    }
  },

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.

Impossible de démarrer le module en raison d’une incompatibilité du système d’exploitation

Symptôme

Le module edgeHub ne démarre pas dans IoT Edge version 1.1.

Cause

Le module Windows utilise une version de Windows incompatible avec la version de Windows sur l’hôte. IoT Edge Windows version 1809 build 17763 est nécessaire en tant que couche de base pour l’image de module, mais une autre version est utilisée.

Solution

Vérifiez la version de vos différents systèmes d’exploitation Windows dans Résoudre les discordances d’images d’hôte et de conteneur. Si les systèmes d’exploitation sont différents, mettez-les à jour pour IoT Edge Windows version 1809 build 17763 et régénérez l’image Docker utilisée pour ce module.

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.
Sélectionnez configurer sous le 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 l’étiquette de nom DNS et sélectionnez Enregistrer.
Copiez le nouveau nom DNS, qui doit être au format <DNSnamelabel>.<vmlocation>.cloudapp.azure.com.
À l’intérieur de la machine virtuelle, utilisez la commande suivante pour installer le runtime IoT Edge avec votre nom DNS :
- Sur Linux :
```
sudo nano /etc/iotedge/config.yaml
```
- Sur Windows :
```
notepad C:\ProgramData\iotedge\config.yaml
```

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.

Sur Windows :

Ouvrez l’application Exécuter.
Entrez regedit dans la zone de texte et sélectionnez Ok.
Dans l’Éditeur du Registre, accédez à HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.
Recherchez le paramètre IPEnableRouter.
1. Si le paramètre existe, affectez la valeur 1 au paramètre.
2. Si le paramètre n’existe pas, ajoutez-le en tant que nouveau paramètre avec les paramètres suivants :
  
  Paramètre Valeur
  
  Name IPEnableRouter
  
  Type REG_DWORD
  
  Valeur 1
Fermez la fenêtre Éditeur du Registre.
Redémarrez votre système pour appliquer les modifications.

Paramètre	Valeur
Name	IPEnableRouter
Type	REG_DWORD
Valeur	1

Sur Linux :

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

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

Partager 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

Impossible d’obtenir les journaux d’activité du runtime IoT Edge sur Windows

Symptômes

Cause

Solution

Erreur du client DPM

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

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

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

Impossible de démarrer le module en raison d’une incompatibilité du système d’exploitation

Symptôme

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

Étapes suivantes

Ressources supplémentaires