LogBrew Swift 0.1.6 이상을 사용하세요. 디버그 아티팩트를 업로드하려면 네이티브 LogBrew CLI 0.1.24 이상을 사용하세요.
수집 범위 계획하기
앱이 실패 유형별로 언제 재전송할 수 있는지 확인하세요.
빌드 전에 릴리스 값을 정하세요. 이 값은 앱 버전과 빌드를 식별해야 합니다. SDK, dSYM 업로드, 이슈 필터에 같은 값을 사용하세요.
크래시 메타데이터에 사용자 페이로드, 요청 본문, 헤더를 붙이지 마세요.
크래시 제품 추가하기
먼저 앱에 SDK 텔레메트리를 설정하세요. 재전송은 그client와 transport를 사용합니다.
Swift Package Manager로 공개 SDK를 추가하세요.
LogBrew 제품을 추가하세요. LogBrewCrash는 앱에서 네이티브 크래시나 멈춤 수집을 명시적으로 켤 때만 추가하세요.
수집 통합은 iOS 15 이상을 지원합니다. 네이티브 치명적 오류 핸들러는 프로세스 전체에 적용되므로, 앱이 소유하는 수집 객체를 1개만 유지하세요.
정확한 식별 정보 하나 설정하기
런타임 설정과 아티팩트 업로드에 같은 프로젝트, 릴리스, 환경, 서비스를 사용하세요. LogBrew는 이 값을 추론하거나 바꾸지 않습니다.NativeCrashConfiguration에는 선택 사항인 한도 2개가 있습니다.
범위를 벗어난 값을 쓰면 설정에서
crash_invalid_configuration 오류가 발생합니다.
멈춤 수집 켜기
watchdog가 nil이면 멈춤 수집이 꺼져 있습니다. 켜려면 install()을 호출하기 전에 위의 watchdog 선언을 다음으로 바꾸세요.
artifactIdentity도 필요합니다. 없으면 설정에서 crash_invalid_configuration 오류가 발생합니다.
프로세스가 살아 있는 동안 crashCapture 객체를 1개만 유지하세요. 두 번째 수집 객체는 설치할 수 없습니다. 그 객체의 install() 호출은 crash_capture_owned 오류를 발생시킵니다. 임곗값을 바꾸려면 다음 앱 실행 때 새 값을 사용하세요.
복구된 멈춤은 crash.handled를 true로 설정해 재전송됩니다. 프로세스 종료로 남은 진행 중 멈춤은 crash.handled를 false로 설정해 재전송됩니다.
두 형식 모두 숫자 durationMs 메타데이터를 포함합니다. 치명적 크래시 프레임과 같은 아티팩트 식별 정보를 유지합니다.
워치독은 앱이 비활성 상태이거나 디버거에 연결된 동안 일시 중지됩니다. 발열이 심할 때도 수집하지 않습니다.
임곗값이 짧으면 정상적인 메인 스레드 작업도 멈춤으로 보고될 수 있습니다. 실제로 배포하는 빌드 구성으로 임곗값을 테스트하세요. 처리됨 상태는 복구되었다는 뜻입니다. 이슈가 해결되었다는 표시가 아닙니다. 처리된 멈춤도 인터페이스를 막았으므로 함께 검토하세요.
실행 후 재전송하기
수집 객체를 설치한 뒤 SDK 클라이언트로 대기 중인 리포트를 재전송하세요.maxReplayBytes보다 큰 리포트를 버립니다. 세 가지 수를 모두 확인하세요. 대기 중인 리포트 수가 0이라는 것만으로는 전송이 증명되지 않습니다.
실패한 요청이 다음 재시작 뒤에도 남아 있어야 한다면 재전송 전에 지속 전송을 켜세요. 일반적인 네트워크 복구나 인증 복구 중에는 purge()를 호출하지 마세요.
일치하는 dSYM 업로드하기
디버그 정보를 켠 상태로 앱을 아카이브하세요. 사용자가 실행하는 바로 그 빌드의 dSYM을 보관하세요. dSYM의 이미지 UUID를 확인하세요.--expect-image-uuid를 반복하세요. 찾은 UUID 집합이 예상 집합과 다르면 명령어가 실패합니다.
계정 접근 권한을 확인하세요. 그런 다음 --dry-run 없이 같은 명령어를 실행하세요.
status가 결과를 보여 줍니다.
빌드 머신은 계정 접근 권한 대신
LOGBREW_TOKEN에 프로젝트 아티팩트 키를 넣어 업로드할 수 있습니다. 키는 아티팩트 키 만들기에 나온 대로 만드세요. 이 업로드는 uploaded를 보고합니다. 나중에 계정 접근 권한으로 각 식별 정보를 확인하세요.
status: "found"는 아티팩트가 있다는 확인입니다. status: "missing"은 LogBrew에 해당 식별 정보의 아티팩트가 없다는 뜻입니다.
프레임 해석은 소스 파일 이름이 아니라 이미지 UUID와 전체 아티팩트 식별 정보로 일치 여부를 판단합니다. 같은 소스를 다시 빌드해도 UUID가 달라질 수 있습니다. 빌드 디렉터리 전체가 아니라 정확한 dSYM 번들을 업로드하세요.
호스팅된 데이터 다시 읽어 확인하기
같은 런타임 범위로 이슈 목록을 필터링하세요. 이 예는unresolved 이슈를 선택합니다. 해결됨 또는 보관됨 이슈는 나타나지 않습니다.
symbolication 객체가 추가됩니다. 이 예는 해석된 프레임이 있는 이슈에서 일부 필드만 보여 줍니다. 전체 응답이 아닙니다.
크래시 근거 읽기
각 프레임에는 자체status가 있습니다. symbolication.status 필드도 같은 값을 사용합니다.
해석되지 않은 프레임은 메모에도 해석되지 않은 상태로 남기세요. 빈 스택으로 보고하지 마세요.
LogBrew는 이슈를 읽을 때 프레임을 해석합니다. 나중에 업로드한 dSYM으로 이전 이벤트의 프레임도 해석할 수 있습니다. 다만 이벤트가 수집하지 않은 프레임을 추가할 수는 없습니다.
애플리케이션 프레임은 코드를 찾을 범위를 좁혀 주지만 원인을 증명하지는 않습니다. 브레드크럼, 예외 체인, 트레이스 근거는 이슈 조사 결과에서 읽으세요.
source: "symbolicated"인 프레임은 업로드된 아티팩트에서 나온 것입니다. source: "captured"인 프레임은 앱이 보낸 위치입니다. 응답 필드는 이슈 조사하기를 참고하세요.
모든 읽기에서 프로젝트, 릴리스, 환경, 서비스 범위를 모두 유지하세요. 조회에 실패했다고 여러 프로젝트로 범위를 넓히지 마세요.
프로덕션 설정 확인하기
배포된 빌드에서 승인된 테스트 실패를 사용하세요. 고객의 액션을 트리거로 사용하지 마세요. 각 항목을 순서대로 확인하고, 처음 실패한 곳에서 멈추세요.- 런타임 식별 정보가 업로드된 아티팩트 식별 정보와 일치합니다.
- 이후 실행에서 접수 확인된 이벤트 1개를 재전송하며, 버린 리포트와 대기 중인 리포트가 모두 0개입니다.
- 범위를 지정한 이슈 목록이 예상한 처리 상태로 테스트 이슈를 반환합니다.
- 예상한 애플리케이션 프레임이 해석됩니다.
- 이후 정상 실행에서 발생 건이 더 추가되지 않습니다.
안전하게 복구하기
일반적인 이슈 조사는 API로 이슈 조사하기를 사용하세요.
