Dela via

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

  • Artikel

Gäller för: Ja-ikon IoT Edge 1.1

Viktigt!

IoT Edge 1.1 slutdatum för support var den 13 december 2022. I informationen om Microsoft-produktens livscykel hittar du fler uppgifter om vilken support som gäller för denna produkt, tjänst, teknik eller detta API. Mer information om hur du uppdaterar till den senaste versionen av IoT Edge finns i 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 konfigurerat 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-portalen. 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 Ange moduler i Azure-portalen eller Skapa distribution för enskilda enhetsfunktioner i 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.

Det går inte att hämta IoT Edge-körningsloggarna i Windows

Symtom

Du får en EventLogException när du använder Get-WinEvent i Windows.

Orsak

Get-WinEvent PowerShell-kommandot förlitar sig på att en registerpost finns för att hitta loggar av en specifik ProviderName.

Lösning

Ange en registerpost för IoT Edge-daemonen. Skapa en iotedge.reg fil med följande innehåll och importera till Windows-registret genom att dubbelklicka på den eller med kommandot 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

DPS-klientfel

Symtom

Det går inte att starta IoT Edge med felmeddelandet failed to provision with IoT Hub, and no valid device backup was found dps client error.

Orsak

En gruppregistrering används för att etablera en IoT Edge-enhet till en IoT Hub. IoT Edge-enheten flyttas till en annan hubb. Registreringen tas bort i DPS. En ny registrering skapas i DPS för den nya hubben. Enheten har inte återskapats.

Lösning

  1. Kontrollera att dina DPS-autentiseringsuppgifter är korrekta.
  2. Använd konfigurationen med .sudo iotedge apply config
  3. Om enheten inte har återskapats startar du om enheten med .sudo iotedge system restart
  4. Om enheten inte har återskapats framtvingar du ometablering med hjälp av sudo iotedge system reprovision.

Om du vill återskapa automatiskt anger du dynamic_reprovisioning: true i enhetskonfigurationsfilen. Om du anger den här flaggan till true väljer du funktionen för dynamisk ometablering. IoT Edge identifierar situationer där enheten verkar ha återskapats i molnet genom att övervaka sin egen IoT Hub-anslutning för vissa fel. IoT Edge svarar genom att stänga av alla Edge-moduler och sig själv. Nästa gång daemonen startas försöker den återskapa den här enheten med Azure för att ta emot den nya IoT Hub-etableringsinformationen.

När du använder extern etablering meddelar daemon även den externa etableringsslutpunkten om ometableringshändelsen innan den stängs av. Mer information finns i Begrepp för ometablering av IoT Hub-enheter.

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 rapporterar kontinuerligt "tom konfigurationsfil...".

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.

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 på rätt plats för din plattform:

Plattform Plats
Linux /etc/docker
Windows-värd med Windows-containrar C:\ProgramData\iotedge-moby\config

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

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

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

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 .

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-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 alternativen för att skapa i Azure-portalen eller direkt i filen deployment.json.

I Azure-portalen:

  1. Gå till din IoT-hubb och välj Enheter under menyn Enhetshantering .

  2. Välj den IoT Edge-enhet som du vill uppdatera.

  3. Välj Ange moduler.

  4. Välj Körningsinställningar.

  5. I inställningarna för Edge Hub-modulen tar du bort allt från textrutan Skapa alternativ .

  6. Spara ändringarna och skapa distributionen.

I filen deployment.json:

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

  2. edgeHub Hitta inställningarna i avsnittet önskade egenskaper för 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. Ta bort linjen createOptions och det avslutande kommatecknet i slutet av image raden före den:

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

  4. Spara filen och 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 som är inställd på false.

OptimizeForPerformance inställt på false

I distributionsmanifestet:

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

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.

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

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

Det gick inte att starta modulen på grund av matchningsfel i operativsystemet

Symptom

EdgeHub-modulen startar inte i IoT Edge version 1.1.

Orsak

Windows-modulen använder en version av Windows som inte är kompatibel med windowsversionen på värden. IoT Edge Windows version 1809 build 17763 behövs som basskikt för modulavbildningen, men en annan version används.

Lösning

Kontrollera versionen av dina olika Windows-operativsystem i Felsöka felmatchningar för värd- och containeravbildningar. Om operativsystemen skiljer sig åt uppdaterar du dem till IoT Edge Windows version 1809 build 17763 och återskapar Docker-avbildningen som används för modulen.

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.

  1. Gå till översiktssidan för den virtuella datorn i Azure-portalen.

  2. Välj konfigurera under DNS-namn. Om den virtuella datorn redan har konfigurerat ett DNS-namn behöver du inte konfigurera ett nytt.

    Konfigurera DNS-namnet på den virtuella datorn

  3. Ange ett värde för DNS-namnetiketten och välj Spara.

  4. Kopiera det nya DNS-namnet, som ska ha formatet <DNSnamelabel.><vmlocation.cloudapp.azure.com>.

  5. I den virtuella datorn använder du följande kommando för att konfigurera IoT Edge-körningen med ditt DNS-namn:

    • I Linux:

      sudo nano /etc/iotedge/config.yaml

    • I Windows:

      notepad C:\ProgramData\iotedge\config.yaml

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.

I Windows:

  1. Öppna programmet Kör .

  2. Ange regedit i textrutan och välj Ok.

  3. I fönstret Registereditorn bläddrar du till HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.

  4. Leta efter parametern IPEnableRouter .

    1. Om parametern finns anger du värdet för parametern till 1.

    2. Om parametern inte finns lägger du till den som en ny parameter med följande inställningar:

      Inställning Värde
      Name IPEnableRouter
      Typ REG_DWORD
      Värde 1

  5. Stäng registerredigerarens fönster.

  6. Starta om systemet för att tillämpa ändringarna.

I Linux:

  1. Öppna filen sysctl.conf.

    sudo nano /etc/sysctl.conf

  2. Lägg till följande rad i filen.

    net.ipv4.ip_forward=1

  3. Spara och stäng filen.

  4. Starta om nätverkstjänsten och Docker-tjänsten för att tillämpa ändringarna.

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.