- Một ứng dụng React Native mà bạn chạy được trên máy cục bộ.
- Một dự án LogBrew. Xem Dự án và thiết lập.
- CLI đã đăng nhập. Xem Dùng CLI.
Cài SDK
Cài cả hai gói trong thư mục ứng dụng. Giữ nguyên các dependency React và React Native của ứng dụng:Tạo khóa SDK của dự án
Cấp cho ứng dụng một khóa SDK theo phạm vi dự án và chỉ có quyền ghi. Expo đưa mọi giá trịEXPO_PUBLIC_* vào bundle của ứng dụng. Không bao giờ đặt thông
tin xác thực của tài khoản hoặc của máy chủ vào biến đó.
CLI v0.1.32 trở lên tạo khóa cho một dự án có sẵn. Lệnh này không tạo dự án
mới. Tìm ID dự án:
--abandon-retry.
Không đưa tệp khóa vào hệ thống quản lý mã nguồn. Không dùng thông tin xác thực
tài khoản đã cấp quyền cho CLI. Khi phát triển Expo trên máy cục bộ, đặt khóa
vào tệp .env.local được bỏ qua (ignored) ở thư mục gốc của ứng dụng:
process.env.EXPO_PUBLIC_LOGBREW_CLIENT_KEY
trong module thiết lập bên dưới. Tải lại hoàn toàn ứng dụng sau khi đổi giá
trị. Xem
biến môi trường Expo
để cấu hình lúc build. Ứng dụng React Native thuần thì tải khóa qua cấu hình
riêng của nó.
Tạo client
Đặt phần thiết lập này trong một module mà ứng dụng tải khi khởi động. Không tạo client ở mỗi lần render. Đặt dịch vụ, môi trường và bản phát hành trongcontext:
stopAppStateListener() khi ứng dụng dọn dẹp lúc tắt.
Với hàng đợi native, mỗi khóa chỉ dùng được cho một client đang hoạt động.
Client thứ hai cho cùng khóa sẽ thất bại với configuration_error. Đây là thêm
một lý do để chỉ tạo client một lần.
Gửi và tìm log thử nghiệm
GọiverifyLogBrewSetup() một lần từ một thao tác thử nghiệm chỉ dành cho môi
trường phát triển. Chờ (await) kết quả và xử lý promise bị reject. Không in
khóa hoặc batch sự kiện.
Kết quả 2xx có batches lớn hơn 0 cho thấy LogBrew đã chấp nhận batch.
Lần flush rỗng trả về 204 với 0 lần thử và 0 batch, vì tính năng tự động gửi có
thể đã gửi sự kiện trước đó. Trong cả hai trường hợp, đọc log đã lưu bằng CLI:
RecordingTransport.alwaysAccept() chỉ dùng cho kiểm thử cục bộ. Nó trả về
202 giả lập và không gửi yêu cầu nào.
Gửi khi ngoại tuyến và sau khi khởi động lại
Đọcclient.deliveryHealth().storage trong ứng dụng đang chạy:
persistent: client dùng hàng đợi native. Các sự kiện đang chờ được tải lại sau khi ứng dụng khởi động lại.memory: các sự kiện đang chờ bị mất khi runtime JavaScript khởi động lại.
persistentQueue: "auto" dùng hàng đợi native khi binary của
ứng dụng chứa module native của LogBrew. Expo Go và các binary cũ hơn dùng hàng
đợi trong bộ nhớ. Bản cập nhật chỉ có JavaScript không thể thêm module native.
Nếu ứng dụng production cần gửi được sau khi khởi động lại, đặt
persistentQueue: "required". Khi đó, việc tạo client sẽ thất bại với
configuration_error nếu thiếu hàng đợi native. Build lại ứng dụng với module
native. Chỉ dùng persistentQueue: "disabled" khi bạn muốn dùng hàng đợi trong
bộ nhớ.
Hàng đợi native chứa tối đa 1.000 sự kiện và 4 MiB dữ liệu sự kiện. Các giới
hạn nhỏ hơn của client cũng được áp dụng. Sự kiện trong hàng đợi native giữ
nguyên ID sự kiện sau khi khởi động lại.
Việc gửi đảm bảo ít nhất một lần (at least once), nên một lần thử lại có thể
gửi một sự kiện hai lần. Khi ID và nội dung sự kiện khớp với một sự kiện
LogBrew đã chấp nhận, LogBrew không lưu sự kiện đó lần nữa. Flush khi chạy nền
chỉ là một lần thử, không phải bằng chứng đã gửi thành công. Kiểm tra việc ghi
nhận khi ngoại tuyến và khi khởi động lại ứng dụng. Sau đó, tìm sự kiện đã lưu
trong dự án.
Đọc trạng thái gửi
client.deliveryHealth() trả về trạng thái hàng đợi và trạng thái gửi, không
kèm nội dung sự kiện. Đọc các trường này trước:
Chọn nội dung log
Giữ mỗi thông điệp ngắn và cụ thể. Mô tả kết quả trong ứng dụng, như một yêu cầu thất bại hoặc một lần thử lại đã lên lịch. Không đưa vào tên, địa chỉ email, access token, giá trị biểu mẫu hoặc body yêu cầu. Dùng mức độ nghiêm trọng phù hợp với sự kiện:info, warning, error hoặc
critical. Giữ dịch vụ, môi trường và bản phát hành nhất quán để bạn tìm được
các bản ghi liên quan.
npx react-native log-ios và npx react-native log-android hiển thị log của
thiết bị cục bộ. Các lệnh này không truy vấn LogBrew. Xem
gỡ lỗi native trong React Native.
Khôi phục khi kiểm tra thất bại
Lệnh gọiflush() thất bại sẽ reject với một mã lỗi SDK. Không đưa khóa và
body sự kiện vào báo cáo lỗi.
Xem Khắc phục sự cố để biết thêm các bước kiểm
tra.
Giữ Debug ID của Expo trong bundle phát hành
Tạo cấu hình Metro cho Expo qua LogBrew. Khi đó, bundle runtime có cùng Debug ID với source map của nó:withLogBrewMetroConfig(). Không dùng hàm bọc đó với Expo. Nếu dùng, bản build
production sẽ dừng với thông điệp chỉ đến getLogBrewExpoConfig().