Dela via


Samla in och tolka feldata

Fel- och händelsedata laddas upp till Azure Sphere-säkerhetstjänsten dagligen. Alla som har åtkomst till en viss katalog kan sedan ladda ned data för katalogen. Rapporten omfattar alla enheter i katalogen.

Varje rapport innehåller högst 1 000 händelser eller 14 dagars data, beroende på vilket som nås först. Data kan skrivas till en fil eller skickas till ett skript eller program. CLI kan bara returnera 1 000 händelser. Använd det offentliga API:et för Azure Sphere för att ange det maximala antalet händelser som returneras på sidan.

Du kan ladda ned data om fel och andra händelser som påverkar dina enheter på följande sätt:

Inga felrapporteringsdata samlas in från RTApps. Om du vill logga fel från RTApps måste du implementera inter-core kommunikation för att kommunicera fel från RTApps till högnivåprogrammet, från vilket feldata kan loggas till nätverkstjänster.

Typer av tillgängliga data

De data som returneras för varje fel eller händelse innehåller följande:

Data Beskrivning
Enhets-ID ID för enheten som påträffade händelsen.
Händelsetyp Om händelsen var planerad eller oplanerad. OS- och appuppdateringar anses vara planerade händelser, medan fel är oplanerade händelser.
Händelseklass Programvarukomponent som påträffade händelsen: OPERATIVSYSTEM eller program.
Antal händelser Antalet gånger händelsen inträffade inom den period som avgränsades av StartTime och EndTime.
Beskrivning Information om händelsen. Det här fältet är allmänt och varierar beroende på händelsen och dess källa. För program kan den innehålla utgångskod, signalstatus och signalkod, men det exakta innehållet i fältet är inte åtgärdat. Det här innehåller information om händelsen och kommer från den första förekomsten av händelsen i tidsintervallet.
Starttid Datum och tid (i UTC) då händelsefönstret började.
Sluttid Datum och tid (i UTC) då händelsefönstret avslutades.

Starttid och sluttid definierar ett tidsintervall under vilket händelsedata aggregeras. Fönstret för en aggregerad grupp med händelser kan vara upp till 24 timmar och maxvärdet är 8 förekomster per tidsintervall.

Programhändelser

Programhändelser inkluderar molninlästa appuppdateringar tillsammans med krascher, utgångar och andra typer av programfel.

Programuppdateringar är planerade händelser. För en AppUpdate-händelse innehåller AppUpdatefältet Beskrivning .

Programkrascher, utgångar, startfel och liknande händelser är oplanerade händelser. För oplanerade händelser beror innehållet i fältet Beskrivning på programmet som påträffade händelsen. I följande tabell visas de fält som kan finnas i fältet Beskrivning för en oplanerad händelse.

Data Beskrivning
exit_status eller exit_code Avsluta status eller kod som rapporterats av programmet.
signal_status Heltal som beskriver orsaken till kraschen på hög nivå, som returneras av operativsystemet. Du hittar en lista över status i dokumentationen för Man 7 eller andra Linux-resurser.
signal_code Heltal som anger detaljerad kraschstatus i den överordnade signalstatusen. Mer information finns i dokumentationen till Man 7 eller andra Linux-resurser.
component_id GUID för programvarukomponenten som kraschade.
image_id GUID för avbildningen som kördes vid tidpunkten för felet.

Den specifika informationen i en AppCrash-beskrivning beror på källan till kraschen. För de flesta kraschar ser beskrivningen ut ungefär så här:

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

I vissa fall utlöser en krasch ytterligare feldata, till exempel följande, som kompletterar data i föregående exempel:

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)

Data Beskrivning
Pc Programräknare. Pekar på adressen för instruktionen som utlöste kraschen.
Lr Länkregister. Pekar eventuellt på avsändaradressen i samtalsfunktionen.
Sp Stackpekare. Pekar högst upp i samtalsstacken.
signo POSIX-signal. Anger feltyp.
Errno POSIX errno. Anger ett fel.
Koden Anger den detaljerade kraschstatusen i den överordnade signalstatusen.
component_id GUID för programvarukomponenten som kraschade.
pc_modulename+förskjutning Namn på modulen och förskjutning i modulen som innehåller koden där kraschen inträffade.
lr_modulename+förskjutning Namn på modulen och förskjutning i modulen som kan ha varit samtalsfunktionen.

Tolka AppCrashes

Du hittar den mesta informationen om en AppCrash i signal_status och signal_code. Följ de här anvisningarna:

  1. Med hjälp av man 7-dokumentationen för signal_status tittar du först på tabellen med etiketten "Signalnumrering för standardsignaler". I kolumnen x86/ARM söker du efter värdet som tilldelats signal_status i felrapporten csv. Observera motsvarande Signalnamn i kolumnen längst till vänster när det hittas.
  2. Rulla upp till tabellen med etiketten "Standardsignaler". Matcha det tidigare fastställda signalnamnet och använd tabellen för att samla in mer information om vad signalen indikerar.
  3. Leta reda på motsvarande lista över si_codes i dokumentationen för man 7 för signal_code och namnet på signalen som du tidigare har hittat.
  4. Använd värdet som tilldelats signal_code i felrapportfilen csv för att avgöra vilken kod som matchar felmeddelandet.

Tänk dig till exempel följande AppCrash-beskrivning:

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

Med hjälp av dokumentationen för Man 7 kan du hitta följande ytterligare information om AppCrash:

  1. Signalerna beskrivs i den 10:e delen av beskrivningen av signalmannens sida. En signal_status av värdet 11 motsvarar en SIGSEGV-signal.
  2. SIGSEGV anger att en ogiltig minnesreferens har inträffat (det kan ofta vara en null-pekare).
  3. SI_Codes beskrivs i det tredje avsnittet i beskrivningen av SigAction man-sidan för varje signal_status. Även om sidan inte innehåller ett indexnummer för varje si_code kan du räkna från varje signal_status kategori med början i index 1. Genom att titta på listan över si_codes för SIGSEGV (med början i index 1) kan du se att den tredje matchar ett SEGV_BNDERR.
  4. SEGV_BNDERR anger att en bunden adresskontroll misslyckades.

Observera

En vanlig AppCrash innehåller en signal_status värdet 9, vilket är en SIGKILL signal, tillsammans med SEND_SIG_PRIV si_code. Den här statusen anger att operativsystemet dödade programmet eftersom det överskred gränsen för minnesanvändning. Mer information om programminnesbegränsningar finns i Minnesanvändning i program på hög nivå.

Tolka AppExits

När en app avslutas utan fel finns inte fälten signal_status och signal_code, och i stället för en exit_status innehåller Beskrivningen en utgångskod:

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

AppExits kan uppstå av flera orsaker, till exempel en programuppdatering, en enhet som tas bort eller användningen av API:t för avstängning, bland annat. Det är viktigt att implementera utgångskoder så att du kan få inblick i orsakerna till en AppExit.

Om du vill tolka AppExits använder du värdet exit_code i fältet Beskrivning i felrapporten. Om appen returnerar en utgångskod kan du använda värdet för exit_code i felrapporten för att avgöra var eller när felet uppstod. Med det här värdet söker du i programkoden för att se vilket meddelande om utgångskod som motsvarar värdet i felrapporten. Leta sedan efter vilken funktion i programmet som returnerade utgångskodsmeddelandet och varför det gjorde det. Genom att visa retursatsen och dess sammanhang kanske du kan hitta orsaken till felet.

OS-händelser

Feldata omfattar också underliggande os- och maskinvaruhändelser som kan påverka ditt program genom att det misslyckas eller startas om. Sådana händelser kan omfatta följande:

  • Oplanerade enhetsomstarter orsakade av kernelfel
  • Uppdateringar för molnoperativsystem
  • Tillfälliga maskinvaruproblem

OS-händelser ingår i data för att hjälpa dig att avgöra om programfel beror på ett OS- eller maskinvaruproblem eller återspegla problem med själva programmet. Om händelsedata visar att en enhet har startats i felsäkert läge kan det hända att dina appar inte kan startas.

Utforska feldata

Om du planerar att utveckla skript eller verktyg för att analysera feldata, men du inte har ett stort antal enheter tillgängliga för att rapportera fel, kan du använda Azure Sphere-exempelprogrammen för att generera sådana data för testning. I exemplet självstudiekurser/felrapportering i azure sphere-exempelrepoen förklaras hur du analyserar fel som rapporterats när programmet kraschar. Följ anvisningarna i viktigt för att skapa exemplet med Visual Studio, Visual Studio-kod eller kommandoraden.

När du distribuerar appen från kommandoraden utan felsökning startar operativsystemet om den varje gång den misslyckas. Liknande händelser aggregeras så att en enhet som ofta misslyckas inte maskerar fel från andra och maximalt åtta förekomster per tidsintervall. Du kan distribuera exemplet från kommandoraden utan felsökning på följande sätt:

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

Generera och ladda ned felrapport

Fel- och händelsedata laddas upp till Azure Sphere-säkerhetstjänsten dagligen. Kontrollera att Azure Sphere-enheten är ansluten till Internet via Wi-Fi eller Ethernet för kommunikation med Azure Sphere-säkerhetstjänsten.

  1. Kör följande kommando för att ladda ned rapporten till en CSV-fil:

    az sphere catalog download-error-report --destination error.csv
    
  2. Öppna den nedladdade CSV-filen och leta efter ditt komponent-ID. Du bör se en felbeskrivning som liknar följande:

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

Du kan också använda azure sphere public API för felrapportering.

Observera

  • Det kan ta upp till 24 timmar innan nyligen rapporterade händelser är tillgängliga för nedladdning.
  • Om en händelse eller ett fel inträffar innan enheten ansluter till en NTP-server kan tidsstämpeln för händelsen som finns i telemetrin som laddats upp till AS3 vara felaktig. Detta återspeglas i en felaktig post i StartTime-kolumnen i den efterföljande rapporten som laddats ned från AS3. I det här fallet använder du fältet EndTime i rapporten för att beräkna när händelsen inträffade. Det här fältet innehåller den tid då molntjänsterna tog emot den uppladdade telemetrin och alltid har ett giltigt datum.

Formatera feldata

Tidsstämplar och datakolumner i felrapportfilen formateras på ett annat sätt än en vanlig CSV-fil. Om du vill visa resultaten i Excel kan du formatera om data genom att skapa nya kolumner och lägga till anpassade formler.

Så här formaterar du tidsstämplarna i den exporterade CSV-filen så att de fungerar med Excel:

  1. Skapa en ny tidsstämpelkolumn och skapa ett anpassat format för den:

    yyyy/mm/dd hh:mm:ss

  2. Lägg till följande formel i cellerna i den nya tidsstämpelkolumnen och ändra värdet för F2-cellen så att det matchar kolumnen och raden:

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

Om du vill dela upp beskrivningsfältet i separata kolumner följer du de här stegen och ändrar cellvärdet F2 så att det matchar kolumnen och raden:

  1. Skapa en ny kolumn med namnet Kortnamn eller något liknande och lägg till följande formel i cellerna:

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

  2. Skapa kolumner där rad1-rubrikerna har samma namn som parametervärdena och lägg till följande formel i cellerna i var och en av kolumnerna:

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