Сбор и интерпретация данных об ошибках

  • Статья

Данные об ошибках и событиях отправляются в службу безопасности Azure Sphere ежедневно. Любой пользователь, имеющий доступ к конкретному клиенту, может скачать данные для этого клиента. Отчет охватывает все устройства в клиенте.

Каждый отчет содержит не более 1000 событий или 14 дней данных, в зависимости от того, какое из них будет достигнуто первым. Данные могут записываться в файл или передаваться по конвейеру в скрипт или приложение. Cli может возвращать только 1000 событий. Используйте общедоступный API Azure Sphere, чтобы указать максимальное количество событий, возвращаемых на странице.

Скачать данные об ошибках и других событиях, влияющих на устройства, можно следующими способами:

  • С помощью команды azsphere tenant download-error-report . Загружается CSV-файл, содержащий сведения об ошибках и событиях, сообщаемых устройствами в текущем клиенте.

  • С помощью общедоступного API Azure Sphere для создания отчетов об ошибках. Конечная точка API возвращает объект JSON, который можно проанализировать в соответствии с вашими потребностями.

Данные отчетов об ошибках не собираются из приложений RTApp. Если вы хотите регистрировать ошибки из приложений RTApps, необходимо реализовать межядерное взаимодействие для передачи ошибок из приложений RTApp в приложение высокого уровня, из которого данные об ошибках могут быть зарегистрированы в сетевых службах. Дополнительные сведения см. в разделах Взаимодействие с приложением высокого уровня и Взаимодействие с приложением с поддержкой реального времени .

Доступные типы данных

Данные, возвращаемые для каждой ошибки или события, включают следующие:

Данных Описание
Идентификатор устройства Идентификатор устройства, на которое произошло событие.
Тип события Было ли мероприятие запланированным или незапланированным. Обновления ОС и приложений считаются запланированными событиями, а ошибки — незапланированными событиями.
Класс событий Программный компонент, который столкнулся с событием: ОС или приложение.
Число событий Количество случаев, когда событие произошло в течение периода, разделенного по StartTime и EndTime.
Описание Сведения о событии. Это поле является универсальным и зависит от события и его источника. Для приложений он может содержать код выхода, состояние сигнала и код сигнала, но точное содержимое поля не фиксируется. Он содержит сведения о событии и относится к первому вхождаю события во временном окне.
Время начала Дата и время (в формате UTC), с которого началось окно события.
Время окончания Дата и время (в формате UTC), на которые закончилось окно события.

Время начала и время окончания определяют период времени, в течение которого объединяются данные о событиях. Окно для любой агрегированной группы событий может составлять до 24 часов, а максимальное — 8 вхождений на период времени.

События приложения

К событиям приложения относятся обновления приложений, загруженные в облако, а также сбои, выходы и другие типы сбоев приложений.

Обновления приложений — это запланированные события. Для события AppUpdate поле Описание содержит AppUpdate.

Сбои приложений, выходы, сбои запуска и аналогичные события являются незапланированными событиями. Для незапланированного события содержимое поля Description зависит от приложения, которое столкнулось с событием. В следующей таблице перечислены поля, которые могут присутствовать в поле Описание для незапланированного события.

Данных Описание
exit_status или exit_code Выйти из состояния или кода, сообщаемого приложением.
signal_status Целое число, описывающее причину сбоя высокого уровня, возвращаемую ОС. Список состояний можно найти в документации по 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)

Данных Описание
Пк Счетчик программ. Указывает на адрес инструкции, которая вызвала сбой.
Lr Регистрация ссылок. Возможно, указывает на возвращаемый адрес в вызывающей функции.
Sp Указатель стека. Указывает на верхнюю часть стека вызовов.
signo Сигнал POSIX. Указывает тип ошибки.
Errno POSIX errno. Указывает на ошибку.
Код Указывает подробное состояние сбоя в родительском состоянии сигнала.
component_id GUID программного компонента, который произошел сбой.
pc_modulename+смещение Имя модуля и смещение модуля, содержащего код, в котором произошел сбой.
lr_modulename+смещение Имя модуля и смещение модуля, который мог быть вызывающей функцией.

Интерпретация appCrashes

Большую часть сведений о AppCrash можно найти в signal_status и signal_code. Выполните следующие действия.

  1. В документации по Man 7 для signal_status сначала просмотрите таблицу с меткой "Нумерирование сигналов для стандартных сигналов". В столбце x86/ARM найдите значение, присвоенное signal_status в отчете csvоб ошибке . После обнаружения обратите внимание на соответствующее имя Signal в крайнем левом столбце.
  2. Прокрутите вверх до таблицы с меткой "Стандартные сигналы". Совпадите ранее определенное имя сигнала и используйте таблицу для сбора дополнительных сведений о том, что указывает сигнал.
  3. В документации по Человеку 7 для signal_code и имени сигнала, который вы нашли ранее, найдите соответствующий список si_codes.
  4. Используйте значение, присвоенное signal_code в файле отчета об csv ошибках, чтобы определить, какой код соответствует сообщению об ошибке.

Например, рассмотрим следующее описание 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:

  1. Сигналы описаны в 10-м разделе описания страницы signal man. Signal_status значения 11 соответствует сигналу SIGSEGV.
  2. SIGSEGV указывает, что произошла недопустимая ссылка на память (часто это может быть пустой указатель).
  3. SI_Codes описаны во 3-м разделе описания страницы пользователя SigAction для каждого signal_status. Хотя на странице не указан номер индекса для каждой si_code, можно считать из каждой signal_status категории, начиная с индекса 1. Просмотрев список si_codes для SIGSEGV (начиная с индекса 1), можно увидеть, что третий соответствует SEGV_BNDERR.
  4. SEGV_BNDERR указывает, что произошел сбой, связанный с адресом проверка.

Примечание

Часто встречающаяся строка AppCrash включает signal_status значение 9, которое является сигналом SIGKILL, а также SEND_SIG_PRIV si_code. Это состояние указывает на то, что ОС убила приложение из-за превышения предельного объема использования памяти. Дополнительные сведения об ограничениях памяти приложений см. в статье Использование памяти в высокоуровневых приложениях.

Интерпретация 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 и его контекст, вы можете обнаружить причину ошибки.

События ОС

Данные об ошибках также включают базовые события ОС и оборудования, которые могут повлиять на приложение, вызвав его сбой или перезапуск. Такие события могут включать следующие:

  • Незапланированные перезагрузки устройства, вызванные ошибками ядра
  • Обновления облачной ОС
  • Временные проблемы с оборудованием

События ОС включаются в данные, чтобы определить, являются ли ошибки приложения результатом проблемы с ОС или оборудованием или отражают проблемы с самим приложением. Если данные события показывают, что устройство загружено в безопасный режим, возможно, приложения не смогут запуститься.

Изучение данных об ошибках

Если вы планируете разрабатывать скрипты или средства для анализа данных об ошибках, но у вас нет большого количества устройств, доступных для сообщения об ошибках, вы можете использовать примеры приложений Azure Sphere для создания таких данных для тестирования. В примере Tutorials/ErrorReporting в репозитории примеров Azure Sphere объясняется, как анализировать ошибки, сообщаемые при сбое приложения. Следуйте инструкциям в файле сведений, чтобы создать пример с помощью Visual Studio, Visual Studio Code или командной строки.

При развертывании приложения из командной строки без отладчика ОС перезапускает его при каждом сбое. Аналогичные события агрегируются таким образом, что одно часто завершающееся сбоем устройство не маскирует ошибки от других устройств, а максимальное количество — восемь вхождений за период времени. Пример можно развернуть из командной строки без отладки, как показано ниже.

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

Создание и скачивание отчета об ошибке

Данные об ошибках и событиях отправляются в службу безопасности Azure Sphere ежедневно. Убедитесь, что устройство Azure Sphere подключено к Интернету с помощью Wi-Fi или Ethernet для связи со службой безопасности Azure Sphere.

  1. Выполните следующую команду, чтобы скачать отчет в CSV-файл:

    azsphere tenant download-error-report --destination error.csv

  2. Откройте скачанный CSV-файл и найдите идентификатор компонента. Должно появиться описание ошибки, аналогичное следующему:

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

Вы также можете использовать общедоступный API Azure Sphere для создания отчетов об ошибках.

Примечание

  • На то, что недавно сообщаемые события будут доступны для скачивания, может потребоваться до 24 часов.
  • Если событие или ошибка возникают перед подключением устройства к NTP-серверу, метка времени события, содержащегося в телеметрии, отправленной в AS3, может быть неправильной. Это будет отражено в неправильной записи в столбце StartTime в последующем отчете, скачанном из AS3. В этой ситуации используйте поле EndTime отчета, чтобы помочь в оценке времени возникновения события. Это поле содержит время получения облачными службами отправленной телеметрии и всегда будет иметь действительную дату.

Форматирование данных об ошибках

Метки времени и столбцы данных в файле отчета об ошибках форматируются иначе, чем в обычном CSV-файле. Если вы хотите просмотреть результаты в Excel, можно переформатировать данные, создав новые столбцы и добавив пользовательские формулы.

Чтобы отформатировать метки времени в экспортируемом CSV-файле для работы с Excel, выполните следующие действия:

  1. Создайте новый столбец Метка времени и создайте для него пользовательский формат:

    yyyy/mm/dd hh:mm:ss

  2. Добавьте следующую формулу в ячейки в новом столбце Метка времени, изменив значение ячейки F2 в соответствии с столбцом и строкой:

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

Чтобы разделить поле Описание на отдельные столбцы, выполните следующие действия, изменив значение ячейки F2 в соответствии со столбцом и строкой.

  1. Создайте столбец с именем Shortname или что-то подобное и добавьте в ячейки следующую формулу:

    =TRIM(LEFT(F2,FIND("(",F2)-1))

  2. Создайте столбцы, в которых заголовки 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)))