Coletar e interpretar dados de erro
Os dados de erro e evento são carregados diariamente no Serviço de Segurança do Azure Sphere. Qualquer pessoa que tenha acesso a um catálogo específico pode baixar os dados desse catálogo. O relatório aborda todos os dispositivos no catálogo.
Cada relatório contém um máximo de 1.000 eventos ou 14 dias de dados, o que for atingido primeiro. Os dados podem ser gravados em um arquivo ou canalizados para um script ou aplicativo. A CLI pode retornar apenas 1.000 eventos. Use a API Pública do Azure Sphere para especificar o número máximo de eventos retornados na página.
Você pode baixar dados sobre os erros e outros eventos que afetam seus dispositivos das seguintes maneiras:
Usando o comando az sphere catalog download-error-report . Um arquivo CSV que contém informações sobre erros e eventos relatados por dispositivos no catálogo atual é baixado.
Usando a API Pública do Azure Sphere para relatórios de erros. O ponto de extremidade da API retorna um objeto JSON que você pode analisar de acordo com suas necessidades.
Nenhum erro de relatório de dados é coletado de RTApps. Se você quiser registrar erros de RTApps, precisará implementar comunicações inter-core para comunicar erros dos RTApps ao aplicativo de alto nível, dos quais os dados de erro podem ser conectados aos serviços de rede.
Tipos de dados disponíveis
Os dados retornados para cada erro ou evento incluem o seguinte:
| Dados | Descrição |
|---|---|
| ID do dispositivo | ID do dispositivo que encontrou o evento. |
| Tipo de evento | Se o evento foi planejado ou não planejado. As atualizações do sistema operacional e do aplicativo são consideradas eventos planejados, enquanto os erros são eventos não planejados. |
| Classe de evento | Componente de software que encontrou o evento: sistema operacional ou aplicativo. |
| Contagem de Eventos | Número de vezes que o evento ocorreu no período delimitado por StartTime e EndTime. |
| Descrição | Informações sobre o evento. Esse campo é genérico e varia dependendo do evento e de sua origem. Para aplicativos, ele pode conter o código de saída, o sinal status e o código de sinal, mas o conteúdo exato do campo não é corrigido. Isso contém informações sobre o evento e é da primeira ocorrência do evento na janela de tempo. |
| Hora de Início | Data e hora (em UTC) em que a janela de eventos começou. |
| Hora de Término | Data e hora (em UTC) em que a janela do evento terminou. |
A Hora de Início e a Hora de Término definem uma janela de tempo durante a qual os dados do evento são agregados. A janela para qualquer grupo agregado de eventos pode ser de até 24 horas e o máximo é de 8 ocorrências por janela de tempo.
Eventos de aplicativo
Os eventos de aplicativo incluem atualizações de aplicativo carregadas na nuvem, juntamente com falhas, saídas e outros tipos de falhas de aplicativo.
As atualizações de aplicativo são eventos planejados. Para um evento AppUpdate, o campo Description contém AppUpdate.
Falhas de aplicativo, saídas, falhas de inicialização e eventos semelhantes são eventos não planejados. Para um evento não planejado, o conteúdo do campo Descrição depende do aplicativo que encontrou o evento. A tabela a seguir lista os campos que podem estar presentes no campo Descrição para um evento não planejado.
| Dados | Descrição |
|---|---|
| exit_status ou exit_code | Saia status ou código relatado pelo aplicativo. |
| signal_status | Inteiro que descreve o motivo de alto nível para a falha, retornado pelo sistema operacional. Você pode encontrar uma lista de status na documentação do Man 7 ou em outros recursos do Linux. |
| signal_code | Inteiro que indica o status de falha detalhado no status de sinal pai. Consulte a documentação do Man 7 ou outros recursos do Linux para obter detalhes. |
| component_id | GUID do componente de software que falhou. |
| image_id | GUID da imagem que estava em execução no momento do erro. |
As informações específicas em uma descrição do AppCrash dependem da origem do acidente. Para a maioria dos falhas, a descrição é semelhante à seguinte:
AppCrash (exit_status=11; signal_status=11; signal_code=3; component_id=685f13af-25a5-40b2-8dd8-8cbc253ecbd8; image_id=7053e7b3-d2bb-431f-8d3a-173f52db9675)
Em alguns casos, uma falha dispara dados de erro adicionais, como o seguinte, que complementa os dados no exemplo 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)
| Dados | Descrição |
|---|---|
| Pc | Contador de Programas. Aponta para o endereço da instrução que desencadeou a falha. |
| Lr | Link Register. Possivelmente aponta para o endereço retornado na função de chamada. |
| Sp | Ponteiro stack. Aponta para a parte superior da pilha de chamadas. |
| signo | Sinal POSIX. Indica o tipo de erro. |
| Errno | POSIX errno. Indica um erro. |
| Código | Indica o status de falha detalhado no status de sinal pai. |
| component_id | GUID do componente de software que falhou. |
| pc_modulename+deslocamento | Nome do módulo e deslocamento para o módulo que contém o código em que ocorreu a falha. |
| lr_modulename+deslocamento | Nome do módulo e deslocamento para o módulo que pode ter sido a função de chamada. |
Interpretar AppCrashes
Você pode encontrar a maioria das informações sobre um AppCrash no signal_status e signal_code. Siga estas etapas:
- Usando a documentação do Homem 7 para signal_status, primeiro examine a tabela rotulada como "Numeração de Sinal para Sinais Padrão". Na coluna x86/ARM, pesquise o valor atribuído ao signal_status no relatório
csvde erro . Depois de encontrado, observe o nome de sinal correspondente na coluna mais à esquerda. - Role até a tabela rotulada como "Sinais Padrão". Corresponda ao nome de sinal determinado anteriormente e use a tabela para coletar mais informações sobre o que o sinal indica.
- Na documentação Do Homem 7 para signal_code e o nome do sinal que você encontrou anteriormente, localize a lista correspondente de si_codes.
- Use o valor atribuído ao signal_code no arquivo de relatório
csvde erro para determinar qual código corresponde à mensagem de erro.
Por exemplo, considere a seguinte descrição do 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 a documentação do Homem 7, você pode descobrir as seguintes informações adicionais sobre o AppCrash:
- Os sinais são descritos na 10ª seção da descrição da página Homem de Sinal. Uma signal_status do valor 11 corresponde a um sinal SIGSEGV.
- O SIGSEGV indica que ocorreu uma referência de memória inválida (isso geralmente pode ser um ponteiro nulo).
- SI_Codes são descritos na 3ª seção da descrição da página SigAction man para cada signal_status. Embora a página não liste um número de índice para cada si_code, você pode contar de cada categoria signal_status começando no índice 1. Olhando para a lista de si_codes para SIGSEGV (começando no índice 1), você pode ver que o terceiro corresponde a um SEGV_BNDERR.
- SEGV_BNDERR indica que ocorreu um marcar de endereço com falha.
Nota
Um AppCrash comumente encontrado inclui um valor signal_status de 9, que é um sinal SIGKILL, juntamente com o SEND_SIG_PRIV si_code. Esse status indica que o sistema operacional matou o aplicativo porque excedeu seu limite de uso de memória. Para saber mais sobre os limites de memória do aplicativo, consulte Uso de memória em aplicativos de alto nível.
Interpretar AppExits
Quando um aplicativo sai sem erro, os campos signal_status e signal_code não estão presentes e, em vez de um exit_status, a Descrição contém um código de saída:
AppExit (exit_code=0; component_id=685f13af-25a5-40b2-8dd8-8cbc253ecbd8; image_id=0a7cc3a2-f7c2-4478-8b02-723c1c6a85cd)
O AppExits pode ocorrer por vários motivos, como uma atualização do aplicativo, um dispositivo que está sendo desconectado ou o uso da API de desligamento, entre outros. É importante implementar códigos de saída para que você possa obter informações sobre os motivos de um AppExit.
Para interpretar AppExits, use o valor exit_code no campo Descrição do relatório de erro. Se o aplicativo retornar um código de saída, você poderá usar o valor do exit_code no relatório de erro para determinar onde ou quando ocorreu o erro. Usando esse valor, pesquise no código do aplicativo para ver qual mensagem de código de saída corresponde ao valor fornecido no relatório de erro. Em seguida, procure encontrar qual função no aplicativo retornou a mensagem de código de saída e por que ela o fez. Ao exibir a instrução de retorno e seu contexto, talvez você possa descobrir o motivo do erro.
Eventos do sistema operacional
Os dados de erro também incluem eventos subjacentes de sistema operacional e hardware que podem afetar seu aplicativo, fazendo com que ele falhe ou reinicie. Esses eventos podem incluir o seguinte:
- Reinicializações de dispositivo não planejadas causadas por erros de kernel
- Atualizações do sistema operacional na nuvem
- Problemas de hardware transitórios
Os eventos do sistema operacional são incluídos nos dados para ajudar você a determinar se os erros de aplicativo são resultado de um problema de sistema operacional ou hardware ou refletem problemas com o próprio aplicativo. Se os dados de evento mostrarem que um dispositivo foi inicializado para o Modo Seguro, seus aplicativos poderão não ser capazes de iniciar.
Explorar dados de erro
Se você planeja desenvolver scripts ou ferramentas para analisar dados de erro, mas não tiver um grande número de dispositivos disponíveis para relatar erros, poderá usar os aplicativos de exemplo do Azure Sphere para gerar esses dados para testes. O exemplo Tutoriais/ErrorReporting no repositório de exemplos do Azure Sphere explica como analisar erros relatados quando o aplicativo falha. Siga as instruções no readme para criar o exemplo usando o Visual Studio, Visual Studio Code ou a linha de comando.
Quando você implanta o aplicativo da linha de comando sem um depurador, o sistema operacional o reinicia sempre que falha. Eventos semelhantes são agregados para que um dispositivo com falha frequente não mascara erros de outros e o máximo é oito ocorrências por janela de tempo. Você pode implantar o exemplo da linha de comando sem depuração, da seguinte maneira:
az sphere device sideload deploy --image-package <path to image package for the app>
Gerar e baixar relatório de erro
Os dados de erro e evento são carregados diariamente no Serviço de Segurança do Azure Sphere. Verifique se o dispositivo do Azure Sphere está conectado à Internet usando Wi-Fi ou Ethernet para se comunicar com o Serviço de Segurança do Azure Sphere.
Execute o seguinte comando para baixar o relatório em um arquivo CSV:
az sphere catalog download-error-report --destination error.csvAbra o arquivo CSV baixado e procure sua ID do componente. Você deve ver uma descrição de erro semelhante à seguinte:
AppExit (exit_code=0; component_id=685f13af-25a5-40b2-8dd8-8cbc253ecbd8; image_id=6d2646aa-c0ce-4e55-b7d6-7c206a7a6363)
Você também pode usar a API Pública do Azure Sphere para relatórios de erros.
Nota
- Pode levar até 24 horas para que eventos relatados recentemente estejam disponíveis para download.
- Se ocorrer um evento ou erro antes de o dispositivo se conectar com um servidor NTP, o carimbo de data/hora do evento contido na telemetria carregada no AS3 poderá estar incorreto. Isso será refletido em uma entrada incorreta na coluna StartTime no relatório subsequente baixado do AS3. Nessa situação, use o campo EndTime do relatório para ajudar a estimar quando o evento ocorreu. Esse campo contém a hora em que os serviços de nuvem receberam a telemetria carregada e sempre terão uma data válida.
Formatar dados de erro
Os carimbos de data/hora e colunas de dados no arquivo de relatório de erro são formatados de forma diferente de um arquivo CSV típico. Se você quiser exibir os resultados no Excel, poderá reformatar os dados criando novas colunas e adicionando fórmulas personalizadas.
Para formatar os carimbos de data/hora no arquivo CSV exportado para trabalhar com o Excel:
Crie uma nova coluna de carimbo de data/hora e crie um formato personalizado para ela:
yyyy/mm/dd hh:mm:ssAdicione a seguinte fórmula às células na nova coluna carimbo de data/hora, alterando o valor da célula F2 para corresponder à coluna e à linha:
=(DATEVALUE(LEFT(RawErrorReport!F2,10))+TIMEVALUE(RIGHT(RawErrorReport!F2,8)))
Para dividir o campo Descrição em colunas separadas, siga estas etapas, alterando o valor da célula F2 para corresponder à coluna e à linha:
Crie uma nova coluna chamada Shortname ou algo semelhante e adicione a seguinte fórmula às células:
=TRIM(LEFT(F2,FIND("(",F2)-1))Crie colunas nas quais os cabeçalhos row1 têm os mesmos nomes que os valores de parâmetro e adicione a seguinte fórmula às células em cada uma das colunas:
=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)))