Sammeln und Interpretieren von Fehlerdaten
Fehler- und Ereignisdaten werden täglich in den Azure Sphere-Sicherheitsdienst hochgeladen. Jeder, der Zugriff auf einen bestimmten Katalog hat, kann dann die Daten für diesen Katalog herunterladen. Der Bericht deckt alle Geräte im Katalog ab.
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 an ein Skript oder eine Anwendung weitergeleitet 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, die sich auf Ihre Geräte auswirken, wie folgt herunterladen:
Mithilfe des Befehls az sphere catalog download-error-report . Eine CSV-Datei mit Informationen zu Fehlern und Ereignissen, die von Geräten im aktuellen Katalog 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 nach Ihren Anforderungen analysieren können.
Es werden keine Fehlerberichtsdaten von RTApps gesammelt. Wenn Sie Fehler von RTApps protokollieren möchten, müssen Sie kernübergreifende Kommunikation implementieren, um Fehler von den RTApps an die allgemeine Anwendung zu übermitteln, von der aus die Fehlerdaten in Netzwerkdiensten protokolliert werden können.
Verfügbare Datentypen
Die für jeden Fehler oder jedes Ereignis zurückgegebenen Daten umfassen Folgendes:
| Daten | Beschreibung |
|---|---|
| Geräte-ID | ID des Geräts, auf dem das Ereignis aufgetreten ist. |
| Ereignistyp | Gibt an, ob das Ereignis geplant oder ungeplant war. Betriebssystem- und App-Updates werden als geplante Ereignisse betrachtet, während Fehler ungeplante Ereignisse sind. |
| Ereignisklasse | Softwarekomponente, bei der das Ereignis aufgetreten ist: Betriebssystem oder Anwendung. |
| Ereignisanzahl | Die Häufigkeit, mit der das Ereignis innerhalb des durch StartTime und EndTime getrennten Zeitraums aufgetreten ist. |
| Beschreibung | Informationen zum Ereignis. Dieses Feld ist generisch und variiert je nach Ereignis und Quelle. Bei Anwendungen kann es den Exitcode, die Signal-status und den Signalcode enthalten, aber der genaue Inhalt des Felds ist nicht festgelegt. Diese enthält Informationen zum Ereignis und stammt aus dem ersten Vorkommen des Ereignisses im Zeitfenster. |
| Startzeit | Datum und Uhrzeit (in UTC), an dem das Ereignisfenster begonnen hat. |
| Endzeit | Datum und Uhrzeit (in UTC), zu dem das Ereignisfenster beendet wurde. |
Startzeit und Endzeit definieren ein Zeitfenster, in dem Ereignisdaten aggregiert werden. Das Fenster für eine aggregierte Gruppe von Ereignissen kann bis zu 24 Stunden und maximal 8 Vorkommen pro Zeitfenster betragen.
Anwendungsereignisse
Anwendungsereignisse umfassen in die Cloud geladene App-Updates sowie Abstürze, Exits und andere Arten von Anwendungsfehlern.
Anwendungsupdates sind geplante Ereignisse. Für ein AppUpdate-Ereignis enthält AppUpdatedas Feld Beschreibung .
Anwendungsabstürze, Beendigungen, Startfehler und ähnliche Ereignisse sind ungeplante Ereignisse. Bei einem ungeplanten Ereignis hängt der Inhalt des Felds Beschreibung von der Anwendung ab, bei der das Ereignis aufgetreten ist. In der folgenden Tabelle sind die Felder aufgeführt, die im Feld Beschreibung für ein ungeplantes Ereignis vorhanden sein können.
| Daten | Beschreibung |
|---|---|
| exit_status oder exit_code | Beenden Sie status von der Anwendung gemeldeten Code. |
| signal_status | Ganze Zahl, die den allgemeinen Grund für den Absturz beschreibt, der vom Betriebssystem zurückgegeben wird. Eine Liste der Status finden Sie in der Man 7-Dokumentation oder in anderen Linux-Ressourcen. |
| signal_code | Ganze Zahl, die den detaillierten Absturz status innerhalb des übergeordneten Signals status angibt. Weitere Informationen finden Sie in der Man 7-Dokumentation oder in anderen Linux-Ressourcen. |
| component_id | GUID der abgestürzten Softwarekomponente. |
| image_id | GUID des Images, das zum Zeitpunkt des Fehlers ausgeführt wurde. |
Die spezifischen Informationen in einer AppCrash-Beschreibung hängen von der Quelle des Absturzes ab. 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 löst ein Absturz zusätzliche Fehlerdaten aus, z. B. die folgenden, die die Daten im vorherigen Beispiel ergänzen:
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 | Programmzähler. Zeigt auf die Adresse der Anweisung, die den Absturz ausgelöst hat. |
| Lr | Link registrieren. Zeigt möglicherweise auf die Rückgabeadresse in der aufrufenden Funktion. |
| Sp | Stapelzeiger. Zeigt auf den anfang der Aufrufliste. |
| Signo | POSIX-Signal. Gibt den Fehlertyp an. |
| Errno | POSIX errno. Gibt einen Fehler an. |
| Code | Gibt den detaillierten Absturz status im übergeordneten Signal status an. |
| component_id | GUID der abgestürzten Softwarekomponente. |
| 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 appCrash finden Sie im signal_status und signal_code. Führen Sie die folgenden Schritte aus:
- Sehen Sie sich anhand 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 nach dem Wert, der dem signal_status im Fehlerbericht
csvzugewiesen ist. Notieren Sie sich nach dem Suchen den entsprechenden Signalnamen in der spalte ganz links. - Scrollen Sie nach oben zu der Tabelle mit der Bezeichnung "Standardsignale". Passen Sie den zuvor ermittelten Signalnamen an, und verwenden Sie die Tabelle, um weitere Informationen darüber zu sammeln, was das Signal angibt.
- Suchen Sie in der Man 7-Dokumentation für signal_code und dem zuvor gefundenen Signalnamen die entsprechende Liste der si_codes.
- Verwenden Sie den Wert, der dem signal_code in der Fehlerberichtsdatei
csvzugewiesen ist, um zu bestimmen, welcher Code mit der Fehlermeldung übereinstimmt.
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)
In der Man 7-Dokumentation können Sie die folgenden zusätzlichen Informationen zu AppCrash ermitteln:
- Signale werden im 10. Abschnitt der Beschreibung der Signal man page beschrieben. Eine signal_status des Werts 11 entspricht einem SIGSEGV-Signal.
- SIGSEGV gibt an, dass ein ungültiger Speicherverweis aufgetreten ist (dies kann häufig ein NULL-Zeiger sein).
- SI_Codes werden im 3. Abschnitt der Beschreibung der SigAction-Manpage für jeden signal_status beschrieben. Obwohl die Seite keine Indexnummer für jede si_code auflistet, können Sie ab Index 1 aus jeder signal_status Kategorie zählen. Wenn Sie sich die Liste der si_codes für SIGSEGV ansehen (beginnend bei Index 1), können Sie sehen, dass die dritte mit einer SEGV_BNDERR übereinstimmt.
- SEGV_BNDERR gibt an, dass eine fehlerhafte Adressbindungsprüfung aufgetreten ist.
Hinweis
Ein häufig auftretender AppCrash enthält den signal_status Wert 9, der ein SIGKILL-Signal ist, zusammen mit dem SEND_SIG_PRIV si_code. Dieser status gibt an, dass das Betriebssystem die Anwendung beendet hat, weil es den Grenzwert für die Arbeitsspeicherauslastung überschritten hat. Weitere Informationen zu Grenzwerten für den Anwendungsspeicher finden Sie unter Arbeitsspeichernutzung in allgemeinen Anwendungen.
Interpretieren von AppExits
Wenn eine App ohne Fehler beendet wird, sind die Felder signal_status und signal_code nicht vorhanden, und anstelle eines exit_status enthält die Beschreibung einen Exitcode:
AppExit (exit_code=0; component_id=685f13af-25a5-40b2-8dd8-8cbc253ecbd8; image_id=0a7cc3a2-f7c2-4478-8b02-723c1c6a85cd)
AppExits können aus verschiedenen Gründen auftreten, z. B. aus einem Anwendungsupdate, einem nicht angeschlossenen Gerät oder der Verwendung der Herunterschalt-API. Es ist wichtig, Exitcodes zu implementieren, damit Sie Einblick in die Gründe für eine AppExit erhalten.
Verwenden Sie zum Interpretieren von AppExits den wert exit_code im Feld Beschreibung des Fehlerberichts. Wenn Ihre App einen Exitcode zurückgibt, können Sie den Wert des 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 Exitcodemeldung dem im Fehlerbericht angegebenen Wert entspricht. Suchen Sie dann nach, welche Funktion in der Anwendung die Exitcodemeldung zurückgegeben hat und warum sie dies getan hat. Wenn Sie die return-Anweisung und ihren Kontext anzeigen, können Sie möglicherweise die Ursache für den Fehler ermitteln.
Betriebssystemereignisse
Fehlerdaten umfassen auch zugrunde liegende Betriebssystem- und Hardwareereignisse, die sich auf Ihre Anwendung auswirken können, indem sie fehlschlägt oder neu gestartet wird. Solche Ereignisse können Folgendes umfassen:
- Ungeplante Geräteneustarts aufgrund von Kernelfehlern
- Cloudbetriebssystemupdates
- Vorübergehende Hardwareprobleme
Betriebssystemereignisse sind in den Daten enthalten, damit Sie ermitteln können, ob Anwendungsfehler das Ergebnis eines Betriebssystem- oder Hardwareproblems sind oder Probleme mit der Anwendung selbst widerspiegeln. Wenn die Ereignisdaten zeigen, dass ein Gerät im abgesicherten Modus gestartet wurde, können Ihre Apps möglicherweise nicht gestartet werden.
Untersuchen von Fehlerdaten
Wenn Sie Skripts oder Tools zum Analysieren von Fehlerdaten entwickeln möchten, aber keine große Anzahl von Geräten zum Melden von Fehlern zur Verfügung stehen, können Sie die Azure Sphere-Beispielanwendungen verwenden, um solche Daten zu Testzwecken zu generieren. Im Beispiel Tutorials/ErrorReporting im Azure Sphere-Beispielrepository wird erläutert, wie Fehler analysiert werden, die beim Absturz der Anwendung gemeldet werden. Befolgen Sie die Anweisungen in der Infodatei, um das Beispiel mithilfe von Visual Studio, Visual Studio Code oder der Befehlszeile zu erstellen.
Wenn Sie die App über die Befehlszeile ohne Debugger bereitstellen, startet das Betriebssystem sie jedes Mal neu, wenn sie fehlschlägt. Ähnliche Ereignisse werden aggregiert, sodass ein gerät, das häufig fehlschlägt, keine Fehler von anderen maskiert, und das Maximum beträgt acht Vorkommen pro Zeitfenster. Sie können das Beispiel über die Befehlszeile ohne Debuggen wie folgt bereitstellen:
az sphere device sideload deploy --image-package <path to image package for the app>
Generieren und Herunterladen eines 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-Sicherheitsdienst zu kommunizieren.
Führen Sie den folgenden Befehl aus, um den Bericht in eine CSV-Datei herunterzuladen:
az sphere catalog download-error-report --destination error.csvÖffnen Sie die heruntergeladene CSV-Datei, und suchen Sie nach Ihrer Komponenten-ID. Es sollte eine Fehlerbeschreibung ähnlich der folgenden angezeigt werden:
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 Fehler auftritt, bevor das Gerät eine Verbindung mit einem NTP-Server herstellt, ist der Zeitstempel für das In AS3 hochgeladene Telemetriedaten möglicherweise falsch. Dies spiegelt sich in einem falschen Eintrag in der Spalte StartTime des nachfolgenden Berichts wider, der von AS3 heruntergeladen wurde. Verwenden Sie in diesem Fall das Feld EndTime des Berichts, um den Zeitpunkt des Auftretens des Ereignisses zu schätzen. Dieses Feld enthält die Uhrzeit, zu der die Clouddienste die hochgeladenen Telemetriedaten empfangen haben, und hat immer ein gültiges Datum.
Formatieren von Fehlerdaten
Die Zeitstempel und Datenspalten in der Fehlerberichtsdatei sind anders formatiert als eine typische CSV-Datei. 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.
So formatieren Sie die Zeitstempel in der exportierten CSV-Datei für die Arbeit mit Excel:
Erstellen Sie eine neue Zeitstempelspalte, und erstellen Sie ein benutzerdefiniertes Format dafür:
yyyy/mm/dd hh:mm:ssFügen Sie den Zellen in der neuen Spalte Timestamp die folgende Formel hinzu, und ändern Sie den Wert der F2-Zelle so, dass er Ihrer Spalte und Zeile entspricht:
=(DATEVALUE(LEFT(RawErrorReport!F2,10))+TIMEVALUE(RIGHT(RawErrorReport!F2,8)))
Um das Feld Beschreibung in separate Spalten aufzuteilen, führen Sie die folgenden Schritte aus, und ändern Sie den Wert der F2-Zelle so, dass er Ihrer Spalte und Zeile entspricht:
Erstellen Sie eine neue Spalte mit dem Namen Kurzname oder etwas Ähnliches, und fügen Sie den Zellen die folgende Formel hinzu:
=TRIM(LEFT(F2,FIND("(",F2)-1))Erstellen Sie Spalten, in denen die Zeilen1-Header die gleichen Namen wie die Parameterwerte haben, und fügen Sie den Zellen in jeder der 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)))