Megosztás a következőn keresztül:


Hibaadatok gyűjtése és értelmezése

Fontos

Ez az Azure Sphere (örökölt) dokumentációja. Az Azure Sphere (örökölt) 2027. szeptember 27-én nyugdíjba vonul, és a felhasználóknak ekkorra az Azure Sphere-be (integrált) kell migrálniuk. Az Azure Sphere (integrált) dokumentációjának megtekintéséhez használja a TOC felett található Verzióválasztót.

A hiba- és eseményadatok naponta feltöltődnek az Azure Sphere Security Service-be. Bárki, aki hozzáfér egy adott bérlőhöz, letöltheti az adott bérlő adatait. A jelentés a bérlő összes eszközét lefedi.

Minden jelentés legfeljebb 1000 eseményt vagy 14 napnyi adatot tartalmaz, attól függően, hogy melyik az első. Az adatok fájlba írhatók, vagy szkriptbe vagy alkalmazásba csövezhetők. A parancssori felület csak 1000 eseményt tud visszaadni. Az Azure Sphere Nyilvános API-val megadhatja az oldalon visszaadott események maximális számát.

A következő módokon töltheti le az eszközöket érintő hibákra és egyéb eseményekre vonatkozó adatokat:

  • Az azsphere-bérlő download-error-report parancsával. A rendszer letölt egy CSV-fájlt, amely információkat tartalmaz az aktuális bérlőn belüli eszközök által jelentett hibákról és eseményekről.

  • Az Azure Sphere Nyilvános API használatával hibajelentést készíthet. Az API-végpont egy JSON-objektumot ad vissza, amelyet igény szerint elemezhet.

Az RTApps nem gyűjt hibajelentési adatokat. Ha az RTApps hibáit szeretné naplózni, magok közötti kommunikációt kell implementálnia az RTApps hibáinak a magas szintű alkalmazás felé való kommunikációhoz, amelyből a hibaadatok naplózhatók a hálózati szolgáltatásokba. Részletekért lásd : Kommunikáció magas szintű alkalmazással és Kommunikáció valós idejű képes alkalmazással .

Elérhető adattípusok

Az egyes hibákhoz vagy eseményekhez visszaadott adatok a következőket tartalmazzák:

Adatok Leírás
Eszközazonosító Az eseményt okozó eszköz azonosítója.
Eseménytípus Az esemény tervezett vagy nem tervezett volt-e. Az operációs rendszer és az alkalmazásfrissítések tervezett eseménynek minősülnek, míg a hibák nem tervezett események.
Eseményosztály Az eseményt okozó szoftverösszetevő: operációs rendszer vagy alkalmazás.
Események száma Az esemény hányszor történt a StartTime és az EndTime által elhatárolt időszakban.
Leírás Információ az eseményről. Ez a mező általános, és az eseménytől és a forrástól függően változik. Alkalmazások esetén tartalmazhat kilépési kódot, jelállapotot és jelkódot, de a mező pontos tartalma nincs rögzítve. Ez információkat tartalmaz az eseményről, és az esemény első előfordulásából származik az időablakban.
Kezdési idő Dátum és idő (UTC-ben), amikor az eseményablak elkezdődött.
Vége Dátum és idő (UTC-ben), amikor az eseményablak véget ért.

A kezdési idő és a befejezési idő azt az időszakot határozza meg, amely alatt az eseményadatok összesítve lesznek. Az összesítő eseménycsoport ablaka legfeljebb 24 óra lehet, és az időablakonként legfeljebb 8 előfordulás lehet.

Alkalmazásesemények

Az alkalmazásesemények közé tartoznak a felhőalapú alkalmazásfrissítések, valamint az összeomlások, a kilépések és más típusú alkalmazáshibák.

Az alkalmazásfrissítések tervezett események. AppUpdate-esemény esetén a Leírás mező tartalmazza a következőt AppUpdate: .

Az alkalmazás összeomlásai, kilépései, indítási hibái és hasonló eseményei nem tervezett események. Nem tervezett esemény esetén a Leírás mező tartalma attól függ, hogy melyik alkalmazás észlelte az eseményt. Az alábbi táblázat felsorolja azokat a mezőket, amelyek egy nem tervezett esemény Leírás mezőjében lehetnek.

Adatok Leírás
exit_status vagy exit_code Az alkalmazás által jelentett kilépési állapot vagy kód.
signal_status Az összeomlás magas szintű okát leíró egész szám, amelyet az operációs rendszer ad vissza. Az állapotok listáját a Man 7 dokumentációjában vagy más Linux-erőforrásokban találja.
signal_code Egész szám, amely a szülőjel állapotán belüli részletes összeomlási állapotot jelzi. Részletekért tekintse meg a Man 7 dokumentációját vagy más Linux-erőforrásokat.
component_id Az összeomlott szoftverösszetevő GUID azonosítója.
image_id A hiba időpontjában futó kép GUID azonosítója.

Az AppCrash leírásában szereplő információk az összeomlás forrásától függenek. A legtöbb összeomlás esetén a leírás a következőhöz hasonlóan néz ki:

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

Bizonyos esetekben az összeomlás további hibaadatokat aktivál, például a következőket, amelyek kiegészítik az előző példában szereplő adatokat:

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)

Adatok Leírás
PC Programszámláló. Az összeomlást kiváltó utasítás címére mutat.
Lr Hivatkozásregisztrálás. Lehetséges, hogy a hívási függvény visszatérési címére mutat.
Sp Veremmutató. A hívásverem tetejére mutat.
signo POSIX-jel. Hibatípust jelez.
errno POSIX errno. Hibát jelez.
code A szülőjel állapotán belüli részletes összeomlási állapotot jelzi.
component_id Az összeomlott szoftverösszetevő GUID azonosítója.
pc_modulename+eltolás A modul neve és az összeomlást okozó kódot tartalmazó modul eltolása.
lr_modulename+eltolás A modul neve és eltolása a modulba, amely lehet a hívó függvény.

AppCrashes értelmezése

Az AppCrash-ről a legtöbb információt megtalálja a signal_status és a signal_code. Tegye a következők egyikét:

  1. A Man 7 dokumentációját használva signal_status, először tekintse meg a "Jel számozása standard jelekhez" feliratú táblázatot. Az x86/ARM oszlopban keresse meg a hibajelentésben csva signal_status hozzárendelt értéket. Miután megtalálta, jegyezze fel a megfelelő jelnevet a bal szélső oszlopban.
  2. Görgessen fel a "Standard Signals" címkével ellátott táblázathoz. Egyezzen a korábban meghatározott jelnévvel, és a táblával további információt gyűjtsön arról, hogy mit jelez a jel.
  3. A Signal_code Man 7 dokumentációjában és a korábban talált jelnévben keresse meg a si_codes megfelelő listáját.
  4. A hibajelentésfájlban csv a signal_code hozzárendelt érték használatával állapítsa meg, hogy melyik kód felel meg a hibaüzenetnek.

Vegyük például a következő AppCrash-leírást:

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

A Man 7 dokumentációja segítségével a következő további információkat fedezheti fel az AppCrash-ről:

  1. A jeleket a Signal man oldal leírásának 10. szakaszában ismertetjük. A 11 érték signal_status egy SIGSEGV-jelnek felel meg.
  2. A SIGSEGV azt jelzi, hogy érvénytelen memóriahivatkozás történt (ez gyakran null mutató lehet).
  3. SI_Codes a SigAction man oldal leírásának 3. szakasza ismerteti az egyes signal_status. Bár a lap nem sorol fel indexszámot az egyes si_code, az 1. indextől kezdve minden signal_status kategóriából számíthat. A SIGSEGV si_codes listájának megtekintésével (az 1. indextől kezdve) láthatja, hogy a harmadik egy SEGV_BNDERR felel meg.
  4. SEGV_BNDERR azt jelzi, hogy sikertelen címkötéses ellenőrzés történt.

Feljegyzés

A gyakran előforduló AppCrash signal_status értéke 9, ami egy SIGKILL-jel, valamint a SEND_SIG_PRIV si_code. Ez az állapot azt jelzi, hogy az operációs rendszer azért ölte meg az alkalmazást, mert túllépte a memóriahasználati korlátját. Az alkalmazás memóriakorlátjairól további információt a memóriahasználat magas szintű alkalmazásokban című témakörben talál.

AppExits értelmezése

Ha egy alkalmazás hiba nélkül kilép, a signal_status és signal_code mezők nem jelennek meg, és exit_status helyett a Leírás tartalmaz egy kilépési kódot:

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

Az AppExits számos okból fordulhat elő, például alkalmazásfrissítés, le nem zárható eszköz vagy a power down API használata miatt. Fontos a kilépési kódok implementálása, hogy betekintést nyerjen az AppExit okaiba.

Az AppExits értelmezéséhez használja a hibajelentés Leírás mezőjének exit_code értékét. Ha az alkalmazás egy kilépési kódot ad vissza, a hibajelentésben szereplő exit_code értékével meghatározhatja, hogy hol vagy mikor történt a hiba. Ezzel az értékkel keressen az alkalmazás kódjában, és ellenőrizze, hogy melyik kilépési kód üzenet felel meg a hibajelentésben megadott értéknek. Ezután keresse meg, hogy az alkalmazás melyik függvénye adta vissza a kilépési kódüzenetet, és miért tette ezt. A visszatérési utasítás és a környezet megtekintésével felfedezheti a hiba okát.

Operációsrendszer-események

A hibaadatok olyan mögöttes operációs rendszert és hardvereseményeket is tartalmaznak, amelyek az alkalmazás meghibásodását vagy újraindítását okozhatják. Az ilyen események közé tartozhatnak a következők:

  • Kernelhibák által okozott nem tervezett eszköz-újraindítások
  • Felhőbeli operációs rendszer frissítései
  • Átmeneti hardverproblémák

Az operációs rendszer eseményei szerepelnek az adatokban, így megállapíthatja, hogy az alkalmazáshibák operációs rendszer- vagy hardverproblémák, vagy az alkalmazással kapcsolatos problémákat tükrözik-e. Ha az eseményadatok azt mutatják, hogy egy eszköz csökkentett módban indult el, előfordulhat, hogy az alkalmazások nem indulnak el.

Hibaadatok feltárása

Ha szkripteket vagy eszközöket tervez fejleszteni a hibaadatok elemzéséhez, de nem rendelkezik nagy számú eszközzel a hibák jelentéséhez, az Azure Sphere-mintaalkalmazásokkal létrehozhat ilyen adatokat teszteléshez. Az Azure Sphere-minták adattárában található oktatóanyagok/ErrorReporting minta bemutatja, hogyan elemezheti az alkalmazás összeomlása esetén jelentett hibákat. Kövesse az olvasási útmutató utasításait a minta Visual Studio, Visual Studio Code vagy parancssor használatával történő létrehozásához.

Ha hibakereső nélkül telepíti az alkalmazást a parancssorból, az operációs rendszer minden sikertelen alkalommal újraindul. A hasonló események összesítése úgy történik, hogy egy gyakran meghibásodott eszköz ne maszkolja a mások hibáit, és a maximális érték időablakonként nyolc előfordulás. A mintát hibakeresés nélkül telepítheti a parancssorból az alábbiak szerint:

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

Hibajelentés létrehozása és letöltése

A hiba- és eseményadatok naponta feltöltődnek az Azure Sphere Security Service-be. Győződjön meg arról, hogy az Azure Sphere-eszköz Wi-Fi vagy Ethernet használatával csatlakozik az internethez az Azure Sphere Security Service-vel való kommunikációhoz.

  1. Futtassa a következő parancsot a jelentés CSV-fájlba való letöltéséhez:

    azsphere tenant download-error-report --destination error.csv
    
  2. Nyissa meg a letöltött CSV-fájlt, és keresse meg az összetevő azonosítóját. A következőhöz hasonló hibaleírásnak kell megjelennie:

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

Az Azure Sphere Nyilvános API-t is használhatja a hibajelentéshez.

Feljegyzés

  • A nemrég jelentett események letöltése akár 24 órát is igénybe vehet.
  • Ha egy esemény vagy hiba történik, mielőtt az eszköz csatlakozik egy NTP-kiszolgálóhoz, az AS3-ba feltöltött telemetriai adatokban szereplő esemény időbélyege helytelen lehet. Ez egy helytelen bejegyzésben jelenik meg az AS3-ból letöltött következő jelentés StartTime oszlopában. Ebben az esetben a jelentés EndTime mezőjével segít megbecsülni, hogy mikor történt az esemény. Ez a mező azt az időt tartalmazza, amikor a felhőszolgáltatások megkapták a feltöltött telemetriát, és mindig érvényes dátummal fognak rendelkezni.

Hibaadatok formázása

A hibajelentésfájl időbélyegei és adatoszlopai a tipikus CSV-fájloktól eltérően vannak formázva. Ha meg szeretné tekinteni az eredményeket az Excelben, új oszlopok létrehozásával és egyéni képletek hozzáadásával újraformálhatja az adatokat.

Az exportált CSV-fájl időbélyegeinek formázása az Excellel való együttműködéshez:

  1. Hozzon létre egy új időbélyegoszlopot, és hozzon létre egy egyéni formátumot:

    yyyy/mm/dd hh:mm:ss

  2. Adja hozzá a következő képletet az új Időbélyeg oszlop celláihoz, és módosítsa az F2 cella értékét úgy, hogy az megfeleljen az oszlopnak és a sornak:

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

Ha a Leírás mezőt külön oszlopokra szeretné felosztani, kövesse az alábbi lépéseket, és módosítsa az F2 cella értékét az oszlopnak és a sornak megfelelően:

  1. Hozzon létre egy rövid vagy hasonló nevű új oszlopot, és adja hozzá a következő képletet a cellákhoz:

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

  2. Hozzon létre olyan oszlopokat, amelyekben a sor1 fejlécek neve megegyezik a paraméterértékekkel, és adja hozzá a következő képletet az egyes oszlopok celláihoz:

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