Raccogliere e interpretare i dati degli errori
I dati relativi a errori ed eventi vengono caricati quotidianamente nel servizio di sicurezza Azure Sphere. Chiunque abbia accesso a un determinato tenant può quindi scaricare i dati per tale tenant. Il report riguarda tutti i dispositivi nel tenant.
Ogni report contiene un massimo di 1.000 eventi o 14 giorni di dati, a seconda di quale evento viene raggiunto per primo. I dati possono essere scritti in un file o reindirizzati a uno script o un'applicazione. L'CLI può restituire solo 1.000 eventi. Usa l'API pubblica Azure Sphere per specificare il numero massimo di eventi restituiti nella pagina.
È possibile scaricare i dati relativi agli errori e ad altri eventi che interessano i dispositivi nei modi seguenti:
Usando il comando azsfera tenant download-error-report . Viene scaricato un file CSV contenente informazioni sugli errori e gli eventi segnalati dai dispositivi all'interno del tenant corrente.
Usando l'API pubblica Azure Sphere per la segnalazione degli errori. L'endpoint API restituisce un oggetto JSON che è possibile analizzare in base alle proprie esigenze.
Nessun dato di segnalazione errori viene raccolto da RTApps. Se si vogliono registrare errori da RTApps, è necessario implementare comunicazioni inter-core per comunicare gli errori da RTApps all'applicazione di alto livello, da cui i dati di errore possono essere registrati ai servizi di rete. Per informazioni dettagliate, vedere Comunicare con un'applicazione di alto livello e Comunicare con un'applicazione in tempo reale .
Tipi di dati disponibili
I dati restituiti per ogni errore o evento includono quanto segue:
| Dati | Descrizione |
|---|---|
| ID dispositivo | ID del dispositivo che ha rilevato l'evento. |
| Tipo di evento | Se l'evento è stato pianificato o non pianificato. Gli aggiornamenti del sistema operativo e delle app sono considerati eventi pianificati, mentre gli errori sono eventi non pianificati. |
| Classe evento | Componente software che ha rilevato l'evento: sistema operativo o applicazione. |
| Numero di eventi | Numero di volte in cui l'evento si è verificato nel periodo delimitato da StartTime e EndTime. |
| Descrizione | Informazioni sull'evento. Questo campo è generico e varia in base all'evento e all'origine. Per le applicazioni, può contenere il codice di uscita, lo stato del segnale e il codice del segnale, ma il contenuto esatto del campo non è fisso. Contiene informazioni sull'evento e si trova dalla prima occorrenza dell'evento nell'intervallo di tempo. |
| Ora inizio | Data e ora (in UTC) in cui è iniziata la finestra dell'evento. |
| Ora fine | Data e ora (in UTC) in cui è terminata la finestra dell'evento. |
L'ora di inizio e l'ora di fine definiscono un intervallo di tempo durante il quale i dati dell'evento vengono aggregati. La finestra per qualsiasi gruppo aggregato di eventi può essere costituita da un massimo di 24 ore e il massimo è 8 occorrenze per ogni intervallo di tempo.
Eventi dell'applicazione
Gli eventi delle applicazioni includono aggiornamenti delle app caricati nel cloud, arresti anomali, uscite e altri tipi di errori delle applicazioni.
Gli aggiornamenti delle applicazioni sono eventi pianificati. Per un evento AppUpdate, il campo Descrizione contiene AppUpdate.
Arresti anomali dell'applicazione, uscite, errori di avvio ed eventi simili sono eventi non pianificati. Per un evento non pianificato, il contenuto del campo Descrizione dipende dall'applicazione che ha rilevato l'evento. La tabella seguente elenca i campi che potrebbero essere presenti nel campo Descrizione per un evento non pianificato.
| Dati | Descrizione |
|---|---|
| exit_status o exit_code | Stato di uscita o codice riportato dall'applicazione. |
| signal_status | Intero che descrive il motivo di alto livello dell'arresto anomalo, restituito dal sistema operativo. Puoi trovare un elenco di stati nella documentazione di Man 7 o in altre risorse Linux. |
| signal_code | Intero che indica lo stato dettagliato dell'arresto anomalo all'interno dello stato del segnale padre. Per informazioni dettagliate, vedere la documentazione di Man 7 o altre risorse Linux. |
| component_id | GUID del componente software che si è arrestato in modo anomalo. |
| image_id | GUID dell'immagine in esecuzione al momento dell'errore. |
Le informazioni specifiche in una descrizione di AppCrash dipendono dall'origine dell'arresto anomalo. Per la maggior parte degli arresti anomali, la descrizione è simile alla seguente:
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 alcuni casi, un arresto anomalo attiva dati di errore aggiuntivi, come ad esempio il seguente, che integra i dati nell'esempio precedente:
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)
| Dati | Descrizione |
|---|---|
| Pc | Contatore programmi. Punta all'indirizzo dell'istruzione che ha generato l'arresto anomalo. |
| Lr | Link Register. Probabilmente punta all'indirizzo del mittente nella funzione chiamante. |
| Sp | Puntatore a pila. Punta all'inizio dello stack di chiamate. |
| Signo | Segnale POSIX. Indica il tipo di errore. |
| Errno | Errno POSIX. Indica un errore. |
| Codice | Indica lo stato dettagliato dell'arresto anomalo all'interno dello stato del segnale padre. |
| component_id | GUID del componente software che si è arrestato in modo anomalo. |
| pc_modulename+offset | Nome del modulo e offset nel modulo contenente il codice in cui si è verificato l'arresto anomalo. |
| lr_modulename+offset | Nome del modulo e offset nel modulo che potrebbe essere stata la funzione chiamante. |
Interpretazione di AppCrashes
La maggior parte delle informazioni su un oggetto AppCrash è disponibile nel signal_status e nella signal_code. Seguire questa procedura:
- Usando la documentazione di Man 7 per signal_status, guarda prima la tabella denominata "Numerazione dei segnali per segnali standard". Nella colonna x86/ARM cercare il valore assegnato al signal_status nella segnalazione
csverrori. Una volta trovato, prendi nota del nome del segnale corrispondente nella colonna all'estrema sinistra. - Scorrere verso l'alto fino alla tabella denominata "Segnali standard". Confronta il nome del segnale determinato in precedenza e usa la tabella per raccogliere ulteriori informazioni su ciò che il segnale indica.
- Nella documentazione di Man 7 per signal_code e il nome del segnale che hai trovato in precedenza, individua l'elenco corrispondente di si_codes.
- Usare il valore assegnato al signal_code nel file della segnalazione
csverrori per determinare il codice che corrisponde al messaggio di errore.
Ad esempio, si consideri la seguente descrizione di 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)
Utilizzando la documentazione di Man 7, è possibile scoprire le seguenti informazioni aggiuntive su AppCrash:
- I segnali sono descritti nella decima sezione della descrizione della pagina Signal man. Un signal_status di valore 11 corrisponde a un segnale SIGSEGV.
- SIGSEGV indica che si è verificato un riferimento di memoria non valido (spesso può essere un puntatore Null).
- SI_Codes sono descritti nella terza sezione della descrizione della pagina SigAction man per ogni signal_status. Anche se la pagina non elenca un numero di indice per ogni si_code, è possibile eseguire il conteggio da ogni categoria di signal_status a partire dall'indice 1. Esaminando l'elenco di si_codes per SIGSEGV (a partire dall'indice 1), si può vedere che la terza corrisponde a una SEGV_BNDERR.
- SEGV_BNDERR indica che si è verificato un controllo associato all'indirizzo non riuscito.
Nota
Un comunemente incontrato AppCrash include un signal_status valore di 9, che è un segnale SIGKILL, insieme al SEND_SIG_PRIV si_code. Questo stato indica che il sistema operativo ha ucciso l'applicazione perché ha superato il limite di utilizzo della memoria. Per ulteriori informazioni sui limiti di memoria delle applicazioni, vedi Uso della memoria nelle applicazioni di alto livello.
Interpretare AppExits
Quando un'app esce senza errori, i campi signal_status e signal_code non sono presenti e, invece di un exit_status, la Descrizione contiene un codice di uscita:
AppExit (exit_code=0; component_id=685f13af-25a5-40b2-8dd8-8cbc253ecbd8; image_id=0a7cc3a2-f7c2-4478-8b02-723c1c6a85cd)
AppExits può verificarsi per una serie di motivi, ad esempio un aggiornamento dell'applicazione, un dispositivo scollegato, o l'uso dell'API di accensione, tra gli altri. È importante implementare i codici di uscita in modo da ottenere informazioni approfondite sui motivi di un AppExit.
Per interpretare AppExits, usare il valore exit_code nel campo Descrizione della segnalazione errori. Se l'app restituisce un codice di uscita, puoi usare il valore del exit_code nel report degli errori per determinare dove o quando si è verificato l'errore. Usando questo valore, eseguire una ricerca all'interno del codice dell'applicazione per vedere quale messaggio di codice di uscita corrisponde al valore fornito nel report degli errori. Cerca quindi quale funzione nell'applicazione ha restituito il messaggio di codice di uscita e il motivo. Visualizzando l'istruzione return e il suo contesto, potresti essere in grado di individuare il motivo dell'errore.
Eventi del sistema operativo
I dati di errore includono anche gli eventi hardware e del sistema operativo sottostanti che possono influire sull'applicazione causando errori o riavvii. Tali eventi possono includere quanto segue:
- Riavvii del dispositivo non pianificati causati da errori del kernel
- Aggiornamenti del sistema operativo cloud
- Problemi hardware temporanei
Gli eventi del sistema operativo sono inclusi nei dati per determinare se gli errori dell'applicazione sono il risultato di un problema del sistema operativo o dell'hardware o riflettono i problemi con l'applicazione stessa. Se i dati dell'evento mostrano che un dispositivo è stato avviato in modalità provvisoria, le app potrebbero non essere in grado di avviarsi.
Esplorare i dati degli errori
Se si prevede di sviluppare script o strumenti per l'analisi dei dati di errore, ma non sono disponibili molti dispositivi per segnalare errori, è possibile usare le applicazioni di esempio Azure Sphere per generare tali dati per i test. L'esempio Tutorials/ErrorReporting nel repository dei campioni di Azure Sphere spiega come analizzare gli errori segnalati in caso di arresto anomalo dell'applicazione. Segui le istruzioni nel file leggimi per creare l'esempio usando Visual Studio, Visual Studio Code o la riga di comando.
Quando si distribuisce l'app dalla riga di comando senza un debugger, il sistema operativo lo riavvia ogni volta che si verifica un errore. Gli eventi simili vengono aggregati in modo che un dispositivo con errori frequenti non maschera gli errori di altri e il massimo è di otto occorrenze per intervallo di tempo. È possibile distribuire l'esempio dalla riga di comando senza eseguire il debug, come indicato di seguito:
azsphere device sideload deploy --image-package <path to image package for the app>
Generare e scaricare la segnalazione degli errori
I dati relativi a errori ed eventi vengono caricati quotidianamente nel servizio di sicurezza Azure Sphere. Assicurati che il dispositivo Azure Sphere sia connesso a Internet tramite Wi-Fi o Ethernet per comunicare con il servizio di sicurezza Azure Sphere.
Eseguire il comando seguente per scaricare il report in un file CSV:
azsphere tenant download-error-report --destination error.csvAprire il file CSV scaricato e cercare l'ID componente. Dovrebbe essere visualizzata una descrizione di errore simile alla seguente:
AppExit (exit_code=0; component_id=685f13af-25a5-40b2-8dd8-8cbc253ecbd8; image_id=6d2646aa-c0ce-4e55-b7d6-7c206a7a6363)
Puoi anche usare l'API pubblica Azure Sphere per la segnalazione degli errori.
Nota
- Potrebbero essere richieste fino a 24 ore prima che gli eventi segnalati di recente siano disponibili per il download.
- Se si verifica un evento o un errore prima che il dispositivo si connetta a un server NTP, il timestamp per l'evento contenuto nella telemetria caricata in AS3 potrebbe non essere corretto. Ciò si rifletterà in una voce non corretta nella colonna StartTime nel report successivo scaricato da AS3. In questo caso, utilizzare il campo EndTime del report per facilitare la stima della data dell'evento. Questo campo contiene l'ora in cui i servizi cloud hanno ricevuto la telemetria caricata e avranno sempre una data valida.
Formattare i dati di errore
I timestamp e le colonne di dati nel file del report degli errori sono formattati in modo diverso rispetto a un tipico file CSV. Se si vogliono visualizzare i risultati in Excel, è possibile riformattare i dati creando nuove colonne e aggiungendo formule personalizzate.
Per formattare i timestamp nel file CSV esportato in modo che funzionino con Excel:
Creare una nuova colonna Timestamp e creare un formato personalizzato:
yyyy/mm/dd hh:mm:ssAggiungere la formula seguente alle celle nella nuova colonna Timestamp, modificando il valore della cella F2 in modo che corrisponda alla colonna e alla riga:
=(DATEVALUE(LEFT(RawErrorReport!F2,10))+TIMEVALUE(RIGHT(RawErrorReport!F2,8)))
Per dividere il campo Descrizione in colonne separate, seguire questa procedura, modificando il valore della cella F2 in modo che corrisponda alla colonna e alla riga:
Creare una nuova colonna denominata Nome breve o qualcosa di simile e aggiungere la formula seguente alle celle:
=TRIM(LEFT(F2,FIND("(",F2)-1))Creare colonne in cui le intestazioni di riga1 abbiano gli stessi nomi dei valori dei parametri e aggiungere la formula seguente alle celle di ognuna delle colonne:
=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)))