오류 데이터 수집 및 해석

아티클
08/09/2023

오류 및 이벤트 데이터는 매일 Azure Sphere Security Service에 업로드됩니다. 특정 카탈로그에 대한 액세스 권한이 있는 사용자는 해당 카탈로그에 대한 데이터를 다운로드할 수 있습니다. 보고서는 카탈로그의 모든 디바이스를 다룹니다.

각 보고서에는 최대 1,000개의 이벤트 또는 14일의 데이터가 포함되며, 그 중 가장 먼저 도달합니다. 데이터를 파일에 쓰거나 스크립트 또는 애플리케이션에 파이프할 수 있습니다. CLI는 1,000개의 이벤트만 반환할 수 있습니다. Azure Sphere 공용 API를 사용하여 페이지에서 반환되는 최대 이벤트 수를 지정합니다.

다음과 같은 방법으로 디바이스에 영향을 주는 오류 및 기타 이벤트에 대한 데이터를 다운로드할 수 있습니다.

az sphere catalog download-error-report 명령을 사용합니다. 현재 카탈로그 내의 디바이스에서 보고한 오류 및 이벤트에 대한 정보가 포함된 CSV 파일이 다운로드됩니다.
오류 보고에 Azure Sphere 공용 API 를 사용합니다. API 엔드포인트는 필요에 따라 구문 분석할 수 있는 JSON 개체를 반환합니다.

RTApps에서 오류 보고 데이터가 수집되지 않습니다. RTApps의 오류를 기록하려면 RTApps에서 오류 데이터를 네트워크 서비스에 기록할 수 있는 상위 수준 애플리케이션으로 오류를 전달하기 위해 코어 간 통신을 구현해야 합니다.

사용 가능한 데이터 형식

각 오류 또는 이벤트에 대해 반환된 데이터에는 다음이 포함됩니다.

데이터	설명
디바이스 ID	이벤트가 발생한 디바이스의 ID입니다.
이벤트 유형	이벤트가 계획되었는지 계획되지 않은지 여부입니다. OS 및 앱 업데이트는 계획된 이벤트로 간주되지만 오류는 계획되지 않은 이벤트입니다.
이벤트 클래스	이벤트가 발생한 소프트웨어 구성 요소: OS 또는 애플리케이션.
이벤트 수	StartTime 및 EndTime으로 구분된 기간 내에 이벤트가 발생한 횟수입니다.
설명	이벤트에 대한 정보입니다. 이 필드는 제네릭이며 이벤트 및 원본에 따라 달라집니다. 애플리케이션의 경우 종료 코드, 신호 상태 및 신호 코드를 포함할 수 있지만 필드의 정확한 내용은 수정되지 않습니다. 여기에는 이벤트에 대한 정보가 포함되며 시간 창에서 이벤트가 처음 발생한 경우의 정보입니다.
시작 시간	이벤트 창이 시작된 날짜 및 시간(UTC)입니다.
종료 시간	이벤트 창이 종료된 날짜 및 시간(UTC)입니다.

시작 시간 및 종료 시간은 이벤트 데이터가 집계되는 기간을 정의합니다. 모든 집계된 이벤트 그룹의 창은 최대 24시간이 될 수 있으며 최대 기간당 최대 8회 발생합니다.

애플리케이션 이벤트

애플리케이션 이벤트에는 크래시, 종료 및 기타 유형의 애플리케이션 오류와 함께 클라우드로 로드된 앱 업데이트가 포함됩니다.

애플리케이션 업데이트는 계획된 이벤트입니다. AppUpdate 이벤트의 경우 설명 필드에 가 포함됩니다 AppUpdate.

애플리케이션 크래시, 종료, 시작 실패 및 유사한 이벤트는 계획되지 않은 이벤트입니다. 계획되지 않은 이벤트의 경우 설명 필드의 내용은 이벤트가 발생한 애플리케이션에 따라 달라집니다. 다음 표에서는 계획되지 않은 이벤트에 대한 설명 필드에 있을 수 있는 필드를 나열합니다.

데이터	설명
exit_status 또는 exit_code	애플리케이션에서 보고한 상태 또는 코드를 종료합니다.
signal_status	OS에서 반환하는 충돌의 상위 수준 이유를 설명하는 정수입니다. Man 7 설명서 또는 기타 Linux 리소스에서 상태 목록을 찾을 수 있습니다.
signal_code	부모 신호 상태 내의 자세한 크래시 상태 나타내는 정수입니다. 자세한 내용은 Man 7 설명서 또는 기타 Linux 리소스를 참조하세요.
component_id	충돌한 소프트웨어 구성 요소의 GUID입니다.
image_id	오류 발생 시 실행 중인 이미지의 GUID입니다.

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)

경우에 따라 크래시가 다음과 같은 추가 오류 데이터를 트리거하여 이전 예제의 데이터를 보완합니다.

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)

데이터	설명
Pc	프로그램 카운터. 충돌을 트리거한 명령의 주소를 가리킵니다.
Lr	링크 등록. 호출 함수의 반환 주소를 가리킵니다.
Sp	스택 포인터입니다. 호출 스택의 위쪽을 가리킵니다.
signo	POSIX 신호. 오류 유형을 나타냅니다.
Errno	POSIX errno. 오류를 나타냅니다.
코드	부모 신호 상태 내의 자세한 크래시 상태 나타냅니다.
component_id	충돌한 소프트웨어 구성 요소의 GUID입니다.
pc_modulename+오프셋	모듈의 이름 및 크래시가 발생한 코드를 포함하는 모듈에 대한 오프셋입니다.
lr_modulename+오프셋	호출 함수일 수 있는 모듈의 이름 및 모듈에 대한 오프셋입니다.

AppCrashes 해석

appCrash에 대한 대부분의 정보는 signal_status 및 signal_code 찾을 수 있습니다. 같이:

signal_status Man 7 설명서를 사용하여 먼저 "표준 신호에 대한 신호 번호 매기기"라는 레이블이 지정된 테이블을 살펴봅니다. x86/ARM 열의 오류 보고서에서 signal_status 할당된 값을 검색합니다 csv. 찾은 후 맨 왼쪽 열에서 해당 신호 이름을 확인합니다.
"표준 신호"라는 레이블이 지정된 테이블까지 스크롤합니다. 이전에 결정된 신호 이름과 일치하고 테이블을 사용하여 신호가 나타내는 내용에 대한 자세한 정보를 수집합니다.
signal_code 대한 Man 7 설명서 및 이전에 찾은 신호 이름에서 해당 si_codes 목록을 찾습니다.
오류 보고서 csv 파일의 signal_code 할당된 값을 사용하여 오류 메시지와 일치하는 코드를 확인합니다.

예를 들어 다음 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)

Man 7 설명서를 사용하여 AppCrash에 대한 다음 추가 정보를 검색할 수 있습니다.

신호는 Signal man 페이지에 대한 설명의 10번째 섹션에 설명되어 있습니다. 값 11의 signal_status SIGSEGV 신호에 해당합니다.
SIGSEGV는 잘못된 메모리 참조가 발생했음을 나타냅니다(null 포인터일 수 있음).
SI_Codes 각 signal_status 대한 SigAction 남자 페이지에 대한 설명의 세 번째 섹션에 설명되어 있습니다. 페이지에는 각 si_code 대한 인덱스 번호가 나열되지 않지만 인덱스 1부터 각 signal_status 범주에서 계산할 수 있습니다. SIGSEGV에 대한 si_codes 목록(인덱스 1부터 시작)을 보면 세 번째 항목이 SEGV_BNDERR 일치하는지 확인할 수 있습니다.
SEGV_BNDERR 실패한 주소 바인딩된 검사 발생했음을 나타냅니다.

참고

일반적으로 발생하는 AppCrash에는 SEND_SIG_PRIV 와 함께 SIGKILL 신호인 9의 signal_status si_code값이 포함됩니다. 이 상태 OS가 메모리 사용 제한을 초과하여 애플리케이션을 중단했음을 나타냅니다. 애플리케이션 메모리 제한에 대한 자세한 내용은 상위 수준 애플리케이션의 메모리 사용을 참조하세요.

AppExits 해석

앱이 오류 없이 종료되면 signal_status 및 signal_code 필드가 없으며 exit_status 대신 설명에 종료 코드가 포함됩니다.

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

AppExits는 애플리케이션 업데이트, 디바이스 분리 또는 전원이 닫힌 API 사용 등의 여러 가지 이유로 발생할 수 있습니다. AppExit의 이유에 대한 인사이트를 얻을 수 있도록 종료 코드를 구현하는 것이 중요합니다.

AppExits를 해석하려면 오류 보고서의 설명 필드에 exit_code 값을 사용합니다. 앱이 종료 코드를 반환하는 경우 오류 보고서에서 exit_code 값을 사용하여 오류가 발생한 위치 또는 시기를 확인할 수 있습니다. 이 값을 사용하여 애플리케이션 코드 내에서 검색하여 오류 보고서에 제공된 값에 해당하는 종료 코드 메시지를 확인합니다. 그런 다음, 애플리케이션에서 종료 코드 메시지를 반환한 함수와 해당 함수를 반환한 이유를 찾습니다. return 문 및 해당 컨텍스트를 보면 오류 원인을 검색할 수 있습니다.

OS 이벤트

오류 데이터에는 애플리케이션이 실패하거나 다시 시작되도록 하여 애플리케이션에 영향을 줄 수 있는 기본 OS 및 하드웨어 이벤트도 포함됩니다. 이러한 이벤트에는 다음이 포함될 수 있습니다.

커널 오류로 인한 계획되지 않은 디바이스 재부팅
클라우드 OS 업데이트
일시적인 하드웨어 문제

OS 이벤트는 애플리케이션 오류가 OS 또는 하드웨어 문제의 결과인지 또는 애플리케이션 자체의 문제를 반영하는지 여부를 확인하는 데 도움이 되는 데이터에 포함됩니다. 이벤트 데이터에 디바이스가 안전 모드로 부팅된 것으로 표시되면 앱을 시작하지 못할 수 있습니다.

오류 데이터 탐색

오류 데이터를 분석하기 위한 스크립트 또는 도구를 개발하려고 하지만 오류를 보고하는 데 사용할 수 있는 디바이스가 많은 경우 Azure Sphere 샘플 애플리케이션을 사용하여 테스트를 위해 이러한 데이터를 생성할 수 있습니다. Azure Sphere 샘플 리포지토리의 Tutorials/ErrorReporting 샘플에서는 애플리케이션이 충돌할 때 보고된 오류를 분석하는 방법을 설명합니다. 추가 정보 지침에 따라 Visual Studio, Visual Studio Code 또는 명령줄을 사용하여 샘플을 빌드합니다.

디버거 없이 명령줄에서 앱을 배포하면 OS는 실패할 때마다 앱을 다시 시작합니다. 자주 실패하는 디바이스 하나가 다른 디바이스의 오류를 마스킹하지 않고 시간당 최대 8회 발생되도록 유사한 이벤트가 집계됩니다. 다음과 같이 디버깅하지 않고 명령줄에서 샘플을 배포할 수 있습니다.

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

오류 보고서 생성 및 다운로드

오류 및 이벤트 데이터는 매일 Azure Sphere Security Service에 업로드됩니다. Azure Sphere 보안 서비스와 통신하기 위해 Wi-Fi 또는 이더넷 을 사용하여 Azure Sphere 디바이스가 인터넷에 연결되어 있는지 확인합니다.

다음 명령을 실행하여 CSV 파일에 보고서를 다운로드합니다.
```
az sphere catalog download-error-report --destination error.csv
```
다운로드한 CSV 파일을 열고 구성 요소 ID를 찾습니다. 다음과 유사한 오류 설명이 표시됩니다.

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

오류 보고에 Azure Sphere 공용 API 를 사용할 수도 있습니다.

참고

최근에 보고된 이벤트를 다운로드할 수 있는 데 최대 24시간이 걸릴 수 있습니다.
디바이스가 NTP 서버에 연결하기 전에 이벤트 또는 오류가 발생하는 경우 AS3에 업로드된 원격 분석에 포함된 이벤트의 타임스탬프가 올바르지 않을 수 있습니다. AS3에서 다운로드한 후속 보고서의 StartTime 열에 잘못된 항목이 반영됩니다. 이 상황에서는 보고서의 EndTime 필드를 사용하여 이벤트가 발생한 시기를 예측하는 데 도움이 될 수 있습니다. 이 필드에는 클라우드 서비스가 업로드된 원격 분석을 수신하고 항상 유효한 날짜가 있는 시간이 포함됩니다.

오류 데이터 서식 지정

오류 보고서 파일의 타임스탬프 및 데이터 열은 일반적인 CSV 파일과 다르게 서식이 지정됩니다. Excel에서 결과를 보려면 새 열을 만들고 사용자 지정 수식을 추가하여 데이터의 서식을 다시 지정할 수 있습니다.

Excel에서 작동하도록 내보낸 CSV 파일의 타임스탬프 서식을 지정하려면 다음을 수행합니다.

새 타임스탬프 열을 만들고 사용자 지정 형식을 만듭니다.

yyyy/mm/dd hh:mm:ss
새 타임스탬프 열의 셀에 다음 수식을 추가하여 F2 셀 값을 열 및 행과 일치하도록 변경합니다.

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

설명 필드를 별도의 열로 분할하려면 다음 단계를 수행하여 F2 셀 값을 열 및 행과 일치하도록 변경합니다.

Shortname 또는 이와 유사한 새 열을 만들고 셀에 다음 수식을 추가합니다.

=TRIM(LEFT(F2,FIND("(",F2)-1))
row1 헤더의 이름이 매개 변수 값과 동일한 열을 만들고 각 열의 셀에 다음 수식을 추가합니다.

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

다음을 통해 공유