Foutgegevens verzamelen en interpreteren

  • Artikel

Fout- en gebeurtenisgegevens worden dagelijks geüpload naar de Azure Sphere-beveiligingsservice. Iedereen die toegang heeft tot een bepaalde catalogus kan vervolgens de gegevens voor die catalogus downloaden. Het rapport bevat alle apparaten in de catalogus.

Elk rapport bevat maximaal 1000 gebeurtenissen of 14 dagen aan gegevens, afhankelijk van wat het eerst wordt bereikt. Gegevens kunnen worden geschreven naar een bestand of worden doorgesluisd naar een script of toepassing. De CLI kan slechts 1000 gebeurtenissen retourneren. Gebruik de openbare API van Azure Sphere om het maximum aantal gebeurtenissen op te geven dat op de pagina wordt geretourneerd.

U kunt op de volgende manieren gegevens downloaden over de fouten en andere gebeurtenissen die van invloed zijn op uw apparaten:

  • Met behulp van de opdracht az sphere catalog download-error-report . Er wordt een CSV-bestand gedownload met informatie over fouten en gebeurtenissen die zijn gerapporteerd door apparaten in de huidige catalogus.

  • Met behulp van de openbare API van Azure Sphere voor foutrapportage. Het API-eindpunt retourneert een JSON-object dat u kunt parseren op basis van uw behoeften.

Er worden geen foutrapportagegegevens verzameld van RTApps. Als u fouten van RTApps wilt vastleggen, moet u communicatie tussen kernen implementeren om fouten van de RTApps door te geven aan de toepassing op hoog niveau, van waaruit de foutgegevens kunnen worden vastgelegd in netwerkservices.

Beschikbare typen gegevens

De gegevens die voor elke fout of gebeurtenis worden geretourneerd, omvatten het volgende:

Gegevens Beschrijving
Apparaat-id Id van het apparaat waarop de gebeurtenis is opgetreden.
Gebeurtenistype Of de gebeurtenis is gepland of niet-gepland. Updates van het besturingssysteem en de app worden beschouwd als geplande gebeurtenissen, terwijl fouten niet-geplande gebeurtenissen zijn.
Gebeurtenisklasse Softwareonderdeel dat de gebeurtenis heeft aangetroffen: besturingssysteem of toepassing.
Aantal gebeurtenissen Het aantal keren dat de gebeurtenis heeft plaatsgevonden binnen de periode die is gescheiden door StartTime en EndTime.
Beschrijving Informatie over de gebeurtenis. Dit veld is algemeen en varieert afhankelijk van de gebeurtenis en de bron. Voor toepassingen kan het de afsluitcode, signaalstatus en signaalcode bevatten, maar de exacte inhoud van het veld staat niet vast. Deze bevat informatie over de gebeurtenis en is afkomstig van het eerste exemplaar van de gebeurtenis in het tijdvenster.
Begintijd Datum en tijd (in UTC) waarop het gebeurtenisvenster is begonnen.
Eindtijd De datum en tijd (in UTC) waarop het gebeurtenisvenster is beëindigd.

De begintijd en eindtijd definiëren een tijdsperiode waarin gebeurtenisgegevens worden geaggregeerd. Het venster voor een geaggregeerde groep gebeurtenissen kan maximaal 24 uur duren en het maximum is 8 exemplaren per tijdvenster.

Toepassingsevenementen

Toepassingsgebeurtenissen omvatten app-updates in de cloud, samen met crashes, afsluiters en andere soorten toepassingsfouten.

Toepassingsupdates zijn geplande gebeurtenissen. Voor een AppUpdate-gebeurtenis bevat AppUpdatehet veld Beschrijving .

Toepassingscrashes, afsluitingen, opstartfouten en soortgelijke gebeurtenissen zijn niet-geplande gebeurtenissen. Voor een niet-geplande gebeurtenis is de inhoud van het veld Beschrijving afhankelijk van de toepassing die de gebeurtenis heeft aangetroffen. De volgende tabel bevat de velden die mogelijk aanwezig zijn in het veld Beschrijving voor een niet-geplande gebeurtenis.

Gegevens Beschrijving
exit_status of exit_code Afsluitstatus of code die is gerapporteerd door de toepassing.
signal_status Geheel getal dat de reden voor de crash op hoog niveau beschrijft, geretourneerd door het besturingssysteem. U vindt een lijst met statussen in de Man 7-documentatie of andere Linux-resources.
signal_code Geheel getal dat de gedetailleerde crashstatus binnen de status van het bovenliggende signaal aangeeft. Zie de Man 7-documentatie of andere Linux-resources voor meer informatie.
component_id GUID van het softwareonderdeel dat is gecrasht.
image_id GUID van de installatiekopieën die op het moment van de fout worden uitgevoerd.

De specifieke informatie in een AppCrash-beschrijving is afhankelijk van de oorzaak van de crash. Voor de meeste crashes ziet de beschrijving er ongeveer als volgt uit:

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

In sommige gevallen activeert een crash extra foutgegevens, zoals de volgende, die een aanvulling vormt op de gegevens in het vorige voorbeeld:

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)

Gegevens Beschrijving
Pc Programmateller. Verwijst naar het adres van de instructie die de crash heeft geactiveerd.
Lr Koppeling Registreren. Verwijst mogelijk naar het retouradres in de aanroepende functie.
Sp Stack Pointer. Verwijst naar de bovenkant van de aanroepstack.
Signo POSIX-signaal. Geeft het fouttype aan.
errno POSIX errno. Geeft een fout aan.
Code Geeft de gedetailleerde crashstatus aan binnen de status van het bovenliggende signaal.
component_id GUID van het softwareonderdeel dat is gecrasht.
pc_modulename+offset Naam van de module en verschuiving in de module met de code waar de crash is opgetreden.
lr_modulename+offset Naam van de module en verschuiving in de module die mogelijk de aanroepende functie was.

AppCrashes interpreteren

U vindt de meeste informatie over een AppCrash in de signal_status en signal_code. Volg deze stappen:

  1. Gebruik de man 7-documentatie voor signal_status en bekijk eerst de tabel met het label 'Signaalnummering voor standaardsignalen'. Zoek in de kolom x86/ARM naar de waarde die is toegewezen aan de signal_status in het foutenrapport csv. Zodra deze is gevonden, noteert u de bijbehorende signaalnaam in de meest linkse kolom.
  2. Schuif omhoog naar de tabel met het label 'Standaardsignalen'. Overeenkomen met de eerder bepaalde signaalnaam en de tabel gebruiken om meer informatie te verzamelen over wat het signaal aangeeft.
  3. Zoek in de man 7-documentatie voor signal_code en de Signal-naam die u eerder hebt gevonden, de bijbehorende lijst met si_codes.
  4. Gebruik de waarde die is toegewezen aan de signal_code in het foutenrapportbestand csv om te bepalen welke code overeenkomt met het foutbericht.

Denk bijvoorbeeld aan de volgende Beschrijving van AppCrash:

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

Met behulp van de Man 7-documentatie kunt u de volgende aanvullende informatie over de AppCrash ontdekken:

  1. Signalen worden beschreven in de 10e sectie van de beschrijving van de signal man pagina. Een signal_status van waarde 11 komt overeen met een SIGSEGV-signaal.
  2. SIGSEGV geeft aan dat er een ongeldige geheugenreferentie is opgetreden (dit kan vaak een null-aanwijzer zijn).
  3. SI_Codes worden beschreven in de derde sectie van de beschrijving van de SigAction man-pagina voor elke signal_status. Hoewel op de pagina geen indexnummer voor elk si_code wordt weergegeven, kunt u vanaf index 1 vanaf elke signal_status categorie tellen. Als u de lijst met si_codes voor SIGSEGV (beginnend bij index 1) bekijkt, ziet u dat de derde overeenkomt met een SEGV_BNDERR.
  4. SEGV_BNDERR geeft aan dat er een mislukte adresgebonden controle is opgetreden.

Opmerking

Een veelgebruikte AppCrash bevat een signal_status-waarde van 9, wat een SIGKILL-signaal is, samen met de SEND_SIG_PRIV si_code. Deze status geeft aan dat het besturingssysteem de toepassing heeft uitgeschakeld omdat deze de limiet voor geheugengebruik heeft overschreden. Zie Geheugengebruik in toepassingen op hoog niveau voor meer informatie over geheugenlimieten van toepassingen.

AppExits interpreteren

Wanneer een app zonder fouten wordt afgesloten, zijn de velden signal_status en signal_code niet aanwezig en bevat de beschrijving in plaats van een exit_status een afsluitcode:

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

AppExits kunnen een aantal redenen hebben, zoals een toepassingsupdate, een apparaat dat wordt losgekoppeld of het gebruik van de power-down-API, onder andere. Het is belangrijk om afsluitcodes te implementeren, zodat u inzicht krijgt in de redenen voor een AppExit.

Als u AppExits wilt interpreteren, gebruikt u de waarde exit_code in het veld Beschrijving van het foutenrapport. Als uw app een afsluitcode retourneert, kunt u de waarde van de exit_code in het foutenrapport gebruiken om te bepalen waar of wanneer de fout is opgetreden. Gebruik deze waarde om te zoeken in de toepassingscode om te zien welk bericht met de afsluitcode overeenkomt met de waarde in het foutenrapport. Zoek vervolgens welke functie in de toepassing het bericht met de afsluitcode heeft geretourneerd en waarom dit is gedaan. Als u de retourinstructie en de bijbehorende context bekijkt, kunt u mogelijk de reden voor de fout achterhalen.

Gebeurtenissen van het besturingssysteem

Foutgegevens omvatten ook onderliggende gebeurtenissen van het besturingssysteem en hardware die van invloed kunnen zijn op uw toepassing doordat deze mislukt of opnieuw wordt opgestart. Dergelijke gebeurtenissen kunnen het volgende omvatten:

  • Niet-gepland opnieuw opstarten van apparaten veroorzaakt door kernelfouten
  • Updates van cloudbesturingssystemen
  • Tijdelijke hardwareproblemen

Besturingssysteemgebeurtenissen worden opgenomen in de gegevens om u te helpen bepalen of toepassingsfouten het gevolg zijn van een besturingssysteem- of hardwareprobleem of problemen met de toepassing zelf weerspiegelen. Als uit de gebeurtenisgegevens blijkt dat een apparaat is opgestart in de veilige modus, kunnen uw apps mogelijk niet worden gestart.

Foutgegevens verkennen

Als u van plan bent scripts of hulpprogramma's te ontwikkelen voor het analyseren van foutgegevens, maar u niet over een groot aantal apparaten beschikt om fouten te melden, kunt u de Azure Sphere-voorbeeldtoepassingen gebruiken om dergelijke gegevens te genereren voor testen. In het voorbeeld zelfstudies/foutrapportage in de opslagplaats azure Sphere-voorbeelden wordt uitgelegd hoe u fouten analyseert die zijn gerapporteerd wanneer de toepassing vastloopt. Volg de instructies in de leesmij om het voorbeeld te bouwen met behulp van Visual Studio, Visual Studio Code of de opdrachtregel.

Wanneer u de app implementeert vanaf de opdrachtregel zonder een foutopsporingsprogramma, start het besturingssysteem deze telkens opnieuw op wanneer het mislukt. Vergelijkbare gebeurtenissen worden geaggregeerd, zodat het ene apparaat dat vaak mislukt, fouten van anderen niet verhult en het maximum acht exemplaren per tijdvenster is. U kunt het voorbeeld als volgt implementeren vanaf de opdrachtregel zonder foutopsporing:

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

Foutenrapport genereren en downloaden

Fout- en gebeurtenisgegevens worden dagelijks geüpload naar de Azure Sphere-beveiligingsservice. Zorg ervoor dat het Azure Sphere-apparaat is verbonden met internet via Wi-Fi of Ethernet voor communicatie met de Azure Sphere-beveiligingsservice.

  1. Voer de volgende opdracht uit om het rapport te downloaden naar een CSV-bestand:

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

  2. Open het gedownloade CSV-bestand en zoek uw onderdeel-id. Er wordt een foutbeschrijving weergegeven die er ongeveer als volgt uitziet:

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

U kunt ook de openbare API van Azure Sphere gebruiken voor foutrapportage.

Opmerking

  • Het kan tot 24 uur duren voordat onlangs gemelde gebeurtenissen beschikbaar zijn om te downloaden.
  • Als er een gebeurtenis of fout optreedt voordat het apparaat verbinding maakt met een NTP-server, is de tijdstempel voor de gebeurtenis in de telemetrie die is geüpload naar AS3 mogelijk onjuist. Dit wordt weergegeven in een onjuiste vermelding in de kolom StartTime in het volgende rapport dat is gedownload van AS3. In deze situatie kunt u het veld EndTime van het rapport gebruiken om te helpen bij het schatten van het tijdstip waarop de gebeurtenis heeft plaatsgevonden. Dit veld bevat het tijdstip waarop de cloudservices de geüploade telemetrie hebben ontvangen en heeft altijd een geldige datum.

Foutgegevens opmaken

De tijdstempels en gegevenskolommen in het foutenrapportbestand hebben een andere indeling dan een typisch CSV-bestand. Als u de resultaten in Excel wilt weergeven, kunt u de gegevens opnieuw opmaken door nieuwe kolommen te maken en aangepaste formules toe te voegen.

De tijdstempels in het geëxporteerde CSV-bestand opmaken voor gebruik met Excel:

  1. Maak een nieuwe tijdstempelkolom en maak er een aangepaste indeling voor:

    yyyy/mm/dd hh:mm:ss

  2. Voeg de volgende formule toe aan de cellen in de nieuwe kolom Tijdstempel en wijzig de celwaarde F2 zodat deze overeenkomt met uw kolom en rij:

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

Als u het veld Beschrijving wilt opsplitsen in afzonderlijke kolommen, volgt u deze stappen en wijzigt u de celwaarde F2 zodat deze overeenkomt met uw kolom en rij:

  1. Maak een nieuwe kolom met de naam Shortname of iets dergelijks en voeg de volgende formule toe aan de cellen:

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

  2. Maak kolommen waarin de rij1-kopteksten dezelfde namen hebben als de parameterwaarden en voeg de volgende formule toe aan de cellen in elk van de kolommen:

    =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)))