2024년 데모 데이에서 Firebase를 사용하여 AI 기반 앱을 빌드하고 실행하는 방법에 관한 데모를 시청하세요. 지금 시청하세요.

Firebase Crashlytics 데이터를 BigQuery로 내보내기

Firebase Crashlytics 데이터를 BigQuery로 내보내 추가 분석을 할 수 있습니다. BigQuery를 사용하면 BigQuery SQL로 데이터를 분석하고 데이터를 다른 클라우드 제공업체로 내보내거나, Google 데이터 스튜디오의 시각화 및 커스텀 대시보드에 데이터를 사용할 수 있습니다.

BigQuery로 내보내기 사용 설정

Firebase Console에서 통합 페이지로 이동합니다.
BigQuery 카드에서 연결을 클릭합니다.
화면에 표시된 안내에 따라 BigQuery로 내보내기를 사용 설정합니다.

BigQuery에서 Crashlytics 데이터에 거의 실시간으로 액세스하려면 스트리밍 내보내기로 업그레이드하는 것이 좋습니다.

내보내기를 사용 설정하면 어떻게 되나요?

데이터 세트 위치를 선택합니다. 데이터 세트를 만든 후에는 위치를 변경할 수 없지만 데이터 세트를 다른 위치에 복사하거나 다른 위치에서 데이터 세트를 수동으로 이동(다시 만들기)할 수 있습니다. 자세한 내용은 기존 내보내기 위치 변경을 참조하세요.

이 위치는 BigQuery로 내보낸 데이터에만 적용되며 Firebase Console의 Crashlytics 대시보드 또는 Android 스튜디오에서 사용하기 위해 저장된 데이터의 위치에는 영향을 미치지 않습니다.

참고: 데이터 내보내기 위치를 선택하고 변경하는 기능은 2024년 10월 중순 이후에 내보내기를 사용 설정했거나 새 내보내기 인프라로 업그레이드한 경우에만 사용 가능합니다.
기본적으로 프로젝트에 있는 모든 앱은 BigQuery에 연결되며 나중에 프로젝트에 추가한 앱은 BigQuery에 자동으로 연결됩니다. 데이터를 전송하는 앱을 별도로 관리할 수 있습니다.
Firebase에서 BigQuery로의 일일 데이터 동기화를 설정합니다.
- 프로젝트를 연결한 후 첫 번째 데이터 세트를 BigQuery로 내보내려면 일반적으로 다음 날 동기화가 완료될 때까지 기다려야 합니다.
- 일일 동기화는 BigQuery에서 설정했을 수 있는 예약된 내보내기에 관계없이 하루에 한 번 실행됩니다. 동기화 작업의 타이밍과 기간을 변경할 수 있으므로 내보내기의 특정 시점을 기준으로 다운스트림 작업을 예약하지 않는 것이 좋습니다.
Firebase에서 기존 데이터의 사본을 BigQuery로 내보냅니다. 내보내기용 데이터 초기 전파를 완료하는 데 최대 48시간이 걸릴 수 있습니다.
- 여기에는 연결된 각 앱에서 이 내보내기에 일일 데이터 동기화로 생성된 데이터가 있는 배치 테이블이 포함됩니다.
- 최대 지난 30일 동안의 또는 BigQuery 내보내기를 사용 설정한 가장 최근 날짜(둘 중 최근)에 대해 배치 테이블의 데이터 백필을 수동으로 예약할 수 있습니다.
2024년 10월 중순 전에 Crashlytics 데이터 내보내기를 사용 설정한 경우 내보내기를 사용 설정한 날짜로부터 30일 전까지 백필할 수도 있습니다.
BigQuery로 Crashlytics 스트리밍 내보내기를 사용 설정하면 연결된 모든 앱에 지속적으로 업데이트되는 데이터가 포함된 실시간 테이블도 포함됩니다.

BigQuery 내보내기를 중지하려면 Firebase Console에서 프로젝트를 연결 해제합니다.

어떤 유형의 데이터를 BigQuery로 내보내나요?

Firebase Crashlytics 데이터는 firebase_crashlytics라는 BigQuery 데이터 세트로 내보내집니다. 기본적으로 개별 테이블은 프로젝트에 있는 각 앱의 Crashlytics 데이터 세트에 생성됩니다. Firebase는 앱의 식별자에 따라 테이블의 이름을 지정하며, 마침표를 밑줄로 변환하고 마지막에 플랫폼 이름을 붙입니다.

예를 들어 패키지 이름이 com.google.test인 Android 앱의 데이터는 com_google_test_ANDROID라는 이름의 테이블에 포함되게 됩니다. 이 배치 테이블은 하루에 한 번 업데이트됩니다. BigQuery로 Crashlytics 스트리밍 내보내기를 사용 설정하면 Crashlytics 데이터도 com_google_test_ANDROID_REALTIME이라는 테이블로 실시간 스트리밍됩니다.

테이블의 각 행은 비정상 종료, 심각하지 않은 오류, ANR을 포함하여 앱에서 발생한 이벤트를 나타냅니다.

BigQuery로 Crashlytics 스트리밍 내보내기

BigQuery 스트리밍을 사용하여 Crashlytics 데이터를 실시간으로 스트리밍할 수 있습니다. 실시간 대시보드에 정보를 표시하거나, 출시 라이브를 보거나, 알림 및 커스텀 워크플로를 트리거하는 애플리케이션 문제를 모니터링하는 등 실시간 데이터가 필요한 모든 상황에서 사용할 수 있습니다.

Crashlytics로 BigQuery 스트리밍 내보내기를 사용 설정하면 배치 테이블 외에 실시간 테이블도 포함됩니다. 다음은 각 테이블 간의 차이점입니다.

배치 테이블	실시간 테이블
데이터를 하루에 한 번 내보냅니다. 이벤트는 BigQuery에 일괄 쓰기 전에 영구적으로 저장됩니다. 최대 30일 전까지 데이터를 백필할 수 있습니다.	데이터를 실시간으로 내보냅니다. 백필을 사용할 수 없습니다.

배치 테이블은 이벤트를 쓰기 전에 영구적으로 저장하므로 장기 분석 및 경과에 따른 트렌드를 식별하는 데 유용하며 최대 30일* 전부터 테이블에 백필할 수 있습니다. 실시간 테이블에 데이터를 쓰면 BigQuery에 즉시 기록되므로 실시간 대시보드와 커스텀 알림에 적합합니다. 이 두 테이블을 병합 쿼리로 결합하면 두 테이블의 이점을 모두 누릴 수 있습니다.

기본적으로 실시간 테이블의 파티션 만료 시간은 30일입니다. 이를 수정하는 방법은 BigQuery 문서의 파티션 만료 시간 설정을 참조하세요.

^{* 새로운 내보내기 인프라로 업그레이드에서 백필 지원에 관한 자세한 내용을 확인하세요.}

BigQuery에 Crashlytics 스트리밍 내보내기 사용 설정

Firebase Console에서 통합 페이지로 이동합니다.
BigQuery 카드에서 관리를 클릭합니다.
스트리밍 포함 체크박스를 선택합니다.

이 작업을 수행하면 연결된 모든 앱에서 스트리밍할 수 있습니다.

내보낸 데이터로 무엇을 할 수 있나요?

BigQuery로 내보낸 데이터에는 기기 유형, 운영체제, 예외(Android 앱) 또는 오류(Apple 앱), Crashlytics 로그를 비롯한 원시 비정상 종료 데이터뿐만 아니라 기타 다른 데이터도 포함됩니다.

이 페이지의 뒷부분에서 내보내는 Crashlytics 데이터와 테이블 스키마를 정확하게 검토합니다.

데이터 스튜디오 템플릿 사용

데이터 스튜디오 템플릿에서 실시간 데이터를 사용 설정하려면 내보낸 Crashlytics 데이터를 데이터 스튜디오로 시각화하기의 안내를 따르세요.

뷰 만들기

BigQuery UI를 사용하여 쿼리를 뷰로 변환할 수 있습니다. 자세한 내용은 BigQuery 문서의 뷰 만들기를 참조하세요.

쿼리 실행

다음 예시는 Crashlytics 데이터에서 실행하여 비정상 종료 이벤트 데이터를 집계하여 더 이해하기 쉽게 요약한 보고서를 생성할 수 있는 쿼리를 보여줍니다. 이러한 유형의 보고서는 Firebase Console의 Crashlytics 대시보드에서 사용할 수 없으므로 비정상 종료 데이터에 대한 분석 및 이해를 보완할 수 있습니다.

예시 1: 날짜별 비정상 종료

버그를 최대한 해결한 후 드디어 팀이 신규 사진 공유 앱을 출시할 준비가 되었다고 생각합니다. 출시 전에 팀은 지난 달의 일일 비정상 종료 횟수를 확인하여, 그 동안 진행한 버그 수정 작업을 통해 앱이 얼마나 더 안정화되었는지 알아보려고 합니다.

다음은 Android 앱의 쿼리 예시입니다. iOS 앱의 경우 패키지 이름과 ANDROID 대신 번들 ID와 IOS를 사용하세요.

SELECT
  COUNT(DISTINCT event_id) AS number_of_crashes,
  FORMAT_TIMESTAMP("%F", event_timestamp) AS date_of_crashes
FROM
 `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
GROUP BY
  date_of_crashes
ORDER BY
  date_of_crashes DESC
LIMIT 30;

예시 2: 가장 심각한 비정상 종료 파악

프로덕션 계획의 우선순위를 적절하게 설정하기 위해 앱에서 가장 심각한 비정상 종료 중 상위 10개를 찾으려고 합니다. 관련 데이터 포인트를 제공하는 쿼리를 생성합니다.

다음은 Android 앱의 쿼리 예시입니다. iOS 앱의 경우 패키지 이름과 ANDROID 대신 번들 ID와 IOS를 사용하세요.

SELECT
  DISTINCT issue_id,
  COUNT(DISTINCT event_id) AS number_of_crashes,
  COUNT(DISTINCT installation_uuid) AS number_of_impacted_user,
  blame_frame.file,
  blame_frame.line
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(),INTERVAL 168 HOUR)
  AND event_timestamp < CURRENT_TIMESTAMP()
GROUP BY
  issue_id,
  blame_frame.file,
  blame_frame.line
ORDER BY
  number_of_crashes DESC
LIMIT 10;

예시 3: 비정상 종료가 가장 많이 발생한 상위 10개 기기

가을은 신규 스마트폰이 출시되는 시기입니다. 귀사는 이 시기가 기기별로 새로운 문제가 발견되는 시기이기도 하다는 것을 알고 있습니다. 특히 Android의 경우 그렇습니다. 앞으로 발생할 호환성 문제를 성공적으로 해결하기 위해, 지난 일주일(168시간) 동안 비정상 종료가 가장 많이 발생했던 10대의 기기를 식별하는 쿼리를 작성합니다.

다음은 Android 앱의 쿼리 예시입니다. iOS 앱의 경우 패키지 이름과 ANDROID 대신 번들 ID와 IOS를 사용하세요.

SELECT
  device.model,
COUNT(DISTINCT event_id) AS number_of_crashes
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 168 HOUR)
  AND event_timestamp < CURRENT_TIMESTAMP()
GROUP BY
  device.model
ORDER BY
  number_of_crashes DESC
LIMIT 10;

예시 4: 커스텀 키별 필터링

여러분은 게임 개발자로, 게임의 어느 레벨에서 비정상 종료가 가장 많이 발생하는지 알고 싶어 합니다.

이 통계를 추적하는 데 도움이 되도록 current_level이라는 커스텀 Crashlytics 키를 설정하고 사용자가 새 레벨에 도달할 때마다 이 키를 업데이트합니다.

Swift

Crashlytics.sharedInstance().setIntValue(3, forKey: "current_level");

Objective-C

CrashlyticsKit setIntValue:3 forKey:@"current_level";

자바

Crashlytics.setInt("current_level", 3);

BigQuery로 내보낼 때 이 키를 사용하면 각 비정상 종료 이벤트와 연결된 current_level 값의 분산을 보고하는 쿼리를 작성할 수 있습니다.

다음은 Android 앱의 쿼리 예시입니다. iOS 앱의 경우 패키지 이름과 ANDROID 대신 번들 ID와 IOS를 사용하세요.

SELECT
COUNT(DISTINCT event_id) AS num_of_crashes,
  value
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
UNNEST(custom_keys)
WHERE
  key = "current_level"
GROUP BY
  key,
  value
ORDER BY
  num_of_crashes DESC

예시 5: 사용자 ID 추출

사전 체험판 Android 앱을 하나 갖고 있습니다. 사용자 대부분은 이 앱을 좋아하지만 세 명의 사용자에게는 이례적으로 자주 비정상 종료가 발생했습니다. 문제의 원인을 파악하기 위해, 팀은 사용자 ID를 사용하여 사용자에게 발생하는 모든 비정상 종료 이벤트를 가져오는 쿼리를 작성합니다.

다음은 Android 앱의 쿼리 예시입니다. iOS 앱의 경우 패키지 이름과 ANDROID 대신 번들 ID와 IOS를 사용하세요.

SELECT *
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  user.id IN ("USER_ID_1", "USER_ID_2", "USER_ID_3")
ORDER BY
  user.id

예시 6: 특정 비정상 종료 문제를 경험한 모든 사용자 파악

팀에서 실수로 베타 테스터 그룹을 대상으로 심각한 버그를 배포했습니다. 팀은 위의 '가장 심각한 비정상 종료 파악' 예시의 쿼리를 사용하여 특정 비정상 종료 문제 ID를 파악할 수 있었습니다. 이제 이들은 이 비정상 종료의 영향을 받은 앱 사용자 목록을 추출하는 다음과 같은 쿼리를 실행합니다.

다음은 Android 앱의 쿼리 예시입니다. iOS 앱의 경우 패키지 이름과 ANDROID 대신 번들 ID와 IOS를 사용하세요.

SELECT user.id as user_id
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  issue_id = "ISSUE_ID"
  AND application.display_version = "APP_VERSION"
  AND user.id != ""
ORDER BY
  user.id;

예시 7: 비정상 종료 문제의 영향을 받은 사용자 수(국가별 분류)

팀에서 새 버전 출시 중 심각한 버그를 탐지했습니다. 위의 '가장 심각한 비정상 종료 파악' 예시의 쿼리를 사용하여 특정 비정상 종료 문제 ID를 파악할 수 있었습니다. 이제 이 비정상 종료가 전 세계 여러 국가의 사용자에게 확산되는지 여부를 관찰하려고 합니다.

이 쿼리를 작성하려면 팀에서 다음을 수행해야 합니다.

Google Analytics 데이터를 BigQuery로 내보내도록 사용 설정합니다. BigQuery에 프로젝트 데이터 내보내기를 참조하세요.

사용자 ID가 Google Analytics SDK 및 Crashlytics SDK에 모두 전달되도록 앱을 업데이트합니다.

Swift

Crashlytics.sharedInstance().setUserIdentifier("123456789");
Analytics.setUserID("123456789");

Objective-C

CrashlyticsKit setUserIdentifier:@"123456789";
FIRAnalytics setUserID:@"12345678 9";

자바

Crashlytics.setUserIdentifier("123456789");
mFirebaseAnalytics.setUserId("123456789");

사용자 ID 필드를 사용하여 Google Analytics 데이터 세트의 이벤트를 Crashlytics 데이터 세트의 비정상 종료와 조인하는 쿼리를 작성합니다.

다음은 Android 앱의 쿼리 예시입니다. iOS 앱의 경우 패키지 이름과 ANDROID 대신 번들 ID와 IOS를 사용하세요.

SELECT DISTINCT c.issue_id, a.geo.country, COUNT(DISTINCT c.user.id) as num_users_impacted
FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` c
INNER JOIN  `PROJECT_ID.analytics_TABLE_NAME.events_*` a on c.user.id = a.user_id
WHERE
  c.issue_id = "ISSUE_ID"
  AND a._TABLE_SUFFIX BETWEEN '20190101'
  AND '20200101'
GROUP BY
  c.issue_id,
  a.geo.country,
  c.user.id

예시 8: 상위 5개 문제(오늘 기준)

다음은 Android 앱의 쿼리 예시입니다. iOS 앱의 경우 패키지 이름과 ANDROID 대신 번들 ID와 IOS를 사용하세요.

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME`
WHERE
  DATE(event_timestamp) = CURRENT_DATE()
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

예시 9: 상위 5개 문제(DATE~오늘)

배치 테이블과 실시간 테이블을 스티칭 쿼리와 결합하여 안정적인 일괄 데이터에 실시간 정보를 추가할 수도 있습니다. event_id는 기본 키이므로 DISTINCT event_id를 사용하여 두 테이블에서 공통 이벤트를 중복 삭제할 수 있습니다.

다음은 Android 앱의 쿼리 예시입니다. iOS 앱의 경우 패키지 이름과 ANDROID 대신 번들 ID와 IOS를 사용하세요.

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM (
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME`
  UNION ALL
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`)
WHERE
  event_timestamp >= "YYYY_MM_DD"
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

BigQuery의 Crashlytics 스키마 이해

BigQuery로 Crashlytics 데이터 내보내기를 설정하면 Firebase는 연결 이틀 전까지의 이벤트를 포함한 최근 이벤트(비정상 종료, 심각하지 않은 오류, ANR)를 내보냅니다. 최대 30일까지 백필할 수 있는 옵션도 제공됩니다.

Firebase는 이 시점부터 내보내기를 비활성화할 때까지 매일 Crashlytics 이벤트를 내보냅니다. 매번 내보내기를 실행한 후 BigQuery에서 데이터를 사용할 수 있을 때까지 몇 분이 소요될 수 있습니다.

데이터 세트

Crashlytics는 Crashlytics 데이터마다 BigQuery에 새 데이터 세트를 만듭니다. 이 데이터 세트는 프로젝트에 여러 개의 앱이 있더라도 프로젝트 전체를 포함합니다.

표

Crashlytics는 특정 앱의 데이터 내보내기를 제외하지 않는 한, 데이터 세트에 프로젝트의 앱별 테이블을 생성합니다. Firebase는 앱의 식별자에 따라 테이블의 이름을 지정하며, 마침표를 밑줄로 변환하고 마지막에 플랫폼 이름을 붙입니다.

예를 들어 패키지 이름이 com.google.test인 Android 앱의 데이터는 com_google_test_ANDROID라는 이름의 테이블에 포함되고, 실시간 데이터(사용 설정된 경우)는 com_google_test_ANDROID_REALTIME이라는 테이블에 포함되게 됩니다.

테이블에는 앱에서 정의한 커스텀 Crashlytics 키 외에 표준 Crashlytics 데이터 세트가 포함됩니다.

행

테이블의 각 행은 앱에 발생한 오류를 나타냅니다.

열

비정상 종료, 심각하지 않은 오류, ANR의 테이블 열은 동일합니다. BigQuery로 Crashlytics 스트리밍 내보내기가 사용 설정되어 있으면 실시간 테이블에 배치 테이블과 동일한 열이 포함됩니다. 스택 트레이스가 없는 이벤트를 나타내는 행에 열이 있을 수 있습니다.

내보내기 파일의 열은 다음 표에 나와 있습니다.

필드 이름	데이터 유형	설명
`platform`	STRING	Firebase 프로젝트에 등록된 앱의 플랫폼입니다(유효한 값: `IOS` 또는 `ANDROID`).
`bundle_identifier`	STRING	Firebase 프로젝트에 등록된 앱의 고유 식별자입니다(예: `com.google.gmail`). Apple 플랫폼 앱의 경우 앱의 번들 ID입니다. Android 앱의 경우 앱의 패키지 이름입니다.
`event_id`	STRING	이벤트의 고유 ID입니다.
`is_fatal`	부울	이 필드는 더 이상 사용되지 않습니다. 대신 `error_type`을 사용하세요. 앱의 비정상 종료 여부
`error_type`	STRING	이벤트의 오류 유형입니다(예: `FATAL`, `NON_FATAL`, `ANR` 등).
`issue_id`	STRING	이벤트와 관련된 문제
`variant_id`	STRING	이 이벤트와 관련된 문제 변형 모든 이벤트에 관련된 문제 변형이 있는 것은 아닙니다.
`event_timestamp`	TIMESTAMP	이벤트가 발생한 시점
`device`	RECORD	이벤트가 발생한 기기
`device.manufacturer`	STRING	기기 제조업체
`device.model`	STRING	기기 모델
`device.architecture`	STRING	예를 들면 `X86_32`, `X86_64`, `ARMV7`, `ARM64`, `ARMV7S` 또는 `ARMV7K`입니다.
`memory`	RECORD	기기의 메모리 상태
`memory.used`	INT64	메모리 사용량(바이트)
`memory.free`	INT64	남은 메모리(바이트)
`storage`	RECORD	기기의 영구 스토리지
`storage.used`	INT64	스토리지 사용량(바이트)
`storage.free`	INT64	남은 스토리지(바이트)
`operating_system`	RECORD	기기의 OS 세부정보
`operating_system.display_version`	STRING	기기의 OS 버전
`operating_system.name`	STRING	기기의 OS 이름
`operating_system.modification_state`	STRING	기기가 수정되었는지 여부(예: 탈옥된 앱은 `MODIFIED`이고 루팅된 앱은 `UNMODIFIED`)
`operating_system.type`	STRING	(Apple 앱만 해당) 기기에서 실행되는 OS 유형(예: `IOS`, `MACOS` 등)
`operating_system.device_type`	STRING	기기 유형(예: `MOBILE`, `TABLET`, `TV` 등), '기기 카테고리'라고도 함
`application`	RECORD	이벤트를 생성한 앱
`application.build_version`	STRING	앱의 빌드 버전
`application.display_version`	STRING
`user`	RECORD	(선택사항) 앱 사용자에 대해 수집된 정보
`user.name`	STRING	이 필드는 지원 중단되었습니다. 이 필드를 사용하지 마세요. (선택사항) 사용자의 이름
`user.email`	STRING	이 필드는 지원 중단되었습니다. 이 필드를 사용하지 마세요. (선택사항) 사용자의 이메일 주소
`user.id`	STRING	(선택사항) 사용자와 연결된 앱별 ID
`custom_keys`	반복 레코드	개발자가 정의한 키-값 쌍
`custom_keys.key`	STRING	개발자가 정의한 키
`custom_keys.value`	STRING	개발자가 정의한 값
`installation_uuid`	STRING	고유의 앱 및 기기 설치를 식별하는 ID
`crashlytics_sdk_versions`	STRING	이벤트를 생성한 Crashlytics SDK 버전
`app_orientation`	STRING	예: `PORTRAIT`, `LANDSCAPE`, `FACE_UP`, `FACE_DOWN`, 등
`device_orientation`	STRING	예: `PORTRAIT`, `LANDSCAPE`, `FACE_UP`, `FACE_DOWN`, 등
`process_state`	STRING	`BACKGROUND` 또는 `FOREGROUND`
`logs`	반복 레코드	Crashlytics 로거에서 생성한 타임스탬프가 적용된 로그 메시지(사용 설정된 경우)
`logs.timestamp`	TIMESTAMP	로그가 작성된 시점
`logs.message`	STRING	로깅된 메시지
`breadcrumbs`	반복 레코드	타임스탬프가 적용된 Google Analytics 탐색경로(사용 설정된 경우)
`breadcrumbs.timestamp`	TIMESTAMP	탐색경로와 연결된 타임스탬프
`breadcrumbs.name`	STRING	탐색경로와 연결된 이름
`breadcrumbs.params`	반복 레코드	탐색경로와 연결된 매개변수
`breadcrumbs.params.key`	STRING	탐색경로와 연결된 매개변수 키
`breadcrumbs.params.value`	STRING	탐색경로와 연결된 매개변수 값
`blame_frame`	RECORD	비정상 종료나 오류의 근본 원인으로 확인된 프레임
`blame_frame.line`	INT64	프레임 파일의 줄 번호
`blame_frame.file`	STRING	프레임 파일의 이름
`blame_frame.symbol`	STRING	수화 기호 또는 원시 기호(수화될 수 없는 경우)
`blame_frame.offset`	INT64	코드가 포함된 바이너리 이미지로의 바이트 오프셋 Java 예외에 대해 설정되지 않음
`blame_frame.address`	INT64	코드가 포함된 바이너리 이미지의 주소 Java 예외에 대해 설정되지 않음
`blame_frame.library`	STRING	프레임을 포함하는 라이브러리의 표시 이름
`blame_frame.owner`	STRING	예: `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM`, `SYSTEM` 등
`blame_frame.blamed`	부울	Crashlytics에서 이 프레임이 비정상 종료나 오류의 근본 원인이라고 판단했는지 여부
`exceptions`	반복 레코드	(Android만 해당) 이 이벤트 중에 발생한 예외. 중첩된 예외는 최신순으로 표시됩니다. 즉, 마지막 레코드가 처음 발생한 예외입니다.
`exceptions.type`	STRING	예외 유형(예: `java.lang.IllegalStateException)`
`exceptions.exception_message`	STRING	예외와 관련된 메시지
`exceptions.nested`	부울	마지막으로 발생한 예외를 제외하고 모두 True(즉, 첫 번째 레코드)
`exceptions.title`	STRING	스레드의 제목
`exceptions.subtitle`	STRING	스레드의 부제목
`exceptions.blamed`	부울	Crashlytics에서 예외를 오류 또는 비정상 종료의 원인으로 판단한 경우 True
`exceptions.frames`	반복 레코드	예외와 관련된 프레임
`exceptions.frames.line`	INT64	프레임 파일의 줄 번호
`exceptions.frames.file`	STRING	프레임 파일의 이름
`exceptions.frames.symbol`	STRING	수화 기호 또는 원시 기호(수화될 수 없는 경우)
`exceptions.frames.offset`	INT64	코드가 포함된 바이너리 이미지로의 바이트 오프셋 Java 예외에 대해 설정되지 않음
`exceptions.frames.address`	INT64	코드가 포함된 바이너리 이미지의 주소 Java 예외에 대해 설정되지 않음
`exceptions.frames.library`	STRING	프레임을 포함하는 라이브러리의 표시 이름
`exceptions.frames.owner`	STRING	예: `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM`, `SYSTEM` 등
`exceptions.frames.blamed`	부울	Crashlytics에서 이 프레임이 비정상 종료나 오류의 근본 원인이라고 판단했는지 여부
`error`	반복 레코드	(Apple 앱만 해당) 심각하지 않은 오류
`error.queue_name`	STRING	스레드가 실행 중인 큐
`error.code`	INT64	앱에서 커스텀 로깅된 NSError와 관련된 오류 코드
`error.title`	STRING	스레드의 제목
`error.subtitle`	STRING	스레드의 부제목
`error.blamed`	부울	Crashlytics에서 이 프레임이 오류의 근본 원인이라고 판단했는지 여부
`error.frames`	반복 레코드	스택 추적의 프레임
`error.frames.line`	INT64	프레임 파일의 줄 번호
`error.frames.file`	STRING	프레임 파일의 이름
`error.frames.symbol`	STRING	수화 기호 또는 원시 기호(수화될 수 없는 경우)
`error.frames.offset`	INT64	코드가 포함된 바이너리 이미지로의 바이트 오프셋
`error.frames.address`	INT64	코드가 포함된 바이너리 이미지의 주소
`error.frames.library`	STRING	프레임을 포함하는 라이브러리의 표시 이름
`error.frames.owner`	STRING	예: `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM`, `SYSTEM` 등
`error.frames.blamed`	부울	Crashlytics에서 이 프레임이 오류의 근본 원인이라고 판단했는지 여부
`threads`	반복 레코드	이벤트 발생 시점에 표시된 스레드
`threads.crashed`	부울	스레드의 비정상 종료 여부
`threads.thread_name`	STRING	스레드의 이름
`threads.queue_name`	STRING	(Apple 앱만 해당) 스레드가 실행 중인 큐
`threads.signal_name`	STRING	앱의 비정상 종료를 유발한 신호의 이름(비정상 종료된 네이티브 스레드에만 있음)
`threads.signal_code`	STRING	앱의 비정상 종료를 유발한 신호의 코드(비정상 종료된 네이티브 스레드에만 있음)
`threads.crash_address`	INT64	앱의 비정상 종료를 유발한 신호의 주소(비정상 종료된 네이티브 스레드에만 있음)
`threads.code`	INT64	(Apple 앱만 해당) 애플리케이션에서 커스텀 로깅된 NSError의 오류 코드
`threads.title`	STRING	스레드의 제목
`threads.subtitle`	STRING	스레드의 부제목
`threads.blamed`	부울	Crashlytics에서 이 프레임이 비정상 종료나 오류의 근본 원인이라고 판단했는지 여부
`threads.frames`	반복 레코드	스레드의 프레임
`threads.frames.line`	INT64	프레임 파일의 줄 번호
`threads.frames.file`	STRING	프레임 파일의 이름
`threads.frames.symbol`	STRING	수화 기호 또는 원시 기호(수화될 수 없는 경우)
`threads.frames.offset`	INT64	코드가 포함된 바이너리 이미지로의 바이트 오프셋
`threads.frames.address`	INT64	코드가 포함된 바이너리 이미지의 주소
`threads.frames.library`	STRING	프레임을 포함하는 라이브러리의 표시 이름
`threads.frames.owner`	STRING	예: `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM`, `SYSTEM` 등
`threads.frames.blamed`	부울	Crashlytics에서 이 프레임이 오류의 근본 원인이라고 판단했는지 여부
`unity_metadata.unity_version`	STRING	이 기기에서 실행 중인 Unity 버전
`unity_metadata.debug_build`	부울	디버그 빌드인 경우
`unity_metadata.processor_type`	STRING	프로세서 유형
`unity_metadata.processor_count`	INT64	프로세서 수(코어)
`unity_metadata.processor_frequency_mhz`	INT64	프로세서의 주파수(MHz)
`unity_metadata.system_memory_size_mb`	INT64	시스템의 메모리 크기(MB)
`unity_metadata.graphics_memory_size_mb`	INT64	그래픽 메모리(MB)
`unity_metadata.graphics_device_id`	INT64	그래픽 기기의 식별자
`unity_metadata.graphics_device_vendor_id`	INT64	그래픽 프로세서 공급업체의 식별자
`unity_metadata.graphics_device_name`	STRING	그래픽 기기의 이름
`unity_metadata.graphics_device_vendor`	STRING	그래픽 기기의 공급업체
`unity_metadata.graphics_device_version`	STRING	그래픽 기기의 버전
`unity_metadata.graphics_device_type`	STRING	그래픽 기기의 유형
`unity_metadata.graphics_shader_level`	INT64	그래픽의 셰이더 수준
`unity_metadata.graphics_render_target_count`	INT64	그래픽 렌더링 대상 수
`unity_metadata.graphics_copy_texture_support`	STRING	Unity API에 정의된 대로 그래픽 텍스처 복사 지원
`unity_metadata.graphics_max_texture_size`	INT64	렌더링 텍스처 전용 최대 크기
`unity_metadata.screen_size_px`	STRING	너비x높이 형식의 화면 크기(픽셀)
`unity_metadata.screen_resolution_dpi`	STRING	화면의 DPI(부동 소수점 수)
`unity_metadata.screen_refresh_rate_hz`	INT64	화면 재생 빈도(Hz)

내보낸 Crashlytics 데이터를 데이터 스튜디오로 시각화

Google 데이터 스튜디오는 BigQuery의 Crashlytics 데이터 세트를 읽기 쉽고 공유하기 쉬우며 완벽하게 맞춤설정이 가능한 보고서로 바꿔줍니다.

데이터 스튜디오의 사용에 관한 자세한 내용은 데이터 스튜디오 빠른 시작 가이드, Data Studio에 오신 것을 환영합니다를 참조하세요.

Crashlytics 보고서 템플릿 사용

데이터 스튜디오에는 내보낸 Crashlytics BigQuery 스키마의 포괄적인 측정기준 및 측정항목 세트를 포함하는 Crashlytics 샘플 보고서가 있습니다. BigQuery로 Crashlytics 스트리밍 내보내기를 사용 설정한 경우 데이터 스튜디오 템플릿의 실시간 트렌드에서 해당 데이터를 볼 수 있습니다.이 샘플을 템플릿으로 사용하면 내 앱의 원시 비정상 종료 데이터를 기반으로 새로운 보고서를 빠르게 작성하고 시각화할 수 있습니다.

Crashlytics 데이터 스튜디오 대시보드 템플릿을 엽니다.
오른쪽 상단의 템플릿 사용을 클릭합니다.
새 데이터 소스 드롭다운에서 새 데이터 소스 만들기를 선택합니다.
BigQuery 카드에서 선택을 클릭합니다.
내 프로젝트 > PROJECT_ID > firebase_crashlytics > TABLE_NAME을 선택하여 내보낸 Crashlytics 데이터가 포함된 테이블을 선택합니다.

배치 테이블은 언제든지 선택할 수 있습니다. BigQuery로 Crashlytics 스트리밍 내보내기가 사용 설정된 경우 실시간 테이블을 대신 선택할 수 있습니다.
구성 아래에서, Crashlytics 템플릿 수준을 기본값으로 설정합니다.
연결을 클릭하여 새 데이터 소스를 만듭니다.
보고서에 추가를 클릭하여 Crashlytics 템플릿으로 돌아갑니다.
마지막으로 보고서 작성을 클릭하여 Crashlytics 데이터 스튜디오 대시보드 템플릿의 사본을 만듭니다.

새 내보내기 인프라로 업그레이드

2024년 10월 중순, Crashlytics는 Crashlytics 데이터를 BigQuery로 내보내기 위한 새로운 인프라를 출시했습니다. 현재 이 새로운 인프라로 업그레이드는 선택사항입니다.

이 새로운 인프라는 미국 이외의 Crashlytics 데이터 세트 위치를 지원합니다.

2024년 10월 중순 이전에 내보내기를 사용 설정한 경우 원하는 경우 BigQuery 지원 데이터 세트 위치로 데이터 내보내기 위치를 변경할 수 있습니다.
2024년 10월 중순 이후에 내보내기를 사용 설정한 경우 설정 중에 BigQuery에서 지원하는 데이터 세트 위치를 선택할 수 있습니다.

새 인프라의 또 다른 차이점은 내보내기를 사용 설정하기 전의 데이터 백필을 지원하지 않는다는 점입니다. (이전 인프라에서는 사용 설정일로부터 최대 30일 전까지 백필할 수 있었습니다.) 새 인프라는 최대 지난 30일 동안의 또는 BigQuery 내보내기를 사용 설정한 가장 최근 날짜(둘 중 최근)에 대해 백필을 지원합니다.

업그레이드의 기본 요건

새 인프라로 업그레이드하기 전에 다음 기본 요건을 충족하는지 확인하세요. 현재 배치 BigQuery 테이블의 식별자가 등록된 Firebase 앱에 설정된 번들 ID 또는 패키지 이름과 일치합니다.

예를 들면 다음과 같습니다.

com_yourcompany_yourproject_IOS라는 BigQuery 테이블이 있는 경우 Firebase 프로젝트에 번들 ID com.yourcompany.yourproject로 등록된 Firebase iOS+ 앱이 있어야 합니다.
com_yourcompany_yourproject_ANDROID라는 BigQuery 테이블이 있는 경우 Firebase 프로젝트에 패키지 이름이 com.yourcompany.yourproject인 Firebase Android 앱이 등록되어 있어야 합니다.

Firebase 프로젝트에 등록된 모든 Firebase 앱을 찾는 방법은 다음과 같습니다.

Firebase Console에서 프로젝트 설정으로 이동합니다.
내 앱 카드까지 아래로 스크롤한 다음 원하는 Firebase 앱을 클릭하여 식별자를 포함한 앱 정보를 확인합니다.

새 내보내기 인프라는 등록된 Firebase 앱에 설정된 패키지 이름 또는 번들 ID를 기반으로 각 앱의 데이터를 내보냅니다. BigQuery 워크플로가 중단되지 않도록 하려면 새 인프라가 모든 새 데이터를 기존 테이블에 추가할 수 있도록 현재 배치 테이블의 이름이 이미 올바른지 확인하는 것이 중요합니다. 등록된 Firebase 앱과 일치하지 않는 배치 테이블 이름이 있지만 업그레이드하려면 Firebase 지원팀에 문의하세요.

새 인프라로 업그레이드하는 방법

이미 내보내기를 사용 설정한 경우 Firebase Console에서 Crashlytics 데이터 내보내기를 사용 중지했다가 다시 사용 설정하기만 하면 새 인프라로 업그레이드할 수 있습니다.

자세한 단계는 다음과 같습니다.

Firebase 콘솔에서 통합 페이지로 이동합니다.
BigQuery 카드에서 관리를 클릭합니다.
Crashlytics 슬라이더를 사용 중지하여 내보내기를 사용 중지합니다. 메시지가 표시되면 데이터 내보내기를 중지할 것인지 확인합니다.
즉시 Crashlytics 슬라이더를 다시 사용 설정하여 내보내기를 다시 사용 설정합니다. 메시지가 표시되면 데이터를 내보낼 것인지 확인합니다.

BigQuery로의 Crashlytics 데이터 내보내기에 이제 새 내보내기 인프라가 사용됩니다.