Partager via


Analyser, diagnostiquer et résoudre les problèmes de connectivité des appareils avec Azure IoT Hub

Les problèmes de connectivité des appareils IoT sont parfois difficiles à résoudre, car il existe de nombreux points de défaillance possibles. La logique d’application, les réseaux physiques, les protocoles, le matériel, IoT Hub et d'autres services cloud sont tous susceptibles d’occasionner des problèmes. La possibilité de détecter et d’identifier la source d’un problème est essentielle. Cela étant, une solution IoT à grande échelle peut impliquer des milliers d’appareils et il n'est pas pratique de vérifier chaque appareil individuellement. IoT Hub intègre deux services Azure pour vous aider à :

  • Azure Monitor Azure Monitor vous permet de collecter, d’analyser et d’agir sur la télémétrie à partir de IoT Hub. Pour vous aider à détecter, diagnostiquer et résoudre ces problèmes à grande échelle, utilisez les fonctionnalités de supervision offertes par IoT Hub via Azure Monitor. Cette approche comprend la configuration d’alertes pour déclencher des notifications et des actions lors de déconnexions, ainsi que la configuration de journaux que vous pouvez utiliser pour découvrir les conditions qui ont provoqué ces déconnexions.

  • Azure Event Grid : pour l’infrastructure critique et les déconnexions par appareil, utilisez Azure Event Grid pour vous abonner aux événements de connexion et de déconnexion des appareils émis par IoT Hub. Azure Event Grid vous permet d’utiliser l’un des gestionnaires d’événements suivants :

    • Azure Functions
    • Logic Apps
    • Azure Automation
    • WebHooks
    • Stockage File d’attente
    • les connexions hybrides
    • Event Hubs

Event Grid ou Azure Monitor

Azure Event Grid offre une solution de supervision par appareil à faible latence qui vous permet de suivre les connexions pour les appareils critiques et l’infrastructure. Azure Monitor propose une métrique appelée Appareils connectés que vous pouvez utiliser pour superviser le nombre d’appareils connectés à votre instance IoT Hub et déclencher une alerte dès que ce nombre descend en dessous d’un seuil statique.

Tenez compte des enjeux suivants lorsque vous décidez d’utiliser Event Grid ou Azure Monitor pour un scénario particulier :

  • Latence de l'alerte : les événements de connexion IoT Hub sont remis plus rapidement via Event Grid. Cet élément fait d’Event Grid un meilleur choix pour les scénarios où une notification rapide est préférable.

  • Notifications par appareil : Event Grid offre la possibilité de suivre les connexions et les déconnexions pour des appareils individuels. Cet élément fait d’Event Grid un meilleur choix pour les scénarios où vous devez surveiller les connexions d’appareils critiques.

  • Installation simplifiée : Les alertes de métrique Azure Monitor fournissent une expérience d’installation simplifiée qui ne nécessite pas d’intégration avec d’autres services pour envoyer des notifications par courrier électronique, SMS, voix et autres notifications. Avec Event Grid, vous devez intégrer d’autres services Azure pour remettre des notifications. Ces deux services peuvent s’intégrer à d’autres services pour déclencher des actions plus complexes.

Event Grid : analyser des événements de connexion et de déconnexion

Pour surveiller les événements de connexion et de déconnexion des appareils dans les environnements de production, nous vous recommandons de vous abonner aux événements DeviceConnected et DeviceDisconnected sur Event Grid pour déclencher des alertes et suivre l’état de connexion de l’appareil. Event Grid offre une latence d’événement inférieure à celle d’Azure Monitor. Vous pouvez l’analyser sur une base par appareil. Ces aspects font d’Event Grid la méthode recommandée pour la supervision des appareils critiques et de l’infrastructure.

Lorsque vous utilisez Event Grid pour surveiller ou déclencher des alertes en cas de déconnexion d’un appareil, veillez à créer une méthode de filtrage des déconnexions périodiques dues à un renouvellement de jeton SAS sur les appareils qui utilisent les kits de développement logiciel (SDK) Azure IoT. Pour plus d’informations, consultez Comportement de déconnexion d’appareil MQTT avec les kits de développement logiciel (SDK) Azure IoT.

Explorez les articles suivantes pour en savoir plus sur la surveillance des événements de connexion des appareils avec Event Grid :

Azure Monitor : utiliser les journaux pour résoudre les erreurs de connectivité

Lorsque vous détectez des déconnexions d’appareils, que ce soit avec des alertes de métrique Azure Monitor ou Event Grid, vous pouvez utiliser les journaux pour résoudre le problème. Cette section décrit comment examiner les problèmes courants dans Azure Monitor Logs. Les étapes présentées ici partent du principe que vous avez déjà créé un paramètre de diagnostic pour envoyer les journaux de connexions IoT Hub vers un espace de travail Log Analytics.

Une fois que vous créez un paramètre de diagnostic pour acheminer des journaux de ressources IoT Hub vers les journaux d'activité Azure Monitor, procédez comme suit pour afficher les journaux dans le Portail Azure.

  1. Accédez à IoT hub dans le portail Azure.

  2. Sous Supervision dans le volet gauche d’IoT hub, sélectionnez Journaux.

  3. Pour isoler les journaux d’activité d’erreurs de connectivité pour IoT Hub, entrez la requête suivante dans l’éditeur de requête, puis sélectionnez Exécuter :

    AzureDiagnostics
    | where ( ResourceType == "IOTHUBS" and Category == "Connections" and Level == "Error")
    
  4. Si des résultats s’affichent, recherchez les éléments OperationName, ResultType (code d’erreur) et ResultDescription (message d’erreur) pour obtenir plus de détails.

    Exemple de journal des erreurs

Suivez les guides de résolution des problèmes ci-dessous pour les erreurs les plus courantes :

Azure Monitor : utiliser les journaux pour surveiller la connectivité d’un appareil spécifique

Il se peut que vous souhaitiez utiliser Azure Monitor pour voir les erreurs de connectivité et les informations à propos d’un appareil spécifique. Pour isoler les événements de connectivité d’un appareil, vous pouvez suivre les mêmes étapes que dans la section précédente, mais en entrant la requête suivante. Remplacez test-device par le nom de votre appareil.

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

La requête retourne les événements d’erreur et d’information pour votre appareil cible. L’exemple de sortie suivant montre un événement deviceConnect d’information :

Capture d’écran de l’événement deviceConnect dans les journaux.

Comportement de déconnexion d’appareil MQTT avec les kits de développement logiciel (SDK) Azure IoT

Les kits de développement logiciel (SDK) d’appareil Azure IoT se déconnectent d’IoT Hub puis se reconnectent lorsqu’ils renouvellent les jetons SAS via le protocole MQTT (et MQTT via WebSockets). Dans les journaux, ces informations s’affichent comme des événements de déconnexion et de connexion, parfois accompagnés d’événements d’erreur.

Par défaut, la durée de vie des jetons est de 60 minutes pour tous les kits de développement logiciel (SDK). Toutefois, cette valeur peut être modifiée par les développeurs dans certains SDK. Le tableau suivant résume la durée de vie des jetons, le renouvellement des jetons et le comportement du renouvellement des jetons pour chacun des kits de développement logiciel (SDK) :

Kit SDK Durée de vie des jetons Renouvellement des jetons Comportement du renouvellement
.NET 60 minutes, configurable 85 % de la durée de vie, configurable Le kit de développement logiciel (SDK) se déconnecte et se reconnecte dès la fin de vie du jeton plus une période de grâce de 10 minutes. Événements d’information et erreurs générés dans les journaux.
Java 60 minutes, configurable 85 % de la durée de vie, non configurable Le kit de développement logiciel (SDK) se déconnecte et se reconnecte dès la fin de vie du jeton plus une période de grâce de 10 minutes. Événements d’information et erreurs générés dans les journaux.
Node.js 60 minutes, configurable configurable Le kit de développement logiciel (SDK) se déconnecte et se reconnecte lors du renouvellement du jeton. Seuls les événements d’information sont générés dans les journaux.
Python 60 minutes, configurable 120 secondes avant l’expiration Le kit de développement logiciel (SDK) se déconnecte et se reconnecte pendant la durée de vie des jetons.

Les captures d’écran suivantes montrent le comportement de renouvellement des jetons dans les journaux Azure Monitor pour différents kits de développement logiciel (SDK). La durée de vie et le seuil de renouvellement des jetons ont été modifiés par rapport à leurs valeurs par défaut, comme indiqué.

  • Kit de développement logiciel (SDK) pour appareils .NET avec une durée de vie de jeton de 1200 secondes (20 minutes) et un renouvellement défini à 90 % de sa durée de vie. Les déconnexions se produisent toutes les 30 minutes :

    Comportement d’erreur pour le renouvellement de jetons via MQTT dans Azure Monitor Logs avec le kit de développement logiciel (SDK) .NET.

  • Kit de développement logiciel (SDK) Java avec une durée de vie des jetons de 300 secondes (5 minutes) et un renouvellement par défaut à 85 % de la durée de vie. Les déconnexions se produisent toutes les 15 minutes :

    Comportement d’erreur pour le renouvellement de jetons via MQTT dans Azure Monitor Logs avec le kit de développement logiciel (SDK) Java.

  • Kit de développement logiciel (SDK) Java avec une durée de vie des jetons de 300 secondes (5 minutes) et un renouvellement des jetons défini pour se produire au bout de 3 minutes. Les déconnexions se produisent lors du renouvellement du jeton. Confirmez également qu’il n’y a aucune erreur. Seuls les événements de connexion/déconnexion à caractère informatif sont émis :

    Comportement d’erreur pour le renouvellement de jetons via MQTT dans Azure Monitor Logs avec le kit de développement logiciel (SDK) Node.

La requête suivante a été utilisée pour collecter les résultats. La requête extrait le nom et la version du kit de développement logiciel (SDK) du conteneur de propriétés. Pour en savoir plus, consultez Version du kit de développement logiciel dans les journaux IoT Hub.

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

En tant que développeur ou opérateur de solutions IoT, vous devez être conscient de ce comportement afin d’interpréter les événements de connexion/déconnexion et les erreurs associées consignées dans les journaux. Si vous souhaitez modifier la durée de vie du jeton ou le comportement de renouvellement des appareils, vérifiez que l’appareil implémente un paramètre de jumeau d’appareil ou une méthode d’appareil qui rend ce changement possible.

Si vous analysez des connexions d’appareils d’analyse avec Event Hubs, assurez-vous de générer de façon à filtrer les déconnexions périodiques dues au renouvellement des jetons SAS. Par exemple, ne déclenchez pas d’actions basées sur des déconnexions tant que l’événement de déconnexion est suivi d’un événement de connexion dans un intervalle de temps donné.

Remarque

IoT Hub ne prend en charge qu’une seule connexion MQTT active par appareil. Toute nouvelle connexion MQTT au nom du même ID d’appareil entraîne l’interruption de la connexion existante par IoT Hub.

Le message 400027 ConnectionForcefullyClosedOnNewConnection sera consigné dans les journaux IoT Hub

J’ai suivi les différentes étapes, mais cela n'a pas fonctionné.

Si les étapes ci-dessus n’ont pas permis de résoudre le problème, essayez ce qui suit :

Étapes suivantes