Partager via

Collecter et interpréter les données d’erreur

  • Article

Les données d’erreur et d’événement sont téléchargées quotidiennement dans le service de sécurité Azure Sphere. Toute personne ayant accès à un catalogue particulier peut alors télécharger les données de ce catalogue. Le rapport couvre tous les appareils du catalogue.

Chaque rapport contient un maximum de 1 000 événements ou 14 jours de données, selon ce qui est atteint en premier. Les données peuvent être écrites dans un fichier ou redirigées vers un script ou une application. L’interface CLI ne peut retourner que 1 000 événements. Utilisez l’API publique Azure Sphere pour spécifier le nombre maximal d’événements retournés sur la page.

Vous pouvez télécharger des données sur les erreurs et autres événements qui affectent vos appareils des manières suivantes :

  • À l’aide de la commande az sphere catalog download-error-report . Un fichier CSV contenant des informations sur les erreurs et les événements signalés par les appareils du catalogue actuel est téléchargé.

  • En utilisant l’API publique Azure Sphere pour le rapport d’erreurs. Le point de terminaison d’API retourne un objet JSON que vous pouvez analyser en fonction de vos besoins.

Aucune donnée de rapport d’erreurs n’est collectée à partir de RTApps. Si vous souhaitez journaliser les erreurs à partir des applications en temps réel, vous devez implémenter des communications intercœurs pour communiquer les erreurs des rtApps à l’application de haut niveau, à partir de laquelle les données d’erreur peuvent être consignées aux services réseau.

Types de données disponibles

Les données retournées pour chaque erreur ou événement incluent les éléments suivants :

Données Description
ID de l’appareil ID de l’appareil qui a rencontré l’événement.
Type d’événement Indique si l’événement a été planifié ou non planifié. Les mises à jour du système d’exploitation et des applications sont considérées comme des événements planifiés, tandis que les erreurs sont des événements non planifiés.
Classe d’événements Composant logiciel qui a rencontré l’événement : système d’exploitation ou application.
Nombre d’événements Nombre de fois où l’événement s’est produit pendant la période délimitée par StartTime et EndTime.
Description Informations sur l’événement. Ce champ est générique et varie en fonction de l’événement et de sa source. Pour les applications, il peut contenir le code de sortie, le status de signal et le code de signal, mais le contenu exact du champ n’est pas fixe. Il contient des informations sur l’événement et provient de la première occurrence de l’événement dans la fenêtre de temps.
Heure de début Date et heure (utc) à laquelle la fenêtre d’événement a commencé.
Heure de fin Date et heure (utc) à laquelle la fenêtre d’événement s’est terminée.

L’heure de début et l’heure de fin définissent une fenêtre de temps pendant laquelle les données d’événement sont agrégées. La fenêtre de n’importe quel groupe agrégé d’événements peut durer jusqu’à 24 heures et le maximum est de 8 occurrences par fenêtre de temps.

Événements d’application

Les événements d’application incluent les mises à jour d’applications chargées dans le cloud, ainsi que les incidents, les sorties et d’autres types d’échecs d’application.

Les mises à jour d’application sont des événements planifiés. Pour un événement AppUpdate, le champ Description contient AppUpdate.

Les incidents d’application, les sorties, les échecs de démarrage et les événements similaires sont des événements non planifiés. Pour un événement non planifié, le contenu du champ Description dépend de l’application qui a rencontré l’événement. Le tableau suivant répertorie les champs qui peuvent être présents dans le champ Description pour un événement non planifié.

Données Description
exit_status ou exit_code Quittez status ou le code signalé par l’application.
signal_status Entier qui décrit la raison générale de l’incident, retourné par le système d’exploitation. Vous trouverez la liste des états dans la documentation Man 7 ou dans d’autres ressources Linux.
signal_code Entier qui indique le status d’incident détaillé dans le status du signal parent. Pour plus d’informations, consultez la documentation Man 7 ou d’autres ressources Linux.
component_id GUID du composant logiciel qui s’est bloqué.
image_id GUID de l’image en cours d’exécution au moment de l’erreur.

Les informations spécifiques dans une description AppCrash dépendent de la source de l’incident. Pour la plupart des incidents, la description ressemble à ce qui suit :

AppCrash (exit_status=11; signal_status=11; signal_code=3; component_id=685f13af-25a5-40b2-8dd8-8cbc253ecbd8; image_id=7053e7b3-d2bb-431f-8d3a-173f52db9675)

Dans certains cas, un incident déclenche des données d’erreur supplémentaires, telles que les suivantes, qui complètent les données de l’exemple précédent :

AppCrash (pc=BEEED2EE; lr=BEEED2E5; sp=BEFFDE58; signo=11; errno=0; code=0; component_id=685f13af-25a5-40b2-8dd8-8cbc253ecbd8; pc_modulename+offset=appname+80000; lr_modulename+offset=app+100CC)

Données Description
Pc Compteur de programmes. Pointe vers l’adresse de l’instruction qui a déclenché l’incident.
Lr Registre de liens. Pointe éventuellement vers l’adresse de retour dans la fonction appelante.
Sp Pointeur de pile. Pointe vers le haut de la pile des appels.
Signo Signal POSIX. Indique le type d’erreur.
Errno POSIX errno. Indique une erreur.
Code Indique le status de plantage détaillé dans le status du signal parent.
component_id GUID du composant logiciel qui s’est bloqué.
pc_modulename+décalage Nom du module et décalage dans le module contenant le code où l’incident s’est produit.
lr_modulename+décalage Nom du module et décalage dans le module qui aurait pu être la fonction appelante.

Interpréter appCrashes

Vous trouverez la plupart des informations sur un AppCrash dans les signal_status et signal_code. Procédez comme suit :

  1. À l’aide de la documentation Man 7 pour signal_status, examinez d’abord le tableau intitulé « Numérotation des signaux standard ». Dans la colonne x86/ARM, recherchez la valeur affectée au signal_status dans le rapport csvd’erreurs . Une fois trouvé, notez le nom du signal correspondant dans la colonne la plus à gauche.
  2. Faites défiler jusqu’à la table intitulée « Signaux standard ». Faites correspondre le nom du signal précédemment déterminé et utilisez le tableau pour collecter plus d’informations sur ce que le signal indique.
  3. Dans la documentation Man 7 pour signal_code et le nom du signal que vous avez trouvé précédemment, recherchez la liste correspondante des si_codes.
  4. Utilisez la valeur affectée au signal_code dans le fichier de rapport csv d’erreurs pour déterminer quel code correspond au message d’erreur.

Par exemple, considérez la description AppCrash suivante :

AppCrash (exit_status=11; signal_status=11; signal_code=3; component_id=685f13af-25a5-40b2-8dd8-8cbc253ecbd8; image_id=7053e7b3-d2bb-431f-8d3a-173f52db9675)

À l’aide de la documentation Man 7, vous pouvez découvrir les informations supplémentaires suivantes sur AppCrash :

  1. Les signaux sont décrits dans la 10e section de la description de la page Man Signal. Une signal_status de valeur 11 correspond à un signal SIGSEGV.
  2. SIGSEGV indique qu’une référence de mémoire non valide s’est produite (il peut souvent s’agir d’un pointeur null).
  3. SI_Codes sont décrits dans la 3e section de la description de la page man SigAction pour chaque signal_status. Bien que la page ne répertorie pas de numéro d’index pour chaque si_code, vous pouvez compter à partir de chaque signal_status catégorie à partir de l’index 1. En examinant la liste des si_codes pour SIGSEGV (à partir de l’index 1), vous pouvez voir que le troisième correspond à un SEGV_BNDERR.
  4. SEGV_BNDERR indique qu’un échec de case activée lié à l’adresse s’est produit.

Note

Un AppCrash couramment rencontré inclut une valeur signal_status de 9, qui est un signal SIGKILL, ainsi que le SEND_SIG_PRIV si_code. Cette status indique que le système d’exploitation a tué l’application parce qu’il a dépassé sa limite d’utilisation de la mémoire. Pour en savoir plus sur les limites de mémoire des applications, consultez Utilisation de la mémoire dans les applications générales.

Interpréter AppExits

Lorsqu’une application se ferme sans erreur, les champs signal_status et signal_code ne sont pas présents, et au lieu d’une exit_status, la description contient un code de sortie :

AppExit (exit_code=0; component_id=685f13af-25a5-40b2-8dd8-8cbc253ecbd8; image_id=0a7cc3a2-f7c2-4478-8b02-723c1c6a85cd)

Les appExits peuvent se produire pour plusieurs raisons, telles qu’une mise à jour d’application, un appareil en cours de débranchement ou l’utilisation de l’API de mise hors tension, entre autres. Il est important d’implémenter des codes de sortie afin de pouvoir obtenir des informations sur les raisons d’un AppExit.

Pour interpréter AppExits, utilisez la valeur exit_code dans le champ Description du rapport d’erreurs. Si votre application retourne un code de sortie, vous pouvez utiliser la valeur du exit_code dans le rapport d’erreurs pour déterminer où et quand l’erreur s’est produite. À l’aide de cette valeur, effectuez une recherche dans le code d’application pour voir quel message de code de sortie correspond à la valeur fournie dans le rapport d’erreurs. Ensuite, recherchez la fonction dans l’application qui a retourné le message de code de sortie et pourquoi elle l’a fait. En affichant l’instruction return et son contexte, vous pouvez découvrir la raison de l’erreur.

Événements de système d’exploitation

Les données d’erreur incluent également des événements matériels et de système d’exploitation sous-jacents susceptibles d’avoir un impact sur votre application en la provoquant en cas d’échec ou de redémarrage. Ces événements peuvent inclure les éléments suivants :

  • Redémarrages d’appareils non planifiés causés par des erreurs de noyau
  • Mises à jour du système d’exploitation cloud
  • Problèmes matériels temporaires

Les événements de système d’exploitation sont inclus dans les données pour vous aider à déterminer si les erreurs d’application sont le résultat d’un problème de système d’exploitation ou de matériel ou reflètent des problèmes liés à l’application elle-même. Si les données d’événement indiquent qu’un appareil a démarré en mode sans échec, vos applications risquent de ne pas pouvoir démarrer.

Explorer les données d’erreur

Si vous envisagez de développer des scripts ou des outils pour analyser les données d’erreur, mais que vous n’avez pas un grand nombre d’appareils disponibles pour signaler des erreurs, vous pouvez utiliser les exemples d’applications Azure Sphere pour générer ces données à des fins de test. L’exemple Tutorials/ErrorReporting dans le référentiel d’exemples Azure Sphere explique comment analyser les erreurs signalées en cas de blocage de l’application. Suivez les instructions du fichier lisez-moi pour générer l’exemple à l’aide de Visual Studio, Visual Studio Code ou de la ligne de commande.

Lorsque vous déployez l’application à partir de la ligne de commande sans débogueur, le système d’exploitation la redémarre chaque fois qu’il échoue. Les événements similaires sont agrégés de sorte qu’un appareil qui échoue fréquemment ne masque pas les erreurs des autres et que le maximum est de huit occurrences par fenêtre de temps. Vous pouvez déployer l’exemple à partir de la ligne de commande sans débogage, comme suit :

az sphere device sideload deploy --image-package <path to image package for the app>

Générer et télécharger un rapport d’erreurs

Les données d’erreur et d’événement sont téléchargées quotidiennement dans le service de sécurité Azure Sphere. Assurez-vous que l’appareil Azure Sphere est connecté à Internet à l’aide du Wi-Fi ou d’Ethernet pour communiquer avec le service de sécurité Azure Sphere.

  1. Exécutez la commande suivante pour télécharger le rapport dans un fichier CSV :

    az sphere catalog download-error-report --destination error.csv

  2. Ouvrez le fichier CSV téléchargé et recherchez votre ID de composant. Vous devez voir une description d’erreur similaire à la suivante :

    AppExit (exit_code=0; component_id=685f13af-25a5-40b2-8dd8-8cbc253ecbd8; image_id=6d2646aa-c0ce-4e55-b7d6-7c206a7a6363)

Vous pouvez également utiliser l’API publique Azure Sphere pour le rapport d’erreurs.

Note

  • Le téléchargement des événements récemment signalés peut prendre jusqu’à 24 heures.
  • Si un événement ou une erreur se produit avant que l’appareil se connecte à un serveur NTP, l’horodatage de l’événement contenu dans les données de télémétrie chargées sur AS3 peut être incorrect. Cela se reflète dans une entrée incorrecte dans la colonne StartTime du rapport suivant téléchargé à partir d’AS3. Dans ce cas, utilisez le champ EndTime du rapport pour vous aider à estimer quand l’événement s’est produit. Ce champ contient l’heure à laquelle les services cloud ont reçu les données de télémétrie chargées et aura toujours une date valide.

Données d’erreur de mise en forme

Les horodatages et les colonnes de données du fichier de rapport d’erreurs sont mis en forme différemment d’un fichier CSV classique. Si vous souhaitez afficher les résultats dans Excel, vous pouvez reformater les données en créant de nouvelles colonnes et en ajoutant des formules personnalisées.

Pour mettre en forme les horodatages dans le fichier CSV exporté pour qu’ils fonctionnent avec Excel :

  1. Créez une colonne Timestamp et créez un format personnalisé pour celle-ci :

    yyyy/mm/dd hh:mm:ss

  2. Ajoutez la formule suivante aux cellules de la nouvelle colonne Timestamp, en modifiant la valeur de cellule F2 pour qu’elle corresponde à votre colonne et à votre ligne :

    =(DATEVALUE(LEFT(RawErrorReport!F2,10))+TIMEVALUE(RIGHT(RawErrorReport!F2,8)))

Pour fractionner le champ Description en colonnes distinctes, procédez comme suit, en modifiant la valeur de cellule F2 pour qu’elle corresponde à votre colonne et à votre ligne :

  1. Créez une colonne nommée Shortname ou quelque chose de similaire, puis ajoutez la formule suivante aux cellules :

    =TRIM(LEFT(F2,FIND("(",F2)-1))

  2. Créez des colonnes dans lesquelles les en-têtes row1 ont les mêmes noms que les valeurs de paramètre et ajoutez la formule suivante aux cellules de chacune des colonnes :

    =IF(ISERROR(FIND("; " & H$1 & "=", SUBSTITUTE($F2,"(","; "))), "", MID($F2, FIND("; " & H$1 & "=", SUBSTITUTE($F2,"(","; ")) + (LEN(H$1) + 2), FIND("; ", SUBSTITUTE($F2,")","; "), FIND("; " & H$1 & "=", SUBSTITUTE($F2,"(","; "))) - FIND("; " & H$1 & "=", SUBSTITUTE($F2,"(","; ")) - (LEN(H$1) + 2)))