Compartir vía

Soluciones a problemas comunes de Azure IoT Edge

  • Artículo

Se aplica a: icono IoT Edge 1.1

Importante

IoT Edge 1.1: la fecha de finalización del soporte técnico fue el 13 de diciembre de 2022. Consulte la página del ciclo de vida de productos de Microsoft para obtener información sobre cómo se admite este producto, servicio, tecnología o API. Para más información sobre cómo actualizar a la versión más reciente de IoT Edge, consulte Actualización de IoT Edge.

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 en el dispositivo IoT Edge, consulte Solución de problemas del dispositivo IoT Edge.

Aprovisionamiento e implementación

El módulo de IoT Edge módulo se implementa correctamente y, a continuación, 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 de Azure Portal o Crear una implementación para un dispositivo individual de Visual Studio Code se aplicarán momentáneamente. Inicialmente, verá en el dispositivo los módulos que ha definido. 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 el artículo Descripción de las implementaciones automáticas de IoT Edge en un único dispositivo o a escala.

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

Síntomas

Aparece EventLogException al usar Get-WinEvent en Windows.

Causa

El comando de PowerShell Get-WinEvent se basa en que esté presente una entrada del Registro para encontrar los registros por un elemento ProviderName concreto.

Solución

Establezca una entrada del 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 mediante el comando 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

Error de cliente de DPS

Síntomas

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

Causa

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

Solución

  1. Compruebe que las credenciales de DPS son correctas.
  2. Aplique la configuración con 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 reaprovisionamiento mediante sudo iotedge system reprovision.

Para volver a aprovisionarlo automáticamente, establezca dynamic_reprovisioning: true en el archivo de configuración del dispositivo. Al establecer esta marca en true, se opta por la característica de reaprovisionamiento 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 determinados errores en su propia conexión de IoT Hub. IoT Edge responde cerrándose él mismo y todos los módulos de Edge. 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.

Al usar el aprovisionamiento externo, el demonio también notificará al punto de conexión de aprovisionamiento externo el evento de reaprovisionamiento antes de cerrarse. Para más información, consulte Conceptos sobre el 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 un minuto aproximadamente y luego 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 cada uno de los módulos en los que se comunica. 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 se está ejecutando edgeAgent, pero notifica "archivo de configuración vacío..." continuamente.

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 del entorno en la configuración del motor de contenedor que se va a 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 correcta para la plataforma:

Plataforma Location
Linux /etc/docker
Host de Windows con contenedores de Windows C:\ProgramData\iotedge-moby\config

Si la ubicación ya contiene el archivo daemon.json, agréguele la clave dns y guarde el archivo.

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

Plataforma Get-Help
Linux sudo systemctl restart docker
Windows (Administrador de PowerShell) Restart-Service iotedge-moby -Force

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

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

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

Advertencia

Si usa este método y especifica la dirección DNS incorrecta, edgeAgent pierde la conexión con IoT Hub y no puede recibir nuevas implementaciones para corregir el problema. Para resolver este problema, puede volver a instalar el entorno de ejecución de Azure IoT Edge. Antes de instalar una nueva instancia de IoT Edge, asegúrese de quitar los contenedores de edgeAgent de la instalación anterior.

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

No se puede ejecutar un contenedor y los registros de edgeAgent informan de 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)

Or

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 a su centro de IoT y seleccione Dispositivos en el menú Administración de dispositivos.

  2. Seleccione el dispositivo IoT Edge que desee actualizar.

  3. Seleccione Set modules (Establecer módulos).

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

  5. En la configuración del módulo Edge Hub, elimine todo el contenido del cuadro de texto Opciones de creación.

  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 que se estableció inicialmente, se rechazará el mensaje y se generará el 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 más información, consulte el registro de cambios de la versión v1.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

En 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 el IoT Hub, seleccione el dispositivo de IoT Edge y, en la página Detalles del dispositivo, seleccione Establecer módulos>Configuración de tiempo de ejecución. Cree una variable de entorno para el módulo del centro de IoT Edge denominada OptimizeForPerformance establecida en false.

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 no se crean los contenedores de módulos. El edgeAgent, edgeHub y otros módulos personalizados no se inician por el servicio IoT Edge. En registros aziot-edged, 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, coloque 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 los montajes /var/run/iotedge/*.sock antiguos, así que los debe docker rm -f.

No se pudo iniciar el módulo debido a un error de coincidencia del sistema operativo

Síntoma

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

Causa

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

Solución

Compruebe la versión de los distintos sistemas operativos Windows en Solución de errores de coincidencia de imágenes de host y contenedor. Si los sistemas operativos son diferentes, actualícelos a la versión 1809 de Windows, compilación 17763 para IoT Edge y vuelva a compilar la imagen de Docker usada para ese módulo.

Redes

Error de nombre de host no válido del demonio de seguridad de IoT Edge

Síntomas

Al intentar consultar los registros del administrador de seguridad de IoT Edge se produce un error y se muestra el siguiente mensaje:

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 el nombre DNS. Si la máquina virtual ya tiene configurado un nombre DNS, no es necesario configurar uno nuevo.

    Configuración del nombre DNS de la máquina virtual

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

  4. Copie el nuevo nombre DNS, que debe tener el formato <etiquetanombreDNS>.< ubicaciónvm>.cloudapp.azure.com.

  5. Dentro de la máquina virtual, use el comando siguiente para configurar el tiempo 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, vea Información sobre 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 Value
      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.