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

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

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 rediriagé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 azsphere tenant download-error-report . Un fichier CSV contenant des informations sur les erreurs et les événements signalés par les appareils au sein du locataire actuel est téléchargé.

  • En utilisant l’API publique Azure Sphere pour la création de rapports 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 consigner des erreurs à partir de RTApps, vous devez implémenter des communications inter-cœurs pour communiquer les erreurs de l’application RTApps à l’application générale, à partir de laquelle les données d’erreur peuvent être consignées dans les services réseau. Pour plus d’informations, consultez Communiquer avec une application de haut niveau et Communiquer avec une application en temps réel .

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 d’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 au cours de 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, l’état du 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 date de la première occurrence de l’événement dans la fenêtre de temps.
Heure de début Date et heure (en UTC) auxquelles la fenêtre d’événement a commencé.
Heure de fin Date et heure (en 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 d’un groupe agrégé d’événements peut être jusqu’à 24 heures et la valeur maximale est de 8 occurrences par fenêtre de temps.

Événements d’application

Les événements d’application incluent des mises à jour d’application chargées dans le cloud, ainsi que des incidents, des sorties et d’autres types de défaillances 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 État de sortie ou 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 une liste d’états dans la documentation Man 7 ou d’autres ressources Linux.
signal_code Entier qui indique l’état détaillé de l’incident dans l’état 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 écrasé.
image_id GUID de l’image qui s’exécutait au moment de l’erreur.

Les informations spécifiques d’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 programme. 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 l’état détaillé de l’incident dans l’état du signal parent.
component_id GUID du composant logiciel qui s’est écrasé.
pc_modulename+offset Nom du module et décalage dans le module contenant le code dans lequel l’incident s’est produit.
lr_modulename+offset Nom du module et décalage dans le module qui peut avoir été la fonction appelante.

Interpréter AppCrashes

Vous trouverez la plupart des informations sur appCrash dans les signal_status et les 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 pour les 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 la table 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 de 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.

Prenons l’exemple de 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. 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 s’agir souvent d’un pointeur null).
  3. 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’une vérification de l’adresse liée a échoué.

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. Cet état indique que le système d’exploitation a tué l’application, car elle a dépassé sa limite d’utilisation de la mémoire. Pour en savoir plus sur les limites de mémoire des applications, consultez l’utilisation de la mémoire dans les applications de haut niveau.

Interpréter AppExits

Lorsqu’une application se termine 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)

AppExits peut se produire pour un certain nombre de raisons, telles qu’une mise à jour d’application, un appareil en cours de débranché 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ù ou quand l’erreur s’est produite. À l’aide de cette valeur, effectuez une recherche dans le code de l’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 de retour et son contexte, vous pouvez découvrir la raison de l’erreur.

Événements du système d’exploitation

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

  • Redémarrages d’appareils non planifiés provoqué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 avec 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 l’analyse des 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 du référentiel d’exemples Azure Sphere explique comment analyser les erreurs signalées lorsque l’application se bloque. Suivez les instructions du lisez-moi pour générer l’exemple à l’aide de Visual Studio, de 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’elle é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 :

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

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

Les données d’erreur et d’événement sont 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 :

    azsphere tenant 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 à ce qui suit :

    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 la création de rapports 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 ne 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 faciliter l’estimation du moment où 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.

Mettre en forme les données d’erreur

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

Pour mettre en forme les horodatages du 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 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 la 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)))