SDK 설치하기
앱 디렉터리에 두 패키지를 모두 설치하세요. 앱의 React 및 React Native 의존성은 그대로 두세요.프로젝트 SDK 키 만들기
앱에는 프로젝트 범위의 쓰기 전용 SDK 키를 주세요. Expo는 모든EXPO_PUBLIC_* 값을 앱 번들에 넣습니다. 이 변수에 계정 자격 증명이나 서버 자격 증명을 넣지 마세요.
CLI v0.1.32 이상은 기존 프로젝트의 키를 만듭니다. 새 프로젝트는 만들지 않습니다. 프로젝트 ID를 찾으세요.
--abandon-retry는 사용하지 마세요.
키 파일은 소스 관리에 넣지 마세요. CLI를 승인한 계정 자격 증명을 사용하지 마세요. 로컬 Expo 개발에서는 앱 루트의 무시된 .env.local 파일에 키를 넣으세요.
process.env.EXPO_PUBLIC_LOGBREW_CLIENT_KEY를 직접 참조하는 코드를 그대로 두세요. 값을 바꾼 뒤에는 앱을 완전히 다시 불러오세요. 빌드 시점 설정은 Expo 환경 변수를 참고하세요. 베어 React Native 앱은 대신 자체 설정으로 키를 불러옵니다.
클라이언트 만들기
이 설정은 앱이 시작할 때 불러오는 모듈 1개에 넣으세요. 렌더링할 때마다 클라이언트를 만들지 마세요. 서비스, 환경, 릴리스는context에 넣으세요.
stopAppStateListener()를 호출하세요.
네이티브 큐를 쓰면 키 1개는 활성 클라이언트 1개만 사용할 수 있습니다. 같은 키로 두 번째 클라이언트를 만들면 configuration_error로 실패합니다. 이것도 클라이언트를 한 번만 만들어야 하는 이유입니다.
테스트 로그 보내고 찾기
개발 전용 테스트 액션에서verifyLogBrewSetup()을 한 번 호출하세요. 결과를 await하고 거부된 promise를 처리하세요. 키나 이벤트 배치를 출력하지 마세요.
2xx 결과의 batches가 0보다 크면 LogBrew가 배치를 접수했다는 뜻입니다. 자동 전송이 이벤트를 먼저 보냈을 수 있으므로, 빈 flush는 시도 0회, 배치 0개와 함께 204를 반환합니다. 두 경우 모두 CLI로 저장된 로그를 읽으세요.
RecordingTransport.alwaysAccept()는 로컬 테스트 전용입니다. 가짜 202를 반환하며 요청을 보내지 않습니다.
오프라인 및 재시작 후 전송
실행 중인 앱에서client.deliveryHealth().storage를 읽으세요.
persistent: 클라이언트가 네이티브 큐를 사용합니다. 대기 중인 이벤트는 앱을 다시 시작한 뒤 다시 불러옵니다.memory: JavaScript 런타임이 다시 시작되면 대기 중인 이벤트가 사라집니다.
persistentQueue: "auto"는 앱 바이너리에 LogBrew 네이티브 모듈이 있으면 네이티브 큐를 사용합니다. Expo Go와 이전 바이너리는 메모리를 사용합니다. JavaScript만 업데이트해서는 네이티브 모듈을 추가할 수 없습니다.
프로덕션 앱에서 재시작 후 전송이 필요하면 persistentQueue: "required"를 설정하세요. 그러면 네이티브 큐가 없을 때 클라이언트 생성이 configuration_error로 실패합니다. 네이티브 모듈을 포함해 앱을 다시 빌드하세요. 메모리 큐를 원할 때만 persistentQueue: "disabled"를 사용하세요.
네이티브 큐에는 최대 1,000개의 이벤트와 4 MiB의 이벤트 데이터가 들어갑니다. 클라이언트 한도가 더 작으면 그 한도도 적용됩니다. 네이티브 큐의 이벤트는 재시작 뒤에도 이벤트 ID를 유지합니다.
전송은 최소 한 번 보장 방식이므로, 재시도로 이벤트가 두 번 전송될 수 있습니다. 이벤트 ID와 내용이 LogBrew가 이미 접수한 이벤트와 일치하면 LogBrew는 다시 저장하지 않습니다. 백그라운드 flush는 시도일 뿐 전송의 증명이 아닙니다. 오프라인 수집과 앱 재시작을 테스트하세요. 그런 다음 프로젝트에서 저장된 이벤트를 찾으세요.
전송 상태 읽기
client.deliveryHealth()는 이벤트 내용 없이 큐 상태와 전송 상태를 반환합니다. 다음 필드를 먼저 읽으세요.
로그 내용 정하기
각 메시지는 짧고 구체적으로 쓰세요. 요청 실패나 예약된 재시도처럼 앱에서 일어난 결과를 설명하세요. 이름, 이메일 주소, 액세스 토큰, 폼 값, 요청 본문을 넣지 마세요. 이벤트에 맞는 심각도를 사용하세요.info, warning, error, critical 중 하나입니다. 관련 기록을 찾을 수 있도록 서비스, 환경, 릴리스를 일관되게 유지하세요.
npx react-native log-ios와 npx react-native log-android는 로컬 기기 로그를 보여 줍니다. LogBrew를 조회하지 않습니다. React Native 네이티브 디버깅을 참고하세요.
확인에 실패했을 때 복구하기
flush()가 실패하면 SDK 오류 코드와 함께 거부됩니다. 오류 보고에 키와 이벤트 본문을 넣지 마세요.
더 많은 확인 방법은 문제 해결을 참고하세요.
릴리스 번들에 Expo Debug ID 유지하기
LogBrew로 Expo Metro 설정을 만드세요. 그러면 런타임 번들이 소스맵과 같은 Debug ID를 갖게 됩니다.withLogBrewMetroConfig()로 감쌉니다. Expo에서는 이 래퍼를 사용하지 마세요. 사용하면 프로덕션 빌드가 getLogBrewExpoConfig()를 안내하는 메시지와 함께 멈춥니다.