Soluciones a problemas comunes de Azure IoT Edge

Artículo
12/10/2024

Se aplica a: IoT Edge 1.5 IoT Edge 1.4

Importante

IoT Edge 1.5 LTS e IoT Edge 1.4 LTS son versiones compatibles. IoT Edge 1.4 LTS finaliza el ciclo de vida el 12 de noviembre de 2024. Si está usando una versión anterior, 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.

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 edgeAgent se está ejecutando, pero informa archivo de configuración vacío....
Cuando se ejecuta sudo iotedge check en un dispositivo, notifica El motor de contenedor no está configurado con el valor del servidor DNS, lo que puede afectar a la conectividad de IoT Hub. Consulte https://aka.ms/iotedge-prod-checklist-dns para ver los procedimientos recomendados.

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.
Si usa una instalación instantánea de IoT Edge, el archivo de configuración de Docker es una ubicación diferente. Consulte la opción de solución 3.

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 aplica 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 el directorio /etc/docker del dispositivo.

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

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

sudo systemctl restart docker

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.

Opción 3: pasar la ubicación del archivo de configuración de Docker para verificar el comando

Si IoT Edge se instala como un ajuste, use el parámetro --container-engine-config-file para especificar la ubicación del archivo de configuración de Docker. Por ejemplo, si el archivo de configuración de Docker se encuentra en /var/snap/docker/current/config/daemon.json, ejecute el siguiente comando: iotedge check --container-engine-config-file '/var/snap/docker/current/config/daemon.json'.

Actualmente, el mensaje de advertencia continúa apareciendo en la salida de comprobación de iotedge incluso después de establecer la ubicación del archivo de configuración. Compruebe el error porque el ajuste de IoT Edge no tiene acceso de lectura al complemento de Docker. Si usa la comprobación de iotedge en el proceso de versión, puede suprimir el mensaje de advertencia mediante el parámetro --ignore container-engine-dns container-engine-logrotate.

Módulo del agente de Edge con informes de conexión LTE "configuración vacía del agente de Edge" y provoca un "error de red transitorio"

Síntomas

Un dispositivo configurado con conexión LTE tiene problemas al iniciar módulos definidos en la implementación. edgeAgent no puede conectarse a IoT Hub e informa sobre una configuración de agente de Edge vacía y se produjo un error transitorio de red.

Causa

Algunas redes tienen sobrecarga de paquetes, lo que hace que la MTU de red de Docker predeterminada (1500) sea demasiado alta y hace que la fragmentación de paquetes impida el acceso a los recursos externos.

Solución

Compruebe la configuración de MTU para la red de Docker.

docker network inspect <network name>
Compruebe la configuración de MTU para el adaptador de red físico en el dispositivo.

ip addr show eth0

Nota:

La MTU de la red de Docker no puede ser superior a la MTU del dispositivo. Póngase en contacto con su ISP para obtener más información.

Si ve un tamaño de MTU diferente para la red de Docker y el dispositivo, pruebe la siguiente solución alternativa:

Cree una nueva red. Por ejemplo,

docker network create --opt com.docker.network.driver.mtu=1430 test-mtu

En el ejemplo, el valor de MTU para el dispositivo es 1430. Por lo tanto, la MTU para la red de Docker se establece en 1430.
Detenga y quite la red de Azure.

docker network rm azure-iot-edge
Vuelva a crear la red de Azure.

docker network create --opt com.docker.network.driver.mtu=1430 azure-iot-edge
Quite todos los contenedores y reinicie el servicio 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

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.

El agente de IoT Edge realiza llamadas de identidad excesivas

Síntomas

El agente de IoT Edge realiza llamadas de identidad excesivas a Azure IoT Hub.

Causa

La configuración incorrecta del manifiesto de implementación de dispositivos provoca una implementación incorrecta en el dispositivo. La lógica de reintento del agente de IoT Edge continúa reintentando la implementación. Cada reintento realiza llamadas de identidad hasta que la implementación se realiza correctamente. Por ejemplo, si el manifiesto de implementación especifica un URI de módulo que no existe en el registro de contenedor o está mal escrito, el agente de IoT Edge reintenta la implementación hasta que se corrija el manifiesto de implementación.

Solución

Compruebe el manifiesto de implementación en Azure Portal. Corrija los errores y vuelva a implementar el manifiesto en el 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)

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:

Vaya a su centro de IoT y seleccione Dispositivos en el menú Administración de dispositivos.
Seleccione el dispositivo IoT Edge que desee actualizar.
Seleccione Set modules (Establecer módulos).
Seleccione Configuración del entorno de ejecución.
En la configuración del módulo Edge Hub, elimine todo el contenido del cuadro de texto Opciones de creación de contenedor.
Seleccione Aplicar para guardar los cambios y crear la implementación.

En el archivo deployment.json:

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

Busque la configuración de edgeHub en la sección de propiedades deseadas de 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"
   }

Quite la línea createOptions y la coma al final de la línea image anterior:

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

Seleccione Crear para aplicarlo de nuevo al dispositivo de 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, rechaza 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 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 con el tipo True/False establecido en False.

Seleccione Aplicar para guardar los cambios y, a continuación, seleccione Revisar y crear.

La variable de entorno ahora está en la propiedad edgeHub del manifiesto de implementación:

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

Seleccione Crear para guardar los cambios e implementar el módulo.

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. CentOS es Fin de vida (EOL). Para más información, consulte la Guía de fin de ciclo de vida de CentOS.

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

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

La limpieza de la cola de mensajes es lenta

Síntomas

La cola de mensajes no se limpia una vez procesados los mensajes. La cola de mensajes crece con el tiempo y finalmente, hace que el entorno de ejecución de IoT Edge se agote la memoria.

Causa

El intervalo de limpieza de mensajes se controla mediante el TTL del mensaje de cliente (período de vida) y la variable de entorno EdgeHub MessageCleanupIntervalSecs. El valor TTL del mensaje predeterminado es dos horas y el valor predeterminado MessageCleanupIntervalSecs valor es de 30 minutos. Si la aplicación usa un valor de TTL más corto que el predeterminado y no ajusta el valor MessageCleanupIntervalSecs, los mensajes expirados no se limpiarán hasta el siguiente intervalo de limpieza.

Solución

Si cambia el valor de TTL de la aplicación que es más corto que el valor predeterminado, ajuste también el valor de MessageCleanupIntervalSecs. El valor MessageCleanupIntervalSecs debe ser significativamente menor que el valor de TTL más pequeño que usa el cliente. Por ejemplo, si la aplicación cliente define un TTL de cinco minutos en el encabezado del mensaje, establezca el valorMessageCleanupIntervalSecs en un minuto. Esta configuración garantiza que los mensajes se limpien en seis (5 + 1) minutos.

Para configurar el valor MessageCleanupIntervalSecs, establezca la variable de entorno en el manifiesto de implementación del módulo del centro de IoT Edge. Para obtener más información acerca de cómo establecer variables de entorno en tiempo de ejecución, consulte Edge Agent and Edge Hub Environment Variables.

IoT Edge Hub informa de System.FormatException mediante el protocolo AMQP

Síntomas

Si enruta mensajes desde un dispositivo con IoT Edge a una instancia de IoT Hub mediante el protocolo AMQP y se establece la propiedad iothub-creation-time-utc en los mensajes salientes del dispositivo, IoT Edge Hub notifica un error System.FormatException. El mensaje de error es similar al siguiente:

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

Causa

El valor iot-hub-creation-time-utc no cumple los criterios de formato estrictos. El formato que requiere Edge Hub es un subconjunto de ISO 8601.

Solución

Se trata de un problema conocido de IoT Edge Hub con el protocolo AMQP. Actualmente, se está buscando una solución para este problema. El protocolo MQTT no tiene este problema.

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.

En Azure Portal, navegue a la hoja de introducción de la máquina virtual.
Para abrir el panel de configuración, seleccione el vínculo No configurado (si la máquina virtual es nueva) o seleccione el nombre DNS existente en Nombre DNS> de Essentials. Si la máquina virtual ya tiene configurado un nombre DNS, no es necesario configurar uno nuevo.
Proporcione un valor para la etiqueta de nombre DNS si aún no tiene uno y seleccione Guardar.
Copie el nuevo nombre DNS, que debe tener el formato siguiente:
<DNSnamelabel>.<vmlocation>.cloudapp.azure.com.
En el dispositivo IoT Edge, abra el archivo de configuración.
```
sudo nano /etc/aziot/config.toml
```
Reemplace el valor de hostname por su nombre DNS.
Guarde y cierre el archivo y, a continuación, aplique los cambios a IoT Edge.
```
sudo iotedge config apply
```

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.

Abra el archivo sysctl.conf.
```
sudo nano /etc/sysctl.conf
```
Agregue la siguiente línea al archivo.
```
net.ipv4.ip_forward=1
```
Guarde y cierre el archivo.
Reinicie el servicio de red y el servicio de Docker para aplicar los cambios.

IoT Edge detrás de una puerta de enlace no puede realizar solicitudes HTTP ni iniciar el módulo edgeAgent

Síntomas

El entorno de ejecución de IoT Edge está activo con un archivo de configuración válido, pero no puede iniciar el módulo edgeAgent. El comando iotedge list devuelve una lista vacía. El entorno de ejecución de IoT Edge informa de Could not perform HTTP request en los registros.

Causa

los dispositivos de IoT Edge detrás de una puerta de enlace obtienen las imágenes del módulo del dispositivo de IoT Edge primario especificado en el campo parent_hostname del archivo de configuración. El error Could not perform HTTP request significa que el dispositivo de nivel inferior no puede llegar a su dispositivo primario mediante HTTP.

Solución

Asegúrese de que el dispositivo de IoT Edge primario puede recibir solicitudes entrantes del dispositivo de IoT Edge de nivel inferior. Abra el tráfico de red en los puertos 443 y 6617 para las solicitudes procedentes del dispositivo de nivel inferior.

IoT Edge detrás de una puerta de enlace no puede realizar solicitudes HTTP ni iniciar el módulo edgeAgent

Síntomas

El demonio de IoT Edge está activo con un archivo de configuración válido, pero no puede iniciar el módulo edgeAgent. El comando iotedge list devuelve una lista vacía. El demonio de IoT Edge registra el informe Could not perform HTTP request.

Causa

Solución

IoT Edge detrás de una puerta de enlace no se puede conectar al migrar de un centro de IoT a otro

Síntomas

Al intentar migrar una jerarquía de dispositivos IoT Edge de un centro de IoT a otro, el dispositivo IoT Edge primario de nivel superior puede conectarse a IoT Hub, pero los dispositivos IoT Edge de nivel inferior, no. El informe de registros Unable to authenticate client downstream-device/$edgeAgent with module credentials.

Causa

Las credenciales de los dispositivos de nivel inferior no se actualizaron correctamente cuando se produjo la migración al nuevo centro IoT. Debido a esto, los módulos edgeAgent y edgeHub se han establecido para tener el tipo de autenticación none de (valor predeterminado si no se establece explícitamente). Durante la conexión, los módulos de los dispositivos de bajada usan credenciales antiguas, lo que provoca un error en la autenticación.

Solución

Al migrar al nuevo centro de IoT (suponiendo que no use DPS), siga estos pasos en orden:

Siga esta guía para exportar e importar identidades de dispositivo desde el centro de IoT antiguo al nuevo
Reconfigure todas las implementaciones y configuraciones de IoT Edge en el nuevo centro de IoT
Reconfigure todas las relaciones entre dispositivos primarios y secundarios en el nuevo centro de IoT
Actualice cada dispositivo para que apunte al nuevo nombre de host de IoT Hub (iothub_hostname en [provisioning] en config.toml)
Si ha elegido excluir las claves de autenticación durante la exportación del dispositivo, vuelva a configurar cada dispositivo con las nuevas claves facilitadas por el nuevo centro de IoT (device_id_pk en [provisioning.authentication]config.tomlen )
Reinicie primero el dispositivo Edge primario de nivel superior y asegúrese de que está en funcionamiento
Reinicie cada dispositivo en el nivel de jerarquía por nivel de arriba a abajo

IoT Edge tiene un rendimiento de mensajes bajo cuando está geográficamente lejos de IoT Hub

Síntomas

Los dispositivos de Azure IoT Edge que están geográficamente lejos de Azure IoT Hub tienen un rendimiento de mensajes inferior al esperado.

Causa

Una latencia alta entre el dispositivo e IoT Hub puede provocar un rendimiento de mensajes inferior al esperado. IoT Edge usa un tamaño de lote de mensajes predeterminado de 10. Esto limita el número de mensajes que se envían en un solo lote, lo que aumenta el número de recorridos de ida y vuelta entre el dispositivo e IoT Hub.

Solución

Intente aumentar la variable de entorno MaxUpstreamBatchSize del centro de IoT Edge. Esto permite enviar más mensajes en un único lote, lo que reduce el número de recorridos de ida y vuelta entre el dispositivo e IoT Hub.

Para establecer variables de entorno de Azure Edge Hub en Azure Portal:

Vaya a IoT Hub y seleccione Dispositivos en el menú Administración de dispositivos.
Seleccione el dispositivo IoT Edge que desee actualizar.
Seleccione Set modules (Establecer módulos).
Seleccione Configuración del entorno de ejecución.
En la pestaña de configuración del módulo Edge Hub, agregue la variable de entorno MaxUpstreamBatchSize como tipo de Número con un valor de 20.
Seleccione Aplicar.

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.

Compartir a través de

Soluciones a problemas comunes de Azure 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

Causa

Solución

Entorno de tiempo de ejecución de IoT Edge

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

Síntomas

Causa

Solución

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

Causa

Solución

Módulo del agente de Edge con informes de conexión LTE "configuración vacía del agente de Edge" y provoca un "error de red transitorio"

Síntomas

Causa

Solución

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

Síntomas

Causa

Solución

El agente de IoT Edge realiza llamadas de identidad excesivas

Síntomas

Causa

Solución

No se puede iniciar el centro de IoT Edge

Síntomas

Causa

Solución

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

Síntomas

Causa

Solución

Problemas de estabilidad en dispositivos más pequeños

Síntomas

Causa

Solución

El demonio de seguridad no se pudo iniciar correctamente

Síntomas

Causa

Solución

La limpieza de la cola de mensajes es lenta

Síntomas

Causa

Solución

IoT Edge Hub informa de System.FormatException mediante el protocolo AMQP

Síntomas

Causa

Solución

Redes

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

Síntomas

Causa

Solución

El módulo IoT Edge notifica errores de conectividad

Síntomas

Causa

Solución

IoT Edge detrás de una puerta de enlace no puede realizar solicitudes HTTP ni iniciar el módulo edgeAgent

Síntomas

Causa

Solución

IoT Edge detrás de una puerta de enlace no puede realizar solicitudes HTTP ni iniciar el módulo edgeAgent

Síntomas

Causa

Solución

IoT Edge detrás de una puerta de enlace no se puede conectar al migrar de un centro de IoT a otro

Síntomas

Causa

Solución

IoT Edge tiene un rendimiento de mensajes bajo cuando está geográficamente lejos de IoT Hub

Síntomas

Causa

Solución

Pasos siguientes

Comentarios

Recursos adicionales