Oplossingen voor veelvoorkomende problemen voor Azure IoT Edge

Let op

In dit artikel wordt verwezen naar CentOS, een Linux-distributie die de status End Of Life (EOL) nadert. Overweeg uw gebruik en planning dienovereenkomstig. Zie de Richtlijnen voor het einde van de levensduur van CentOS voor meer informatie.

Van toepassing op: IoT Edge 1.5 IoT Edge 1.4

Belangrijk

IoT Edge 1.5 LTS en IoT Edge 1.4 LTS worden ondersteund releases. IoT Edge 1.4 LTS eindigt op 12 november 2024. Raadpleeg IoT Edge bijwerken als u een eerdere versie hebt.

Gebruik dit artikel om veelvoorkomende problemen te identificeren en op te lossen bij het gebruik van IoT Edge-oplossingen. Als u informatie nodig hebt over het vinden van logboeken en fouten van uw IoT Edge-apparaat, raadpleegt u Problemen met uw IoT Edge-apparaat oplossen.

Inrichten en implementeren

De IoT Edge-module wordt geïmplementeerd, maar verdwijnt vervolgens van het apparaat

Symptomen

Nadat u modules voor een IoT Edge-apparaat hebt ingesteld, worden de modules geïmplementeerd, maar na een paar minuten verdwijnen ze van het apparaat en van de apparaatdetails in Azure Portal. Andere modules dan de modules die zijn gedefinieerd, kunnen ook op het apparaat worden weergegeven.

Oorzaak

Als een automatische implementatie is gericht op een apparaat, heeft deze prioriteit boven het handmatig instellen van de modules voor één apparaat. De functionaliteit Modules instellen in Azure Portal of Implementatie maken voor functionaliteit voor één apparaat in Visual Studio Code wordt even van kracht. U ziet de modules die u hebt gedefinieerd, beginnen op het apparaat. Vervolgens wordt de prioriteit van de automatische implementatie gestart en worden de gewenste eigenschappen van het apparaat overschreven.

Oplossing

Gebruik slechts één type implementatiemechanisme per apparaat, ofwel een automatische implementatie of afzonderlijke apparaatimplementaties. Als u meerdere automatische implementaties hebt die zijn gericht op een apparaat, kunt u prioriteit of doelbeschrijvingen wijzigen om ervoor te zorgen dat de juiste implementatie van toepassing is op een bepaald apparaat. U kunt de apparaatdubbel ook bijwerken zodat deze niet meer overeenkomt met de doelbeschrijving van de automatische implementatie.

Zie Automatische implementaties van IoT Edge voor afzonderlijke apparaten of op schaal begrijpen voor meer informatie.

IoT Edge-runtime

IoT Edge-agent stopt na een minuut

Symptomen

De edgeAgent-module wordt ongeveer een minuut gestart en uitgevoerd en stopt vervolgens. De logboeken geven aan dat de IoT Edge-agent probeert verbinding te maken met IoT Hub via AMQP en vervolgens probeert verbinding te maken via AMQP via WebSocket. Als dat mislukt, wordt de IoT Edge-agent afgesloten.

Voorbeeld van edgeAgent-logboeken:

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

Oorzaak

Een netwerkconfiguratie op het hostnetwerk voorkomt dat de IoT Edge-agent het netwerk bereikt. De agent probeert eerst verbinding maken via AMQP (poort 5671). Als de verbinding mislukt, wordt WebSockets (poort 443) geprobeerd.

De IoT Edge-runtime stelt een netwerk in voor elk van de modules waarmee moet worden gecommuniceerd. In Linux is dit netwerk een brugnetwerk. In Windows wordt NAT gebruikt. Dit probleem komt vaker voor op Windows-apparaten die gebruikmaken van Windows-containers die het NAT-netwerk gebruiken.

Oplossing

Zorg ervoor dat er een route naar internet is voor de IP-adressen die zijn toegewezen aan dit brug-/NAT-netwerk. Soms heeft een VPN-configuratie op de host voorrang op het IoT Edge-netwerk.

Edge-agentmodule rapporteert 'leeg configuratiebestand' en er worden geen modules gestart op het apparaat

Symptomen

• Het apparaat ondervindt problemen bij het starten van modules die zijn gedefinieerd in de implementatie. Alleen de edgeAgent wordt uitgevoerd, maar rapporteert een leeg configuratiebestand....

• Wanneer u op een apparaat uitvoert sudo iotedge check , wordt gerapporteerd dat de containerengine niet is geconfigureerd met de DNS-serverinstelling, wat van invloed kan zijn op de connectiviteit met IoT Hub. https://aka.ms/iotedge-prod-checklist-dns Zie de aanbevolen procedures.

Oorzaak

• Standaard start IoT Edge modules in hun eigen geïsoleerde containernetwerk. Het apparaat ondervindt mogelijk problemen met DNS-naamomzetting binnen dit privénetwerk.
• Als u een module-installatie van IoT Edge gebruikt, is het Docker-configuratiebestand een andere locatie. Zie oplossingsoptie 3.

Oplossing

Optie 1: DNS-server instellen in instellingen voor container-engine

Geef de DNS-server voor uw omgeving op in de instellingen van de containerengine, die van toepassing zijn op alle containermodules die door de engine zijn gestart. Maak een bestand met de naam daemon.jsonen geef vervolgens de DNS-server op die moet worden gebruikt. Voorbeeld:

{
    "dns": ["1.1.1.1"]
}

Deze DNS-server is ingesteld op een openbaar toegankelijke DNS-service. Sommige netwerken, zoals bedrijfsnetwerken, hebben echter hun eigen DNS-servers geïnstalleerd en staan geen toegang tot openbare DNS-servers toe. Als uw edge-apparaat geen toegang heeft tot een openbare DNS-server, vervangt u dit door een toegankelijk DNS-serveradres.

Plaats daemon.json deze in de /etc/docker map op uw apparaat.

Als de locatie al een daemon.json bestand bevat, voegt u de DNS-sleutel eraan toe en slaat u het bestand op.

Start de containerengine opnieuw op om de updates van kracht te laten worden.

sudo systemctl restart docker

Optie 2: DNS-server instellen in IoT Edge-implementatie per module

U kunt dns-server instellen voor de createOptions van elke module in de IoT Edge-implementatie. Voorbeeld:

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

Waarschuwing

Als u deze methode gebruikt en het verkeerde DNS-adres opgeeft, verliest edgeAgent de verbinding met IoT Hub en kan geen nieuwe implementaties ontvangen om het probleem op te lossen. U kunt dit probleem oplossen door de IoT Edge-runtime opnieuw te installeren. Voordat u een nieuw exemplaar van IoT Edge installeert, moet u alle EdgeAgent-containers uit de vorige installatie verwijderen.

Zorg ervoor dat u deze configuratie ook instelt voor de edgeAgent - en EdgeHub-modules .

Optie 3: Geef de locatie van het docker-configuratiebestand door om de opdracht te controleren

Als IoT Edge is geïnstalleerd als een module, gebruikt u de --container-engine-config-file parameter om de locatie van het Docker-configuratiebestand op te geven. Als het Docker-configuratiebestand zich bijvoorbeeld bevindt/var/snap/docker/current/config/daemon.json, voert u de volgende opdracht uit: iotedge check --container-engine-config-file '/var/snap/docker/current/config/daemon.json'

Op dit moment wordt het waarschuwingsbericht weergegeven in de uitvoer van iotedge-controle, zelfs nadat u de locatie van het configuratiebestand hebt ingesteld. Controleer de fout omdat de IoT Edge-module geen leestoegang heeft tot de Docker-module. Als u iotedge gebruikt om uw releaseproces in te checken , kunt u het waarschuwingsbericht onderdrukken met behulp van de --ignore container-engine-dns container-engine-logrotate parameter.

Edge Agent-module met LTE-verbindingsrapporten 'lege configuratie van edge-agent' en veroorzaakt 'tijdelijke netwerkfout'

Symptomen

Een apparaat dat is geconfigureerd met LTE-verbinding heeft problemen bij het starten van modules die zijn gedefinieerd in de implementatie. EdgeAgent kan geen verbinding maken met de IoT Hub en rapporteert dat er een lege edge-agentconfiguratie en tijdelijke netwerkfout is opgetreden.

Oorzaak

Sommige netwerken hebben pakketoverhead, waardoor de standaard Docker Network MTU (1500) te hoog is en pakketfragmentatie de toegang tot externe resources verhindert.

Oplossing

1. Controleer de MTU-instelling voor uw Docker-netwerk.

   docker network inspect <network name>

2. Controleer de MTU-instelling voor de fysieke netwerkadapter op uw apparaat.

   ip addr show eth0

Notitie

De MTU voor het Docker-netwerk mag niet hoger zijn dan de MTU voor uw apparaat. Neem contact op met uw internetprovider voor meer informatie.

Als u een andere MTU-grootte ziet voor uw Docker-netwerk en het apparaat, kunt u de volgende tijdelijke oplossing proberen:

1. Maak een nieuw netwerk. Voorbeeld:

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

   In het voorbeeld is de MTU-instelling voor het apparaat 1430. Daarom is de MTU voor het Docker-netwerk ingesteld op 1430.

2. Stop en verwijder het Azure-netwerk.

   docker network rm azure-iot-edge

3. Maak het Azure-netwerk opnieuw.

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

4. Verwijder alle containers en start de aziot-edged-service opnieuw op.

   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

De IoT Edge-agent heeft geen toegang tot de installatiekopie van een module (403)

Symptomen

Een container kan niet worden uitgevoerd en in de edgeAgent-logboeken wordt een 403-fout gerapporteerd.

Oorzaak

De IoT Edge-agentmodule heeft geen machtigingen voor toegang tot de installatiekopieën van een module.

Oplossing

Zorg ervoor dat uw containerregisterreferenties juist zijn voor het implementatiemanifest van uw apparaat.

IoT Edge-agent maakt overmatige identiteitsoproepen

Symptomen

IoT Edge-agent maakt overmatige identiteitsoproepen naar Azure IoT Hub.

Oorzaak

Onjuiste configuratie van apparaatimplementatie veroorzaakt een mislukte implementatie op het apparaat. De logica voor opnieuw proberen van IoT Edge-agent blijft de implementatie opnieuw proberen. Elke nieuwe poging doet identiteitsoproepen totdat de implementatie is geslaagd. Als het implementatiemanifest bijvoorbeeld een module-URI opgeeft die niet in het containerregister bestaat of onjuist is getypt, probeert de IoT Edge-agent de implementatie opnieuw totdat het implementatiemanifest is gecorrigeerd.

Oplossing

Controleer het implementatiemanifest in Azure Portal. Corrigeer eventuele fouten en implementeer het manifest opnieuw op het apparaat.

IoT Edge-hub kan niet worden gestart

Symptomen

De EdgeHub-module kan niet worden gestart. Mogelijk ziet u een bericht zoals een van de volgende fouten in de logboeken:

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)

Oorzaak

Een ander proces op de hostcomputer heeft een poort gebonden die de edgeHub-module probeert te binden. De IoT Edge-hub wijst poorten 443, 5671 en 8883 toe voor gebruik in gatewayscenario's. De module kan niet worden gestart als er al een ander proces aan een van deze poorten is gebonden.

Oplossing

U kunt dit probleem op twee manieren oplossen:

Als het IoT Edge-apparaat werkt als een gatewayapparaat, moet u het proces zoeken en stoppen dat gebruikmaakt van poort 443, 5671 of 8883. Een fout voor poort 443 betekent meestal dat het andere proces een webserver is.

Als u het IoT Edge-apparaat niet als gateway hoeft te gebruiken, kunt u de poortbindingen verwijderen uit de opties voor het maken van edgeHub-modules. U kunt de opties voor maken wijzigen in Azure Portal of rechtstreeks in het deployment.json-bestand.

In Azure Portal:

1. Navigeer naar uw IoT-hub en selecteer Apparaten in het menu Apparaatbeheer.

2. Selecteer het IoT Edge-apparaat dat u wilt bijwerken.

3. Selecteer Modules instellen.

4. Selecteer Runtime-Instellingen.

5. Verwijder alles uit het tekstvak Opties voor container maken in de Edge Hub-module-instellingen.

6. Selecteer Toepassen om uw wijzigingen op te slaan en de implementatie te maken.

In het bestand deployment.json:

1. Open het deployment.json-bestand dat u hebt toegepast op uw IoT Edge-apparaat.

2. Zoek de edgeHub instellingen in de sectie gewenste eigenschappen van 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. Verwijder de createOptions lijn en de volgkomma aan het einde van de image regel ervoor:

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

4. Selecteer Maken om het opnieuw toe te passen op uw IoT Edge-apparaat.

IoT Edge-module kan geen bericht verzenden naar edgeHub met 404-fout

Symptomen

Een aangepaste IoT Edge-module kan geen bericht verzenden naar de IoT Edge-hub met een 404-fout Module not found . De IoT Edge-runtime drukt het volgende bericht af in de logboeken:

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 )

Oorzaak

De IoT Edge-runtime dwingt procesidentificatie af voor alle modules die verbinding maken met edgeHub om veiligheidsredenen. Hiermee wordt gecontroleerd of alle berichten die door een module worden verzonden afkomstig zijn van de hoofdproces-id van de module. Als een bericht wordt verzonden door een module van een andere proces-id dan in eerste instantie tot stand is gebracht, wordt het bericht geweigerd met een 404-foutbericht.

Oplossing

Vanaf versie 1.0.7 zijn alle moduleprocessen gemachtigd om verbinding te maken. Zie het wijzigingenlogboek voor de release 1.0.7 voor meer informatie.

Als een upgrade naar 1.0.7 niet mogelijk is, voert u de volgende stappen uit. Zorg ervoor dat dezelfde proces-id altijd wordt gebruikt door de aangepaste IoT Edge-module om berichten naar edgeHub te verzenden. Zorg er bijvoorbeeld voor dat ENTRYPOINT u in plaats van CMD de opdracht in uw Docker-bestand. De CMD opdracht leidt naar één proces-id voor de module en een andere proces-id voor de bash-opdracht waarop het hoofdprogramma wordt uitgevoerd, maar ENTRYPOINT leidt tot één proces-id.

Stabiliteitsproblemen op kleinere apparaten

Symptomen

U kunt stabiliteitsproblemen ondervinden op apparaten met beperkte resources, zoals de Raspberry Pi, met name wanneer u als gateway wordt gebruikt. Symptomen zijn uitzonderingen met onvoldoende geheugen in de IoT Edge-hubmodule, downstreamapparaten die geen verbinding kunnen maken of het apparaat kan na enkele uren geen telemetrieberichten verzenden.

Oorzaak

De IoT Edge-hub, die deel uitmaakt van de IoT Edge-runtime, is standaard geoptimaliseerd voor prestaties en probeert grote segmenten geheugen toe te wijzen. Deze optimalisatie is niet ideaal voor beperkte edge-apparaten en kan stabiliteitsproblemen veroorzaken.

Oplossing

Stel voor de IoT Edge-hub een omgevingsvariabele OptimizeForPerformance in op false. Er zijn twee manieren om omgevingsvariabelen in te stellen:

In Azure Portal:

1. Selecteer in uw IoT Hub uw IoT Edge-apparaat en selecteer op de pagina met apparaatdetails en Set Modules>Runtime Instellingen.

2. Maak een omgevingsvariabele voor de IoT Edge-hubmodule met de naam OptimizeForPerformance met het type True/False die is ingesteld op False.

3. Selecteer Toepassen om wijzigingen op te slaan en selecteer Vervolgens Beoordelen en maken.

   De omgevingsvariabele bevindt zich nu in de edgeHub eigenschap van het implementatiemanifest:

      "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. Selecteer Maken om uw wijzigingen op te slaan en de module te implementeren.

Beveiligingsdaemon kan niet worden gestart

Symptomen

De beveiligingsdemon kan niet worden gestart en modulecontainers worden niet gemaakt. De edgeAgenten edgeHub andere aangepaste modules worden niet gestart door de IoT Edge-service. In aziot-edged logboeken ziet u deze fout:

• De daemon kan niet worden opgestart: kan de beheerservice niet starten
• veroorzaakt door: Er is een fout opgetreden voor pad /var/run/iotedge/mgmt.sock
• veroorzaakt door: Machtiging geweigerd (besturingssysteemfout 13)

Oorzaak

Voor alle Linux-distributies behalve CentOS 7 is de standaardconfiguratie van IoT Edge het gebruik van systemd socketactivering. Er treedt een machtigingsfout op als u het configuratiebestand wijzigt om geen socketactivering te gebruiken, maar de URL's /var/run/iotedge/*.sockongewijzigd laat, omdat de gebruiker niet kan schrijven naar /var/run/iotedge de betekenis dat het iotedge de sockets zelf niet kan ontgrendelen en koppelen.

Oplossing

U hoeft socketactivering niet uit te schakelen voor een distributie waarbij socketactivering wordt ondersteund. Als u echter liever helemaal geen socketactivering gebruikt, plaatst u de sockets in /var/lib/iotedge/.

1. Uitvoeren systemctl disable iotedge.socket iotedge.mgmt.socket om de socketeenheden uit te schakelen, zodat de systeemeenheden niet onnodig worden gestart
2. De iotedge-configuratie wijzigen voor gebruik /var/lib/iotedge/*.sock in zowel connectlisten secties als in beide secties
3. Als u al modules hebt, hebben ze de oude /var/run/iotedge/*.sock koppels, dus docker rm -f ze.

Netwerken

IoT Edge-beveiligingsdaemon mislukt met een ongeldige hostnaam

Symptomen

Het controleren van de IoT Edge-beveiligingsbeheerlogboeken mislukt en het volgende bericht wordt afgedrukt:

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

Oorzaak

De IoT Edge-runtime kan alleen hostnamen ondersteunen die korter zijn dan 64 tekens. Fysieke machines hebben meestal geen lange hostnamen, maar het probleem komt vaker voor op een virtuele machine. De automatisch gegenereerde hostnamen voor virtuele Windows-machines die worden gehost in Azure, zijn meestal lang.

Oplossing

Wanneer u deze fout ziet, kunt u deze oplossen door de DNS-naam van uw virtuele machine te configureren en vervolgens de DNS-naam in te stellen als de hostnaam in de installatieopdracht.

1. Navigeer in Azure Portal naar de overzichtspagina van uw virtuele machine.

2. Open het configuratievenster door Niet geconfigureerd te selecteren (als uw virtuele machine nieuw is) onder DNS-naam of selecteer uw bestaande DNS-naam. Als op uw virtuele machine al een DNS-naam is geconfigureerd, hoeft u geen nieuwe te configureren.

   

3. Geef een waarde op voor het DNS-naamlabel als u er nog geen hebt en selecteer Opslaan.

4. Kopieer de nieuwe DNS-naam, die de indeling moet hebben:
   <DNSnamelabel>.<vmlocation.cloudapp.azure.com>.

5. Open het configuratiebestand op het IoT Edge-apparaat.

   sudo nano /etc/aziot/config.toml
   

6. Vervang de waarde door hostname uw DNS-naam.

7. Sla het bestand op en sluit het en pas de wijzigingen vervolgens toe op IoT Edge.

   sudo iotedge config apply
   

IoT Edge-module rapporteert connectiviteitsfouten

Symptomen

IoT Edge-modules die rechtstreeks verbinding maken met cloudservices, inclusief de runtimemodules, werken niet meer zoals verwacht en retourneren fouten rond verbindings- of netwerkfouten.

Oorzaak

Containers zijn afhankelijk van het doorsturen van IP-pakketten om verbinding te maken met internet, zodat ze kunnen communiceren met cloudservices. Doorsturen van IP-pakketten is standaard ingeschakeld in Docker, maar als het wordt uitgeschakeld, werken modules die verbinding maken met cloudservices niet zoals verwacht. Zie Informatie over containercommunicatie in de Docker-documentatie voor meer informatie.

Oplossing

Gebruik de volgende stappen om doorsturen van IP-pakketten in te schakelen.

1. Open het bestand sysctl.conf .

   sudo nano /etc/sysctl.conf
   

2. Voeg de volgende regel aan het bestand toe.

   net.ipv4.ip_forward=1
   

3. Sla het bestand op en sluit het bestand.

4. Start de netwerkservice en docker-service opnieuw op om de wijzigingen toe te passen.

IoT Edge achter een gateway kan geen HTTP-aanvragen uitvoeren en kan de edgeAgent-module niet starten

Symptomen

De IoT Edge-runtime is actief met een geldig configuratiebestand, maar kan de edgeAgent-module niet starten. De opdracht iotedge list retourneert een lege lijst. De IoT Edge-runtimerapporten Could not perform HTTP request in de logboeken.

Oorzaak

IoT Edge-apparaten achter een gateway krijgen hun module-installatiekopieën van het bovenliggende IoT Edge-apparaat dat is opgegeven in het parent_hostname veld van het configuratiebestand. De Could not perform HTTP request fout betekent dat het downstreamapparaat het bovenliggende apparaat niet kan bereiken via HTTP.

Oplossing

Zorg ervoor dat het bovenliggende IoT Edge-apparaat binnenkomende aanvragen kan ontvangen van het downstream IoT Edge-apparaat. Open netwerkverkeer op poorten 443 en 6617 voor aanvragen die afkomstig zijn van het downstreamapparaat.

IoT Edge achter een gateway kan geen HTTP-aanvragen uitvoeren en kan de edgeAgent-module niet starten

Symptomen

De IoT Edge-daemon is actief met een geldig configuratiebestand, maar kan de edgeAgent-module niet starten. De opdracht iotedge list retourneert een lege lijst. Het rapport Could not perform HTTP requestioT Edge-daemonlogboeken.

Oorzaak

IoT Edge-apparaten achter een gateway krijgen hun module-installatiekopieën van het bovenliggende IoT Edge-apparaat dat is opgegeven in het parent_hostname veld van het configuratiebestand. De Could not perform HTTP request fout betekent dat het downstreamapparaat het bovenliggende apparaat niet kan bereiken via HTTP.

Oplossing

Zorg ervoor dat het bovenliggende IoT Edge-apparaat binnenkomende aanvragen kan ontvangen van het downstream IoT Edge-apparaat. Open netwerkverkeer op poorten 443 en 6617 voor aanvragen die afkomstig zijn van het downstreamapparaat.

IoT Edge achter een gateway kan geen verbinding maken bij het migreren van de ene IoT-hub naar een andere

Symptomen

Wanneer u probeert een hiërarchie van IoT Edge-apparaten te migreren van de ene IoT Hub naar een andere, kan het bovenliggende IoT Edge-apparaat op het hoogste niveau verbinding maken met IoT Hub, maar downstream-IoT Edge-apparaten kunnen dat niet. Het logboekrapport Unable to authenticate client downstream-device/$edgeAgent with module credentials.

Oorzaak

De referenties voor de downstreamapparaten zijn niet correct bijgewerkt toen de migratie naar de nieuwe IoT-hub plaatsvond. edgeAgentedgeHub Daarom zijn modules ingesteld op verificatietype none (standaard indien niet expliciet ingesteld). Tijdens de verbinding gebruiken de modules op de downstreamapparaten oude referenties, waardoor de verificatie mislukt.

Oplossing

Wanneer u migreert naar de nieuwe IoT-hub (ervan uitgaande dat u DPS niet gebruikt), volgt u deze stappen in volgorde:

1. Volg deze handleiding voor het exporteren en vervolgens importeren van apparaat-id's van de oude IoT-hub naar de nieuwe
2. Alle IoT Edge-implementaties en -configuraties opnieuw configureren in de nieuwe IoT-hub
3. Alle bovenliggende en onderliggende apparaatrelaties opnieuw configureren in de nieuwe IoT-hub
4. Werk elk apparaat bij zodat deze verwijst naar de nieuwe hostnaam van de IoT-hub (iothub_hostnameonder [provisioning] )config.toml
5. Als u ervoor kiest om verificatiesleutels uit te sluiten tijdens het exporteren van het apparaat, configureert u elk apparaat opnieuw met de nieuwe sleutels die zijn opgegeven door de nieuwe IoT-hub (device_id_pk onder [provisioning.authentication] in config.toml)
6. Start eerst het bovenliggende Edge-apparaat op het hoogste niveau opnieuw op, zorg ervoor dat het actief is
7. Start elk apparaat op hiërarchieniveau opnieuw op niveau van boven naar beneden

IoT Edge heeft een lage berichtdoorvoer wanneer deze geografisch ver van IoT Hub ligt

Symptomen

Azure IoT Edge-apparaten die geografisch ver van Azure IoT Hub liggen, hebben een lagere berichtdoorvoer dan verwacht.

Oorzaak

Hoge latentie tussen het apparaat en IoT Hub kan leiden tot een lagere dan verwachte berichtdoorvoer. IoT Edge maakt gebruik van een standaardgrootte van 10 berichtenbatch. Dit beperkt het aantal berichten dat in één batch wordt verzonden, waardoor het aantal retouren tussen het apparaat en IoT Hub toeneemt.

Oplossing

Probeer de omgevingsvariabele MaxUpstreamBatchSize van IoT Edge Hub te verhogen. Hierdoor kunnen er meer berichten in één batch worden verzonden, waardoor het aantal retouren tussen het apparaat en IoT Hub wordt verminderd.

Omgevingsvariabelen voor Azure Edge Hub instellen in Azure Portal:

1. Navigeer naar uw IoT Hub en selecteer Apparaten in het menu Apparaatbeheer .
2. Selecteer het IoT Edge-apparaat dat u wilt bijwerken.
3. Selecteer Modules instellen.
4. Selecteer Runtime-Instellingen.
5. Voeg op het tabblad Instellingen van de Edge Hub-module de omgevingsvariabele MaxUpstreamBatchSize toe als type Number met de waarde 20.
6. Selecteer Toepassen.

Volgende stappen

Denkt u dat u een fout op het IoT Edge-platform hebt gevonden? Dien een probleem in, zodat we kunnen blijven verbeteren.

Als u meer vragen hebt, maakt u een ondersteuningsaanvraag voor hulp.