Recopilar e interpretar datos de error
Los datos de errores y eventos se cargan diariamente en el Servicio de Seguridad azure Sphere. Cualquier persona que tenga acceso a un catálogo determinado puede descargar los datos para ese catálogo. El informe trata todos los dispositivos del catálogo.
Cada informe contiene un máximo de 1000 eventos o 14 días de datos, lo que se alcance primero. Los datos se pueden escribir en un archivo o canalizarse a un script o aplicación. La CLI solo puede devolver 1000 eventos. Use la API pública de Azure Sphere para especificar el número máximo de eventos devueltos en la página.
Puedes descargar datos sobre los errores y otros eventos que afectan a tus dispositivos de las siguientes maneras:
Mediante el comando az sphere catalog download-error-report . Se descarga un archivo CSV que contiene información sobre los errores y eventos notificados por los dispositivos en el catálogo actual.
Mediante el uso de la API pública de Azure Sphere para el informe de errores. El punto de conexión de API devuelve un objeto JSON que puede analizar según sus necesidades.
No se recopilan datos de informes de errores de RTApps. Si desea registrar errores de RTApps, tendrá que implementar comunicaciones entre núcleos para comunicar errores de las RTApps a la aplicación de alto nivel, desde la que se pueden registrar los datos de error en los servicios de red.
Tipos de datos disponibles
Los datos devueltos para cada error o evento incluyen lo siguiente:
| Datos | Descripción |
|---|---|
| Id. de dispositivo | Identificador del dispositivo que encontró el evento. |
| Tipo de evento | Si el evento fue planeado o no planeado. Las actualizaciones del sistema operativo y las aplicaciones se consideran eventos planeados, mientras que los errores son eventos no planeados. |
| Clase de evento | Componente de software que encontró el evento: sistema operativo o aplicación. |
| Recuento de eventos | Número de veces que el evento se produjo dentro del período delimitado por StartTime y EndTime. |
| Descripción | Información sobre el evento. Este campo es genérico y varía según el evento y su origen. Para las aplicaciones, puede contener el código de salida, el estado de la señal y el código de señal, pero no se fija el contenido exacto del campo. Esto contiene información sobre el evento y proviene de la primera aparición del evento en el intervalo de tiempo. |
| Hora de inicio | Fecha y hora (en UTC) en la que comenzó la ventana del evento. |
| Hora de finalización | Fecha y hora (en UTC) en la que finalizó la ventana del evento. |
La Hora de inicio y la Hora de finalización definen un intervalo de tiempo durante el cual se agregan los datos del evento. La ventana de cualquier grupo agregado de eventos puede ser de hasta 24 horas y el máximo es de 8 repeticiones por intervalo de tiempo.
Eventos de aplicación
Los eventos de la aplicación incluyen actualizaciones de aplicaciones cargadas en la nube junto con bloqueos, salidas y otros tipos de errores de la aplicación.
Las actualizaciones de las aplicaciones son eventos planeados. Para un evento AppUpdate, el campo Description contiene AppUpdate.
Los bloqueos de aplicaciones, las salidas, los errores de inicio y eventos similares son eventos no planeados. Para un evento no planeado, el contenido del campo Description depende de la aplicación que encontró el evento. En la tabla siguiente se enumeran los campos que pueden estar presentes en el campo Descripción para un evento no planeado.
| Datos | Descripción |
|---|---|
| exit_status o exit_code | Estado de salida o código notificado por la aplicación. |
| signal_status | Entero que describe la razón de alto nivel del bloqueo, devuelto por el sistema operativo. Puede encontrar una lista de estados en la documentación de Man 7 u otros recursos de Linux. |
| signal_code | Entero que indica el estado detallado de bloqueo dentro del estado de la señal principal. Consulta la documentación de Man 7 u otros recursos de Linux para obtener más información. |
| component_id | GUID del componente de software que se bloqueó. |
| image_id | GUID de la imagen que se estaba ejecutando en el momento del error. |
La información específica de una descripción de AppCrash depende del origen del bloqueo. Para la mayoría de los bloqueos, la descripción es similar a la siguiente:
AppCrash (exit_status=11; signal_status=11; signal_code=3; component_id=685f13af-25a5-40b2-8dd8-8cbc253ecbd8; image_id=7053e7b3-d2bb-431f-8d3a-173f52db9675)
En algunos casos, un bloqueo desencadena datos de error adicionales, como el siguiente, que complementa los datos en el ejemplo anterior:
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)
| Datos | Descripción |
|---|---|
| Pc | Contador de programas. Apunta a la dirección de la instrucción que desencadenó el bloqueo. |
| Lr | Registro de vínculos. Posiblemente apunta a la dirección de remite en la función de llamada. |
| Sp | Puntero de pila. Apunta a la parte superior de la pila de llamadas. |
| signo | Señal POSIX. Indica el tipo de error. |
| Errno | POSIX errno. Indica un error. |
| Código | Indica el estado de bloqueo detallado dentro del estado de la señal principal. |
| component_id | GUID del componente de software que se bloqueó. |
| pc_modulename+desplazamiento | Nombre del módulo y desplazamiento en el módulo que contiene el código en el que se produjo el bloqueo. |
| lr_modulename+desplazamiento | Nombre del módulo y desplazamiento en el módulo que pudo haber sido la función de llamada. |
Interpretar las appCrashes
Puede encontrar la mayor parte de la información sobre un AppCrash en el signal_status y signal_code. Sigue estos pasos:
- Usando la documentación de Man 7 para signal_status, primero mire la tabla con la etiqueta "Numeración de señal para señales estándar". En la columna x86/ARM, busque el valor asignado a la signal_status en el informe
csvde errores . Una vez encontrado, anota el nombre de la señal correspondiente en la columna situada más a la izquierda. - Desplázate hacia arriba hasta la tabla con la etiqueta "Señales estándar". Haga coincidir el nombre de señal previamente determinado y use la tabla para recopilar más información sobre lo que indica la señal.
- En la documentación de Man 7 para signal_code y el nombre de la señal que has encontrado anteriormente, busca la lista correspondiente de si_codes.
- Use el valor asignado a la signal_code en el archivo del informe
csvde errores para determinar qué código coincide con el mensaje de error.
Por ejemplo, tenga en cuenta la siguiente descripción de 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 documentación de Man 7, puede descubrir la siguiente información adicional sobre AppCrash:
- Las señales se describen en la 10ª sección de la descripción de la página del hombre de la señal. Una signal_status del valor 11 corresponde a una señal SIGSEGV.
- SIGSEGV indica que se produjo una referencia de memoria no válida (esto puede ser a menudo un puntero nulo).
- SI_Codes se describen en la 3ª sección de la descripción de la página man SigAction para cada signal_status. Aunque en la página no se muestra un número de índice para cada si_code, puede contar desde cada categoría de signal_status a partir del índice 1. Si mira la lista de si_codes para SIGSEGV (a partir del índice 1), puede ver que la tercera coincide con un SEGV_BNDERR.
- SEGV_BNDERR indica que se ha producido un error en la comprobación del límite de direcciones.
Nota
Un AppCrash comúnmente encontrado incluye un valor de signal_status de 9, que es una señal SIGKILL, junto con el SEND_SIG_PRIV si_code. Este estado indica que el sistema operativo mató a la aplicación porque superó el límite de uso de memoria. Para obtener más información sobre los límites de memoria de las aplicaciones, consulta Uso de memoria en aplicaciones de alto nivel.
Interpretar AppExits
Cuando una aplicación sale sin error, los campos signal_status y signal_code no están presentes y, en lugar de un exit_status, la Descripción contiene un código de salida:
AppExit (exit_code=0; component_id=685f13af-25a5-40b2-8dd8-8cbc253ecbd8; image_id=0a7cc3a2-f7c2-4478-8b02-723c1c6a85cd)
AppExits puede ocurrir por una serie de razones, como una actualización de la aplicación, un dispositivo desenchufado o el uso de la API de apagado, entre otros. Es importante implementar códigos de salida para que pueda obtener información sobre las razones de un AppExit.
Para interpretar AppExits, use el valor de exit_code en el campo Descripción del informe de errores. Si la aplicación devuelve un código de salida, puedes usar el valor de la exit_code en el informe de errores para determinar dónde o cuándo se produjo el error. Con este valor, busque dentro del código de la aplicación para ver qué mensaje de código de salida corresponde al valor proporcionado en el informe de errores. A continuación, busque qué función de la aplicación devolvió el mensaje de código de salida y por qué lo hizo. Al ver la declaración de devolución y su contexto, es posible que pueda descubrir el motivo del error.
Eventos del sistema operativo
Los datos de errores también incluyen eventos de hardware y sistema operativo subyacentes que pueden afectar a la aplicación al provocar errores o reiniciarse. Estos eventos pueden incluir lo siguiente:
- Reinicios de dispositivos no planeados causados por errores del kernel
- Actualizaciones del sistema operativo en la nube
- Problemas de hardware transitorios
Los eventos del so se incluyen en los datos para ayudarle a determinar si los errores de la aplicación son el resultado de un problema del sistema operativo o hardware, o reflejar problemas con la propia aplicación. Si los datos del evento muestran que un dispositivo ha arrancado en modo seguro, es posible que las aplicaciones no puedan iniciarse.
Explorar datos de errores
Si planea desarrollar scripts o herramientas para analizar datos de errores, pero no tiene un gran número de dispositivos disponibles para notificar errores, puede usar las aplicaciones de muestra de Azure Sphere para generar dichos datos para pruebas. El ejemplo Tutoriales/ErrorReporting del repositorio de muestras de Azure Sphere explica cómo analizar los errores notificados cuando la aplicación se bloquea. Siga las instrucciones del archivo Léame para crear el ejemplo con Visual Studio, Visual Studio Code o la línea de comandos.
Al implementar la aplicación desde la línea de comandos sin un depurador, el sistema operativo la reinicia cada vez que se produce un error. Los eventos similares se agregan de modo que un dispositivo con errores frecuentes no enmascara los errores de otros y el máximo es de ocho repeticiones por intervalo de tiempo. Puede implementar el ejemplo desde la línea de comandos sin depurar, de la siguiente manera:
az sphere device sideload deploy --image-package <path to image package for the app>
Generar y descargar un informe de errores
Los datos de errores y eventos se cargan diariamente en el Servicio de Seguridad azure Sphere. Asegúrese de que el dispositivo Azure Sphere está conectado a Internet mediante Wi-Fi o Ethernet para comunicarse con el Servicio de Seguridad de Azure Sphere.
Ejecute el siguiente comando para descargar el informe en un archivo CSV:
az sphere catalog download-error-report --destination error.csvAbra el archivo CSV descargado y busque el id. de componente. Debería ver una descripción de error similar a la siguiente:
AppExit (exit_code=0; component_id=685f13af-25a5-40b2-8dd8-8cbc253ecbd8; image_id=6d2646aa-c0ce-4e55-b7d6-7c206a7a6363)
También puede usar la API pública de Azure Sphere para el informe de errores.
Nota
- La descarga de los eventos notificados recientemente puede tardar hasta 24 horas.
- Si se produce un evento o error antes de que el dispositivo se conecte con un servidor NTP, la marca de tiempo para el evento contenido en la telemetría cargada a AS3 puede ser incorrecta. Esto se reflejará en una entrada incorrecta en la columna StartTime del informe posterior descargado de AS3. En esta situación, use el campo EndTime del informe para ayudar a calcular cuándo se produjo el evento. Este campo contiene la hora en la que los servicios en la nube recibieron la telemetría cargada y siempre tendrán una fecha válida.
Dar formato a datos de error
Las marcas de tiempo y las columnas de datos del archivo del informe de errores tienen un formato diferente de un archivo CSV típico. Si desea ver los resultados en Excel, puede cambiar el formato de los datos creando nuevas columnas y agregando fórmulas personalizadas.
Para aplicar formato a las marcas de tiempo en el archivo CSV exportado para que funcionen con Excel:
Cree una nueva columna Timestamp y cree un formato personalizado para ella:
yyyy/mm/dd hh:mm:ssAgregue la fórmula siguiente a las celdas de la nueva columna Timestamp y cambie el valor de la celda F2 para que coincida con la columna y la fila:
=(DATEVALUE(LEFT(RawErrorReport!F2,10))+TIMEVALUE(RIGHT(RawErrorReport!F2,8)))
Para dividir el campo Descripción en columnas independientes, siga estos pasos para cambiar el valor de la celda F2 para que coincida con la columna y la fila:
Cree una nueva columna denominada Nombre corto o algo similar y agregue la siguiente fórmula a las celdas:
=TRIM(LEFT(F2,FIND("(",F2)-1))Cree columnas en las que los encabezados de fila1 tengan los mismos nombres que los valores de parámetro y agregue la siguiente fórmula a las celdas de cada una de las columnas:
=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)))