Soluciones a problemas comunes para Azure IoT Edge

Se aplica a: IoT Edge 1.5

Use este artículo para identificar y resolver problemas comunes al usar soluciones de IoT Edge. Para obtener información sobre cómo buscar registros y errores desde el dispositivo IoT Edge, consulte Troubleshoot your IoT Edge device.

Aprovisionamiento e implementación

IoT Edge módulo se implementa correctamente y, a continuación, desaparece del dispositivo.

Síntomas

Después de establecer 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 el portal de Azure. 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 el portal de Azure o la funcionalidad Crear implementación para un solo dispositivo en Visual Studio Code entra en vigor por un momento. Verá que 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 dispositivos 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 obtener más información, consulte Understand IoT Edge implementaciones automáticas para dispositivos individuales o a escala.

tiempo de ejecución de IoT Edge

IoT Edge Agente 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 muestran que el agente de IoT Edge intenta conectarse a IoT Hub a través de AMQP e intenta conectarse mediante AMQP a través de WebSocket. Cuando se produce un error en esa conexión, 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 red en la red host impide que el agente de IoT Edge llegue a 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 para la comunicación. En Linux, esta red es una red de puente. En Windows, usa NAT. Este problema es más común en dispositivos Windows que utilizan contenedores de Windows que emplean la red NAT.

Solución

Asegúrese de que hay una ruta a Internet para las direcciones IP asignadas a este puente o red NAT. A veces, una configuración de VPN en el host invalida la red 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 notifica un archivo de configuración vacío....

• Al ejecutar sudo iotedge check en un dispositivo, notifica El motor de contenedores no está configurado con la configuración del servidor DNS, lo que puede afectar a la conectividad con IoT Hub. Consulte https://aka.ms/iotedge-prod-checklist-dns para conocer las mejores prácticas.

Causa

• De forma predeterminada, IoT Edge inicia módulos en su propia red de contenedor aislada. Es posible que el dispositivo tenga 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 se encuentra en 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. Esta configuración se aplica a todos los módulos de contenedor que inicia el motor. Cree un archivo denominado daemon.jsony 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 sus propios servidores DNS y no permiten 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: Configurar el servidor DNS en la implementación de IoT Edge por módulo

Puede establecer el servidor DNS para la sección 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.

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

Si instala IoT Edge como un snap, 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 iotedge check incluso después de establecer la ubicación del archivo de configuración. Compruebe el error porque el ajuste IoT Edge no tiene acceso de lectura al complemento docker. Si utiliza iotedge check en su proceso de lanzamiento, puede suprimir el mensaje de advertencia mediante el uso del 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 una conexión LTE tiene problemas al iniciar módulos definidos en la implementación. El edgeAgent no se puede conectar a IoT Hub y reporta "configuración vacía del agente perimetral" 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 provoca la fragmentación de paquetes. Esta fragmentación impide el acceso a recursos externos.

Solución

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

   docker network inspect <network name>

2. Compruebe la configuración de MTU para el adaptador de red físico en el dispositivo.

   ip addr show eth0

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

1. 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. Establezca la MTU para la red de Docker en 1430.

2. Detenga y elimine la red de Azure.

   docker network rm azure-iot-edge

3. Vuelva a crear la red de Azure.

   docker network create --opt com.docker.network.driver.mtu=1430 azure-iot-edge

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

IoT Edge agente 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 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 autenticación 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 despliegue de dispositivos provoca un despliegue no exitoso en el dispositivo. La lógica de reintento del agente de IoT Edge continúa intentando la implementación. Cada reintento hace llamadas de identidad hasta que la implementación tenga éxito. 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 el portal de Azure. Corrija los errores y vuelva a implementar el manifiesto en el dispositivo.

El hub de IoT Edge falla al iniciar

Síntomas

El módulo edgeHub no se inicia. Es posible que vea un mensaje como 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

Otro proceso de la máquina host enlaza un puerto que el módulo edgeHub intenta enlazar. 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 enlaza uno de esos puertos.

Solución

Resuelva este problema de una de estas dos maneras:

Si el dispositivo IoT Edge funciona como dispositivo de puerta de enlace, busque y detenga el proceso que usa 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, quite los enlaces de puerto de las opciones de creación del módulo de EdgeHub. Puede cambiar las opciones de creación en el portal de Azure o directamente en el archivo deployment.json.

En el portal de Azure:

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

2. Seleccione el dispositivo IoT Edge que desea 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 de contenedor.

6. Seleccione Aplicar para guardar los cambios y crear 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": {
         "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"
      }
   

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

4. Seleccione Crear para volver a aplicarlo al dispositivo IoT Edge.

IoT Edge módulo no puede enviar un mensaje a edgeHub y devuelve el error 404

Síntomas

Un módulo de IoT Edge personalizado no puede enviar un mensaje al centro de IoT Edge y devuelve un 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 del proceso para todos los módulos que se conectan a edgeHub. Comprueba que todos los mensajes que envía un módulo proceden del identificador de proceso principal del módulo. Si un módulo intenta enviar un mensaje desde un identificador de proceso diferente, el tiempo de ejecución rechaza el mensaje y devuelve un mensaje de error 404.

Solución

A partir de la versión 1.0.7, todos los procesos de módulo se pueden conectar. Para obtener más información, consulte el registro de cambios de versión 1.0.7.

Si no puede actualizar a la versión 1.0.7, siga estos pasos. Asegúrese de que el módulo de IoT Edge personalizado siempre usa el mismo identificador de proceso para enviar mensajes a edgeHub. Por ejemplo, use el ENTRYPOINT comando en lugar del comando en el CMD archivo de Docker. El CMD comando da como resultado un identificador de proceso para el módulo y otro identificador de proceso para el comando bash que ejecuta el programa principal. El ENTRYPOINT comando da como resultado un identificador de proceso único.

Problemas de estabilidad en dispositivos más pequeños

Síntomas

Es posible que experimente problemas de estabilidad en dispositivos con restricciones de recursos como Raspberry Pi, especialmente cuando se usa como puerta de enlace. Los síntomas incluyen excepciones de memoria insuficiente en el módulo concentrador de IoT Edge, dispositivos descendentes que no se pueden conectar, o que el dispositivo falle al enviar mensajes de telemetría después de unas horas.

Causa

El centro de IoT Edge, que forma parte del entorno de ejecución de IoT Edge, está optimizado para el rendimiento de forma 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. Puede establecer variables de entorno de una de estas dos maneras:

En el portal de Azure:

1. En la IoT Hub, seleccione el dispositivo IoT Edge. En la página de detalles del dispositivo, seleccione Establecer la configuración del entorno de ejecución de módulos>.

2. Cree una variable de entorno para el módulo central de IoT Edge denominado OptimizeForPerformance con el tipo True/False y establézcalo en False.

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

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

El demonio de seguridad no se puede iniciar

Síntomas

El daemon de seguridad no se puede iniciar y no se crean contenedores de módulos. El servicio IoT Edge no inicia edgeAgent, edgeHub u otros módulos personalizados. En los aziot-edged registros, verá este mensaje de error:

• El daemon no pudo iniciarse con éxito: 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 OS)

Causa

Para todas las distribuciones de Linux excepto CentOS 7, IoT Edge usa systemd activación de socket de forma predeterminada. Si cambia el archivo de configuración para deshabilitar la activación del socket, pero mantiene las direcciones URL como /var/run/iotedge/*.sock, obtendrá un error de permiso. El iotedge usuario no puede escribir en /var/run/iotedge, por lo que no puede desbloquear ni montar los sockets. CentOS ha llegado al final de su ciclo de vida (EOL). Para obtener más información, consulte la Guía de fin de ciclo de vida de CentOS.

Solución

No deshabilite la activación de sockets en una distribución que admita la activación del socket. Sin embargo, si no desea 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 el sistema no las inicie.
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 antiguos /var/run/iotedge/*.sock , así que ejecute docker rm -f para quitarlos.

La limpieza de la cola de mensajes es lenta

Síntomas

La cola de mensajes no se limpia después de procesar los mensajes. La cola de mensajes crece con el tiempo y, finalmente, hace que el tiempo de ejecución de IoT Edge se quede sin memoria.

Causa

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

Solución

Si cambia el valor de TTL de la aplicación a un valor más corto que el predeterminado, ajuste también el MessageCleanupIntervalSecs valor. El MessageCleanupIntervalSecs valor 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 MessageCleanupIntervalSecs valor 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 concentrador de IoT Edge. Para obtener más información sobre cómo establecer variables de entorno en tiempo de ejecución, consulte Edge Agent and Edge Hub Environment Variables.

IoT Edge Hub notifica el error System.FormatException al usar el protocolo AMQP

Síntomas

Al enrutar mensajes de un dispositivo IoT Edge a un IoT Hub mediante el protocolo AMQP y establece la propiedad iothub-creation-time-utc en mensajes de dispositivo salientes, el centro de IoT Edge 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

Este problema es un problema conocido en IoT Edge Hub para el protocolo AMQP. Actualmente, el equipo del producto está investigando una corrección. El protocolo MQTT no tiene este problema.

Redes

El daemon de seguridad de IoT Edge falla con un nombre de host no válido

Síntomas

Al intentar compruebe los registros del administrador de seguridad de IoT Edge genera un error e imprime el mensaje siguiente:

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

Causa

El entorno de ejecución de IoT Edge admite 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 Windows máquinas virtuales hospedadas en Azure, en particular, tienden a ser largos.

Solución

Cuando vea este error, resuélvalo configurando el nombre DNS de su máquina virtual y, a continuación, establezca el nombre DNS como el nombre de host en el comando de configuración.

1. En el portal de Azure, vaya a la página de información general de la máquina virtual.

2. Para abrir el panel de configuración, seleccione el vínculo No configurado (si la máquina virtual es nueva) o seleccione su nombre DNS existente bajo Essentials>Nombre DNS. Si la máquina virtual ya tiene configurado un nombre DNS, no es necesario configurar uno nuevo.

3. Escriba un valor para la etiqueta de nombre DNS si aún no tiene uno y seleccione Guardar.

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

5. En el dispositivo IoT Edge, abra el archivo de configuración.

   sudo nano /etc/aziot/config.toml
   

6. Reemplace el valor de hostname por su nombre DNS.

7. Guarde y cierre el archivo y, a continuación, aplique los cambios a IoT Edge.

   sudo iotedge config apply
   

IoT Edge módulo notifica errores de conectividad

Síntomas

Los módulos de IoT Edge que se conectan directamente a servicios en la nube, incluidos los módulos en tiempo de ejecución, dejan de funcionar como se espera y devuelven errores relacionados con fallas de conexión o de 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. Docker habilita el reenvío de paquetes IP de forma predeterminada, pero si lo deshabilita, los módulos que se conectan a los servicios en la nube no funcionan 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.

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.

El dispositivo 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 reporta Could not perform HTTP request en los registros.

Causa

Los dispositivos IoT Edge detrás de una puerta de enlace obtienen sus imágenes de módulo del dispositivo padre IoT Edge especificado en el campo parent_hostname del archivo de configuración. El Could not perform HTTP request error significa que el dispositivo descendente no puede conectar con su dispositivo principal a través de HTTP.

Solución

Asegúrese de que el dispositivo principal IoT Edge puede recibir solicitudes entrantes del dispositivo IoT Edge descendente. 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 conectarse al migrar de un hub de IoT a otro

Síntomas

Al migrar una jerarquía de dispositivos de IoT Edge de un IoT hub a otro, el dispositivo primario de nivel superior IoT Edge se conecta a IoT Hub, pero los dispositivos IoT Edge de bajada no pueden hacerlo. El informe de registros Unable to authenticate client downstream-device/$edgeAgent with module credentials.

Causa

La migración no actualizó correctamente las credenciales de los dispositivos de bajada. Debido a este problema, los edgeAgent módulos y edgeHub tienen un tipo de autenticación de none (el valor predeterminado si no lo 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 usa DPS), siga estos pasos en orden:

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

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

Síntomas

Dispositivos Azure IoT Edge que están geográficamente distantes de Azure IoT Hub tienen una menor capacidad de mensajería.

Causa

La latencia alta entre el dispositivo y la IoT Hub provoca un menor rendimiento de los mensajes. IoT Edge usa un tamaño de lote de mensaje predeterminado de 10. Este tamaño de lote 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 y IoT Hub.

Solución

Intente aumentar la variable de entorno MaxUpstreamBatchSize de IoT Edge Hub. Este cambio envía más mensajes en un solo lote, lo que reduce el número de recorridos de ida y vuelta entre el dispositivo y IoT Hub.

Para configurar las variables de entorno de Azure Edge Hub en el portal de Azure:

1. Vaya al IoT Hub y seleccione Dispositivos en el menú Administración de dispositivos.
2. Seleccione el dispositivo IoT Edge que desea actualizar.
3. Seleccione Set modules (Establecer módulos).
4. Seleccione Configuración del entorno de ejecución.
5. 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.
6. Seleccione Aplicar.

Pasos siguientes

¿Cree que encontró un error en la plataforma de IoT Edge? Submiter un problema para que el equipo del producto pueda seguir mejorando la plataforma.

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