Condividi tramite

Soluzioni ai problemi comuni per Azure IoT Edge

Si applica a:Icona di conferma IoT Edge 1.1

Importante

IoT Edge 1.1 data di fine del supporto è stata il 13 dicembre 2022. Controlla il ciclo di vita dei prodotti Microsoft per ottenere informazioni sul modo in cui viene supportato questo prodotto, servizio, tecnologia o API. Per altre informazioni sull'aggiornamento alla versione più recente di IoT Edge, vedere Aggiornare IoT Edge.

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 implementazione

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. Vedi che i moduli che hai definito iniziano sul 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.

Non è possibile ottenere i log di runtime di IoT Edge in Windows

Sintomi

Quando si utilizza Get-WinEvent su Windows, si verifica un'eccezione di tipo EventLogException.

Causa

Il comando PowerShell Get-WinEvent si basa sulla presenza di una voce del Registro di sistema per trovare i log da uno specifico ProviderName.

Soluzione

Impostare una voce di registro per il daemon IoT Edge. Creare un file iotedge.reg con il contenuto seguente e importarlo nel Registro di sistema di Windows facendo doppio clic su di esso o usando il 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

Errore del client DPS

Sintomi

IoT Edge non si avvia, mostrandosi il seguente messaggio di errore: failed to provision with IoT Hub, and no valid device backup was found dps client error.

Causa

Una registrazione di gruppo viene usata per effettuare il provisioning di un dispositivo IoT Edge in un hub IoT. Il dispositivo IoT Edge viene spostato in un hub diverso. La registrazione viene eliminata in DPS. Viene creata una nuova registrazione nel servizio DPS per il nuovo hub. Il dispositivo non è stato riconfigurato.

Soluzione

  1. Verificare che le credenziali DPS siano corrette.
  2. Applicare la configurazione usando sudo iotedge apply config.
  3. Se il dispositivo non viene ripreparato, riavviare il dispositivo usando sudo iotedge system restart.
  4. Se il dispositivo non è stato provisioning nuovamente, forzare il reprovisioning usando sudo iotedge system reprovision.

Per riprovvedere automaticamente, impostare dynamic_reprovisioning: true nel file di configurazione del dispositivo. L'impostazione di questo flag su true acconsente esplicitamente alla funzionalità di reprovisioning dinamico. IoT Edge rileva le situazioni in cui il dispositivo sembra essere stato sottoposto a reprovisioning nel cloud monitorando la propria connessione all'hub IoT per determinati errori. IoT Edge risponde arrestando tutti i moduli Edge e se stesso. Al successivo avvio del daemon, tenterà di effettuare nuovamente il provisioning del dispositivo con Azure per ricevere le nuove informazioni di provisioning dell'hub IoT.

Quando si usa il provisioning esterno, il daemon notificherà anche all'endpoint di provisioning esterno l'evento di reprovisioning prima dell'arresto. Per maggiori informazioni, vedere i Concetti di reprovisioning dei dispositivi nell'hub IoT.

Ambiente di esecuzione IoT Edge

L'agente Edge IoT si ferma dopo 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 esce.

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. Su Windows viene utilizzato 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 sovrascrive la 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 il edgeAgent è in esecuzione, ma segnala continuamente "file di configurazione vuoto...".

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.

Soluzione

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

Specificare il server DNS per l'ambiente nelle impostazioni del motore di contenitori, che verranno applicate a tutti i moduli contenitore avviati dal motore. Creare un file denominato daemon.json, quindi specificare il server DNS da usare. Per 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 posizione giusta per la piattaforma:

Piattaforma Posizione
Linux /etc/docker
Host Windows con contenitori di Windows C:\ProgramData\iotedge-moby\config

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.

Piattaforma Comando
Linux sudo systemctl restart docker
Windows (Admin PowerShell) Restart-Service iotedge-moby -Force

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. Per esempio:

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

Avvertimento

Se si usa questo metodo e si specifica l'indirizzo DNS errato, edgeAgent perde la connessione con l'hub IoT e non può ricevere nuove distribuzioni per risolvere il problema. Per risolvere questo problema, è possibile reinstallare il runtime di IoT Edge. Prima di installare una nuova istanza di IoT Edge, assicurarsi di rimuovere tutti i contenitori edgeAgent dall'installazione precedente.

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

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

Sintomi

Un contenitore non riesce a partire e i log di edgeAgent segnalano un errore 403.

Causa

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

Soluzione

Assicurati che le credenziali del registro contenitori siano corrette nel manifesto della distribuzione del tuo 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 Edge Hub eliminare tutti gli elementi dalla casella di testo Crea opzioni.

  6. 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": {
    "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. Rimuovere la riga createOptions e la virgola finale alla fine della riga image prima di essa:

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

  4. Salvare il file e applicarlo di nuovo 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, rifiuterà 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:

Nell'hub IoT, seleziona il tuo dispositivo IoT Edge dalla pagina dei dettagli del dispositivo e seleziona Imposta moduli>Impostazioni runtime. Creare una variabile di ambiente per il modulo hub IoT Edge denominato OptimizeForPerformance impostato su false.

Nel file di configurazione della distribuzione:

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

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.

Soluzione

Non è necessario disabilitare l'attivazione del socket in una distribuzione in cui è supportata l'attivazione del socket. Tuttavia, se si preferisce di non utilizzare affatto l'attivazione del socket, mettere 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 attacchi /var/run/iotedge/*.sock, quindi sostituiteli con docker rm -f.

Impossibile avviare il modulo a causa di mancata corrispondenza del sistema operativo

Sintomo

Il modulo edgeHub non si avvia in IoT Edge versione 1.1.

Causa

Il modulo windows usa una versione di Windows non compatibile con la versione di Windows nell'host. IoT Edge Windows versione 1809 build 17763 è necessaria come livello di base per l'immagine del modulo, ma è in uso una versione diversa.

Soluzione

Controlla la versione dei tuoi sistemi operativi Windows in per risolvere i problemi di incompatibilità tra l'immagine dell'host e quella del contenitore. Se i sistemi operativi sono diversi, aggiornarli a IoT Edge Windows versione 1809 build 17763 e ricompilare l'immagine Docker usata per tale modulo.

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. Selezionare e configurare sotto Nome DNS. Se la macchina virtuale dispone già di un nome DNS configurato, non è necessario configurarne uno nuovo.

    Configurare il nome DNS della macchina virtuale

  3. Specificare un valore per l'etichetta del nome DNS e selezionare Salva.

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

  5. All'interno della macchina virtuale, utilizzare il comando seguente per configurare il runtime IoT Edge con il nome DNS:

    • In Linux:

      sudo nano /etc/iotedge/config.yaml

    • In Windows:

      notepad C:\ProgramData\iotedge\config.yaml

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.

In Windows:

  1. Aprire l'applicazione Esegui.

  2. Immettere regedit nella casella di testo e selezionare Ok.

  3. Nella finestra Editor del Registro di sistema , passare a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.

  4. Cercare il parametro IPEnableRouter.

    1. Se il parametro esiste, impostare il valore del parametro su 1.

    2. Se il parametro non esiste, aggiungerlo come nuovo parametro con le impostazioni seguenti:

      Impostazione Valore
      Nome IPEnableRouter
      TIPO REG_DWORD
      Valore 1

  5. Chiudere la finestra dell'editor del Registro di sistema.

  6. Riavviare il sistema per applicare le modifiche.

In Linux:

  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 chiudi il file.

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

Passaggi successivi

Pensi di aver trovato un bug nella piattaforma IoT Edge? Inviare un problema in modo da poter migliorare l'esperienza.

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

  • Last updated on