Soluzioni ai problemi comuni per IoT Edge di Azure
Si applica 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 i log e gli errori dal dispositivo IoT Edge, vedere Risolvere i problemi relativi al 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 nell'portale di Azure. Altri moduli rispetto a quelli definiti potrebbero essere visualizzati anche nel dispositivo.
Causa
Se una distribuzione automatica è destinata a un dispositivo, la priorità viene impostata manualmente sui moduli per un singolo dispositivo. La funzionalità Set modules in portale di Azure o Create deployment for single device functionality in Visual Studio Code ha effetto per un momento. Vengono visualizzati i moduli definiti per avviare nel dispositivo. La priorità della distribuzione automatica inizia quindi e sovrascrive le proprietà desiderate del dispositivo.
Soluzione
Usa solo un tipo di meccanismo di distribuzione per dispositivo, una distribuzione automatica o singole distribuzioni di dispositivi. Se sono presenti più distribuzioni automatiche destinate a un dispositivo, è possibile modificare le descrizioni di priorità o di destinazione per assicurarsi che quella corretta si applica a un determinato dispositivo. È anche possibile aggiornare il dispositivo gemello per non corrispondere 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 IoT Edge in Windows
Sintomi
Si ottiene un evento EventLogException quando si usa Get-WinEvent
in Windows.
Causa
Il comando di PowerShell Get-WinEvent
si basa su una voce del Registro di sistema che deve essere presente per trovare i log da uno specifico ProviderName
.
Soluzione
Impostare una voce del Registro di sistema per il daemon di IoT Edge. Creare un file iotedge.reg con il contenuto seguente e importarlo nel Registro di sistema di Windows facendovi doppio clic 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 riesce a iniziare con il messaggio di errorefailed to provision with IoT Hub, and no valid device backup was found dps client error.
Causa
Una registrazione del 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 in DPS per il nuovo hub. Il dispositivo non viene riprovisionato.
Soluzione
- Verificare che le credenziali DPS siano corrette.
- Applicare la configurazione usando
sudo iotedge apply config
. - Se il dispositivo non viene riprovisionato, riavviare il dispositivo usando
sudo iotedge system restart
. - Se il dispositivo non viene riprovisionato, forzare il reprovisioning usando
sudo iotedge system reprovision
.
Per eseguire automaticamente il reprovisioning, impostare dynamic_reprovisioning: true
nel file di configurazione del dispositivo. L'impostazione di questo flag su true opta per la funzionalità di reprovisioning dinamica. IoT Edge rileva situazioni in cui il dispositivo sembra essere stato riprovisionato nel cloud monitorando la propria connessione hub IoT per determinati errori. IoT Edge risponde arrestando tutti i moduli Edge e se stesso. Al successivo avvio del daemon, tenterà di eseguire nuovamente il provisioning di questo dispositivo con Azure per ricevere le nuove informazioni di provisioning hub IoT.
Quando si usa il provisioning esterno, il daemon notificherà anche l'endpoint di provisioning esterno sull'evento di reprovisioning prima di arrestare. Per altre informazioni, vedere hub IoT concetti relativi al reprovisioning dei dispositivi.
Runtime IoT Edge
IoT Edge agente si arresta 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 IoT Edge tenta di connettersi a hub IoT tramite AMQP e quindi tenta di connettersi usando AMQP tramite 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 di 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
Assicurarsi che sia presente una route a Internet per gli indirizzi IP assegnati a questa rete 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 ha problemi di avvio dei moduli definiti nella distribuzione. Solo 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 di contenitori
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. Ad esempio:
{
"dns": ["1.1.1.1"]
}
Questo server DNS è impostato su un servizio DNS accessibile pubblicamente. Alcune reti, ad esempio reti aziendali, hanno i propri server DNS installati e non consentono l'accesso ai server DNS pubblici. Pertanto, se il dispositivo perimetrale non può accedere a un server DNS pubblico, sostituirlo con un indirizzo server DNS accessibile.
Posizionare daemon.json
nella posizione giusta per la piattaforma:
Piattaforma | Posizione |
---|---|
Linux | /etc/docker |
Host Windows con contenitori Windows | C:\ProgramData\iotedge-moby\config |
Se il percorso contiene daemon.json
già il file, aggiungere la chiave DNS e salvare il file.
Riavviare il motore del contenitore per gli aggiornamenti da attivare.
Piattaforma | Comando |
---|---|
Linux | sudo systemctl restart docker |
Windows (Amministrazione PowerShell) | Restart-Service iotedge-moby -Force |
Opzione 2: Impostare il server DNS in IoT Edge distribuzione per modulo
È possibile impostare il server DNS per la creazione di ogni moduloOptions nella distribuzione di IoT Edge. Ad esempio:
"createOptions": {
"HostConfig": {
"Dns": [
"x.x.x.x"
]
}
}
Avviso
Se si usa questo metodo e si specifica l'indirizzo DNS errato, edgeAgent perde la connessione con 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 essere eseguito e i log edgeAgent segnalano un errore 403.
Causa
Il modulo dell'agente IoT Edge non dispone delle autorizzazioni per accedere all'immagine di un modulo.
Soluzione
Assicurarsi che le credenziali del Registro contenitori siano corrette del manifesto della distribuzione del dispositivo.
L'hub di IoT Edge non si avvia
Sintomi
Il modulo edgeHub non viene avviato. È possibile che venga visualizzato un messaggio simile a uno degli errori seguenti nei log:
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)
Oppure
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
Alcuni altri processi nel computer host hanno associato una porta che il modulo edgeHub sta tentando di associare. L'hub IoT Edge esegue il mapping delle porte 443, 5671 e 8883 per l'uso negli scenari del 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 porta dalle opzioni di creazione del modulo di EdgeHub. È possibile modificare le opzioni di creazione nel portale di Azure o direttamente nel file deployment.json.
Nel portale di Azure:
Passare all'hub IoT e selezionare Dispositivi nel menu Gestione dispositivi .
Selezionare il dispositivo IoT Edge da aggiornare.
Selezionare Imposta moduli.
Selezionare Impostazioni runtime.
Nelle impostazioni del modulo hub edge eliminare tutto dalla casella di testo Crea opzioni .
Salvare le modifiche e creare la distribuzione.
Nel file deployment.json:
Aprire il file deployment.json applicato al dispositivo di IoT Edge.
Trovare le
edgeHub
impostazioni nella sezione proprietà desiderate 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" }
Rimuovere la
createOptions
riga e la virgola finale alla fine dellaimage
riga prima:"edgeHub": { "settings": { "image": "mcr.microsoft.com/azureiotedge-hub:1.1" }, "type": "docker", "status": "running", "restartPolicy": "always" }
Salvare il file e applicarlo nuovamente al dispositivo IoT Edge.
Il modulo IoT Edge non riesce a inviare un messaggio a edgeHub con errore 404
Sintomi
Un modulo di IoT Edge personalizzato non riesce a inviare un messaggio all'hub IoT Edge con un errore 404Module not found
. Il runtime di 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
Il runtime di IoT Edge applica l'identificazione dei processi per tutti i moduli che si connettono al edgeHub per motivi di sicurezza. Verifica che tutti i messaggi inviati da un modulo provengano dall'ID del processo principale del modulo. Se viene inviato un messaggio da un modulo da un ID di processo diverso rispetto a quello inizialmente stabilito, 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 alla 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 ENTRYPOINT
CMD
non usare il comando nel file Docker. Il CMD
comando 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 vincolati alle risorse, ad esempio Raspberry Pi, soprattutto se usati come gateway. I sintomi includono eccezioni di memoria insufficiente nel modulo hub IoT Edge, i dispositivi downstream non riescono a connettersi o il dispositivo non riesce a inviare messaggi di telemetria dopo qualche ora.
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 perimetrali vincolati 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:
Nella hub IoT selezionare il dispositivo IoT Edge e nella pagina dei dettagli del dispositivo e selezionare Impostaimpostazioni runtimemoduli>. Creare una variabile di ambiente per il modulo hub IoT Edge denominato OptimizeForPerformance impostato su false.
Nel manifesto 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 riesce a avviare e i contenitori di moduli non vengono creati. I edgeAgent
moduli personalizzati e , edgeHub
non vengono avviati dal servizio IoT Edge. Nei aziot-edged
log viene visualizzato questo errore:
- Impossibile avviare correttamente il daemon: Impossibile avviare il servizio di gestione
- causato da: si è verificato un errore per percorso /var/run/iotedge/mgmt.sock
- causato da: Autorizzazione negata (errore del sistema operativo 13)
Causa
Per tutte le distribuzioni Linux tranne CentOS 7, IoT Edge configurazione predefinita consiste nell'usare systemd
l'attivazione socket. Si verifica un errore di autorizzazione se si modifica il file di configurazione in modo da non usare l'attivazione del socket, ma lasciare gli URL come /var/run/iotedge/*.sock
, poiché l'utente iotedge
non può scrivere in /var/run/iotedge
modo che non possa 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 non usare l'attivazione del socket, inserire i socket in /var/lib/iotedge/
.
- Eseguire
systemctl disable iotedge.socket iotedge.mgmt.socket
per disabilitare le unità socket in modo che il sistema non li avvia inutilmente - Modificare la configurazione di iotedge da usare
/var/lib/iotedge/*.sock
in entrambeconnect
le sezioni elisten
- Se si hanno già moduli, hanno i
/var/run/iotedge/*.sock
vecchi montaggi, quindidocker rm -f
.
Impossibile avviare il modulo a causa della mancata corrispondenza del sistema operativo
Sintomo
Il modulo edgeHub non viene avviato in IoT Edge versione 1.1.
Causa
Il modulo Windows usa una versione di Windows incompatibile con la versione di Windows nell'host. IoT Edge build 1809 di Windows 17763 è necessario come livello di base per l'immagine del modulo, ma è in uso una versione diversa.
Soluzione
Controllare la versione dei vari sistemi operativi Windows in Risolvere i problemi di mancata corrispondenza dell'immagine host e 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 di gestione sicurezza IoT Edge ha esito negativo e stampa 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.
Nel portale di Azure passare alla pagina di panoramica della macchina virtuale.
Selezionare Configura sotto Nome DNS. Se la macchina virtuale dispone già di un nome DNS configurato, non è necessario configurarne uno nuovo.
Specificare un valore per Etichetta del nome DNS e selezionare Salva.
Copiare il nuovo nome DNS, che deve essere nel formato <DNSnamelabel>.< vmlocation.cloudapp.azure.com>.
All'interno della macchina virtuale, usare il comando seguente per configurare il runtime di 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
IoT Edge moduli 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 tra contenitori nella documentazione di Docker.
Soluzione
Usare la procedura seguente per abilitare l'inoltro di pacchetti IP.
In Windows:
Aprire l'applicazione Esegui .
Immettere
regedit
nella casella di testo e selezionare Ok.Nella finestra Editor del Registro di sistema passare a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.
Cercare il parametro IPEnableRouter .
Se il parametro esiste, impostare il valore del parametro su 1.
Se il parametro non esiste, aggiungerlo come nuovo parametro con le impostazioni seguenti:
Impostazione Valore Nome IPEnableRouter Tipo REG_DWORD Valore 1
Chiudere la finestra dell'editor del Registro di sistema.
Riavviare il sistema per applicare le modifiche.
In Linux:
Aprire il file sysctl.conf .
sudo nano /etc/sysctl.conf
Aggiungere al file la riga seguente.
net.ipv4.ip_forward=1
Salvare e chiudere il file.
Riavviare il servizio di rete e il servizio Docker per applicare le modifiche.
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.