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

S’applique à : IoT Edge 1.1

Utilisez cet article pour identifier et résoudre les problèmes courants lors de l’utilisation de solutions IoT Edge. Si vous avez besoin d'informations sur la façon de trouver les journaux et les erreurs de votre appareil IoT Edge, consultez Dépanner votre appareil 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.

La 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 aux critères de ciblage 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’exécution IoT Edge sur Windows

Symptômes

Vous obtenez une eventLogException lors de l’utilisation Get-WinEvent sur Windows.

La cause

La Get-WinEvent commande PowerShell s’appuie sur une entrée de Registre pour rechercher les journaux par un paramètre spécifique ProviderName.

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 reg import iotedge.reg commande :

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 DPS

Symptômes

IoT Edge ne parvient pas à démarrer avec le message d’erreur failed to provision with IoT Hub, and no valid device backup was found dps client error.

La cause

Une inscription de groupe est utilisée pour approvisionner un appareil IoT Edge sur un hub IoT. 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’a pas été reprovisionné.

Solution

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

Pour reprovisionner automatiquement, définissez-le dynamic_reprovisioning: true dans le fichier de configuration de l’appareil. Définir cet indicateur sur true opte pour la fonctionnalité de reprovisionnement dynamique. IoT Edge détecte les situations où l'appareil semble avoir été réinitialisé pour le cloud en surveillant sa propre connexion à IoT Hub afin de détecter 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 tentera de reprovisionner cet appareil avec Azure pour recevoir les nouvelles informations d’approvisionnement IoT Hub.

Lorsqu'on utilise l'approvisionnement externe, le démon notifie également le point de terminaison d'approvisionnement externe concernant l'événement de reprovisionnement avant d'arrêter le service. Pour plus d’informations, consultez Concepts du réapprovisionnement d’appareils IoT Hub.

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

La 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 signale continuellement « fichier de configuration vide... ».

La 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 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’appliqueront à 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 à l’emplacement approprié pour votre plateforme,

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

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

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"
    ]
  }
}

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.

La 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 comme l’une des erreurs suivantes dans les journaux de log.

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)

ou

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)

La 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 :

1. Accédez à votre hub IoT et sélectionnez Appareils sous le menu Gestion des périphériques.

2. Sélectionnez l’appareil IoT Edge que vous souhaitez modifier.

3. Sélectionnez Définir modules.

4. Sélectionnez Paramètres du runtime.

5. Dans les paramètres du module Edge Hub , supprimez tout dans la zone de texte Créer des options .

6. Enregistrez vos modifications et créez le déploiement.

Dans le fichier deployment.json :

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

2. 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"
   }
   

3. 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"
   }
   

4. Enregistrez le fichier et appliquez-le à 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 )

La 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 ID de processus différent de celui initialement établi, 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.

La 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 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)

La 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/.

1. 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
2. Modifiez la configuration d’iotedge pour utiliser /var/lib/iotedge/*.sock dans les sections connect et listen
3. Si vous avez déjà des modules, ils ont les anciens montages /var/run/iotedge/*.sock, alors remplacez-les par docker rm -f.

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

Symptôme

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

La 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 problèmes d’incompatibilité d’image hôte et conteneur. Si les systèmes d’exploitation sont différents, mettez-les à jour vers IoT Edge Windows version 1809 build 17763 et régénérez l’image Docker utilisée pour ce module.

Réseautage

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

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

1. Dans le Portail Azure, accédez au panneau Vue d’ensemble de votre machine virtuelle.

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

   

3. Fournissez une valeur pour l’étiquette de nom DNS , puis sélectionnez Enregistrer.

4. Copiez le nouveau nom DNS, qui doit être au format <DNSnamelabel>.<vmlocation.cloudapp.azure.com>.

5. Dans la machine virtuelle, utilisez la commande suivante pour configurer 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.

La 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 :

1. Ouvrez l’application Exécuter .

2. Entrez regedit dans la zone de texte, puis sélectionnez Ok.

3. Dans la fenêtre Éditeur du Registre , accédez à HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.

4. Recherchez le paramètre IPEnableRouter .

   1. Si le paramètre existe, définissez la valeur du paramètre sur 1.

   2. Si le paramètre n’existe pas, ajoutez-le en tant que nouveau paramètre avec les paramètres suivants :

      Réglage	Valeur
      Nom	IPEnableRouter
      Catégorie	REG_DWORD
      Valeur	1

5. Fermez la fenêtre de l’éditeur de Registre.

6. Redémarrez votre système pour appliquer les modifications.

Sur Linux :

1. Ouvrez le fichier sysctl.conf.

   sudo nano /etc/sysctl.conf
   

2. Ajoutez la ligne suivante au fichier.

   net.ipv4.ip_forward=1
   

3. Enregistrez et fermez le fichier.

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