Raccogliere e interpretare i dati sugli errori
Importante
Questa è la documentazione di Azure Sphere (legacy). Azure Sphere (legacy) viene ritirato il 27 settembre 2027 e gli utenti devono eseguire la migrazione ad Azure Sphere (integrato) entro questo periodo. Usare il selettore di versione posizionato sopra il sommario per visualizzare la documentazione di Azure Sphere (integrata).
I dati su errori ed eventi vengono caricati quotidianamente nel servizio di sicurezza di Azure Sphere. Chiunque abbia accesso a un tenant specifico può quindi scaricare i dati per tale tenant. Il report copre tutti i dispositivi nel tenant.
Ogni report contiene un massimo di 1.000 eventi o 14 giorni di dati, a qualsiasi valore raggiunto per primo. I dati possono essere scritti in un file o inviati tramite pipe a uno script o a un'applicazione. L'interfaccia della riga di comando può restituire solo 1.000 eventi. Usare l'API pubblica di Azure Sphere per specificare il numero massimo di eventi restituiti nella pagina.
È possibile scaricare i dati sugli errori e altri eventi che influiscono sui dispositivi nei modi seguenti:
Usando il comando azsphere tenant download-error-report. Viene scaricato un file CSV contenente informazioni sugli errori e sugli eventi segnalati dai dispositivi all'interno del tenant corrente.
Usando l'API pubblica di 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 desidera registrare errori da RTApps, è necessario implementare comunicazioni tra core per comunicare gli errori dalle applicazioni RTApp all'applicazione di alto livello, da cui i dati degli errori possono essere registrati nei servizi di rete. Per informazioni dettagliate, vedere Comunicare con un'applicazione di alto livello e Comunicare con un'applicazione con funzionalità 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 | Indica se l'evento è stato pianificato o no. Gli aggiornamenti del sistema operativo e delle app sono considerati eventi pianificati, mentre gli errori sono eventi non pianificati. |
| Event Class | Componente software che ha rilevato l'evento: sistema operativo o applicazione. |
| Conteggio 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 a seconda dell'evento e della relativa 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 proviene dalla prima occorrenza dell'evento nell'intervallo di tempo. |
| Ora di avvio | Data e ora (in formato UTC) in cui è iniziata la finestra dell'evento. |
| Ora di fine | Data e ora (in formato UTC) in cui è terminata la finestra dell'evento. |
La data/ora di inizio e la data/ora di fine definiscono una finestra temporale durante la quale vengono aggregati i dati degli eventi. La finestra per qualsiasi gruppo aggregato di eventi può essere fino a 24 ore e il massimo è 8 occorrenze per intervallo di tempo.
Eventi dell'applicazione
Gli eventi delle applicazioni includono aggiornamenti di app caricati dal cloud oltre ad arresti anomali, uscite e altri tipi di errori.
Gli aggiornamenti delle applicazioni sono eventi pianificati. Per un evento AppUpdate, il campo della descrizione contiene AppUpdate.
Gli arresti anomali, le uscite, gli errori di avvio ed eventi simili sono eventi non pianificati. Per un evento non pianificato, il contenuto del campo della descrizione dipende dall'applicazione che ha rilevato l'evento. Nella tabella seguente sono elencati i campi che possono essere presenti nel campo della descrizione per un evento non pianificato.
| Dati | Descrizione |
|---|---|
| exit_status o exit_code | Stato o codice di uscita segnalato dall'applicazione. |
| signal_status | Intero che descrive il motivo dettagliato dell'arresto anomalo, restituito dal sistema operativo. Per un elenco di stati, vedere la documentazione di Man 7 o altre risorse Linux. |
| signal_code | Intero che indica lo stato dettagliato dell'arresto anomalo con lo stato del segnale padre. Per informazioni dettagliate, vedere la documentazione di Man 7 o altre risorse Linux. |
| component_id | GUID del componente software 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 aggiuntivi sugli errori, ad esempio quelli riportati di seguito, che integrano i dati dell'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 attivato l'arresto anomalo. |
| lr | Link Register (Registra collegamento). Possibilmente punta all'indirizzo restituito nella funzione chiamante. |
| sp | Puntatore dello stack. Punta alla parte superiore dello stack di chiamate. |
| signo | Segnale POSIX. Indica il tipo di errore. |
| errno | POSIX errno. Indica un errore. |
| codice | Indica lo stato di arresto anomalo dettagliato all'interno dello stato del segnale padre. |
| component_id | GUID del componente software 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 la funzione chiamante. |
Interpretare AppCrashes
È possibile trovare la maggior parte delle informazioni su appCrash nel signal_status e signal_code. Seguire questa procedura:
- Usando la documentazione man 7 per signal_status, esaminare prima di tutto la tabella con l'etichetta "Numerazione dei segnali standard". Nella colonna x86/ARM cercare il valore assegnato al signal_status nel report degli
csverrori . Una volta trovato, prendere nota del nome del segnale corrispondente nella colonna all'estrema sinistra. - Scorrere verso l'alto fino alla tabella con l'etichetta "Segnali standard". Trovare la corrispondenza con il nome del segnale determinato in precedenza e usare la tabella per raccogliere altre informazioni su ciò che indica il segnale.
- Nella documentazione man 7 per signal_code e il nome del segnale trovato in precedenza individuare l'elenco corrispondente di si_codes.
- Usare il valore assegnato al signal_code nel file di report
csvdegli errori per determinare quale codice corrisponde al messaggio di errore.
Si consideri ad esempio 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)
Usando la documentazione di Man 7, è possibile trovare le informazioni aggiuntive seguenti su AppCrash:
- I segnali sono descritti nella sezione 10 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 di gestione SigAction per ogni signal_status. Anche se la pagina non elenca un numero di indice per ogni si_code, è possibile contare da ogni signal_status categoria a partire dall'indice 1. Esaminando l'elenco di si_codes per SIGSEGV (a partire dall'indice 1), è possibile notare che il terzo corrisponde a un SEGV_BNDERR.
- SEGV_BNDERR indica che si è verificato un controllo associato a un indirizzo non riuscito.
Nota
Un'istanza comunemente rilevata da AppCrash include un valore signal_status pari a 9, ovvero un segnale SIGKILL, insieme al SEND_SIG_PRIV si_code. Questo stato indica che il sistema operativo ha terminato l'applicazione perché ha superato il limite di utilizzo della memoria. Per altre informazioni sui limiti di memoria delle applicazioni, vedere Uso della memoria nelle applicazioni di alto livello.
Interpretare AppExits
Quando un'app viene chiusa senza errori, i campi signal_status e signal_code non sono presenti e invece di 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 diversi motivi, ad esempio un aggiornamento dell'applicazione, un dispositivo scollegato o l'uso dell'API di spegnimento, tra gli altri. È importante implementare i codici di uscita in modo da ottenere informazioni dettagliate 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, cercare all'interno del codice dell'applicazione per vedere quale messaggio di codice di uscita corrisponde al valore specificato nel report degli errori. Cercare quindi quale funzione nell'applicazione ha restituito il messaggio di codice di uscita e il motivo per cui è stato fatto. Visualizzando l'istruzione return e il relativo contesto, è possibile individuare il motivo dell'errore.
Eventi del sistema operativo
I dati sugli errori includono eventi del sistema operativo e dell'hardware sottostanti che potrebbero influire sull'applicazione generandone il riavvio o altri errori. Gli eventi includono i seguenti:
- Riavvii non pianificati del dispositivo causati da errori del kernel
- Aggiornamenti del sistema operativo dal 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 sugli eventi mostrano che un dispositivo è stato avviato in modalità provvisoria, potrebbe non essere possibile avviare le app.
Esplorare i dati sugli errori
Se si prevede di sviluppare script o strumenti per l'analisi dei dati degli errori, ma non si dispone di un numero elevato di dispositivi disponibili per segnalare gli errori, è possibile usare le applicazioni di esempio di Azure Sphere per generare tali dati per i test. L'esempio Tutorials/ErrorReporting nel repository di esempi di Azure Sphere illustra come analizzare gli errori segnalati quando l'applicazione si arresta in modo anomalo. Seguire le istruzioni nel file leggimi per compilare 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 la riavvia ogni volta che l'esecuzione non riesce. Gli eventi simili vengono aggregati in modo che un dispositivo con errori frequenti non maschera gli errori di altri utenti e che il massimo sia otto occorrenze per intervallo di tempo. È possibile distribuire l'esempio dalla riga di comando senza eseguire il debug, come indicato di seguito:
- Interfaccia della riga di comando di Azure Sphere
- Interfaccia della riga di comando classica di Azure Sphere
azsphere device sideload deploy --image-package <path to image package for the app>
Generare e scaricare la segnalazione degli errori
I dati su errori ed eventi vengono caricati quotidianamente nel servizio di sicurezza di Azure Sphere. Assicurarsi che il dispositivo Azure Sphere sia connesso a Internet tramite Wi-Fi o Ethernet per comunicare con il servizio di sicurezza di Azure Sphere.
Eseguire il comando seguente per scaricare il report in un file CSV:
- Interfaccia della riga di comando di Azure Sphere
- Interfaccia della riga di comando classica di Azure Sphere
azsphere tenant download-error-report --destination error.csvAprire il file CSV scaricato e cercare l'ID componente. Verrà visualizzata una descrizione dell'errore simile alla seguente:
AppExit (exit_code=0; component_id=685f13af-25a5-40b2-8dd8-8cbc253ecbd8; image_id=6d2646aa-c0ce-4e55-b7d6-7c206a7a6363)
È anche possibile usare l'API pubblica di Azure Sphere per la segnalazione degli errori.
Nota
- Potrebbero essere necessarie 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 nei dati di telemetria caricati in AS3 potrebbe non essere corretto. Ciò si rifletterà in una voce non corretta nella colonna StartTime nel report successivo scaricato da AS3. In questa situazione usare il campo EndTime del report per facilitare la stima quando si è verificato l'evento. Questo campo contiene l'ora in cui i servizi cloud hanno ricevuto i dati di telemetria caricati e avranno sempre una data valida.
Formato dei dati sugli errori
I timestamp e le colonne di dati nel file di report degli errori vengono 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 sia compatibile con Excel:
Creare una nuova colonna Timestamp e un formato personalizzato:
yyyy/mm/dd hh:mm:ssAggiungere la formula seguente alle celle nella nuova colonna Timestamp, cambiando il valore della cella F2 in base al contenuto della colonna e della riga:
=(DATEVALUE(LEFT(RawErrorReport!F2,10))+TIMEVALUE(RIGHT(RawErrorReport!F2,8)))
Per dividere il campo della descrizione in colonne separate, seguire questa procedura, cambiando il valore della cella F2 in base al contenuto della colonna e della riga:
Creare una nuova colonna denominata Shortname o un nome simile e aggiungere la formula seguente alle celle:
=TRIM(LEFT(F2,FIND("(",F2)-1))Creare colonne in cui le intestazioni row1 hanno gli stessi nomi dei valori di parametro e aggiungere la formula seguente alle celle in 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)))