Mengumpulkan dan menginterpretasikan data kesalahan
Data kesalahan dan kejadian diunggah ke Azure Sphere Security Service setiap hari. Siapa pun yang memiliki akses ke katalog tertentu kemudian dapat mengunduh data untuk katalog tersebut. Laporan ini mencakup semua perangkat dalam katalog.
Setiap laporan berisi maksimal 1.000 kejadian atau data 14 hari, mana pun yang tercapai terlebih dahulu. Data dapat ditulis ke file atau disalurkan ke skrip atau aplikasi. CLI hanya dapat mengembalikan 1.000 acara. Gunakan API Publik Azure Sphere untuk menentukan jumlah maksimum kejadian yang dikembalikan pada halaman.
Anda dapat mengunduh data tentang kesalahan dan kejadian lain yang memengaruhi perangkat Anda dengan cara berikut:
Dengan menggunakan perintah unduhan-kesalahan-laporan katalog bola az . File CSV yang berisi informasi tentang kesalahan dan kejadian yang dilaporkan oleh perangkat dalam katalog saat ini diunduh.
Dengan menggunakan API Publik Azure Sphere untuk pelaporan kesalahan. Titik akhir API mengembalikan objek JSON yang dapat Anda pilah sesuai dengan kebutuhan Anda.
Tidak ada data pelaporan kesalahan yang dikumpulkan dari RTApps. Jika Anda ingin mencatat kesalahan dari RTApps, Anda harus menerapkan komunikasi antar-inti untuk mengkomunikasikan kesalahan dari RTApps ke aplikasi tingkat tinggi, dari mana data kesalahan dapat dicatat ke layanan jaringan.
Tipe data yang tersedia
Data yang dikembalikan untuk setiap kesalahan atau kejadian mencakup hal berikut:
| Data | Deskripsi |
|---|---|
| ID Perangkat | ID perangkat yang menemui kejadian tersebut. |
| Tipe Kejadian | Apakah acara direncanakan atau tidak direncanakan. Pembaruan APLIKASI dan OS dianggap sebagai acara yang direncanakan, sedangkan kesalahan adalah kejadian yang tidak direncanakan. |
| Kelas Acara | Komponen perangkat lunak yang menemukan kejadian: OS atau aplikasi. |
| Jumlah Acara | Berapa kali kejadian terjadi dalam periode yang dipisahkan oleh StartTime dan EndTime. |
| Deskripsi | Informasi tentang acara. Bidang ini umum dan bervariasi tergantung pada acara dan sumbernya. Untuk aplikasi, kode ini mungkin berisi kode keluar, status sinyal, dan kode sinyal, tetapi konten bidang yang tepat tidak diperbaiki. Ini berisi informasi tentang acara dan berasal dari kejadian pertama dalam jendela waktu. |
| Waktu Mulai | Tanggal dan waktu (di UTC) di mana jendela acara dimulai. |
| Waktu Selesai | Tanggal dan waktu (di UTC) di mana jendela acara berakhir. |
Waktu Mulai dan Waktu Akhir menentukan jendela waktu saat data kejadian diagregat. Jendela untuk sekelompok acara agregat dapat mencapai 24 jam dan maksimum adalah 8 kemunculan per jendela waktu.
Kejadian aplikasi
Kejadian aplikasi mencakup pembaruan aplikasi yang dimuat awan bersama dengan crash, keluar, dan jenis kegagalan aplikasi lainnya.
Pembaruan aplikasi adalah acara yang direncanakan. Untuk acara AppUpdate, bidang Deskripsi berisi AppUpdate.
Aplikasi mengalami crash, keluar, kegagalan start-up, dan kejadian serupa adalah kejadian yang tidak terencana. Untuk acara yang tidak dienkripsi, konten bidang Deskripsi bergantung pada aplikasi yang mengalami kejadian. Tabel berikut ini mencantumkan bidang yang mungkin ada dalam bidang Deskripsi untuk acara yang tidak diencana.
| Data | Deskripsi |
|---|---|
| exit_status atau exit_code | Status keluar atau kode yang dilaporkan oleh aplikasi. |
| signal_status | Bilangan bulat yang menjelaskan alasan tingkat tinggi untuk crash, yang dikembalikan oleh OS. Anda dapat menemukan daftar status dalam dokumentasi Man 7 atau sumber daya Linux lainnya. |
| signal_code | Bilangan bulat yang menunjukkan status crash mendetail dalam status sinyal induk. Lihat dokumentasi Man 7 atau sumber daya Linux lainnya untuk detailnya. |
| component_id | GUID komponen perangkat lunak yang mengalami crash. |
| image_id | GUID gambar yang berjalan pada saat kesalahan. |
Informasi spesifik dalam deskripsi AppCrash bergantung pada sumber crash. Untuk sebagian besar crash, deskripsinya terlihat seperti berikut ini:
AppCrash (exit_status=11; signal_status=11; signal_code=3; component_id=685f13af-25a5-40b2-8dd8-8cbc253ecbd8; image_id=7053e7b3-d2bb-431f-8d3a-173f52db9675)
Dalam beberapa kasus, crash memicu data kesalahan tambahan, seperti berikut ini, yang melengkapi data dalam contoh sebelumnya:
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)
| Data | Deskripsi |
|---|---|
| Pc | Program Counter. Mengarah ke alamat instruksi yang memicu crash. |
| Lr | Daftar Tautan. Mungkin menunjuk ke alamat pengembalian dalam fungsi panggilan. |
| Sp | Penunjuk Tumpuk. Menunjuk ke bagian atas tumpukan panggilan. |
| signo | Sinyal POSIX. Menunjukkan tipe kesalahan. |
| errno | POSIX errno. Menunjukkan kesalahan. |
| Kode | Menunjukkan status crash mendetail dalam status sinyal induk. |
| component_id | GUID komponen perangkat lunak yang mengalami crash. |
| pc_modulename+offset | Nama modul dan offset ke dalam modul yang berisi kode tempat crash terjadi. |
| lr_modulename+offset | Nama modul dan offset ke dalam modul yang mungkin telah menjadi fungsi panggilan. |
Menginterpretasikan AppCrash
Anda bisa menemukan sebagian besar informasi tentang AppCrash di signal_status dan signal_code. Ikuti langkah-langkah ini:
- Menggunakan dokumentasi Man 7 untuk signal_status, lihat tabel berlabel "Penomoran Sinyal untuk Sinyal Standar." Di kolom x86/ARM, cari nilai yang ditetapkan ke signal_status dalam laporan
csvkesalahan. Setelah ditemukan, perhatikan nama Sinyal yang terkait di kolom paling kiri. - Gulir ke atas ke tabel berlabel "Sinyal Standar." Cocokkan nama Sinyal yang ditentukan sebelumnya dan gunakan tabel untuk mengumpulkan informasi selengkapnya tentang apa yang ditunjukkan sinyal.
- Dalam dokumentasi Man 7 untuk signal_code dan nama Sinyal yang sebelumnya Anda temukan, temukan daftar si_codes yang terkait.
- Gunakan nilai yang ditetapkan ke signal_code dalam file laporan
csvkesalahan untuk menentukan kode mana yang cocok dengan pesan kesalahan.
Misalnya, pertimbangkan deskripsi AppCrash berikut:
AppCrash (exit_status=11; signal_status=11; signal_code=3; component_id=685f13af-25a5-40b2-8dd8-8cbc253ecbd8; image_id=7053e7b3-d2bb-431f-8d3a-173f52db9675)
Dengan dokumentasi Man 7, Anda dapat menemukan informasi tambahan berikut tentang AppCrash:
- Sinyal dijelaskan di bagian ke-10 dari deskripsi halaman Pria sinyal. Signal_status nilai 11 terkait dengan sinyal SIGSEGV.
- SIGSEGV mengindikasikan bahwa referensi memori yang tidak valid terjadi (sering kali ini bisa berupa penunjuk null).
- SI_Codes dijelaskan di bagian ke-3 dari deskripsi halaman pria SigAction untuk setiap signal_status. Meskipun halaman tidak mencantumkan nomor indeks untuk setiap si_code, Anda bisa menghitung dari setiap kategori signal_status dimulai dari indeks 1. Dengan melihat daftar si_codes untuk SIGSEGV (dimulai dari indeks 1), Anda dapat melihat bahwa yang ketiga cocok dengan SEGV_BNDERR.
- SEGV_BNDERR menunjukkan bahwa pemeriksaan terikat alamat gagal terjadi.
Catatan
AppCrash yang sering ditemui mencakup nilai signal_status 9, yang merupakan sinyal SIGKILL, bersama dengan SEND_SIG_PRIV si_code. Status ini menunjukkan bahwa OS membunuh aplikasi karena melebihi batas penggunaan memorinya. Untuk mempelajari selengkapnya tentang batas memori aplikasi, lihat Penggunaan memori dalam aplikasi tingkat tinggi.
Menginterpretasikan AppExits
Ketika aplikasi keluar tanpa kesalahan, bidang signal_status dan signal_code tidak ada, dan bukan exit_status, Deskripsi berisi kode keluar:
AppExit (exit_code=0; component_id=685f13af-25a5-40b2-8dd8-8cbc253ecbd8; image_id=0a7cc3a2-f7c2-4478-8b02-723c1c6a85cd)
AppExits dapat terjadi karena beberapa alasan, seperti pembaruan aplikasi, perangkat yang dilepas, atau penggunaan API power down, antara lain. Penting untuk menerapkan kode keluar sehingga Anda dapat memperoleh wawasan tentang alasan appexit.
Untuk menginterpretasikan AppExits, gunakan nilai exit_code dalam bidang Deskripsi laporan kesalahan. Jika aplikasi mengembalikan kode keluar, Anda dapat menggunakan nilai exit_code dalam laporan kesalahan untuk menentukan di mana atau kapan kesalahan terjadi. Dengan menggunakan nilai ini, cari di dalam kode aplikasi untuk melihat pesan kode keluar mana yang sesuai dengan nilai yang disediakan dalam laporan kesalahan. Lalu, lihat untuk menemukan fungsi mana dalam aplikasi yang mengembalikan pesan kode keluar dan mengapa fungsi tersebut melakukannya. Dengan menampilkan pernyataan pengembalian dan konteksnya, Anda mungkin dapat menemukan alasan kesalahan tersebut.
Acara OS
Data kesalahan juga mencakup kejadian OS dan perangkat keras yang mendasar yang dapat memengaruhi aplikasi Anda dengan menyebabkan kegagalan atau memulai ulang. Kejadian tersebut dapat mencakup hal berikut:
- Reboot perangkat tidak terencana yang disebabkan oleh kesalahan kernel
- Pembaruan OS cloud
- Masalah perangkat keras sementara
Kejadian OS disertakan dalam data untuk membantu Anda menentukan apakah kesalahan aplikasi merupakan hasil dari masalah OS atau perangkat keras atau mencerminkan masalah dengan aplikasi itu sendiri. Jika data kejadian memperlihatkan bahwa perangkat yang di-boot ke Mode Aman, aplikasi Anda mungkin tidak dapat memulai.
Menjelajahi data kesalahan
Jika berencana untuk mengembangkan skrip atau alat untuk menganalisis data kesalahan, tetapi tidak memiliki banyak perangkat yang tersedia untuk melaporkan kesalahan, Anda dapat menggunakan aplikasi sampel Azure Sphere untuk menghasilkan data tersebut untuk pengujian. Contoh Tutorial/ErrorReporting di repo sampel Azure Sphere menjelaskan cara menganalisis kesalahan yang dilaporkan saat aplikasi mengalami crash. Ikuti instruksi dalam pembaca untuk menyusun sampel menggunakan Visual Studio, Visual Studio Code, atau baris perintah.
Saat Anda menyebarkan aplikasi dari baris perintah tanpa debugger, OS memulai ulang aplikasi setiap kali gagal. Kejadian serupa diagregat sehingga satu perangkat yang sering gagal tidak menutupi kesalahan dari orang lain dan maksimum adalah delapan kemunculan per jendela waktu. Anda dapat menyebarkan sampel dari baris perintah tanpa melakukan debugging, sebagai berikut:
az sphere device sideload deploy --image-package <path to image package for the app>
Membuat dan mengunduh laporan kesalahan
Data kesalahan dan kejadian diunggah ke Azure Sphere Security Service setiap hari. Pastikan bahwa perangkat Azure Sphere tersambung ke internet menggunakan Wi-Fi atau Ethernet untuk berkomunikasi dengan Azure Sphere Security Service.
Jalankan perintah berikut untuk mengunduh laporan ke file CSV:
az sphere catalog download-error-report --destination error.csvBuka file CSV yang diunduh dan cari ID komponen Anda. Anda akan melihat deskripsi kesalahan yang mirip dengan yang berikut ini:
AppExit (exit_code=0; component_id=685f13af-25a5-40b2-8dd8-8cbc253ecbd8; image_id=6d2646aa-c0ce-4e55-b7d6-7c206a7a6363)
Anda juga dapat menggunakan API Publik Azure Sphere untuk pelaporan kesalahan.
Catatan
- Mungkin memerlukan waktu hingga 24 jam agar acara yang baru dilaporkan tersedia untuk diunduh.
- Jika terjadi kejadian atau kesalahan sebelum perangkat tersambung dengan server NTP, stempel waktu untuk kejadian yang terdapat dalam telemetri yang diunggah ke AS3 mungkin salah. Ini akan terlihat dalam entri yang salah dalam kolom StartTime dalam laporan berikutnya yang diunduh dari AS3. Dalam situasi ini gunakan bidang EndTime laporan untuk membantu memperkirakan kapan kejadian terjadi. Bidang ini berisi waktu layanan awan menerima telemetri yang diunggah dan akan selalu memiliki tanggal yang valid.
Memformat data kesalahan
Stempel waktu dan kolom data dalam file laporan kesalahan diformat secara berbeda dari file CSV umum. Jika Anda ingin menampilkan hasilnya di Excel, Anda bisa memformat ulang data dengan membuat kolom baru dan menambahkan rumus kustom.
Untuk memformat cap waktu dalam file CSV yang diekspor agar berfungsi dengan Excel:
Buat kolom Stempel Waktu baru dan buat format kustom untuk kolom tersebut:
yyyy/mm/dd hh:mm:ssTambahkan rumus berikut ke sel di kolom Stempel Waktu baru, ubah nilai sel F2 agar sesuai dengan kolom dan baris Anda:
=(DATEVALUE(LEFT(RawErrorReport!F2,10))+TIMEVALUE(RIGHT(RawErrorReport!F2,8)))
Untuk memisahkan bidang Deskripsi menjadi kolom terpisah, ikuti langkah-langkah ini, ubah nilai sel F2 agar sesuai dengan kolom dan baris Anda:
Buat kolom baru bernama Namasingkat atau yang serupa, dan tambahkan rumus berikut ke sel:
=TRIM(LEFT(F2,FIND("(",F2)-1))Buat kolom di mana header baris1 memiliki nama yang sama seperti nilai parameter dan tambahkan rumus berikut ke sel di setiap kolom:
=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)))