Skip to main content
Kirim log dari aplikasi React Native ke LogBrew. Mulai dengan satu log uji, lalu gunakan CLI untuk menemukannya di proyek yang benar. Panduan ini memakai Expo. Aplikasi React Native bare memuat kunci melalui konfigurasinya sendiri. Sebelum mulai, Anda memerlukan:

Instal SDK

Instal kedua paket di direktori aplikasi. Pertahankan dependensi React dan React Native milik aplikasi:

Buat kunci SDK proyek

Berikan aplikasi kunci SDK khusus proyek yang hanya bisa menulis. Expo memasukkan setiap nilai EXPO_PUBLIC_* ke bundle aplikasi. Jangan pernah memasukkan kredensial akun atau server ke variabel itu. CLI v0.1.32 atau yang lebih baru membuat kunci untuk proyek yang sudah ada. CLI tidak membuat proyek baru. Cari ID proyek:
Buat kunci. Gunakan path file baru di direktori yang hanya bisa diakses pemiliknya:
Lanjutkan hanya setelah perintah berhasil. Jika hasilnya tidak jelas, jalankan lagi perintah yang sama dengan argumen yang sama. Jangan pakai --abandon-retry. Jauhkan file kunci dari source control. Jangan pakai kredensial akun yang mengotorisasi CLI. Untuk pengembangan Expo lokal, simpan kunci di file .env.local yang diabaikan source control, di root aplikasi:
Pertahankan referensi langsung process.env.EXPO_PUBLIC_LOGBREW_CLIENT_KEY di modul penyiapan di bawah. Muat ulang aplikasi sepenuhnya setelah Anda mengubah nilainya. Lihat variabel lingkungan Expo untuk konfigurasi saat build. Aplikasi React Native bare memuat kunci melalui konfigurasinya sendiri sebagai gantinya.

Buat klien

Letakkan penyiapan ini di satu modul yang dimuat aplikasi saat startup. Jangan membuat klien di setiap render. Masukkan layanan, lingkungan, dan rilis ke context:
Transport fetch mengaktifkan pengiriman otomatis dengan percobaan ulang yang terbatas dan antrean. Jangan tambahkan timer flush kedua. Listener AppState meminta flush terakhir saat aplikasi menjadi tidak aktif atau masuk ke latar belakang. Panggil stopAppStateListener() saat aplikasi dihentikan. Dengan antrean native, hanya satu klien aktif yang bisa memakai satu kunci. Klien kedua untuk kunci yang sama gagal dengan configuration_error. Ini satu alasan lagi untuk membuat klien sekali saja.

Kirim dan temukan log uji

Panggil verifyLogBrewSetup() sekali dari tindakan uji khusus development. Tunggu hasilnya dengan await dan tangani promise yang ditolak. Jangan cetak kunci atau batch peristiwa. Hasil 2xx dengan batches di atas 0 menunjukkan bahwa LogBrew menerima batch. Flush kosong mengembalikan 204 dengan 0 percobaan dan 0 batch, karena pengiriman otomatis bisa mengirim peristiwa lebih dulu. Dalam kedua kasus, baca log yang tersimpan dengan CLI:
Periksa waktu peristiwa dan layanan di hasil. Hasil kosong tidak menunjukkan penyebabnya. Periksa proyek, kunci, dan rentang waktu. RecordingTransport.alwaysAccept() hanya untuk pengujian lokal. Fungsi ini mengembalikan 202 sintetis dan tidak mengirim permintaan.

Pengiriman saat offline dan setelah restart

Baca client.deliveryHealth().storage di aplikasi yang sedang berjalan:
  • persistent: klien memakai antrean native. Peristiwa yang tertunda dimuat lagi setelah aplikasi di-restart.
  • memory: peristiwa yang tertunda hilang saat runtime JavaScript di-restart.
Nilai default persistentQueue: "auto" memakai antrean native jika biner aplikasi berisi modul native LogBrew. Expo Go dan biner lama memakai memori. Pembaruan yang hanya berisi JavaScript tidak bisa menambahkan modul native. Jika aplikasi produksi memerlukan pengiriman setelah restart, atur persistentQueue: "required". Dengan begitu, pembuatan klien gagal dengan configuration_error jika antrean native tidak ada. Build ulang aplikasi dengan modul native. Gunakan persistentQueue: "disabled" hanya jika Anda memang menginginkan antrean memori. Antrean native menampung paling banyak 1.000 peristiwa dan 4 MiB data peristiwa. Batas klien yang lebih kecil juga berlaku. Peristiwa di antrean native mempertahankan ID peristiwanya setelah restart. Pengiriman dijamin minimal sekali (at least once), jadi percobaan ulang bisa mengirim satu peristiwa dua kali. Jika ID dan isi peristiwa cocok dengan peristiwa yang sudah diterima LogBrew, LogBrew tidak menyimpannya lagi. Flush di latar belakang adalah percobaan, bukan bukti pengiriman. Uji perekaman saat offline dan restart aplikasi. Lalu temukan peristiwa yang tersimpan di proyek.

Baca status pengiriman

client.deliveryHealth() mengembalikan status antrean dan pengiriman tanpa isi peristiwa. Baca kolom berikut terlebih dahulu:

Pilih isi log

Buat setiap pesan singkat dan spesifik. Jelaskan apa yang terjadi di aplikasi, seperti permintaan yang gagal atau percobaan ulang yang dijadwalkan. Jangan sertakan nama, alamat email, token akses, nilai formulir, atau body permintaan. Gunakan tingkat keparahan yang sesuai dengan peristiwa: info, warning, error, atau critical. Jaga agar layanan, lingkungan, dan rilis konsisten supaya Anda bisa menemukan data yang saling terkait. npx react-native log-ios dan npx react-native log-android menampilkan log perangkat lokal. Perintah ini tidak mengambil data dari LogBrew. Lihat debugging native React Native.

Pulihkan dari pemeriksaan yang gagal

Jika flush() gagal, promise-nya ditolak dengan kode error SDK. Jauhkan kunci dan body peristiwa dari laporan error. Lihat Mengatasi kendala untuk pemeriksaan lainnya.

Pertahankan Debug ID Expo di bundle rilis

Buat konfigurasi Metro Expo melalui LogBrew. Dengan begitu, bundle runtime mendapatkan Debug ID yang sama dengan source map-nya:
Jika aplikasi memakai mode bundle React Native Worklets, terapkan transformasi itu setelah helper LogBrew:
Helper ini mempertahankan plugin pra-serialisasi Expo yang sudah ada. Sebagai gantinya, aplikasi React Native bare membungkus konfigurasi Metro finalnya dengan withLogBrewMetroConfig(). Jangan pakai pembungkus itu dengan Expo. Jika Anda memakainya, build produksi berhenti dengan pesan yang mengarah ke getLogBrewExpoConfig().