Soluzioni ai problemi comuni per Azure IoT Edge

Si applica a: IoT Edge 1.5 IoT Edge 1.4

Usare questo articolo per identificare e risolvere i problemi comuni quando si usano soluzioni IoT Edge. Se sono necessarie informazioni su come trovare log ed errori dal dispositivo IoT Edge, vedere Risolvere i problemi del dispositivo IoT Edge.

Provisioning e distribuzione

Il modulo di IoT Edge esegue correttamente la distribuzione e quindi scompare dal dispositivo

Sintomi

Dopo aver impostato i moduli per un dispositivo IoT Edge, i moduli vengono distribuiti correttamente, ma dopo alcuni minuti scompaiono dal dispositivo e dai dettagli del dispositivo nel portale di Azure. Nel dispositivo potrebbero essere visualizzati anche moduli diversi da quelli definiti.

Causa

Se una distribuzione automatica è destinata a un dispositivo, assume la priorità rispetto all'impostazione manuale dei moduli per un singolo dispositivo. La funzionalità Imposta moduli nel portale di Azure o Crea distribuzione per un singolo dispositivo in Visual Studio Code diventa effettiva per un attimo. Vengono visualizzati i moduli definiti per l'avvio nel dispositivo. La priorità della distribuzione automatica inizia quindi e sovrascrive le proprietà desiderate del dispositivo.

Soluzione

Usare un solo tipo di meccanismo di distribuzione per dispositivo, ovvero una distribuzione automatica o singole distribuzioni di dispositivi. Se sono presenti più distribuzioni automatiche destinate a un dispositivo, è possibile modificare la priorità o le descrizioni di destinazione per assicurarsi che quello corretto si applichi a un determinato dispositivo. È inoltre possibile aggiornare il dispositivo gemello in modo che non corrisponda più alla descrizione di destinazione della distribuzione automatica.

Per altre informazioni, vedere Informazioni sulle distribuzioni automatiche di IoT Edge per singoli dispositivi o su vasta scala.

Runtime IoT Edge

L'agente IoT Edge si arresta dopo circa un minuto

Sintomi

Il modulo edgeAgent viene avviato ed eseguito correttamente per circa un minuto, quindi si arresta. I log indicano che l'agente Edge prova a connettersi all'hub IoT tramite AMQP e quindi tenta di connettersi tramite AMQP su WebSocket. In caso di errore, l'agente di IoT Edge viene chiuso.

Log edgeAgent di esempio:

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 configurazione di rete nella rete host impedisce all'agente IoT Edge di raggiungere la rete. L'agente prova prima a connettersi tramite AMQP (porta 5671). Se la connessione non riesce, prova WebSocket (porta 443).

Il runtime di IoT Edge configura una rete per ognuno dei moduli usati per la comunicazione. In Linux questa rete è una rete di bridge. In Windows si usa la rete NAT. Questo problema è più comune nei dispositivi Windows con contenitori Windows che usano la rete NAT.

Soluzione

Verificare che sia presente un instradamento a Internet per gli indirizzi IP assegnati a questa rete di bridge/NAT. Talvolta una configurazione VPN nell'host esegue l'override della rete di IoT Edge.

Il modulo dell'agente Edge segnala "file config vuoto" e non vengono avviati moduli nel dispositivo

Sintomi

• Il dispositivo presenta problemi durante l'avvio dei moduli definiti nella distribuzione. Solo edgeAgent è in esecuzione ma segnala file di configurazione vuoto....

• Quando si esegue sudo iotedge check su un dispositivo, segnala che il Motore contenitore non è configurato con l'impostazione del server DNS, che può influire sulla connettività all'hub IoT. Vedere https://aka.ms/iotedge-prod-checklist-dns per le procedure consigliate.

Causa

• Per impostazione predefinita, IoT Edge avvia i moduli nella propria rete contenitore isolata. Il dispositivo potrebbe avere problemi con la risoluzione dei nomi DNS all'interno di questa rete privata.
• Se si usa un'installazione snap di IoT Edge, il file di configurazione Docker è un percorso diverso. Vedere l'opzione 3 della soluzione.

Soluzione

Opzione 1: Impostare il server DNS nelle impostazioni del motore del contenitore

Specificare il server DNS per l'ambiente nelle impostazioni del motore del contenitore, che si applicano a tutti i moduli contenitore avviati dal motore. Creare un file denominato daemon.json, quindi specificare il server DNS da usare. Ad esempio:

{
    "dns": ["1.1.1.1"]
}

Questo server DNS è impostato su un servizio DNS accessibile pubblicamente. Tuttavia, alcune reti, ad esempio le reti aziendali, hanno i propri server DNS installati e non consentono l'accesso ai server DNS pubblici. Pertanto, se il dispositivo perimetrale non riesce ad accedere a un server DNS pubblico, sostituirlo con un indirizzo del server DNS accessibile.

Posizionare daemon.json nella directory /etc/docker sul dispositivo.

Se il percorso contiene già un file daemon.json, aggiungere la chiave dns e salvare il file.

Riavviare il motore del contenitore per rendere effettivi gli aggiornamenti.

sudo systemctl restart docker

Opzione 2: Impostare il server DNS nella distribuzione IoT Edge per modulo

È possibile impostare il server DNS per ogni modulo createOptions nella distribuzione di IoT Edge. Ad esempio:

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

Assicurarsi di impostare questa configurazione anche per i moduli edgeAgent e edgeHub.

Opzione 3: Passare il percorso del file di configurazione docker per controllare il comando

Se IoT Edge è installato come snap, utilizzare il parametro --container-engine-config-file per specificare il percorso del file di configurazione Docker. Ad esempio, se il file di configurazione Docker si trova in /var/snap/docker/current/config/daemon.json, eseguire il comando seguente: iotedge check --container-engine-config-file '/var/snap/docker/current/config/daemon.json'.

Attualmente, il messaggio di avviso continua a essere visualizzato nell'output del controllo iotedge anche dopo aver impostato il percorso del file di configurazione. Il controllo segnala l'errore perché lo snap IoT Edge non ha accesso in lettura allo snap Docker. Se si usa il controllo iotedge nel processo di rilascio, è possibile eliminare il messaggio di avviso usando il parametro --ignore container-engine-dns container-engine-logrotate.

Il modulo Agente Edge con connessione LTE segnala "configurazione dell'agente perimetrale vuota" e genera "errore di rete temporaneo"

Sintomi

Un dispositivo configurato con la connessione LTE presenta problemi di avvio dei moduli definiti nella distribuzione. edgeAgent non è in grado di connettersi all'hub IoT e segnala configurazione dell'agente perimetrale vuota e che si è verificato un errore di rete temporaneo.

Causa

Alcune reti hanno un sovraccarico di pacchetti, che rende la rete Docker predefinita MTU (1500) troppo elevata e causa la frammentazione dei pacchetti che impedisce l'accesso alle risorse esterne.

Soluzione

1. Controllare l'impostazione MTU per la rete Docker.

   docker network inspect <network name>

2. Controllare l'impostazione MTU per l'adattatore di rete fisica sul dispositivo.

   ip addr show eth0

Se viene visualizzata una dimensione MTU diversa per la rete Docker e il dispositivo, provare la soluzione alternativa seguente:

1. Creare una nuova rete. ad esempio:

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

   Nell'esempio l'impostazione MTU per il dispositivo è 1430. Di conseguenza, la MTU per la rete Docker è impostata su 1430.

2. Arrestare e rimuovere la rete di Azure.

   docker network rm azure-iot-edge

3. Ricreare la rete di Azure.

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

4. Rimuovere tutti i contenitori e riavviare il servizio 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

L'agente di IoT Edge non può accedere all'immagine di un modulo (403)

Sintomi

Un contenitore non viene eseguito e i log edgeAgent segnalano un errore 403.

Causa

Il modulo agente IoT Edge non dispone delle autorizzazioni per accedere all'immagine di un modulo.

Soluzione

Assicurarsi che le credenziali del registro contenitori siano corrette nel manifesto della distribuzione del dispositivo.

L'agente IoT Edge effettua chiamate di identità eccessive

Sintomi

L'agente IoT Edge effettua chiamate di identità eccessive all'hub IoT di Azure.

Causa

La configurazione errata del manifesto della distribuzione del dispositivo causa una distribuzione non riuscita sul dispositivo. La logica di ripetizione dei tentativi dell'agente IoT Edge continua a ripetere la distribuzione. Ogni tentativo effettua chiamate di identità fino a quando la distribuzione non riesce. Ad esempio, se il manifesto della distribuzione specifica un URI del modulo che non esiste nel registro contenitori o viene digitato in modo non corretto, l'agente IoT Edge ritenta la distribuzione fino a quando il manifesto della distribuzione non viene corretto.

Soluzione

Verificare il manifesto della distribuzione nel portale di Azure. Correggere eventuali errori e ridistribuire il manifesto nel dispositivo.

L'hub di IoT Edge non si avvia

Sintomi

L'avvio del modulo edgeHub non riesce. Nei log potrebbe essere visualizzato un messaggio simile a uno degli errori seguenti:

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

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

Un altro processo nel computer host ha associato una porta che il modulo edgeHub sta tentando di associare. L'hub di Edge esegue il mapping delle porte 443, 5671 e 8883 per l'uso negli scenari di gateway. Il modulo non viene avviato se un altro processo ha già associato una di queste porte.

Soluzione

È possibile risolvere questo problema in due modi:

Se il dispositivo IoT Edge funziona come dispositivo gateway, è necessario trovare e arrestare il processo che usa la porta 443, 5671 o 8883. Un errore per la porta 443 indica in genere che l'altro processo è un server Web.

Se non è necessario usare il dispositivo IoT Edge come gateway, è possibile rimuovere le associazioni di porte dalle opzioni di creazione del modulo edgeHub. È possibile modificare le opzioni di creazione nel portale di Azure o direttamente nel file di deployment.json.

Nel portale di Azure:

1. Passare all'hub IoT e selezionare Dispositivi nel menu Gestione dispositivi.

2. Selezionare il dispositivo IoT Edge da aggiornare.

3. Selezionare Set Modules (Configura i moduli).

4. Selezionare Impostazioni di runtime.

5. Nelle impostazioni del modulo Hub Edge eliminare tutti gli elementi dalla casella di testo Opzioni di creazione del contenitore.

6. Selezionare Applica per salvare le modifiche e creare la distribuzione.

Nel file deployment.json:

1. Aprire il file deployment.json applicato al dispositivo IoT Edge.

2. Trovare le impostazioni di edgeHub nella sezione delle proprietà desiderate di 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. Rimuovere la riga createOptions e la virgola finale alla fine della riga image prima di essa:

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

4. Selezionare Crea per la nuova applicazione al dispositivo IoT Edge.

Il modulo IoT Edge non riesce a inviare un messaggio a edgeHub con errore 404

Sintomi

Un modulo IoT Edge personalizzato non riesce a inviare un messaggio all'hub IoT Edge con un errore di Module not found 404. Il runtime IoT Edge stampa il messaggio seguente nei log:

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

Per motivi di sicurezza, il runtime IoT Edge impone l'identificazione del processo a tutti i moduli che si connettono a edgeHub. Verifica che tutti i messaggi inviati da un modulo provengano dall'ID del processo principale del modulo. Se un messaggio viene inviato da un modulo da un ID processo diverso da quello stabilito inizialmente, rifiuta il messaggio con un messaggio di errore 404.

Soluzione

A partire dalla versione 1.0.7, tutti i processi del modulo sono autorizzati a connettersi. Per altre informazioni, vedere il log delle modifiche della versione 1.0.7.

Se l'aggiornamento alla versione 1.0.7 non è possibile, completare la procedura seguente. Verificare che il modulo IoT Edge personalizzato usi sempre lo stesso ID di processo per inviare messaggi a edgeHub. Ad esempio, assicurarsi di utilizzare ENTRYPOINT anziché il comando CMD nel file Docker. Il comando CMD porta a un ID processo per il modulo e un altro ID processo per il comando bash che esegue il programma principale, ma ENTRYPOINT porta a un singolo ID processo.

Problemi di stabilità su dispositivi di dimensioni inferiori

Sintomi

È possibile che si verifichino problemi di stabilità nei dispositivi con limiti come Raspberry Pi, in particolare se usati come gateway. I sintomi includono eccezioni di memoria insufficiente nel modulo dell'hub IoT Edge, i dispositivi downstream che non riescono a connettersi o il dispositivo non riesce a inviare messaggi di telemetria dopo alcune ore.

Causa

L'hub IoT Edge, che fa parte del runtime di IoT Edge, è ottimizzato per le prestazioni per impostazione predefinita e tenta di allocare blocchi di memoria di grandi dimensioni. Questa ottimizzazione non è ideale per i dispositivi Edge con limiti e può causare problemi di stabilità.

Soluzione

Per l'hub IoT Edge, impostare una variabile di ambiente OptimizeForPerformance su false. Esistono due modi per impostare le variabili di ambiente:

Nel portale di Azure:

1. Nell'hub IoT selezionare il dispositivo IoT Edge e nella pagina dei dettagli del dispositivo e selezionare Imposta moduli>Impostazioni runtime.

2. Creare una variabile di ambiente per il modulo hub di IoT Edge denominato OptimizeForPerformance con tipoVero/Falso impostato su Falso.

3. Selezionare Applica per salvare le modifiche e quindi selezionare Rivedi e crea.

   La variabile di ambiente è ora nella proprietà edgeHub del manifesto della distribuzione:

      "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. Selezionare Crea per salvare le modifiche e distribuire il modulo.

Impossibile avviare correttamente il daemon di sicurezza

Sintomi

Il daemon di sicurezza non viene avviato e i contenitori di moduli non vengono creati. edgeAgent, edgeHub e altri moduli personalizzati non vengono avviati dal servizio IoT Edge. Nei log aziot-edged viene visualizzato questo errore:

• Impossibile avviare correttamente il daemon: Non è stato possibile avviare il servizio di gestione
• causata da: Si è verificato un errore per il percorso /var/run/iotedge/mgmt.sock
• causata da: Autorizzazione negata (errore del sistema operativo 13)

Causa

Per tutte le distribuzioni Linux ad eccezione di CentOS 7, la configurazione predefinita di IoT Edge consiste nell'usare l'attivazione socket systemd. Si verifica un errore di autorizzazione se si modifica il file di configurazione in modo da non usare l'attivazione socket, ma lasciare gli URL come /var/run/iotedge/*.sock, perché l'utente iotedge non può scrivere in /var/run/iotedge, il che significa che non è possibile sbloccare e montare i socket stessi. CentOS è End of Life (EOL). Per ulteriori informazioni, consultare la Guida alla fine del ciclo di vita di CentOS.

Soluzione

Non è necessario disabilitare l'attivazione del socket in una distribuzione in cui è supportata l'attivazione del socket. Tuttavia, se si preferisce non usare affatto l'attivazione del socket, inserire i socket in /var/lib/iotedge/.

1. Eseguire systemctl disable iotedge.socket iotedge.mgmt.socket per disabilitare le unità socket in modo che systemd non li avvii inutilmente
2. Modificare la configurazione di iotedge per usare /var/lib/iotedge/*.sock in entrambe le sezioni connect e listen
3. Se si dispone già di moduli, presentano i vecchi montaggi /var/run/iotedge/*.sock, quindi docker rm -f.

La pulizia della coda dei messaggi è lenta

Sintomi

La coda dei messaggi non viene pulita dopo l'elaborazione dei messaggi. La coda di messaggi aumenta nel tempo e alla fine causa la perdita di memoria del runtime IoT Edge.

Causa

L'intervallo di pulizia dei messaggi è controllato dal TTL del messaggio client (time to live) e dalla variabile di ambiente EdgeHub MessageCleanupIntervalSecs. Il valore TTL del messaggio predefinito è di due ore e il valore predefinito MessageCleanupIntervalSecs è pari a 30 minuti. Se l'applicazione usa un valore TTL più breve del valore predefinito e non si modifica il valore MessageCleanupIntervalSecs, i messaggi scaduti non verranno puliti fino al successivo intervallo di pulizia.

Soluzione

Se si modifica il valore TTL per l'applicazione più breve del valore predefinito, modificare anche il valore MessageCleanupIntervalSecs. Il valore MessageCleanupIntervalSecs deve essere notevolmente inferiore al valore TTL più piccolo usato dal client. Ad esempio, se l'applicazione client definisce un valore TTL di cinque minuti nell'intestazione del messaggio, impostare il valore MessageCleanupIntervalSecs su un minuto. Queste impostazioni assicurano che i messaggi vengano puliti entro sei (5 + 1) minuti.

Per configurare il valore MessageCleanupIntervalSecs, impostare la variabile di ambiente nel manifesto della distribuzione per il modulo hub di IoT Edge. Per altre informazioni sull'impostazione delle variabili di ambiente di runtime, vedere Variabili di ambiente Edge Agent e Edge Hub.

L'hub IoT Edge segnala System.FormatException usando il protocollo AMQP

Sintomi

Quando si instradano messaggi da un dispositivo IoT Edge a un hub IoT usando il protocollo AMQP e si imposta la iothub-creation-time-utc proprietà sui messaggi del dispositivo in uscita, l'hub IoT Edge segnala un System.FormatException errore. Il messaggio di errore è simile al seguente:

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

Causa

Il iot-hub-creation-time-utc valore non soddisfa i criteri di formato rigorosi. Il formato dell'hub edge richiede è un subset di ISO 8601.

Soluzione

Si tratta di un problema noto nell'hub IoT Edge per il protocollo AMQP. Attualmente, il problema è in corso di analisi per una correzione. Il protocollo MQTT non ha questo problema.

Rete

Se il nome host non è valido, l'esecuzione del daemon di sicurezza di IoT Edge ha esito negativo.

Sintomi

Il tentativo di controllare i log del gestore della sicurezza di IoT Edge ha esito negativo e visualizza il messaggio seguente:

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

Causa

Il runtime di IoT Edge può supportare solo nomi host contenenti meno di 64 caratteri. I computer fisici non hanno in genere nomi host lunghi, ma il problema è più comune in una macchina virtuale. I nomi host generati automaticamente per le macchine virtuali Windows ospitate in Azure, in particolare, tendono a essere lunghi.

Soluzione

Quando viene visualizzato questo errore, è possibile risolvere il problema configurando il nome DNS della macchina virtuale e quindi impostando il nome DNS come nome host nel comando di configurazione.

1. Nel portale di Azure passare alla pagina di panoramica della macchina virtuale.

2. Aprire il pannello di configurazione selezionando il collegamento Non configurato (se la macchina virtuale è nuova) o selezionare il nome DNS esistente in Nome DNS essentials>. Se la macchina virtuale dispone già di un nome DNS configurato, non è necessario configurarne uno nuovo.

3. Specificare un valore per l'etichetta del nome DNS se non ne è già disponibile uno e selezionare Salva.

4. Copiare il nuovo nome DNS, che deve essere nel formato :
   <DNSnamelabel>.<vmlocation>.cloudapp.azure.com.

5. Nel dispositivo IoT Edge aprire il file di configurazione.

   sudo nano /etc/aziot/config.toml
   

6. Sostituire il valore di hostname con il nome DNS.

7. Salvare e chiudere il file, quindi applicare le modifiche a IoT Edge.

   sudo iotedge config apply
   

Il modulo IoT Edge segnala errori di connettività

Sintomi

I moduli IoT Edge che si connettono direttamente ai servizi cloud, inclusi i moduli di runtime, smettono di funzionare come previsto e restituiscono errori di connessione o di rete.

Causa

I contenitori si basano sull'inoltro di pacchetti IP per connettersi a Internet in modo che possano comunicare con i servizi cloud. L'inoltro di pacchetti IP è abilitato per impostazione predefinita in Docker, ma se viene disabilitato, tutti i moduli che si connettono ai servizi cloud non funzioneranno come previsto. Per altre informazioni, vedere Informazioni sulla comunicazione dei contenitori nella documentazione di Docker.

Soluzione

Usare la procedura seguente per abilitare l'inoltro di pacchetti IP.

1. Aprire il file sysctl.conf.

   sudo nano /etc/sysctl.conf
   

2. Aggiungere al file la riga seguente.

   net.ipv4.ip_forward=1
   

3. Salva e chiude il file .

4. Riavviare il servizio di rete e il servizio Docker per applicare le modifiche.

IoT Edge dietro un gateway non può eseguire richieste HTTP e avviare il modulo edgeAgent

Sintomi

Il runtime IoT Edge è attivo con un file di configurazione valido, ma non può avviare il modulo edgeAgent. Il comando iotedge list restituisce un elenco vuoto. I report del runtime IoT Edge Could not perform HTTP request nei log.

Causa

I dispositivi IoT Edge dietro un gateway ottengono le immagini del modulo dal dispositivo IoT Edge padre specificato nel campo parent_hostname del file di configurazione. L'errore Could not perform HTTP request indica che il dispositivo downstream non è in grado di raggiungere il dispositivo padre tramite HTTP.

Soluzione

Assicurarsi che il dispositivo padre IoT Edge possa ricevere richieste in ingresso dal dispositivo downstream IoT Edge. Aprire il traffico di rete sulle porte 443 e 6617 per le richieste provenienti dal dispositivo downstream.

IoT Edge dietro un gateway non può eseguire richieste HTTP e avviare il modulo edgeAgent

Sintomi

Il runtime o il daemon IoT Edge è attivo con un file di configurazione valido, ma non può avviare il modulo edgeAgent. Il comando iotedge list restituisce un elenco vuoto. Il report dei log Could not perform HTTP request del daemon IoT Edge.

Causa

I dispositivi IoT Edge dietro un gateway ottengono le immagini del modulo dal dispositivo IoT Edge padre specificato nel campo parent_hostname del file di configurazione. L'errore Could not perform HTTP request indica che il dispositivo downstream non è in grado di raggiungere il dispositivo padre tramite HTTP.

Soluzione

Assicurarsi che il dispositivo padre IoT Edge possa ricevere richieste in ingresso dal dispositivo downstream IoT Edge. Aprire il traffico di rete sulle porte 443 e 6617 per le richieste provenienti dal dispositivo downstream.

IoT Edge dietro un gateway non può connettersi durante la migrazione da un hub IoT a un altro

Sintomi

Quando si tenta di eseguire la migrazione di una gerarchia di dispositivi IoT Edge da un hub IoT a un altro, il dispositivo IoT Edge padre di primo livello può connettersi all'hub IoT, ma i dispositivi IoT Edge downstream non possono farlo. Report dei log Unable to authenticate client downstream-device/$edgeAgent with module credentials.

Causa

Le credenziali per i dispositivi downstream non sono state aggiornate correttamente quando si è verificata la migrazione al nuovo hub IoT. Per questo motivo, i moduli edgeAgent e edgeHub sono stati impostati in modo che abbiano il tipo di autenticazione none (impostazione predefinita se non impostata in modo esplicito). Durante la connessione, i moduli sui dispositivi downstream usano credenziali precedenti, causando l'esito negativo dell'autenticazione.

Soluzione

Quando si esegue la migrazione al nuovo hub IoT (presupponendo che non usi DPS), seguire questa procedura nell'ordine seguente:

1. Seguire questa guida per esportare e quindi importare le identità dei dispositivi dall'hub IoT precedente a quello nuovo
2. Riconfigurare tutte le distribuzioni e le configurazioni di IoT Edge nel nuovo hub IoT
3. Riconfigurare tutte le relazioni tra dispositivi padre-figlio nel nuovo hub IoT
4. Aggiornare ogni dispositivo in modo che punti al nuovo nome host dell'hub IoT (iothub_hostname sotto [provisioning] in config.toml)
5. Se si sceglie di escludere le chiavi di autenticazione durante l'esportazione del dispositivo, riconfigurare ogni dispositivo con le nuove chiavi fornite dal nuovo hub IoT (device_id_pk sotto [provisioning.authentication] in config.toml)
6. Riavviare prima il dispositivo Edge padre di primo livello, assicurarsi che sia operativo
7. Riavviare ogni dispositivo a livello di gerarchia per livello dall'alto verso il basso

IoT Edge ha una velocità effettiva dei messaggi ridotta quando è geograficamente distante dall'hub IoT

Sintomi

I dispositivi Azure IoT Edge geograficamente distanti dall'hub IoT di Azure hanno una velocità effettiva dei messaggi inferiore al previsto.

Causa

Una latenza elevata tra il dispositivo e l'hub IoT può causare una velocità effettiva dei messaggi inferiore al previsto. IoT Edge usa una dimensione predefinita del batch di messaggi pari a 10. Questo limita il numero di messaggi inviati in un singolo batch, il che aumenta il numero di round trip tra il dispositivo e l'hub IoT.

Soluzione

Provare ad aumentare l'hub IoT Edge variabile di ambiente MaxUpstreamBatchSize. In questo modo è possibile inviare più messaggi in un singolo batch, riducendo così il numero di round trip tra il dispositivo e l'hub IoT.

Per impostare le variabili di ambiente dell'hub Edge di Azure nel portale di Azure:

1. Passare all'hub IoT e selezionare Dispositivi nel menu Gestione dei dispositivi.
2. Selezionare il dispositivo IoT Edge da aggiornare.
3. Selezionare Set Modules (Configura i moduli).
4. Selezionare Impostazioni di runtime.
5. Nella scheda impostazioni del modulo Hub Edge aggiungere la variabile di ambiente MaxUpstreamBatchSize come tipo Numero con un valore pari a 20.
6. Selezionare Applica.

Passaggi successivi

Se si ritiene di aver rilevato un bug nella piattaforma di IoT Edge, Inviare un problema in modo da poter migliorare l'esperienza.

In caso di altre domande, creare una Richiesta di supporto per assistenza.