Dela via

Övervaka, diagnostisera och felsöka Azure IoT Hub-enhetsanslutning

  • Artikel

Anslutningsproblem för IoT-enheter kan vara svåra att felsöka eftersom det finns många möjliga felpunkter. Programlogik, fysiska nätverk, protokoll, maskinvara, IoT Hub och andra molntjänster kan orsaka problem. Möjligheten att identifiera och hitta källan till ett problem är kritisk. En IoT-lösning i stor skala kan dock ha tusentals enheter, så det är inte praktiskt att kontrollera enskilda enheter manuellt. IoT Hub integreras med två Azure-tjänster som hjälper dig:

  • Med Azure Monitor Azure Monitor kan du samla in, analysera och agera på telemetri från IoT Hub. Om du vill hjälpa dig att identifiera, diagnostisera och felsöka dessa problem i stor skala använder du de övervakningsfunktioner som IoT Hub tillhandahåller via Azure Monitor. Den här metoden omfattar att konfigurera aviseringar för att utlösa meddelanden och åtgärder när frånkopplingar inträffar och konfigurera loggar som du kan använda för att identifiera de villkor som orsakade frånkopplingar.

  • Azure Event Grid För kritisk infrastruktur och frånkoppling per enhet använder du Azure Event Grid för att prenumerera på enhetsanslutnings- och frånkopplingshändelser som genereras av IoT Hub. Med Azure Event Grid kan du använda någon av följande händelsehanterare:

    • Azure Functions
    • Logic Apps
    • Azure Automation
    • WebHooks
    • Queue Storage
    • Hybridanslutningar
    • Event Hubs

Event Grid jämfört med Azure Monitor

Event Grid tillhandahåller en lösning för övervakning per enhet med låg svarstid som du kan använda för att spåra enhetsanslutningar för kritiska enheter och infrastruktur. Azure Monitor tillhandahåller ett mått med namnet Anslutna enheter som du kan använda för att övervaka antalet enheter som är anslutna till din IoT Hub och utlösa en avisering när det antalet sjunker under ett statiskt tröskelvärde.

Tänk på följande när du bestämmer dig för att använda Event Grid eller Azure Monitor för ett visst scenario:

  • Svarstid för aviseringar: IoT Hub-anslutningshändelser levereras mycket snabbare via Event Grid. Detta gör Event Grid till ett bättre val för scenarier där snabbmeddelanden är önskvärda.

  • Meddelanden per enhet: Event Grid ger möjlighet att spåra anslutningar och frånkopplingar för enskilda enheter. Detta gör Event Grid till ett bättre val för scenarier där du behöver övervaka anslutningarna för kritiska enheter.

  • Enkel konfiguration: Azure Monitor-måttaviseringar ger en enkel konfigurationsupplevelse som inte kräver integrering med andra tjänster för att leverera meddelanden via e-post, SMS, röst och andra meddelanden. Med Event Grid måste du integrera med andra Azure-tjänster för att leverera meddelanden. Båda tjänsterna kan integreras med andra tjänster för att utlösa mer komplexa åtgärder.

Event Grid: Övervaka anslutnings- och frånkopplingshändelser

För att övervaka enhetsanslutnings- och frånkopplingshändelser i produktion rekommenderar vi att du prenumererar på händelserna DeviceConnected och DeviceDisconnected i Event Grid för att utlösa aviseringar och övervaka enhetens anslutningstillstånd. Event Grid ger lägre händelsefördröjning än Azure Monitor och du kan övervaka per enhet. Dessa faktorer gör Event Grid till den bästa metoden för övervakning av kritiska enheter och infrastruktur.

När du använder Event Grid för att övervaka eller utlösa aviseringar på enhetens frånkopplingar ska du skapa ett sätt att filtrera bort de periodiska frånkopplingarna på grund av SAS-tokenförnyelse på enheter som använder Azure IoT SDK:er. Mer information finns i MQTT-enhetens frånkopplingsbeteende med Azure IoT SDK:er.

Utforska följande artiklar för att lära dig mer om övervakning av enhetsanslutningshändelser med Event Grid:

Azure Monitor: Använd loggar för att lösa anslutningsfel

När du upptäcker att enheten kopplas från med hjälp av Azure Monitor-måttaviseringar eller Event Grid kan du använda loggar för att felsöka orsaken. I det här avsnittet beskrivs hur du söker efter vanliga problem i Azure Monitor-loggar. Stegen här förutsätter att du redan har skapat en diagnostikinställning för att skicka IoT Hub-anslutningsloggar till en Log Analytics-arbetsyta.

När du har skapat en diagnostikinställning för att dirigera IoT Hub-resursloggar till Azure Monitor-loggar följer du de här stegen för att visa loggarna i Azure-portalen.

  1. Gå till din IoT-hubb i Azure-portalen.

  2. Under Övervakning i den vänstra rutan i din IoT-hubb väljer du Loggar.

  3. Om du vill isolera anslutningsfelloggar för IoT Hub anger du följande fråga i frågeredigeraren och väljer sedan Kör:

    AzureDiagnostics
| where ( ResourceType == "IOTHUBS" and Category == "Connections" and Level == "Error")

  4. Om det finns resultat letar du efter , ResultType (felkod) och ResultDescription (felmeddelande) för OperationNameatt få mer information.

    Exempel på fellogg

Använd följande problemlösningsguider för att få hjälp med de vanligaste felen:

Azure Monitor: Använda loggar för att övervaka anslutningen för en specifik enhet

Det kan finnas situationer när du vill använda Azure Monitor för att se anslutningsfel och information för en specifik enhet. Om du vill isolera anslutningshändelser för en enhet kan du följa samma steg som i föregående avsnitt, men ange följande fråga. Ersätt testenheten med namnet på enheten.

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.DEVICES" and ResourceType == "IOTHUBS"
| where Category == "Connections"
| extend DeviceId = tostring(parse_json(properties_s).deviceId)
| where DeviceId == "test-device"

Frågan returnerar både fel- och informationshändelser för målenheten. Följande exempelutdata visar en informationsenhetAnslut händelse:

Skärmbild av deviceConnect-händelsen i loggar.

MQTT-enhetens frånkopplingsbeteende med Azure IoT SDK:er

Azure IoT-enhets-SDK:er kopplar från IoT Hub och återansluter sedan när de förnyar SAS-token via MQTT-protokollet (och MQTT över WebSockets). I loggar visas detta som att informationsenheten kopplar från och ansluter händelser som ibland åtföljs av felhändelser.

Som standard är tokens livslängd 60 minuter för alla SDK:er. Utvecklare kan dock ändra det i vissa SDK:er. I följande tabell sammanfattas beteendet för tokenlivslängd, tokenförnyelse och tokenförnyelse för var och en av SDK:erna:

SDK Livslängd för token Tokenförnyelse Förnyelsebeteende
.NET 60 minuter, kan konfigureras 85 % av livslängden, konfigurerbar SDK kopplar från och återansluter vid tokens livslängd plus en respitperiod på 10 minuter. Informationshändelser och fel som genereras i loggar.
Java 60 minuter, kan konfigureras 85 % av livslängden, inte konfigurerbar SDK kopplar från och återansluter vid tokens livslängd plus en respitperiod på 10 minuter. Informationshändelser och fel som genereras i loggar.
Node.js 60 minuter, kan konfigureras Konfigurerbara SDK kopplar från och återansluter vid tokenförnyelse. Endast informationshändelser genereras i loggar.
Python 60 minuter, kan konfigureras 120 sekunder före förfallodatum SDK kopplar från och återansluter vid tokens livslängd.

Följande skärmbilder visar beteendet för tokenförnyelse i Azure Monitor-loggar för olika SDK:er. Tröskelvärdet för tokenlivslängd och förnyelse har ändrats från deras standardvärden enligt vad som anges.

  • .NET-enhets-SDK med en tokenlivslängd på 1 200 sekunder (20 minuter) och förnyelse inställd på 90 % av livslängden. frånkoppling sker var 30:e minut:

    Felbeteende för tokenförnyelse via MQTT i Azure Monitor-loggar med .NET SDK.

  • Java SDK med en tokenlivslängd på 300 sekunder (5 minuter) och standardvärdet är 85 % av livslängdsförnyelsen. Frånkopplingar sker var 15:e minut:

    Felbeteende för tokenförnyelse via MQTT i Azure Monitor-loggar med Java SDK.

  • Node SDK med en tokenlivslängd på 300 sekunder (5 minuter) och tokenförnyelse inställd på 3 minuter. Frånkopplingar sker vid tokenförnyelse. Det finns heller inga fel. Endast informationsbaserade anslutnings-/frånkopplingshändelser genereras:

    Felbeteende för tokenförnyelse via MQTT i Azure Monitor-loggar med Node SDK.

Följande fråga användes för att samla in resultaten. Frågan extraherar SDK-namnet och versionen från egenskapsväskan. Mer information finns i SDK-versionen i IoT Hub-loggar.

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.DEVICES" and ResourceType == "IOTHUBS"
| where Category == "Connections"
| extend parsed_json = parse_json(properties_s)
| extend SDKVersion = tostring(parsed_json.sdkVersion) , DeviceId = tostring(parsed_json.deviceId) , Protocol =  tostring(parsed_json.protocol)
| distinct TimeGenerated, OperationName, Level, ResultType, ResultDescription, DeviceId, Protocol, SDKVersion

Som utvecklare eller operatör för IoT-lösningar måste du vara medveten om det här beteendet för att tolka anslutnings-/frånkopplingshändelser och relaterade fel i loggar. Om du vill ändra tokens livslängd eller förnyelsebeteende för enheter kontrollerar du om enheten implementerar en enhetstvillinginställning eller en enhetsmetod som gör den här ändringen möjlig.

Om du övervakar enhetsanslutningar med Event Hubs ser du till att du skapar ett sätt att filtrera bort de periodiska frånkopplingarna på grund av förnyelse av SAS-token. Du kan till exempel inte utlösa åtgärder baserat på frånkopplingar så länge frånkopplingshändelsen följs av en anslutningshändelse inom ett visst tidsintervall.

Kommentar

IoT Hub stöder endast en aktiv MQTT-anslutning per enhet. Alla nya MQTT-anslutningar för samma enhets-ID gör att IoT Hub släpper den befintliga anslutningen.

400027 ConnectionForcefullyClosedOnNewConnection loggas in i IoT Hub-loggar

Jag försökte stegen, men de fungerade inte

Om föregående steg inte hjälpte kan du prova:

Nästa steg