Teilen über

Erfassen und Interpretieren von Fehlerdaten

  • Artikel

Wichtig

Dies ist die Dokumentation zu Azure Sphere (Legacy). Azure Sphere (Legacy) wird am 27. September 2027 eingestellt, und Benutzer müssen bis zu diesem Zeitpunkt zu Azure Sphere (integriert) migrieren. Verwenden Sie die Versionsauswahl oberhalb des Inhaltsverzeichniss, um die Dokumentation zu Azure Sphere (Integriert) anzuzeigen.

Fehler- und Ereignisdaten werden täglich in den Azure Sphere-Sicherheitsdienst hochgeladen. Alle Benutzer, die Zugriff auf einen bestimmten Mandanten haben, können die Daten dann für diesen Mandanten herunterladen. Im Bericht sind alle Geräte des Mandanten abgedeckt.

Jeder Bericht enthält maximal 1.000 Ereignisse oder 14 Tage Daten, je nachdem, was zuerst erreicht wird. Daten können in eine Datei geschrieben oder per Pipezeichen mit einem Skript oder einer Anwendung verknüpft werden. Die CLI kann nur 1.000 Ereignisse zurückgeben. Verwenden Sie die öffentliche Azure Sphere-API, um die maximale Anzahl von Ereignissen anzugeben, die auf der Seite zurückgegeben werden.

Sie können Daten zu den Fehlern und anderen Ereignissen herunterladen, die sich auf Ihre Geräte wie folgt auswirken:

  • Mithilfe des Azsphere-Mandanten-Download-Error-Report-Befehls. Eine CSV-Datei, die Informationen zu Fehlern und Ereignissen enthält, die von Geräten innerhalb des aktuellen Mandanten gemeldet werden, wird heruntergeladen.

  • Mithilfe der öffentlichen Azure Sphere-API für die Fehlerberichterstattung. Der API-Endpunkt gibt ein JSON-Objekt zurück, das Sie entsprechend Ihren Anforderungen analysieren können.

Es werden keine Fehlerberichtsdaten von RTApps gesammelt. Wenn Sie Fehler von RTApps protokollieren möchten, müssen Sie die kernübergreifende Kommunikation implementieren, um Fehler von rtApps an die allgemeine Anwendung zu kommunizieren, von der aus die Fehlerdaten bei Netzwerkdiensten protokolliert werden können. Weitere Informationen finden Sie unter "Kommunizieren mit einer allgemeinen Anwendung " und "Kommunizieren mit einer echtzeitfähigen Anwendung" .

Verfügbare Datentypen

Für jeden Fehler bzw. jedes Ereignis werden beispielsweise die folgenden Daten zurückgegeben:

Daten Beschreibung
Geräte-ID ID des Geräts, für das das Ereignis eingetreten ist.
Ereignistyp Gibt an, ob das Ereignis geplant oder ungeplant war. Betriebssystem- und App-Updates werden als geplante Ereignisse angesehen, während Fehler ungeplante Ereignisse sind.
Ereignisklasse Softwarekomponente, die das Ereignis gefunden hat: Betriebssystem oder Anwendung.
Ereignisanzahl Gibt an, wie oft das Ereignis innerhalb des Zeitraums eingetreten ist, der mit „StartTime“ und „EndTime“ angegeben wird.
Beschreibung Informationen zum Ereignis. Dieses Feld ist generisch und variiert je nach Ereignis und der zugehörigen Quelle. Für Anwendungen kann es den Exitcode, Signalstatus und Signalcode enthalten, aber der genaue Inhalt des Felds ist nicht fest vorgegeben. Dies enthält Informationen zum Ereignis und stammt aus dem ersten Vorkommen des Ereignisses im Zeitfenster.
Startzeit Datum und Uhrzeit (in UTC), um den Beginn des Ereignisfensters anzugeben.
Endzeit Datum und Uhrzeit (in UTC), um das Ende des Ereignisfensters anzugeben.

Mit der Start- und Endzeit wird ein Zeitfenster angegeben, in dem Ereignisdaten aggregiert werden. Das Fenster für jede aggregierte Gruppe von Ereignissen kann bis zu 24 Stunden betragen, und das Maximum beträgt 8 Vorkommen pro Zeitfenster.

Anwendungsereignisse

Anwendungsereignisse können per Cloud geladene App-Updates sowie Abstürze, Beendigungen und andere Arten von Anwendungsfehlern sein.

Anwendungsupdates sind geplante Ereignisse. Für ein AppUpdate-Ereignis enthält das Feld „Beschreibung“ die Zeichenfolge AppUpdate.

Abstürze, Beendigungen, Startfehler und ähnliche Anwendungsereignisse sind ungeplante Ereignisse. Bei einem ungeplanten Ereignis hängt der Inhalt des Felds „Description“ (Beschreibung) von der Anwendung ab, für die das Ereignis eingetreten ist. In der folgenden Tabelle sind die Felder angegeben, die für ein ungeplantes Ereignis im Feld „Description“ (Beschreibung) enthalten sein können.

Daten Beschreibung
„exit_status“ oder „exit_code“ Der Beendigungsstatus oder der Code, der von der Anwendung gemeldet wird.
signal_status Ganze Zahl zur Beschreibung der allgemeinen Absturzursache, die vom Betriebssystem zurückgegeben wird. Eine Liste mit Informationen zum Status finden Sie in der Man 7-Dokumentation oder in anderen Linux-Ressourcen.
signal_code Ganze Zahl, mit der der ausführliche Absturzstatus innerhalb des übergeordneten Signalstatus angegeben wird. Ausführliche Informationen finden Sie in der Man 7-Dokumentation oder anderen Linux-Ressourcen.
component_id GUID der Softwarekomponente, die abgestürzt ist.
image_id GUID des Images, das zum Zeitpunkt des Fehlers ausgeführt wurde.

Die spezifischen Informationen in einer AppCrash-Beschreibung richten sich nach der Quelle des Absturzes. Bei den meisten Abstürzen sieht die Beschreibung in etwa wie folgt aus:

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 einigen Fällen werden bei einem Absturz zusätzliche Fehlerdaten ausgelöst, z. B. (Erweiterung der Daten des vorherigen Beispiels):

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)

Daten Beschreibung
pc Befehlszähler. Verweist auf die Adresse der Anweisung, die den Absturz ausgelöst hat.
lr Linkregister. Verweist möglicherweise auf die Absenderadresse in der aufrufenden Funktion.
sp Stapelzeiger. Zeigt auf den oberen Rand des Aufrufstapels.
signo POSIX-Signal. Gibt den Fehlertyp an.
errno POSIX errno. Gibt einen Fehler an.
code Gibt den detaillierten Absturzstatus innerhalb des übergeordneten Signalstatus an.
component_id GUID der Softwarekomponente, die abgestürzt ist.
pc_modulename+Offset Name des Moduls und Offset in das Modul, das den Code enthält, in dem der Absturz aufgetreten ist.
lr_modulename+Offset Name des Moduls und Offset in das Modul, das möglicherweise die aufrufende Funktion war.

Interpretieren von AppCrashes

Die meisten Informationen zu einem AppCrash finden Sie im signal_status und signal_code. Führen Sie folgende Schritte aus:

  1. Sehen Sie sich in der Man 7-Dokumentation für signal_status zuerst die Tabelle mit der Bezeichnung "Signalnummerierung für Standardsignale" an. Suchen Sie in der Spalte x86/ARM im Fehlerbericht csvnach dem Wert, der dem signal_status zugewiesen ist. Notieren Sie sich den entsprechenden Signalnamen in der spalte ganz links.
  2. Scrollen Sie nach oben zur Tabelle mit der Bezeichnung "Standardsignale". Stimmen Sie mit dem zuvor ermittelten Signalnamen überein, und verwenden Sie die Tabelle, um weitere Informationen darüber zu sammeln, was das Signal angibt.
  3. Suchen Sie in der Man 7-Dokumentation für signal_code und den zuvor gefundenen Signalnamen die entsprechende Liste der si_codes.
  4. Verwenden Sie den Wert, der der signal_code in der Fehlerberichtsdatei csv zugewiesen ist, um zu bestimmen, welcher Code der Fehlermeldung entspricht.

Betrachten Sie beispielsweise die folgende AppCrash-Beschreibung:

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

Mithilfe der Man 7-Dokumentation können Sie die folgenden zusätzlichen Informationen zum AppCrash entdecken:

  1. Signale werden im 10. Abschnitt der Beschreibung der Seite "Signal man" beschrieben. Ein signal_status von Wert 11 entspricht einem SIGSEGV-Signal.
  2. SIGSEGV gibt an, dass ein ungültiger Speicherverweis aufgetreten ist (dies kann häufig ein Nullzeiger sein).
  3. SI_Codes werden im 3. Abschnitt der Beschreibung der SigAction-Man-Seite für jede signal_status beschrieben. Obwohl die Seite keine Indexnummer für jede si_code auflistet, können Sie von jeder signal_status Kategorie ab Index 1 zählen. Wenn Sie sich die Liste der si_codes für SIGSEGV (beginnend bei Index 1) ansehen, können Sie sehen, dass der dritte mit einem SEGV_BNDERR übereinstimmt.
  4. SEGV_BNDERR gibt an, dass eine fehlgeschlagene adressgebundene Überprüfung aufgetreten ist.

Hinweis

Ein häufig auftretender AppCrash enthält einen signal_status Wert von 9, bei dem es sich um ein SIGKILL-Signal zusammen mit dem SEND_SIG_PRIV si_codehandelt. Dieser Status gibt an, dass das Betriebssystem die Anwendung getötet hat, da sie die Speicherauslastungsgrenze überschritten hat. Weitere Informationen zu Anwendungsspeicherbeschränkungen finden Sie unter "Arbeitsspeichernutzung in Anwendungen auf hoher Ebene".

Interpretieren von AppExits

Wenn eine App ohne Fehler beendet wird, sind die Felder „signal_status“ und „signal_code“ nicht vorhanden, und anstelle von „exit_status“ enthält „Description“ einen Exitcode:

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

AppExits können aus einer Reihe von Gründen auftreten, z. B. ein Anwendungsupdate, ein Gerät, das nicht angeschlossen wird, oder die Verwendung der Power Down-API, unter anderem. Es ist wichtig, Exitcodes zu implementieren, damit Sie Einblicke in die Gründe für eine AppExit erhalten können.

Verwenden Sie zum Interpretieren von AppExits den exit_code Wert im Feld "Beschreibung" des Fehlerberichts. Wenn Ihre App einen Ausgangscode zurückgibt, können Sie den Wert der exit_code im Fehlerbericht verwenden, um zu bestimmen, wo oder wann der Fehler aufgetreten ist. Suchen Sie mithilfe dieses Werts im Anwendungscode, um zu sehen, welche Ausgangscodemeldung dem im Fehlerbericht angegebenen Wert entspricht. Suchen Sie dann nach der Funktion in der Anwendung, die die Ausgangscodemeldung zurückgegeben hat, und warum dies der Fehler war. Durch Anzeigen der Rückgabe-Anweisung und des zugehörigen Kontexts können Sie möglicherweise den Grund für den Fehler ermitteln.

Betriebssystemereignisse

Fehlerdaten umfassen auch zugrunde liegende Betriebssystem- und Hardwareereignisse, die sich auf Ihre Anwendung auswirken können, indem Fehler auftreten oder ein Neustart durchgeführt wird. Beispiele für Ereignisse dieser Art sind:

  • Ungeplante Neustarts von Geräten, die durch Kernelfehler verursacht werden
  • Cloud OS-Updates
  • Vorübergehende Hardwareprobleme

Betriebssystemereignisse sind in den Daten enthalten, um festzustellen, ob Anwendungsfehler das Ergebnis eines Betriebssystem- oder Hardwareproblems sind oder Probleme mit der Anwendung selbst widerspiegeln. Falls die Ereignisdaten zeigen, dass ein Gerät im abgesicherten Modus gestartet wurde, können Ihre Apps ggf. nicht gestartet werden.

Untersuchen von Fehlerdaten

Wenn Sie Skripts oder Tools für die Analyse von Fehlerdaten entwickeln möchten, aber keine große Anzahl von Geräten zum Melden von Fehlern zur Verfügung steht, können Sie die Azure Sphere-Beispielanwendungen verwenden, um solche Daten für Tests zu generieren. Das Beispiel "Lernprogramme/ErrorReporting " im Azure Sphere-Beispiel-Repository erläutert, wie Fehler analysiert werden, die gemeldet werden, wenn die Anwendung abstürzt. Folgen Sie den Anweisungen in der Infodatei, um das Beispiel mit Visual Studio, Visual Studio Code oder der Befehlszeile zu erstellen.

Wenn Sie die App über die Befehlszeile ohne Debugger bereitstellen, wird sie vom Betriebssystem bei jedem Fehler neu gestartet. Ähnliche Ereignisse werden aggregiert, sodass ein häufig fehlerhaftes Gerät keine Fehler von anderen maskiert, und die maximale Anzahl von acht Vorkommen pro Zeitfenster beträgt. Sie können das Beispiel über die Befehlszeile ohne Debugging wie folgt bereitstellen:

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

Generieren und Herunterladen des Fehlerberichts

Fehler- und Ereignisdaten werden täglich in den Azure Sphere-Sicherheitsdienst hochgeladen. Stellen Sie sicher, dass das Azure Sphere-Gerät über WLAN oder Ethernet mit dem Internet verbunden ist, um mit dem Azure Sphere Security Service zu kommunizieren.

  1. Führen Sie den folgenden Befehl aus, um den Bericht in eine CSV-Datei herunterzuladen:

    azsphere tenant download-error-report --destination error.csv

  2. Öffnen Sie die heruntergeladene CSV-Datei, und suchen Sie nach Ihrer Komponenten-ID. Die angezeigte Fehlerbeschreibung sollte in etwa wie folgt lauten:

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

Sie können auch die öffentliche Azure Sphere-API für die Fehlerberichterstattung verwenden.

Hinweis

  • Es kann bis zu 24 Stunden dauern, bis kürzlich gemeldete Ereignisse zum Download verfügbar sind.
  • Wenn ein Ereignis oder ein Fehler auftritt, bevor das Gerät eine Verbindung mit einem NTP-Server herstellt, ist der Zeitstempel für das in der Telemetrie hochgeladene Ereignis in AS3 möglicherweise falsch. Dies wird in einem falschen Eintrag in der Spalte "StartTime " im nachfolgenden Bericht widerzuspiegeln, der von AS3 heruntergeladen wurde. Verwenden Sie in dieser Situation das Feld "EndTime " des Berichts, um bei der Schätzung zu helfen, wann das Ereignis aufgetreten ist. Dieses Feld enthält die Uhrzeit, zu der die Clouddienste die hochgeladene Telemetrie erhalten haben und immer ein gültiges Datum haben.

Formatieren von Fehlerdaten

Die Zeitstempel und Datenspalten in der Fehlerberichtdatei sind anders als in einer typischen CSV-Datei formatiert. Wenn Sie die Ergebnisse in Excel anzeigen möchten, können Sie die Daten neu formatieren, indem Sie neue Spalten erstellen und benutzerdefinierte Formeln hinzufügen.

Formatieren Sie die Zeitstempel in der exportierten CSV-Datei für die Verwendung mit Excel wie folgt:

  1. Erstellen Sie eine neue Spalte „Timestamp“ (Zeitstempel), und erstellen Sie dafür ein benutzerdefiniertes Format:

    yyyy/mm/dd hh:mm:ss

  2. Fügen Sie den Zellen in der neuen Spalte „Timestamp“ die folgende Formel hinzu, indem Sie den Wert der Zelle F2 an Ihre Spalte und Zeile anpassen:

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

Führen Sie zum Unterteilen des Felds „Description“ in separate Spalten die folgenden Schritte aus, indem Sie den Wert der Zelle F2 an Ihre Spalte und Zeile anpassen:

  1. Erstellen Sie eine neue Spalte mit dem Namen „Shortname“ oder einer ähnlichen Bezeichnung, und fügen Sie den Zellen die folgende Formel hinzu:

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

  2. Erstellen Sie Spalten, in denen die row1-Header die gleichen Namen wie die Parameterwerte aufweisen, und fügen Sie den Zellen in den einzelnen Spalten die folgende Formel hinzu:

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