エラー データを収集して解釈する
重要
これは Azure Sphere (レガシ) のドキュメントです。 Azure Sphere (レガシ) は 2027 年 9 月 27 日に 再提供されておりユーザーは現時点で Azure Sphere (統合) に移行する必要があります。 TOC の上にある Version セレクターを使用して、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 からエラーを通信する必要があります。 詳細については、 高度なアプリケーションを使用したcommunicate およびリアルタイム対応アプリケーションでの Communicate に関するページを参照してください。
利用可能なデータの種類
各エラーまたはイベントについて返されるデータには、次のものがあります。
| データ | 説明 |
|---|---|
| Device ID | イベントが発生したデバイスの ID。 |
| イベントの種類 | イベントが予定、または予定外のいずれであるか。 OS とアプリの更新は予定イベントと見なされますが、エラーは予定外イベントです。 |
| Event Class | イベントが発生したソフトウェア コンポーネント:OS またはアプリケーション。 |
| イベント数 | 開始時刻および終了時刻で指定された期間内に発生したイベントの回数。 |
| 説明 | イベントに関する情報。 このフィールドは汎用的で、イベントとそのソースによって異なります。 アプリケーションの場合、これには、終了コード、信号ステータス、信号コードが含まれる可能性がありますが、このフィールドの正確な内容は固定されていません。 これには、イベントに関する情報が含まれており、時間枠内で最初に発生したイベントからの情報です。 |
| Start Time | イベント ウィンドウが開始された日時 (UTC)。 |
| End Time | イベント ウィンドウが終了した日時 (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。 エラーを示します。 |
| code | 親シグナル状態内の詳細なクラッシュ状態を示します。 |
| component_id | クラッシュしたソフトウェア コンポーネントの GUID。 |
| pc_modulename + offset | モジュールの名前と、クラッシュが発生したコードを含むモジュールへのオフセット。 |
| lr_modulename+ offset | モジュールの名前と、呼び出し元の関数である可能性があるモジュールへのオフセット。 |
AppCrashes の解釈
AppCrash に関するほとんどの情報は、signal_statusとsignal_codeで確認できます。 次のステップを実行します。
- signal_statusの Man 7 ドキュメントを使用して、まず「Signal Numbering for Standard Signals」というラベルの表を参照してください。x86/ARM 列で、エラー レポート
csvのsignal_statusに割り当てられている値を検索します。 見つかったら、左端の列に対応するシグナル名を書き留めます。 - "Standard Signals" というラベルのテーブルまでスクロールします。前に決定したシグナル名と一致し、テーブルを使用して、シグナルが示す内容に関する詳細情報を収集します。
- 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 man ページの説明の 3 番目のセクション で説明します。 ページには各si_codeのインデックス番号は表示されませんが、インデックス 1 から始まる各signal_statusカテゴリからカウントできます。 SIGSEGV のsi_codesの一覧 (インデックス 1 から始まる) を見ると、3 番目がSEGV_BNDERRと一致していることがわかります。
- SEGV_BNDERRは、失敗したアドレス バインド チェックが発生したことを示します。
Note
よく見られる AppCrash には、signal_status値 9 が含まれています。これは SIGKILL シグナルであり、SEND_SIG_PRIV 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 の理由を把握できるように、 exit コード を実装することが重要です。
AppExits を解釈するには、エラー レポートの [説明] フィールドのexit_code値を使用します。 アプリから終了コードが返された場合は、エラー レポートのexit_codeの値を使用して、エラーが発生した場所またはタイミングを判断できます。 この値を使用して、アプリケーション コード内で検索し、エラー レポートで指定された値に対応する終了コード メッセージを確認します。 次に、終了コード メッセージを返したアプリケーション内の関数とその理由を見つけます。 return ステートメントとそのコンテキストを表示することで、エラーの理由を検出できる場合があります。
OS イベント
エラー データには、エラーや再起動を発生させてアプリケーションに影響を与える可能性のある、基になる OS およびハードウェアのイベントも含まれます。 このようなイベントとしては、次のようなものがあります。
- カーネルのエラーによって発生する予定外のデバイスの再起動
- クラウド OS の更新
- 一時的なハードウェアの問題
OS イベントはデータに含まれており、アプリケーション エラーが OS またはハードウェアの問題の結果であるか、アプリケーション自体の問題を反映しているかを判断するのに役立ちます。 イベント データに、デバイスがセーフ モードで起動されたことが示された場合、アプリを起動できない可能性があります。
エラー データを調べる
エラー データを分析するためのスクリプトまたはツールを開発する予定であっても、エラーを報告できるデバイスが多数ない場合は、Azure Sphere サンプル アプリケーションを使用して、テスト用にこのようなデータを生成できます。 Azure Sphere サンプル リポジトリの Tutorials/ErrorReporting サンプルアプリケーションがクラッシュしたときに報告されたエラーを分析する方法について説明します。 Readme の指示に従って、Visual Studio、Visual Studio Code、またはコマンド ラインを使用してサンプルをビルドします。
デバッガーを使用しないでアプリをデプロイすると、OS はエラーが発生するたびに再起動します。 同様のイベントが集計され、頻繁に失敗する 1 台のデバイスが他のデバイスからのエラーをマスクせず、最大で 1 時間枠あたり 8 回発生します。 次のように、デバッグを行わずにコマンド ラインからサンプルをデプロイできます。
azsphere device sideload deploy --image-package <path to image package for the app>
エラー レポートの生成とダウンロード
エラーおよびイベントのデータは毎日、Azure Sphere Security Service にアップロードされます。 Azure Sphere セキュリティ サービスと通信するために、 Wi-Fi または Ethernet を使用して、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 を使用することもできます。
Note
- 最近報告されたイベントがダウンロードできるようになるまでに最大 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))行 1 のヘッダーの名前がパラメーター値と同じである列を作成し、各列のセルに次の数式を追加します。
=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)))