Lösningar på vanliga problem för Azure IoT Edge

Artikel
01/24/2025

Gäller för: IoT Edge 1.5 IoT Edge 1.4

Viktigt!

IoT Edge 1.5 LTS är den version som stöds. IoT Edge 1.4 LTS upphör från och med den 12 november 2024. Om du har en tidigare version läser du Uppdatera IoT Edge.

Använd den här artikeln för att identifiera och lösa vanliga problem när du använder IoT Edge-lösningar. Om du behöver information om hur du hittar loggar och fel från din IoT Edge-enhet kan du läsa Felsöka din IoT Edge-enhet.

Etablering och distribution

IoT Edge-modulen distribueras korrekt och försvinner sedan från enheten

Symtom

När du har angett moduler för en IoT Edge-enhet distribueras modulerna, men efter några minuter försvinner de från enheten och från enhetsinformationen i Azure Portal. Andra moduler än de som definierats kan också visas på enheten.

Orsak

Om en automatisk distribution riktar sig mot en enhet prioriteras den framför att manuellt ange modulerna för en enskild enhet. Funktionen Set modules in Azure Portal or Create deployment for single device functionality in Visual Studio Code börjar gälla en stund. Du ser de moduler som du definierade startar på enheten. Sedan startar och skriver den automatiska distributionens prioritet över enhetens önskade egenskaper.

Lösning

Använd endast en typ av distributionsmekanism per enhet, antingen en automatisk distribution eller enskilda enhetsdistributioner. Om du har flera automatiska distributioner riktade till en enhet kan du ändra prioritets- eller målbeskrivningar för att se till att rätt distribution gäller för en viss enhet. Du kan också uppdatera enhetstvillingen så att den inte längre matchar målbeskrivningen för den automatiska distributionen.

Mer information finns i Förstå automatiska IoT Edge-distributioner för enskilda enheter eller i stor skala.

IoT Edge-körning

IoT Edge-agenten stoppas efter en minut

Symtom

EdgeAgent-modulen startar och körs i ungefär en minut och stoppas sedan. Loggarna anger att IoT Edge-agenten försöker ansluta till IoT Hub via AMQP och sedan försöker ansluta med AMQP via WebSocket. När det misslyckas avslutas IoT Edge-agenten.

Exempel på edgeAgent-loggar:

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

Orsak

En nätverkskonfiguration i värdnätverket hindrar IoT Edge-agenten från att nå nätverket. Agenten försöker ansluta via AMQP (port 5671) först. Om anslutningen misslyckas försöker den använda WebSockets (port 443).

IoT Edge-körningen ställer in ett nätverk för varje modul att kommunicera på. På Linux är nätverket en nätverksbrygga. I Windows använder den NAT. Det här problemet är vanligare på Windows-enheter som använder Windows-containrar som använder NAT-nätverket.

Lösning

Se till att det finns en väg till Internet för IP-adresserna som tilldelats till den här bryggan/NAT-nätverket. Ibland åsidosätter en VPN-konfiguration på värden IoT Edge-nätverket.

Edge-agentmodulen rapporterar "tom konfigurationsfil", och inga moduler startar på enheten

Symtom

Enheten har problem med att starta moduler som definierats i distributionen. Endast edgeAgent körs men och rapporterar en tom konfigurationsfil....
När du kör sudo iotedge check på en enhet rapporterar den att containermotorn inte har konfigurerats med DNS-serverinställningen, vilket kan påverka anslutningen till IoT Hub. https://aka.ms/iotedge-prod-checklist-dns Se för bästa praxis.

Orsak

Som standard startar IoT Edge moduler i sitt eget isolerade containernätverk. Enheten kan ha problem med DNS-namnmatchning i det här privata nätverket.
Om du använder en snapinstallation av IoT Edge är Docker-konfigurationsfilen en annan plats. Se lösningsalternativ 3.

Lösning

Alternativ 1: Ange DNS-server i inställningar för containermotorn

Ange DNS-servern för din miljö i inställningarna för containermotorn, som gäller för alla containermoduler som startas av motorn. Skapa en fil med namnet daemon.jsonoch ange sedan den DNS-server som ska användas. Till exempel:

{
    "dns": ["1.1.1.1"]
}

Den här DNS-servern är inställd på en offentligt tillgänglig DNS-tjänst. Men vissa nätverk, till exempel företagsnätverk, har sina egna DNS-servrar installerade och tillåter inte åtkomst till offentliga DNS-servrar. Om gränsenheten därför inte kan komma åt en offentlig DNS-server ersätter du den med en tillgänglig DNS-serveradress.

Placera daemon.json i /etc/docker katalogen på enheten.

Om platsen redan innehåller en daemon.json fil lägger du till dns-nyckeln i den och sparar filen.

Starta om containermotorn så att uppdateringarna börjar gälla.

sudo systemctl restart docker

Alternativ 2: Ange DNS-server i IoT Edge-distribution per modul

Du kan ange DNS-server för varje moduls createOptions i IoT Edge-distributionen. Till exempel:

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

Varning

Om du använder den här metoden och anger fel DNS-adress förlorar edgeAgent anslutningen till IoT Hub och kan inte ta emot nya distributioner för att åtgärda problemet. Du kan lösa problemet genom att installera om IoT Edge-körningen. Innan du installerar en ny instans av IoT Edge måste du ta bort alla edgeAgent-containrar från föregående installation.

Se till att ange den här konfigurationen även för edgeAgent - och edgeHub-modulerna .

Alternativ 3: Skicka platsen för docker-konfigurationsfilen för att kontrollera kommandot

Om IoT Edge installeras som en snap använder du parametern --container-engine-config-file för att ange platsen för Docker-konfigurationsfilen. Om Docker-konfigurationsfilen till exempel finns på /var/snap/docker/current/config/daemon.jsonkör du följande kommando: iotedge check --container-engine-config-file '/var/snap/docker/current/config/daemon.json'.

För närvarande visas varningsmeddelandet fortfarande i utdata från iotedge-kontrollen även efter att du har angett konfigurationsfilens plats. Kontrollera rapporterar felet eftersom IoT Edge-snapen inte har läsbehörighet till Docker-snapen. Om du använder iotedge-kontrollen i versionsprocessen kan du ignorera varningsmeddelandet med hjälp av parametern --ignore container-engine-dns container-engine-logrotate .

Edge Agent-modulen med LTE-anslutningsrapporterna "empty edge agent config" och orsakar "tillfälligt nätverksfel"

Symtom

En enhet som konfigurerats med LTE-anslutning har problem med att starta moduler som definierats i distributionen. EdgeAgent kan inte ansluta till IoT Hub och rapporterar att det uppstod en tom gränsagentkonfiguration och ett tillfälligt nätverksfel.

Orsak

Vissa nätverk har paketkostnader, vilket gör standardnätverket för Docker MTU (1 500) för högt och orsakar paketfragmentering som förhindrar åtkomst till externa resurser.

Lösning

Kontrollera MTU-inställningen för docker-nätverket.

docker network inspect <network name>
Kontrollera MTU-inställningen för den fysiska nätverksadaptern på enheten.

ip addr show eth0

Kommentar

MTU:n för docker-nätverket får inte vara högre än MTU:n för enheten. Kontakta din ISP om du vill ha mer information.

Om du ser en annan MTU-storlek för docker-nätverket och enheten kan du prova följande lösning:

Skapa ett nytt nätverk. Ett exempel:

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

I exemplet är MTU-inställningen för enheten 1430. Därför är MTU för Docker-nätverket inställt på 1430.
Stoppa och ta bort Azure-nätverket.

docker network rm azure-iot-edge
Återskapa Azure-nätverket.

docker network create --opt com.docker.network.driver.mtu=1430 azure-iot-edge
Ta bort alla containrar och starta om tjänsten aziot-edged .

sudo iotedge system stop && sudo docker rm -f $(docker ps -aq -f "label=net.azure-devices.edge.owner=Microsoft.Azure.Devices.Edge.Agent") && sudo iotedge config apply

IoT Edge-agenten kan inte få åtkomst till en moduls avbildning (403)

Symtom

Det går inte att köra en container och edgeAgent-loggarna rapporterar ett 403-fel.

Orsak

IoT Edge-agentmodulen har inte behörighet att komma åt en moduls avbildning.

Lösning

Kontrollera att dina autentiseringsuppgifter för containerregistret är korrekta för enhetsdistributionsmanifestet.

IoT Edge-agenten gör överdrivna identitetsanrop

Symtom

IoT Edge-agenten gör överdrivna identitetsanrop till Azure IoT Hub.

Orsak

Felaktig konfiguration av enhetsdistributionsmanifestet orsakar en misslyckad distribution på enheten. IoT Edge-agentens omprövningslogik fortsätter att försöka distribuera igen. Varje återförsök gör identitetsanrop tills distributionen lyckas. Om distributionsmanifestet till exempel anger en modul-URI som inte finns i containerregistret eller är feltypad, försöker IoT Edge-agenten distribuera igen tills distributionsmanifestet har korrigerats.

Lösning

Verifiera distributionsmanifestet i Azure Portal. Korrigera eventuella fel och distribuera om manifestet till enheten.

IoT Edge-hubb startar inte

Symtom

Det går inte att starta edgeHub-modulen. Du kan se ett meddelande som något av följande fel i loggarna:

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)

Eller

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)

Orsak

En annan process på värddatorn har bundit en port som edgeHub-modulen försöker binda. IoT Edge-hubben mappar portarna 443, 5671 och 8883 för användning i gatewayscenarier. Det går inte att starta modulen om en annan process redan har bundit en av dessa portar.

Lösning

Du kan lösa det här problemet på två sätt:

Om IoT Edge-enheten fungerar som en gatewayenhet måste du hitta och stoppa processen som använder port 443, 5671 eller 8883. Ett fel för port 443 innebär vanligtvis att den andra processen är en webbserver.

Om du inte behöver använda IoT Edge-enheten som en gateway kan du ta bort portbindningarna från edgeHubs modulskapandealternativ. Du kan ändra skapandealternativen i Azure Portal eller direkt i deployment.json-filen.

I Azure-portalen:

Gå till din IoT-hubb och välj Enheter under menyn Enhetshantering .
Välj den IoT Edge-enhet som du vill uppdatera.
Välj Ange moduler.
Välj Körningsinställningar.
I inställningarna för Edge Hub-modulen tar du bort allt från textrutan Alternativ för containerskapande .
Välj Använd för att spara ändringarna och skapa distributionen.

I filen deployment.json:

Öppna den deployment.json fil som du har tillämpat på din IoT Edge-enhet.

edgeHub Hitta inställningarna i avsnittet önskade egenskaper för 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"
   }

Ta bort linjen createOptions och det avslutande kommatecknet i slutet av image raden före den:

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

Välj Skapa för att tillämpa den på din IoT Edge-enhet igen.

IoT Edge-modulen misslyckas med att skicka ett meddelande till edgeHub och får 404-fel

Symtom

En anpassad IoT Edge-modul kan inte skicka ett meddelande till IoT Edge-hubben med ett 404-fel Module not found . IoT Edge-körningen skriver ut följande meddelande till loggarna:

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 )

Orsak

IoT Edge-körningen tillämpar processidentifiering för alla moduler som ansluter till edgeHub av säkerhetsskäl. Den verifierar att alla meddelanden som skickas av en modul kommer från modulens huvudprocess-ID. Om ett meddelande skickas av en modul från ett annat process-ID än vad som ursprungligen upprättades avvisas meddelandet med ett 404-felmeddelande.

Lösning

Från och med version 1.0.7 har alla modulprocesser behörighet att ansluta. Mer information finns i versionsändringsloggen 1.0.7.

Om du inte kan uppgradera till 1.0.7 utför du följande steg. Kontrollera att samma process-ID alltid används av den anpassade IoT Edge-modulen för att skicka meddelanden till edgeHub. Se till exempel till i ENTRYPOINT stället för CMD kommandot i Docker-filen. Kommandot CMD leder till ett process-ID för modulen och ett annat process-ID för bash-kommandot som kör huvudprogrammet, men ENTRYPOINT leder till ett enda process-ID.

Stabilitetsproblem på mindre enheter

Symtom

Du kan uppleva stabilitetsproblem på resursbegränsade enheter som Raspberry Pi, särskilt när de används som en gateway. Symtomen är minnesfel i IoT Edge-hubbmodulen, underordnade enheter som inte kan ansluta eller att enheten inte kan skicka telemetrimeddelanden efter några timmar.

Orsak

IoT Edge-hubben, som är en del av IoT Edge-körningen, är optimerad för prestanda som standard och försöker allokera stora mängder minne. Den här optimeringen är inte idealisk för begränsade gränsenheter och kan orsaka stabilitetsproblem.

Lösning

För IoT Edge-hubben anger du en miljövariabel OptimizeForPerformance till false. Det finns två sätt att ange miljövariabler:

I Azure-portalen:

I din IoT Hub väljer du din IoT Edge-enhet och på sidan enhetsinformation och väljer Ange inställningar för modulkörning>.
Skapa en miljövariabel för IoT Edge-hubbmodulen med namnet OptimizeForPerformance med typen True/False som är inställd på False.

Välj Använd för att spara ändringar och välj sedan Granska + skapa.

Miljövariabeln finns nu i edgeHub egenskapen för distributionsmanifestet:

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

Välj Skapa för att spara ändringarna och distribuera modulen.

Det gick inte att starta säkerhetsdaemonen

Symtom

Säkerhetsdaemonen startar inte och modulcontainrar skapas inte. Och edgeAgentedgeHub andra anpassade moduler startas inte av IoT Edge-tjänsten. I aziot-edged loggar visas det här felet:

Det gick inte att starta daemonen: Det gick inte att starta hanteringstjänsten

orsakad av: Ett fel uppstod för sökvägen /var/run/iotedge/mgmt.sock

orsakad av: Behörighet nekad (os-fel 13)

Orsak

För alla Linux-distributioner utom CentOS 7 är IoT Edge standardkonfiguration att använda systemd socketaktivering. Ett behörighetsfel inträffar om du ändrar konfigurationsfilen så att den inte använder socketaktivering, men lämnar URL:erna som /var/run/iotedge/*.sock, eftersom iotedge användaren inte kan skriva så att /var/run/iotedge den inte kan låsa upp och montera själva socketarna. CentOS är End of Life (EOL). Mer information finns i CentOS End Of Life-vägledningen.

Lösning

Du behöver inte inaktivera socketaktivering på en distribution där socketaktivering stöds. Men om du föredrar att inte använda socketaktivering alls, placera socketarna i /var/lib/iotedge/.

Kör systemctl disable iotedge.socket iotedge.mgmt.socket för att inaktivera socketenheterna så att systemd inte startar dem i onödan
Ändra iotedge-konfigurationen så att den används /var/lib/iotedge/*.sock i både connect avsnitten och listen
Om du redan har moduler har de gamla /var/run/iotedge/*.sock monteringarna, så docker rm -f de.

Det går långsamt att rensa meddelandekön

Symtom

Meddelandekön rensas inte när meddelanden har bearbetats. Meddelandekön växer med tiden och gör så småningom att IoT Edge-körningen får slut på minne.

Orsak

Intervallet för rensning av meddelanden styrs av klientmeddelandet TTL (time to live) och miljövariabeln EdgeHub MessageCleanupIntervalSecs . Standardvärdet för meddelande-TTL är två timmar och standardvärdet MessageCleanupIntervalSecs är 30 minuter. Om programmet använder ett TTL-värde som är kortare än standardvärdet och du inte justerar värdet MessageCleanupIntervalSecs rensas inte utgångna meddelanden förrän nästa rensningsintervall .

Lösning

Om du ändrar TTL-värdet för ditt program som är kortare än standardvärdet justerar du även värdet MessageCleanupIntervalSecs . Värdet MessageCleanupIntervalSecs bör vara betydligt mindre än det minsta TTL-värde som klienten använder. Om klientprogrammet till exempel definierar en TTL på fem minuter i meddelandehuvudet anger du värdet MessageCleanupIntervalSecs till en minut. De här inställningarna säkerställer att meddelanden rensas inom sex (5 + 1) minuter.

Konfigurera värdet MessageCleanupIntervalSecs genom att ange miljövariabeln i distributionsmanifestet för IoT Edge-hubbmodulen. Mer information om hur du ställer in miljövariabler för körning finns i Miljövariabler för Edge Agent och Edge Hub.

IoT Edge Hub rapporterar System.FormatException med AMQP-protokoll

Symtom

När du dirigerar meddelanden från en IoT Edge-enhet till en IoT Hub med hjälp av AMQP-protokollet och du anger iothub-creation-time-utc egenskapen för utgående enhetsmeddelanden rapporterar IoT Edge Hub ett System.FormatException fel. Felmeddelandet liknar följande:

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

Orsak

Värdet iot-hub-creation-time-utc uppfyller inte strikta formatvillkor. Formatet Edge Hub kräver är en delmängd av ISO 8601.

Lösning

Det här är ett känt problem i IoT Edge Hub för AMQP-protokollet. För närvarande utreds problemet för en korrigering. MQTT-protokollet har inte det här problemet.

Nätverk

IoT Edge-säkerhetsdaemon misslyckas med ett ogiltigt värddatornamn

Symtom

Försök att kontrollera IoT Edge-säkerhetshanterarens loggar misslyckas och skriver ut följande meddelande:

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

Orsak

IoT Edge-körningen kan bara stödja värdnamn som är kortare än 64 tecken. Fysiska datorer har vanligtvis inte långa värdnamn, men problemet är vanligare på en virtuell dator. De automatiskt genererade värdnamnen för virtuella Windows-datorer som finns i Azure, i synnerhet, tenderar att vara långa.

Lösning

När du ser det här felet kan du lösa det genom att konfigurera DNS-namnet på den virtuella datorn och sedan ange DNS-namnet som värdnamn i installationskommandot.

I Azure Portal navigerar du till översiktssidan för den virtuella datorn.
Öppna konfigurationspanelen genom att välja länken Inte konfigurerad (om den virtuella datorn är ny) eller välj ditt befintliga DNS-namn under Essentials>DNS-namn. Om den virtuella datorn redan har konfigurerat ett DNS-namn behöver du inte konfigurera ett nytt.
Ange ett värde för DNS-namnetiketten om du inte redan har en och välj Spara.
Kopiera det nya DNS-namnet, som ska vara i formatet:
<DNSnamelabel>.<vmlocation.cloudapp.azure.com>.
Öppna konfigurationsfilen på IoT Edge-enheten.
```
sudo nano /etc/aziot/config.toml
```
Ersätt värdet hostname för med ditt DNS-namn.
Spara och stäng filen och tillämpa sedan ändringarna på IoT Edge.
```
sudo iotedge config apply
```

IoT Edge-modulen rapporterar anslutningsfel

Symtom

IoT Edge-moduler som ansluter direkt till molntjänster, inklusive runtime-moduler, slutar fungera som förväntat och returnerar fel kring anslutnings- eller nätverksfel.

Orsak

Containrar förlitar sig på vidarebefordran av IP-paket för att kunna ansluta till Internet så att de kan kommunicera med molntjänster. Vidarebefordran av IP-paket är aktiverat som standard i Docker, men om det inaktiveras fungerar inte moduler som ansluter till molntjänster som förväntat. Mer information finns i Förstå containerkommunikation i Docker-dokumentationen.

Lösning

Använd följande steg för att aktivera vidarebefordran av IP-paket.

Öppna filen sysctl.conf.
```
sudo nano /etc/sysctl.conf
```
Lägg till följande rad i filen.
```
net.ipv4.ip_forward=1
```
Spara och stäng filen.
Starta om nätverkstjänsten och Docker-tjänsten för att tillämpa ändringarna.

IoT Edge bakom en gateway kan inte utföra HTTP-begäranden och starta Edge-agentmodulen

Symtom

IoT Edge-körningen är aktiv med en giltig konfigurationsfil, men det går inte att starta edgeAgent-modulen . Kommandot iotedge list returnerar en tom lista. IoT Edge-körningsrapporterna Could not perform HTTP request i loggarna.

Orsak

IoT Edge-enheter bakom en gateway får sina modulbilder från den överordnade IoT Edge-enheten som anges i fältet i parent_hostname konfigurationsfilen. Felet Could not perform HTTP request innebär att den underordnade enheten inte kan nå sin överordnade enhet via HTTP.

Lösning

Kontrollera att den överordnade IoT Edge-enheten kan ta emot inkommande begäranden från den underordnade IoT Edge-enheten. Öppna nätverkstrafik på portarna 443 och 6617 för begäranden som kommer från den underordnade enheten.

IoT Edge bakom en gateway kan inte utföra HTTP-begäranden och starta Edge-agentmodulen

Symtom

IoT Edge-daemonen är aktiv med en giltig konfigurationsfil, men den kan inte starta edgeAgent-modulen. Kommandot iotedge list returnerar en tom lista. IoT Edge-daemonloggrapporten Could not perform HTTP request.

Orsak

Lösning

IoT Edge bakom en gateway kan inte ansluta när du migrerar från en IoT-hubb till en annan

Symtom

När du försöker migrera en hierarki med IoT Edge-enheter från en IoT-hubb till en annan kan den överordnade IoT Edge-enheten på den översta nivån ansluta till IoT Hub, men underordnade IoT Edge-enheter kan inte göra det. Loggrapporten Unable to authenticate client downstream-device/$edgeAgent with module credentials.

Orsak

Autentiseringsuppgifterna för nedströmsenheterna uppdaterades inte korrekt när migreringen till den nya IoT-hubben skedde. edgeAgent edgeHub Därför har modulerna angetts ha autentiseringstyp none (standard om de inte anges explicit). Under anslutningen använder modulerna på de underordnade enheterna gamla autentiseringsuppgifter, vilket gör att autentiseringen misslyckas.

Lösning

När du migrerar till den nya IoT-hubben (förutsatt att du inte använder DPS) följer du dessa steg i ordning:

Följ den här guiden för att exportera och sedan importera enhetsidentiteter från den gamla IoT-hubben till den nya
Konfigurera om alla IoT Edge-distributioner och konfigurationer i den nya IoT-hubben
Konfigurera om alla överordnade och underordnade enhetsrelationer i den nya IoT-hubben
Uppdatera varje enhet så att den pekar på det nya IoT Hub-värdnamnet (iothub_hostname under [provisioning] i config.toml)
Om du väljer att undanta autentiseringsnycklar under enhetsexporten konfigurerar du om varje enhet med de nya nycklar som ges av den nya IoT-hubben (device_id_pk under [provisioning.authentication] i config.toml)
Starta först om den överordnade Edge-enheten på den översta nivån och kontrollera att den är igång
Starta om varje enhet på hierarkinivå efter nivå uppifrån och ned

IoT Edge har lågt dataflöde för meddelanden när det är geografiskt avlägset från IoT Hub

Symtom

Azure IoT Edge-enheter som är geografiskt avlägsna från Azure IoT Hub har ett lägre dataflöde än förväntat.

Orsak

Långa svarstider mellan enheten och IoT Hub kan orsaka ett lägre dataflöde än förväntat. IoT Edge använder en standardstorlek för meddelandebatch på 10. Detta begränsar antalet meddelanden som skickas i en enda batch, vilket ökar antalet tur- och returresor mellan enheten och IoT Hub.

Lösning

Prova att öka miljövariabeln IoT Edge Hub MaxUpstreamBatchSize . På så sätt kan fler meddelanden skickas i en enda batch, vilket minskar antalet tur- och returresor mellan enheten och IoT Hub.

Så här anger du miljövariabler för Azure Edge Hub i Azure Portal:

Gå till din IoT Hub och välj Enheter under menyn Enhetshantering .
Välj den IoT Edge-enhet som du vill uppdatera.
Välj Ange moduler.
Välj Körningsinställningar.
På fliken Inställningar för Edge Hub-modul lägger du till miljövariabeln MaxUpstreamBatchSize som typ Tal med värdet 20.
Välj Använd.

Nästa steg

Tror du att du har hittat ett fel i IoT Edge-plattformen? Skicka in ett problem så att vi kan fortsätta att förbättra.

Om du har fler frågor skapar du en supportbegäran om hjälp.

Dela via

Lösningar på vanliga problem för Azure IoT Edge

Etablering och distribution

IoT Edge-modulen distribueras korrekt och försvinner sedan från enheten

Symtom

Orsak

Lösning

IoT Edge-körning

IoT Edge-agenten stoppas efter en minut

Symtom

Orsak

Lösning

Edge-agentmodulen rapporterar "tom konfigurationsfil", och inga moduler startar på enheten

Symtom

Orsak

Lösning

Edge Agent-modulen med LTE-anslutningsrapporterna "empty edge agent config" och orsakar "tillfälligt nätverksfel"

Symtom

Orsak

Lösning

IoT Edge-agenten kan inte få åtkomst till en moduls avbildning (403)

Symtom

Orsak

Lösning

IoT Edge-agenten gör överdrivna identitetsanrop

Symtom

Orsak

Lösning

IoT Edge-hubb startar inte

Symtom

Orsak

Lösning

IoT Edge-modulen misslyckas med att skicka ett meddelande till edgeHub och får 404-fel

Symtom

Orsak

Lösning

Stabilitetsproblem på mindre enheter

Symtom

Orsak

Lösning

Det gick inte att starta säkerhetsdaemonen

Symtom

Orsak

Lösning

Det går långsamt att rensa meddelandekön

Symtom

Orsak

Lösning

IoT Edge Hub rapporterar System.FormatException med AMQP-protokoll

Symtom

Orsak

Lösning

Nätverk

IoT Edge-säkerhetsdaemon misslyckas med ett ogiltigt värddatornamn

Symtom

Orsak

Lösning

IoT Edge-modulen rapporterar anslutningsfel

Symtom

Orsak

Lösning

IoT Edge bakom en gateway kan inte utföra HTTP-begäranden och starta Edge-agentmodulen

Symtom

Orsak

Lösning

IoT Edge bakom en gateway kan inte utföra HTTP-begäranden och starta Edge-agentmodulen

Symtom

Orsak

Lösning

IoT Edge bakom en gateway kan inte ansluta när du migrerar från en IoT-hubb till en annan

Symtom

Orsak

Lösning

IoT Edge har lågt dataflöde för meddelanden när det är geografiskt avlägset från IoT Hub

Symtom

Orsak

Lösning

Nästa steg

Feedback

Ytterligare resurser