Soluciones a problemas comunes de Azure IoT Edge

Se aplica a: IoT Edge 1.1

Use este artículo para identificar y resolver problemas comunes al usar soluciones de IoT Edge. Si necesita información sobre cómo buscar registros y errores desde el dispositivo IoT Edge, consulte Solución de problemas del dispositivo IoT Edge.

Aprovisionamiento e implementación

El módulo de IoT Edge se implementa correctamente y luego desaparece del dispositivo

Síntomas

Después de configurar los módulos para un dispositivo IoT Edge, los módulos se implementan correctamente, pero después de unos minutos desaparecen del dispositivo y de los detalles del dispositivo en Azure Portal. También pueden aparecer en el dispositivo otros módulos distintos a los definidos.

Causa

Si una implementación automática tiene como destino un dispositivo, tendrá prioridad sobre la configuración manual de los módulos para un único dispositivo. La funcionalidad Establecer módulos en Azure Portal o Crear implementación para una sola funcionalidad de dispositivo en Visual Studio Code surte efecto durante un momento. Verá cómo los módulos que ha definido comienzan en el dispositivo. A continuación, se aplicará la prioridad de la implementación automática, que sobrescribe las propiedades deseadas del dispositivo.

Solución

Use solo un tipo de mecanismo de implementación por dispositivo, ya sea una implementación automática o implementaciones de dispositivo individuales. Si tiene varias implementaciones automáticas que tienen como destino un dispositivo, puede cambiar la prioridad o las descripciones de destino para asegurarse de que se aplique la correcta a un dispositivo determinado. También puede actualizar el dispositivo gemelo para que ya no coincida con la descripción de destino de la implementación automática.

Para más información, consulte Descripción de las implementaciones automáticas de IoT Edge para dispositivos individuales o a escala.

No se pueden obtener los registros del entorno de ejecución de IoT Edge en Windows

Síntomas

Obtienes una excepción EventLogException cuando usas Get-WinEvent en Windows.

Causa

El Get-WinEvent comando de PowerShell depende de que una entrada del Registro esté presente para encontrar logs mediante un determinado ProviderName.

Solución

Establezca una entrada de registro para el demonio de IoT Edge. Cree un archivo iotedge.reg con el siguiente contenido e impórtelo en el Registro de Windows haciendo doble clic en él o usando el reg import iotedge.reg comando :

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

Error de cliente de DPS

Síntomas

IoT Edge no se puede iniciar con el mensaje de error failed to provision with IoT Hub, and no valid device backup was found dps client error.

Causa

Una inscripción de grupo se usa para aprovisionar un dispositivo IoT Edge en un IoT Hub. El dispositivo IoT Edge se mueve a otro centro. El registro se elimina en DPS. Se crea un nuevo registro en DPS para el nuevo centro. El dispositivo no se reaproviona.

Solución

1. Compruebe que las credenciales de DPS son correctas.
2. Aplique la configuración mediante sudo iotedge apply config.
3. Si el dispositivo no se vuelve a aprovisionar, reinicie el dispositivo mediante sudo iotedge system restart.
4. Si el dispositivo no se vuelve a aprovisionar, fuerce el aprovisionamiento mediante sudo iotedge system reprovision.

Para volver a aprovisionar automáticamente, establezca dynamic_reprovisioning: true en el archivo de configuración del dispositivo. Al establecer esta bandera en "true," se opta por la característica de reprovisionamiento dinámico. IoT Edge detecta situaciones en las que parece que el dispositivo se ha vuelto a aprovisionar en la nube mediante la supervisión de su propia conexión con IoT Hub para detectar ciertos errores. IoT Edge responde cerrando todos los módulos de Edge y sí mismos. La próxima vez que se inicie el demonio, intentará volver a aprovisionar este dispositivo con Azure para recibir la nueva información de aprovisionamiento de IoT Hub.

Cuando se utiliza el aprovisionamiento externo, el demonio también notificará al endpoint de aprovisionamiento externo sobre el evento de reaprovisionamiento antes de apagarse. Para más información, consulte Conceptos de reaprovisionamiento de dispositivos de IoT Hub.

Entorno de tiempo de ejecución de IoT Edge

El agente de IoT Edge se detiene después de un minuto

Síntomas

El módulo edgeAgent se inicia y se ejecuta correctamente durante aproximadamente un minuto y, a continuación, se detiene. Los registros indican que el agente de IoT Edge intenta conectarse a IoT Hub a través de AMQP y después intenta conectarse mediante AMQP a través de WebSocket. Cuando se produce un error, se cierra el agente de IoT Edge.

Registros de ejemplo de 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...

Causa

Una configuración de redes en la red del host evita que el agente de IoT Edge alcance la red. El agente intentará conectarse en primer lugar a través de AMQP (puerto 5671). Si se produce un error en la conexión, lo intentará mediante los protocolos WebSocket (puerto 443).

El entorno de ejecución de IoT Edge configura una red para que cada uno de los módulos pueda comunicarse. En Linux, esta red es una red de puente. En Windows, se usa NAT. Este problema es más frecuente en los dispositivos de Windows que usan contenedores de Windows que usan la red NAT.

Solución

Asegúrese de que hay una ruta a Internet para las direcciones IP asignadas a esta red de puente o NAT. A veces, una configuración de VPN en el host invalida la red de IoT Edge.

El módulo Agente de Edge notifica "archivo de configuración vacío" y no se inicia ningún módulo en el dispositivo

Síntomas

El dispositivo tiene problemas para iniciar los módulos definidos en la implementación. Solo edgeAgent se está ejecutando, pero informa continuamente de "archivo de configuración vacío...".

Causa

De forma predeterminada, IoT Edge inicia módulos en su propia red de contenedores aislada. El dispositivo pueda tener problemas con la resolución de nombres DNS dentro de esta red privada.

Solución

Opción 1: Establecer el servidor DNS en la configuración del motor de contenedor

Especifique el servidor DNS para su entorno en la configuración del motor de contenedor, que se aplicará a todos los módulos de contenedor iniciados por el motor. Cree un archivo denominado daemon.json y especifique el servidor DNS que se va a usar. Por ejemplo:

{
    "dns": ["1.1.1.1"]
}

Este servidor DNS se establece en un servicio DNS accesible públicamente. Sin embargo, algunas redes, como las redes corporativas, tienen instalados sus propios servidores DNS y no permitirán el acceso a los servidores DNS públicos. Por lo tanto, si el dispositivo perimetral no puede acceder a un servidor DNS público, reemplácelo por una dirección de servidor DNS accesible.

Coloque daemon.json en la ubicación adecuada para su plataforma:

Si la ubicación ya contiene daemon.json el archivo, agregue la clave dns a él y guarde el archivo.

Reinicie el motor de contenedor para que las actualizaciones se apliquen.

Opción 2: Establecimiento del servidor DNS en la implementación de IoT Edge por módulo

Se puede establecer el servidor DNS para createOptions de cada módulo en la implementación de IoT Edge. Por ejemplo:

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

Asegúrese de establecer esta configuración también para los módulos edgeAgent y edgeHub .

El agente de IoT Edge no puede acceder a la imagen de un módulo (403)

Síntomas

Un contenedor no se puede ejecutar y edgeAgent registra un error 403.

Causa

El módulo del agente de IoT Edge no tiene permisos para acceder a la imagen de un módulo.

Solución

Asegúrese de que las credenciales del registro de contenedor sean correctas en el manifiesto de implementación del dispositivo.

No se puede iniciar el centro de IoT Edge

Síntomas

El módulo edgeHub no se inicia. Puede ver un mensaje similar a uno de los siguientes errores en los registros:

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)

O bien

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)

Causa

Algún otro proceso en la máquina host ha enlazado un puerto al que el módulo edgeHub está intentando enlazarse. El centro de IoT Edge asigna los puertos 443, 5671 y 8883 para su uso en escenarios de puerta de enlace. El módulo no se inicia si otro proceso ya ha enlazado uno de esos puertos.

Solución

Puede resolver este problema de dos maneras:

Si el dispositivo IoT Edge funciona como un dispositivo de puerta de enlace, debe buscar y detener el proceso que está usando el puerto 443, 5671 o 8883. Un error en el puerto 443 normalmente significa que el otro proceso es un servidor web.

Si no necesita usar el dispositivo IoT Edge como puerta de enlace, puede quitar los enlaces de puertos de las opciones de creación del módulo edgeHub. Puede cambiar las opciones de creación en Azure Portal o directamente en el archivo deployment.json.

En Azure Portal:

1. Vaya al centro de IoT y seleccione Dispositivos en el menú Administración de dispositivos.

2. Seleccione el dispositivo IoT Edge que desee actualizar.

3. Seleccione Establecer módulos.

4. Seleccione Configuración del entorno de ejecución.

5. En la configuración del módulo edge Hub , elimine todo en el cuadro de texto Crear opciones .

6. Guarde los cambios y cree la implementación.

En el archivo deployment.json:

1. Abra el archivo deployment.json que aplicó al dispositivo IoT Edge.

2. Busque la configuración de edgeHub en la sección de propiedades deseadas de 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. Quite la línea createOptions y la coma al final de la línea image anterior:

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

4. Guarde el archivo y vuelva a aplicarlo al dispositivo IoT Edge.

El módulo de IoT Edge no puede enviar un mensaje a edgeHub y se produce el error 404

Síntomas

Un módulo de IoT Edge personalizado no puede enviar un mensaje al centro de IoT Edge y se produce el error 404 Module not found. El entorno de ejecución de IoT Edge imprime el mensaje siguiente en los registros:

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 )

Causa

Por motivos de seguridad, el entorno de ejecución de IoT Edge aplica la identificación de proceso para todos los módulos que se conectan a edgeHub. Comprueba que todos los mensajes enviados por un módulo proceden del identificador de proceso principal del módulo. Si un módulo envía un mensaje desde un identificador de proceso diferente del establecido inicialmente, rechazará el mensaje con un mensaje de error 404.

Solución

A partir de la versión 1.0.7, todos los procesos de módulo tienen autorización para conectarse. Para obtener más información, consulte el registro de cambios de versión 1.0.7.

Si no es posible actualizar a la versión 1.0.7, realice los pasos siguientes. Asegúrese de que el módulo de IoT Edge personalizado siempre usa el mismo identificador de proceso para enviar los mensajes a edgeHub. Por ejemplo, asegúrese de usar ENTRYPOINT en lugar del comando CMD en el archivo de Docker. El comando CMD genera un identificador de proceso para el módulo y otro identificador de proceso para el comando bash que ejecuta el programa principal, pero ENTRYPOINT produce un único identificador de proceso.

Problemas de estabilidad en dispositivos más pequeños

Síntomas

Es posible que experimente problemas de estabilidad en dispositivos con recursos limitados como Raspberry Pi, especialmente cuando se utiliza como puerta de enlace. Los síntomas incluyen excepciones de memoria insuficiente en el módulo del centro de IoT Edge, los dispositivos de nivel inferior no pueden conectarse o el dispositivo deja de enviar mensajes de telemetría después de unas horas.

Causa

El centro de IoT Edge, que forma parte del runtime de IoT Edge, está optimizado para el rendimiento de manera predeterminada e intenta asignar grandes fragmentos de memoria. Esta optimización no es ideal para dispositivos con perímetro limitado y puede causar problemas de estabilidad.

Solución

Para el centro de IoT Edge, establezca una variable de entorno OptimizeForPerformance en false. Hay dos maneras de establecer variables de entorno:

En Azure Portal:

En su IoT Hub, seleccione su dispositivo IoT Edge y, en la página de detalles del dispositivo, seleccione Configurar módulos>Configuración del entorno de ejecución. Cree una variable de entorno para el módulo del centro de IoT Edge denominado OptimizeForPerformance establecido en false.

En el manifiesto de implementación:

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

El demonio de seguridad no se pudo iniciar correctamente

Síntomas

El demonio de seguridad no se inicia y los contenedores de módulos no se crean. El edgeAgent, edgeHub y otros módulos personalizados no se inician por el servicio de IoT Edge. En los registros aziot-edged, usted ve este error:

• El demonio no se pudo iniciar correctamente: no se pudo iniciar el servicio de administración
• causado por: un error en la ruta de acceso /var/run/iotedge/mgmt.sock
• causado por: Permiso denegado (error 13 del SO)

Causa

Para todas las distribuciones de Linux excepto CentOS 7, la configuración predeterminada de IoT Edge es usar la activación de sockets systemd. Se produce un error de permiso si cambia el archivo de configuración para que no use la activación de sockets, pero deja las direcciones URL como /var/run/iotedge/*.sock, ya que el usuario iotedge no puede escribir a /var/run/iotedge, lo que significa que no puede desbloquear y montar los propios sockets.

Solución

No es necesario deshabilitar la activación de sockets en una distribución en la que se admite la activación de sockets. Sin embargo, si prefiere no usar la activación de sockets, sitúe los sockets en /var/lib/iotedge/.

1. Ejecute systemctl disable iotedge.socket iotedge.mgmt.socket para deshabilitar las unidades de socket para que systemd no las inicie innecesariamente.
2. Cambio de la configuración de iotedge para usar /var/lib/iotedge/*.sock en las secciones connect y listen
3. Si ya tiene módulos, tienen las monturas /var/run/iotedge/*.sock antiguas, así que debe docker rm -f.

No se pudo iniciar el módulo debido a que el sistema operativo no coincide

Síntoma

El módulo edgeHub no se inicia en la versión 1.1 de IoT Edge.

Causa

El módulo de Windows usa una versión de Windows que no es compatible con la versión de Windows en el host. Se necesita la versión 1809 compilación 17763 de Windows IoT Edge como capa base para la imagen del módulo, pero se está usando una versión diferente.

Solución

Compruebe la versión de los distintos sistemas operativos Windows en Solucionar problemas de incompatibilidad de imágenes de host y contenedor. Si los sistemas operativos son diferentes, actualícelos a la versión 1809 de Windows de IoT Edge, compilación 17763 y recompile la imagen de Docker que se usa para ese módulo.

Redes

El demonio de seguridad de IoT Edge falla por un nombre de host no válido

Síntomas

Se produce un error al intentar comprobar los registros del administrador de seguridad de IoT Edge e imprime el mensaje siguiente:

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

Causa

El tiempo de ejecución de IoT Edge solo puede admitir los nombres de host que tienen menos de 64 caracteres. Las máquinas físicas no suelen tener nombres de host largos, pero el problema es más común en una máquina virtual. Los nombres de host generados automáticamente para las máquinas virtuales Windows hospedadas en Azure, en particular, suelen ser largos.

Solución

Cuando vea este error, puede resolverlo configurando el nombre DNS de la máquina virtual y, a continuación, estableciendo el nombre DNS como nombre de host en el comando de configuración.

1. En Azure Portal, navegue a la hoja de introducción de la máquina virtual.

2. Seleccione Configurar en Nombre DNS. Si la máquina virtual ya tiene configurado un nombre DNS, no es necesario configurar uno nuevo.

   

3. Proporcione un valor para la etiqueta de nombre DNS y seleccione Guardar.

4. Copie el nuevo nombre DNS, que debe tener el formato <DNSnamelabel>.<vmlocation.cloudapp.azure.com>.

5. Dentro de la máquina virtual, use el siguiente comando para configurar el entorno de ejecución de IoT Edge con el nombre DNS:

   • En Linux:

     sudo nano /etc/iotedge/config.yaml
     

   • En Windows:

     notepad C:\ProgramData\iotedge\config.yaml
     

El módulo IoT Edge notifica errores de conectividad

Síntomas

Los módulos IoT Edge que se conectan directamente a los servicios en la nube, incluidos los módulos en tiempo de ejecución, dejan de funcionar según lo previsto y devuelven errores de conexión o red.

Causa

Los contenedores se basan en el reenvío de paquetes IP para conectarse a Internet para que puedan comunicarse con los servicios en la nube. El reenvío de paquetes IP está habilitado de forma predeterminada en Docker, pero, si se deshabilita, los módulos que se conectan a los servicios en la nube no funcionarán según lo previsto. Para más información, consulte Descripción de la comunicación de contenedores en la documentación de Docker.

Solución

Siga estos pasos para habilitar el reenvío de paquetes IP.

En Windows:

1. Abra la aplicación Ejecutar .

2. Escriba regedit en el cuadro de texto y seleccione Aceptar.

3. En la ventana Editor del Registro, vaya a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.

4. Busque el parámetro IPEnableRouter .

   1. Si el parámetro existe, establezca el valor del parámetro en 1.

   2. Si el parámetro no existe, agréguelo como nuevo parámetro con la siguiente configuración:

      Configuración	Valor
      Nombre	IPEnableRouter
      Tipo	REG_DWORD
      Valor	1

5. Cierre la ventana del editor del Registro.

6. Reinicie el sistema para aplicar los cambios.

En Linux:

1. Abra el archivo sysctl.conf .

   sudo nano /etc/sysctl.conf
   

2. Agregue la siguiente línea al archivo.

   net.ipv4.ip_forward=1
   

3. Guarde y cierre el archivo.

4. Reinicie el servicio de red y el servicio de Docker para aplicar los cambios.

Pasos siguientes

¿Cree que encontró un error en la plataforma de IoT Edge? Envíe un problema para que podamos seguir mejorando.

Si tiene más preguntas, cree una solicitud de soporte técnico para obtener ayuda.