Felsöka din IoT Edge-enhet

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

Viktigt!

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

Om du får problem med att köra Azure IoT Edge i din miljö använder du den här artikeln som en guide för felsökning och diagnostik.

Kör kommandot "check"

Ditt första steg när du felsöker IoT Edge bör vara att använda check kommandot, som kör en samling konfigurations- och anslutningstester för vanliga problem. Kommandot check är tillgängligt i version 1.0.7 och senare.

Kommentar

Felsökningsverktyget kan inte köra anslutningskontroller om IoT Edge-enheten finns bakom en proxyserver.

Du kan köra kommandot på check följande sätt eller inkludera --help flaggan för att se en fullständig lista med alternativ:

sudo iotedge check

Felsökningsverktyget kör många kontroller som är sorterade i följande tre kategorier:

• Konfigurationskontroller undersöker information som kan hindra IoT Edge-enheter från att ansluta till molnet, inklusive problem med konfigurationsfilen och containermotorn.
• Anslut ion kontrollerar att IoT Edge-körningen kan komma åt portar på värdenheten och att alla IoT Edge-komponenter kan ansluta till IoT Hub. Den här uppsättningen kontroller returnerar fel om IoT Edge-enheten finns bakom en proxy.
• Produktionsberedskapskontroller letar efter rekommenderade metodtips för produktion, till exempel status för certifikat för enhetscertifikatutfärdare (CA) och konfiguration av modulloggfil.

IoT Edge-kontrollverktyget använder en container för att köra dess diagnostik. Containeravbildningen, mcr.microsoft.com/azureiotedge-diagnostics:latest, är tillgänglig via Microsoft Container Registry. Om du behöver köra en kontroll på en enhet utan direkt åtkomst till Internet behöver dina enheter åtkomst till containeravbildningen.

I ett scenario med kapslade IoT Edge-enheter kan du få åtkomst till diagnostikbilden på underordnade enheter genom att dirigera avbildningen genom de överordnade enheterna.

sudo iotedge check --diagnostics-image-name <parent_device_fqdn_or_ip>:<port_for_api_proxy_module>/azureiotedge-diagnostics:1.2

Information om var och en av de diagnostiska kontroller som det här verktyget kör, inklusive vad du ska göra om du får ett fel eller en varning, finns i IoT Edge-felsökningskontroller.

Samla in felsökningsinformation med kommandot "support-bundle"

När du behöver samla in loggar från en IoT Edge-enhet är det enklaste sättet att använda support-bundle kommandot. Som standard samlar det här kommandot in modulen, IoT Edge-säkerhetshanteraren och containermotorloggar, iotedge check JSON-utdata och annan användbar felsökningsinformation. Den komprimerar dem till en enda fil för enkel delning. Kommandot support-bundle är tillgängligt i version 1.0.9 och senare.

support-bundle Kör kommandot med --since flaggan för att ange hur länge från det förflutna du vill hämta loggar. Till exempel 6h kommer att hämta loggar sedan de senaste sex timmarna, 6d sedan de senaste sex dagarna, 6m sedan de senaste sex minuterna och så vidare. --help Ta med flaggan för att se en fullständig lista med alternativ.

sudo iotedge support-bundle --since 6h

Som standard support-bundle skapar kommandot en zip-fil med namnet support_bundle.zip i katalogen där kommandot anropas. Använd flaggan --output för att ange en annan sökväg eller ett annat filnamn för utdata.

Mer information om kommandot finns i hjälpinformationen.

iotedge support-bundle --help

Du kan också använda det inbyggda direktmetodanropet UploadSupportBundle för att ladda upp utdata från kommandot supportpaket till Azure Blob Storage.

Varning

Utdata från support-bundle kommandot kan innehålla värd-, enhets- och modulnamn, information som loggas av dina moduler osv. Tänk på detta om du delar utdata i ett offentligt forum.

Granska mått som samlats in från körningen

IoT Edge-runtime-modulerna skapar mått som hjälper dig att övervaka och förstå hälsotillståndet för dina IoT Edge-enheter. Lägg till modulen metrics-collector i dina distributioner för att hantera insamling av dessa mått och skicka dem till molnet för enklare övervakning.

Mer information finns i Samla in och transportera mått.

Kontrollera din IoT Edge-version

Om du kör en äldre version av IoT Edge kan du eventuellt lösa problemet genom att uppgradera. Verktyget iotedge check kontrollerar att IoT Edge-säkerhetsdaemonen är den senaste versionen, men kontrollerar inte versionerna av IoT Edge-hubben och agentmodulerna. Om du vill kontrollera versionen av runtime-modulerna på enheten använder du kommandona iotedge logs edgeAgent och iotedge logs edgeHub. Versionsnumret skrivs ut i loggarna när modulen startas.

Anvisningar om hur du uppdaterar enheten finns i Uppdatera IoT Edge-säkerhetsdaemonen och körningen.

Kontrollera installationen av IoT Edge på dina enheter

Du kan kontrollera installationen av IoT Edge på dina enheter genom att övervaka edgeAgent-modultvillingen.

Om du vill hämta den senaste edgeAgent-modultvillingen kör du följande kommando från Azure Cloud Shell:

az iot hub module-twin show --device-id <edge_device_id> --module-id '$edgeAgent' --hub-name <iot_hub_name>

Det här kommandot matar ut alla rapporterade egenskaper för edgeAgent. Här är några användbara som övervakar enhetens status:

• körningsstatus
• starttid för körning
• körning senaste avslutstid
• antal omstarter av körning

Kontrollera statusen för IoT Edge-säkerhetshanteraren och dess loggar

IoT Edge-säkerhetshanteraren ansvarar för åtgärder som att initiera IoT Edge-systemet vid start och etablering av enheter. Om IoT Edge inte startar kan loggarna för säkerhetshanteraren ge användbar information.

• Visa status för IoT Edge-systemtjänsterna:

  sudo iotedge system status
  

• Visa loggarna för IoT Edge-systemtjänsterna:

  sudo iotedge system logs -- -f
  

• Aktivera loggar på felsökningsnivå för att visa mer detaljerade loggar för IoT Edge-systemtjänsterna:

  1. Aktivera loggar på felsökningsnivå.

     sudo iotedge system set-log-level debug
     sudo iotedge system restart
     

  2. Växla tillbaka till standardloggarna på informationsnivå efter felsökning.

     sudo iotedge system set-log-level info
     sudo iotedge system restart
     

Kontrollera om det finns problem i containerloggarna

När IoT Edge-säkerhetsdaemonen körs kan du titta på loggarna för containrarna för att identifiera problem. Börja med dina distribuerade containrar och titta sedan på de containrar som utgör IoT Edge-körningen: edgeAgent och edgeHub. IoT Edge-agentloggarna innehåller vanligtvis information om livscykeln för varje container. IoT Edge-hubbloggarna innehåller information om meddelanden och routning.

Du kan hämta containerloggarna från flera platser:

• På IoT Edge-enheten kör du följande kommando för att visa loggar:

  iotedge logs <container name>
  

• I Azure-portalen använder du det inbyggda felsökningsverktyget. Övervaka och felsöka IoT Edge-enheter från Azure-portalen

• Använd direct-metoden UploadModuleLogs för att ladda upp loggarna för en modul till Azure Blob Storage.

Rensa containerloggar

Som standard anger moby-containermotorn inte storleksbegränsningar för containerloggar. Med tiden kan omfattande loggar leda till att enheten fylls med loggar och att diskutrymmet börjar ta slut. Om stora containerloggar påverkar IoT Edge-enhetens prestanda använder du följande kommando för att tvinga bort containern tillsammans med dess relaterade loggar.

Om du fortfarande felsöker väntar du tills du har inspekterat containerloggarna för att ta det här steget.

Varning

Om du tvingar bort edgeHub-containern medan den har ett meddelande som inte har levererats och ingen värdlagring har konfigurerats kommer de olevererade meddelandena att gå förlorade.

docker rm --force <container name>

För pågående loggunderhåll och produktionsscenarier konfigurerar du standardloggningsdrivrutinen.

Visa meddelandena som går via IoT Edge-hubben

Du kan visa meddelanden som går via IoT Edge-hubben och samla in insikter från utförliga loggar från körningscontainrarna. Om du vill aktivera utförliga loggar på dessa containrar anger du RuntimeLogLevel miljövariabeln i distributionsmanifestet.

Om du vill visa meddelanden som går via IoT Edge-hubben anger du RuntimeLogLevel miljövariabeln till debug för edgeHub-modulen.

Både edgeHub- och edgeAgent-modulerna har den här miljövariabeln för körningsloggen, med standardvärdet inställt på info. Den här miljövariabeln kan ha följande värden:

• Dödlig
• fel
• varning
• Information om
• debug
• utförlig

Du kan också kontrollera de meddelanden som skickas mellan IoT Hub- och IoT-enheter. Visa dessa meddelanden med hjälp av Azure IoT Hub-tillägget för Visual Studio Code. Mer information finns i Praktiskt verktyg när du utvecklar med Azure IoT.

Starta om containrar

När du har undersökt loggarna och meddelandena för information kan du prova att starta om containrar.

På IoT Edge-enheten använder du följande kommandon för att starta om moduler:

iotedge restart <container name>

Starta om IoT Edge-körningscontainrarna:

iotedge restart edgeAgent && iotedge restart edgeHub

Du kan också starta om moduler via fjärranslutning från Azure-portalen. Mer information finns i Övervaka och felsöka IoT Edge-enheter från Azure-portalen.

Kontrollera konfigurationsreglerna för brandväggen och porten

Azure IoT Edge tillåter kommunikation från en lokal server till Azure-molnet med hjälp av IoT Hub-protokoll som stöds, se välja ett kommunikationsprotokoll. För förbättrad säkerhet är kommunikationskanaler mellan Azure IoT Edge och Azure IoT Hub alltid konfigurerade för utgående trafik. Den här konfigurationen baseras på mönstret För tjänstassisterad kommunikation, vilket minimerar attackytan för en skadlig entitet att utforska. Inkommande kommunikation krävs endast för specifika scenarier där Azure IoT Hub behöver skicka meddelanden till Azure IoT Edge-enheten. Meddelanden från moln till enhet skyddas med säkra TLS-kanaler och kan skyddas ytterligare med X.509-certifikat och TPM-enhetsmoduler. Azure IoT Edge Security Manager styr hur den här kommunikationen kan upprättas, se IoT Edge Security Manager.

Även om IoT Edge ger förbättrad konfiguration för att skydda Azure IoT Edge-körning och distribuerade moduler, är det fortfarande beroende av den underliggande datorn och nätverkskonfigurationen. Därför är det absolut nödvändigt att se till att rätt nätverks- och brandväggsregler konfigureras för säker gräns-till-molnkommunikation. Följande tabell kan användas som en riktlinje när du konfigurerar brandväggsregler för de underliggande servrar där Azure IoT Edge-körningen finns:

Protokoll	Port	Inkommande	Utgående	Vägledning
MQTT	8883	BLOCKERAD (standard)	BLOCKERAD (standard)	Konfigurera utgående (utgående) som Öppen när du använder MQTT som kommunikationsprotokoll. 1883 för MQTT stöds inte av IoT Edge. Inkommande (inkommande) anslutningar ska blockeras.
AMQP	5671	BLOCKERAD (standard)	ÖPPNA (standard)	Standardprotokoll för kommunikation för IoT Edge. Måste konfigureras för att vara Öppen om Azure IoT Edge inte har konfigurerats för andra protokoll som stöds eller AMQP är önskat kommunikationsprotokoll. 5672 för AMQP stöds inte av IoT Edge. Blockera den här porten när Azure IoT Edge använder ett annat protokoll som stöds av IoT Hub. Inkommande (inkommande) anslutningar ska blockeras.
HTTPS	443	BLOCKERAD (standard)	ÖPPNA (standard)	Konfigurera utgående (utgående) att vara Öppen på 443 för IoT Edge-etablering. Den här konfigurationen krävs när du använder manuella skript eller Azure IoT Device Provisioning Service (DPS). Inkommande (inkommande) anslutning bör endast vara Öppen för specifika scenarier: Om du har en transparent gateway med underordnade enheter som kan skicka metodbegäranden. I det här fallet behöver port 443 inte vara öppen för externa nätverk för att ansluta till IoTHub eller tillhandahålla IoTHub-tjänster via Azure IoT Edge. Den inkommande regeln kan därför begränsas till att endast öppna Inkommande (inkommande) från det interna nätverket. För C2D-scenarier (klient till enhet). 80 för HTTP stöds inte av IoT Edge. Om icke-HTTP-protokoll (till exempel AMQP eller MQTT) inte kan konfigureras i företaget; meddelandena kan skickas via WebSockets. Port 443 används i så fall för WebSocket-kommunikation.

Sista utväg: stoppa och återskapa alla containrar

Ibland kan ett system kräva betydande särskilda ändringar för att fungera med befintliga nätverks- eller operativsystembegränsningar. Ett system kan till exempel kräva en annan datadiskmontering och proxyinställningar. Om du har provat alla tidigare steg och fortfarande får containerfel kanske docker-systemet cachelagrar eller bevarade nätverksinställningar inte är uppdaterade med den senaste omkonfigurationen. I det här fallet är det sista alternativet att använda docker prune få en ren start från början.

Följande kommando stoppar IoT Edge-systemet (och därmed alla containrar), använder alternativet "alla" och "volym" för docker prune att ta bort alla containrar och volymer. Granska varningen om att kommandot har problem och bekräfta med y när det är klart.

sudo iotedge system stop
docker system prune --all --volumes

WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all volumes not used by at least one container
  - all images without at least one container associated to them
  - all build cache

Are you sure you want to continue? [y/N]

Starta systemet igen. För att vara säker använder du eventuell återstående konfiguration och startar systemet med ett kommando.

sudo iotedge config apply

Vänta några minuter och kontrollera igen.

sudo iotedge list

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.