Collecter et interpréter des données d’erreur
Important
Il s’agit de la documentation Azure Sphere (héritée). Azure Sphere (hérité) prend sa retraite le 27 septembre 2027 et les utilisateurs doivent migrer vers Azure Sphere (intégré) pour l’instant. Utilisez le sélecteur de version situé au-dessus du TOC pour afficher la documentation Azure Sphere (intégrée).
Les données d’erreur et d’événement sont chargées quotidiennement vers 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 se trouvant dans le 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 dirigé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 d’autres événements qui affectent vos appareils de la manière suivante :
À 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 des erreurs entre les applications RTApps à l’application de haut niveau, à partir de laquelle les données d’erreur peuvent être journalisées dans les services réseau. Pour plus d’informations, consultez Communiquer avec une application de haut niveau et Communiquer avec une application compatible 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 de périphérique | ID de l’appareil qui a rencontré l’événement. |
| Type d’événement | Indique si l’événement était planifié ou non. Les mises à jour du système d’exploitation et des applications sont considérées comme des événements planifiés, alors 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 dans 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 du signal, mais le contenu exact du champ n’est pas fixe. Cela 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 (au format UTC) auxquelles la fenêtre d’événement a commencé. |
| Heure de fin | Date et heure (au format UTC) auxquelles la fenêtre d’événement s’est arrêtée. |
Les valeurs Heure de début et 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 atteindre 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 les mises à jour d’applications chargées par le cloud, ainsi que les plantages, 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 (mise à jour d’application), le champ Description contient AppUpdate.
Les plantages 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 liste 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 ou code de sortie signalé par l’application. |
| signal_status | Entier qui décrit le motif général du plantage, 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 l’état détaillé des plantages 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 a subi un plantage. |
| image_id | GUID de l’image qui s’exécutait au moment de l’erreur. |
Les informations spécifiques figurant dans une description d’AppCrash dépendent de la source du plantage. Pour la plupart des plantages, 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 plantage déclenche des données d’erreur supplémentaires, semblable à ce qui suit, 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é le blocage. |
| lr | S’inscrire. Pointe peut-être 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’incident détaillé dans l’état du signal parent. |
| component_id | GUID du composant logiciel qui a subi un plantage. |
| pc_modulename+offset | Nom du module et offset dans le module contenant le code où l’incident s’est produit. |
| lr_modulename+offset | Nom du module et offset dans le module qui a peut-être été la fonction appelante. |
Interpréter AppCrashes
Vous trouverez la plupart des informations sur appCrash dans le signal_status et signal_code. Effectuez les étapes suivantes :
- À l’aide de la documentation Man 7 pour signal_status, consultez d’abord la table intitulée « 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 de signal correspondant dans la colonne la plus à gauche. - Faites défiler jusqu’à la table intitulée « Signaux standard ». Correspondez au nom du signal déterminé précédemment et utilisez la table pour collecter plus d’informations sur ce que le signal indique.
- Dans la documentation Man 7 pour signal_code et le nom signal que vous avez trouvé précédemment, recherchez la liste correspondante de si_codes.
- Utilisez la valeur affectée au signal_code dans le fichier de rapport
csvd’erreurs pour déterminer le code correspondant 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 :
- Les signaux sont décrits dans la 10e section de la description de la page de l’homme Signal. Une signal_status de la valeur 11 correspond à un signal SIGSEGV.
- SIGSEGV indique qu’une référence de mémoire non valide s’est produite (il peut souvent s’agir d’un pointeur Null).
- SI_Codes sont décrits dans la 3ème section de la description de la page de l’homme 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 de chaque catégorie signal_status commençant à 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.
- SEGV_BNDERR indique qu’une vérification liée à l’adresse a échoué s’est produite.
Remarque
Un AppCrash couramment rencontré comprend une valeur de 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 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 de haut niveau.
Interpréter AppExits
Quand une application se ferme sans erreur, les champs signal_status et signal_code ne sont pas présents et, à la place d’une valeur exit_status, le champ 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 plusieurs raisons, telles qu’une mise à jour d’application, un appareil déconnecté ou l’utilisation de l’API de mise hors tension, entre autres. Il est important d’implémenter des codes de sortie pour vous permettre d’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’erreur. 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, recherchez 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 return et son contexte, vous pourrez peut-être découvrir la raison de l’erreur.
Événements du système d’exploitation
Les données d’erreur incluent également des événements matériels et du système d’exploitation sous-jacents qui peuvent avoir un impact sur votre application en provoquant son échec ou son redémarrage. Ces événements peuvent inclure les suivants :
- Redémarrages non planifiés de l’appareil 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, il est possible que vos applications ne puissent pas 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 ne disposez pas d’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 lorsque l’application se bloque. 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.
Quand 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. Des événements similaires sont agrégés afin qu’un appareil fréquemment défaillant 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 vers le service de sécurité Azure Sphere. Assurez-vous que l’appareil Azure Sphere est connecté à Internet à l’aide du Wi-Fi ou ethernet pour communiquer avec le service de sécurité Azure Sphere.
Exécutez la commande suivante pour télécharger le rapport dans un fichier CSV :
azsphere tenant download-error-report --destination error.csvOuvrez le fichier CSV téléchargé et recherchez votre ID de composant. Vous devriez voir une description d’erreur semblable à 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.
Remarque
- 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 la télémétrie chargée sur AS3 peut être incorrect. Cela sera reflété dans une entrée incorrecte dans la colonne StartTime dans le 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 auront toujours une date valide.
Mettre en forme des données d’erreur
Les horodatages et les colonnes de données du fichier de rapport d’erreurs ne sont pas mis en forme comme dans un fichier CSV standard. Si vous voulez voir les résultats dans Excel, vous pouvez remettre en forme 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é en vue d’utiliser Excel :
Créez une nouvelle colonne d’horodatages (Timestamp), puis créez un format personnalisé pour celle-ci :
yyyy/mm/dd hh:mm:ssAjoutez la formule suivante aux cellules de la nouvelle colonne d’horodatages, en changeant la valeur de la 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, effectuez les étapes suivantes, en changeant la valeur de la cellule F2 pour qu’elle corresponde à votre colonne et à votre ligne :
Créez une colonne nommée ShortName ou avec un nom similaire, puis ajoutez la formule suivante aux cellules :
=TRIM(LEFT(F2,FIND("(",F2)-1))Créez des colonnes dans lesquelles les en-têtes row1 (ligne1) portent les mêmes noms que les valeurs de paramètres, puis 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)))