오류 데이터 수집 및 해석
Important
Azure Sphere(레거시) 설명서입니다. Azure Sphere(레거시)는 2027년 9월 27일에 사용 중지되며 사용자는 이 시간까지 Azure Sphere(통합)로 마이그레이션해야 합니다. TOC 위에 있는 버전 선택기를 사용하여 Azure Sphere(통합) 설명서를 볼 수 있습니다.
오류 및 이벤트 데이터는 매일 Azure Sphere Security Service에 업로드됩니다. 특정 테넌트에 대한 액세스 권한이 있는 사용자는 해당 테넌트에 대한 데이터를 다운로드할 수 있습니다. 이 보고서는 테넌트에 있는 모든 디바이스를 다룹니다.
각 보고서에는 최대 1,000개의 이벤트 또는 14일의 데이터가 포함되며, 이 중 먼저 도달합니다. 데이터를 파일에 쓰거나 스크립트 또는 애플리케이션에 파이프할 수 있습니다. CLI는 1,000개의 이벤트만 반환할 수 있습니다. Azure Sphere 공용 API를 사용하여 페이지에서 반환되는 최대 이벤트 수를 지정합니다.
다음과 같은 방법으로 디바이스에 영향을 주는 오류 및 기타 이벤트에 대한 데이터를 다운로드할 수 있습니다.
azsphere tenant download-error-report 명령을 사용합니다. 현재 테넌트 내의 디바이스에서 보고한 오류 및 이벤트에 대한 정보가 포함된 CSV 파일이 다운로드됩니다.
오류 보고에 Azure Sphere 공용 API 를 사용합니다. API 엔드포인트는 필요에 따라 구문 분석할 수 있는 JSON 개체를 반환합니다.
RTApps에서 오류 보고 데이터가 수집되지 않습니다. RTApps의 오류를 기록하려면 RTApps에서 오류 데이터를 네트워크 서비스에 기록할 수 있는 상위 수준 애플리케이션으로 오류를 전달하기 위해 코어 간 통신을 구현해야 합니다. 자세한 내용은 상위 수준 애플리케이션과 통신 및 실시간 지원 애플리케이션과 통신을 참조하세요.
사용 가능한 데이터 형식
각 오류 또는 이벤트에 대해 반환되는 데이터에는 다음이 포함됩니다.
| 데이터 | 설명 |
|---|---|
| 디바이스 ID | 이벤트가 발생한 디바이스의 ID입니다. |
| 이벤트 유형 | 이벤트가 계획되었는지 계획되지 않았는지 여부입니다. OS 및 앱 업데이트는 계획된 이벤트로 간주되지만 오류는 계획되지 않은 이벤트입니다. |
| Event Class | 이벤트가 발생한 소프트웨어 구성 요소: 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 해석
signal_status 및 signal_code AppCrash에 대한 대부분의 정보를 찾을 수 있습니다. 다음 단계를 수행합니다.
- signal_status Man 7 설명서를 사용하여 먼저 "표준 신호에 대한 신호 번호 매기기"라는 테이블을 살펴봅니다. x86/ARM 열의 오류 보고서에서
csvsignal_status 할당된 값을 검색합니다. 발견되면 맨 왼쪽 열에서 해당 신호 이름을 확인합니다. - "표준 신호"라는 레이블이 지정된 테이블까지 스크롤합니다. 이전에 결정된 신호 이름과 일치하고 테이블을 사용하여 신호가 나타내는 내용에 대한 자세한 정보를 수집합니다.
- 이전에 찾은 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에 대한 다음 추가 정보를 검색할 수 있습니다.
- 신호는 신호 맨 페이지에 대한 설명의 10번째 섹션에 설명되어 있습니다. 값 11의 signal_status SIGSEGV 신호에 해당합니다.
- SIGSEGV는 잘못된 메모리 참조가 발생했음을 나타냅니다(null 포인터일 수 있음).
- SI_Codes 각 signal_status 대한 SigAction man 페이지에 대한 설명의 세 번째 섹션에 설명되어 있습니다. 페이지에는 각 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 값을 사용하여 오류가 발생한 위치 또는 시기를 확인할 수 있습니다. 이 값을 사용하여 애플리케이션 코드 내에서 검색하여 오류 보고서에 제공된 값에 해당하는 종료 코드 메시지를 확인합니다. 그런 다음, 종료 코드 메시지를 반환한 애플리케이션의 함수와 해당 함수가 반환된 이유를 찾습니다. 반환 문 및 해당 컨텍스트를 보면 오류 원인을 검색할 수 있습니다.
OS 이벤트
오류 데이터에는 애플리케이션이 실패하거나 다시 시작되도록 하여 애플리케이션에 영향을 줄 수 있는 기본 OS 및 하드웨어 이벤트도 포함됩니다. 이러한 이벤트에는 다음이 포함될 수 있습니다.
- 커널 오류로 인한 계획되지 않은 디바이스 다시 부팅
- 업데이트 클라우드 OS
- 일시적인 하드웨어 문제
OS 이벤트는 애플리케이션 오류가 OS 또는 하드웨어 문제의 결과인지 또는 애플리케이션 자체의 문제를 반영하는지 확인하는 데 도움이 되도록 데이터에 포함됩니다. 이벤트 데이터에 디바이스가 안전 모드로 부팅된 것으로 표시되면 앱이 시작되지 않을 수 있습니다.
오류 데이터 탐색
오류 데이터를 분석하기 위한 스크립트 또는 도구를 개발하려고 하지만 오류를 보고하는 데 사용할 수 있는 디바이스가 많은 경우 Azure Sphere 샘플 애플리케이션을 사용하여 테스트를 위해 이러한 데이터를 생성할 수 있습니다. Azure Sphere 샘플 리포지토리의 Tutorials/ErrorReporting 샘플에서는 애플리케이션이 충돌할 때 보고된 오류를 분석하는 방법을 설명합니다. 추가 정보 지침에 따라 Visual Studio, Visual Studio Code 또는 명령줄을 사용하여 샘플을 빌드합니다.
디버거 없이 명령줄에서 앱을 배포하면 OS는 실패할 때마다 앱을 다시 시작합니다. 자주 실패하는 디바이스 하나가 다른 디바이스의 오류를 마스킹하지 않고 시간 창당 최대 8회 발생되도록 유사한 이벤트가 집계됩니다. 다음과 같이 디버깅하지 않고 명령줄에서 샘플을 배포할 수 있습니다.
azsphere device sideload deploy --image-package <path to image package for the app>
오류 보고서 생성 및 다운로드
오류 및 이벤트 데이터는 매일 Azure Sphere Security Service에 업로드됩니다. Azure Sphere 보안 서비스와 통신하기 위해 Wi-Fi 또는 이더넷을 사용하여 Azure Sphere 디바이스가 인터넷에 연결되어 있는지 확인합니다.
다음 명령을 실행하여 CSV 파일에 보고서를 다운로드합니다.
azsphere tenant 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)))