エラー データを収集して解釈する
エラーデータとイベント データは、毎日 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 時間で、最大は 1 時間枠あたり 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 列で、エラー レポート
csvの signal_status に割り当てられた値を検索します。 見つかったら、左端の列に対応する Signal 名を書き留めます。 - "Standard Signals" というラベルが付いたテーブルまでスクロールします。前に決定した Signal 名と一致し、テーブルを使用して、シグナルが示す内容に関する詳細情報を収集します。
- signal_codeの Man 7 ドキュメントと、以前に見つけた Signal 名で、対応する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 man ページ の説明の第 3 セクションで説明されています。 ページには各si_codeのインデックス番号は一覧表示されませんが、インデックス 1 から始まる各signal_statusカテゴリからカウントできます。 SIGSEGV のsi_codesの一覧 (インデックス 1 から始まる) を見ると、3 つ目がSEGV_BNDERRと一致していることがわかります。
- SEGV_BNDERRは、失敗したアドレスバインドチェック発生したことを示します。
メモ
一般的に検出される AppCrash には、signal_status値 9 が含まれています。これは SIGKILL シグナルであり、SEND_SIG_PRIV si_codeと共に です。 この状態は、OS がメモリ使用量の制限を超えたためにアプリケーションを強制終了したことを示します。 アプリケーションのメモリ制限の詳細については、「 上位レベルのアプリケーションでのメモリの使用」を参照してください。
AppExits の解釈
アプリがエラーなしで終了すると、signal_statusフィールドとsignal_codeフィールドは存在せず、exit_statusの代わりに Description に終了コードが含まれます。
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 サンプルでは、アプリケーションがクラッシュしたときに報告されたエラーを分析する方法について説明します。 Readme の指示に従って、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 Public API を使用してエラー報告を行うこともできます。
メモ
- 最近報告されたイベントがダウンロードできるようになるには、最大で 24 時間かかる場合があります。
- デバイスが NTP サーバーに接続する前にイベントまたはエラーが発生した場合、AS3 にアップロードされたテレメトリに含まれるイベントのタイムスタンプが正しくない可能性があります。 これは、AS3 からダウンロードされた後続のレポートの StartTime 列の正しくないエントリに反映されます。 この状況では、レポートの EndTime フィールドを使用して、イベントが発生したタイミングの見積もりを支援します。 このフィールドには、クラウド サービスがアップロードされたテレメトリを受信した時刻が含まれており、常に有効な日付が設定されます。
エラー データの書式設定
エラー レポート ファイルのタイムスタンプとデータ列は、一般的な CSV ファイルとは異なる形式で書式設定されます。 Excel で結果を表示する場合は、新しい列を作成し、カスタム数式を追加することで、データを再フォーマットできます。
エクスポートされた CSV ファイルのタイムスタンプを書式設定して Excel で動作させるには:
新しい Timestamp 列を作成し、そのカスタム形式を作成します。
yyyy/mm/dd hh:mm:ss新しい Timestamp 列のセルに次の数式を追加し、列と行に一致するように 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)))