您可以將 Firebase Crashlytics 資料匯出至 BigQuery,以進行進一步分析。BigQuery 讓您使用 BigQuery SQL 分析資料、匯出至其他雲端供應商,以及透過 Looker Studio 製作視覺化圖表和自訂資訊主頁。
匯出資料的用途
匯出至 BigQuery 的檔案包含原始當機資料,包括裝置類型、作業系統、例外狀況 (Android 應用程式) 或錯誤 (Apple 應用程式),以及 Crashlytics 記錄和其他資料。您稍後可在本頁查看匯出的Crashlytics資料內容和資料表結構定義。
以下列舉幾個匯出資料的用途:Crashlytics
- 執行查詢 
 您可以對 Crashlytics 資料執行查詢,產生報表,將當機事件資料匯總至更容易理解的摘要中。由於這些類型的報表無法在控制台的 Crashlytics 資訊主頁中取得,因此可做為補充資料,協助您分析及瞭解當機資料。Firebase本頁稍後會提供查詢範例。
- 使用 Looker Studio 範本 
 Crashlytics 提供預先建構的 Looker Studio 範本 ,用於將匯出的資料視覺化。
- 建立檢視區塊 
 使用 BigQuery UI 建立檢視區塊,也就是由 SQL 查詢定義的虛擬資料表。如需不同類型檢視區塊的詳細操作說明,以及如何建立檢視區塊,請參閱 BigQuery 說明文件。
- 將 Crashlytics 專屬資料與 Firebase 工作階段資料合併 
 設定 Crashlytics 資料匯出功能時,您也可以匯出 Firebase 工作階段資料。運用這項工作階段資料,進一步瞭解未發生當機情形的使用者和工作階段。
將資料串流匯出至 BigQuery 的優點
根據預設,資料會每天批次匯出至 BigQuery。 此外,您也可以使用BigQuery串流功能,即時串流 Crashlytics 資料和 Firebase 工作階段。您可以使用這項功能處理任何需要即時資料的用途,例如在即時資訊主頁中呈現資訊、觀看發布作業的即時情況,或是監控會觸發快訊和自訂工作流程的應用程式問題。
啟用串流匯出至 BigQuery 時,您也會取得即時資料表 (除了批次資料表之外)。這兩種資料表都會有相同的資料集結構定義,但批次資料表和即時資料表之間有以下重要差異:
| 批次資料表 | 即時表格 | 
|---|---|
| 
 | 
 | 
批次資料表適合長期分析及找出一段時間內的趨勢,因為系統會先永久儲存事件,再寫入資料表,且最多可回填 30 天的資料*。當我們將資料寫入即時資料表時,會立即將資料寫入 BigQuery,因此非常適合用於即時資訊主頁和自訂快訊。這兩個資料表可以透過縫合查詢合併,同時享有兩者的優點。
根據預設,即時資料表的分區到期時間為 30 天。如要瞭解如何修改這項設定,請參閱 BigQuery 說明文件中的「設定分割區到期時間」。
* 如要瞭解回填支援的詳細資訊,請參閱「升級至新的匯出基礎架構」。
啟用匯出至「BigQuery」的功能
- 前往 Firebase 控制台的「整合」頁面。 
- 在 BigQuery 資訊卡中,按一下「連結」。 
- 按照畫面上的指示啟用匯出至 BigQuery 的功能, 包括下列選項: - 如要進一步瞭解未受當機影響的使用者和未發生當機情形的工作階段,請啟用 Firebase 工作階段資料匯出功能。 
- 如要在 BigQuery 中近乎即時地存取 Crashlytics 資料和 Firebase 工作階段資料,請啟用串流匯出功能。 
 
啟用匯出功能後會發生什麼情況?
- Firebase 會匯出連結至 BigQuery 的應用程式資料。 - 設定時,專案中的所有應用程式預設都會連結至 BigQuery,但您可以在設定期間選擇「不」連結特定應用程式。 
- 您之後加進 Firebase 專案的應用程式,都會自動連結至 BigQuery。 
- 您隨時可以管理哪些應用程式可以匯出資料。 
 
- Firebase 會將資料匯出至您在設定期間選取的資料集位置。 - 這個位置會同時套用到 Crashlytics 資料集和 Firebase 工作階段資料集 (如果已啟用工作階段資料匯出功能)。 
- 這個位置僅適用於匯出至 BigQuery 的資料,不會影響儲存的資料位置,這些資料可用於 Firebase 控制台的 Crashlytics 資訊主頁或 Android Studio。 
- 資料集建立後,該資料集的位置就無法再變更,不過您可以將資料集複製到其他位置,或將資料集手動移動 (重新建立) 至其他位置。詳情請參閱「變更現有匯出作業的位置」。 
 
- Firebase 會設定每日將批次資料同步至 BigQuery。 - 連結至 BigQuery 後,初始批次資料匯出作業最多可能需要 48 小時。 
- 無論您在 BigQuery 中設定的排定匯出作業為何,系統每天都會執行一次每日同步作業。請注意,同步作業的時間和持續時間可能會變更,因此不建議根據匯出的特定時間安排下游作業或工作。 
 
- Firebase 會將現有資料副本匯出至 BigQuery。 - 針對每個連結的應用程式,匯出內容會包含一個批次資料表,內含每日同步處理的資料。 
- 您可以手動排定資料回填作業,為批次資料表回填過去 30 天的資料或啟用匯出至 BigQuery 的最新日期資料 (以較近的日期為準)。 
 - 請注意,如果您在 2024 年 10 月中旬前啟用 Crashlytics 資料匯出功能,也可以回填啟用匯出功能前 30 天的資料。 
- 如果您啟用串流匯出至 BigQuery,則適用下列規定。 - 此外,每個已連結的應用程式都會有自己的即時資料表,其中包含持續更新的資料 (除了應用程式的批次資料表,用於每日批次匯出)。 
- 啟用串流後,最多可能需要 1 小時,資料才會開始串流。 
 
查詢範例
範例 1:使用 Firebase 工作階段資料計算未發生當機情形的指標
您在最新版本中大幅改版應用程式,解決重要使用者歷程中的當機問題。您收到許多使用者好評,但希望取得量化證據,證明應用程式比以往更穩定。
未發生當機情形的指標可協助您取得這項資訊。這些指標是重要的評估標準,有助於瞭解應用程式的整體健康狀態。您可以使用基本查詢,透過 Firebase 工作階段資料和 Crashlytics 事件計算這些指標。
以下是 Android 應用程式的查詢範例。如果是 iOS 應用程式,請使用軟體包 ID 和 IOS (而非套件名稱和 ANDROID)。
特定版本的未遇到當機情形的使用者:
SELECT TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY) AS event_date, (1 - (COUNT (DISTINCT installation_uuid) / COUNT (DISTINCT instance_id))) AS CFU FROM `PROJECT_ID.firebase_sessions.PACKAGE_NAME_ANDROID` AS sessions LEFT JOIN `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` AS crashlytics ON TIMESTAMP_TRUNC(_PARTITIONTIME,DAY) = TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY) WHERE crashlytics.error_type="FATAL" AND crashlytics.application.display_version="APP_VERSION" AND sessions.application.display_version = "APP_VERSION" GROUP BY event_date ORDER BY event_date
過去一週 (過去 168 小時) 未發生當機情形的工作階段:
SELECT TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY) AS event_date, (1 - (COUNT (DISTINCT crashlytics.event_id) / COUNT (DISTINCT sessions.session_id))) AS CFS FROM `PROJECT_ID.firebase_sessions.PACKAGE_NAME_ANDROID` AS sessions LEFT JOIN `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` AS crashlytics ON TIMESTAMP_TRUNC(_PARTITIONTIME,DAY) = TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY) WHERE crashlytics.error_type="FATAL" AND _PARTITIONTIME >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 168 HOUR) AND _PARTITIONTIME < CURRENT_TIMESTAMP() GROUP BY event_date ORDER BY event_date
範例 2:按天顯示的當機次數
在開發人員盡力修正各種錯誤後,您認為團隊終於可以推出新的相片分享應用程式。不過,您想先查看過去一個月內每天當機的次數,確認這段時間排除錯誤的確讓應用程式變得更穩定。
以下是 Android 應用程式的查詢範例。如果是 iOS 應用程式,請使用軟體包 ID 和 IOS (而非套件名稱和 ANDROID)。
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;
範例 3:找出最常發生的當機問題
為了適當排定生產計畫的優先順序,您想找出應用程式中最常出現的 10 大當機問題,因此產生查詢,提供相關資料點。
以下是 Android 應用程式的查詢範例。如果是 iOS 應用程式,請使用軟體包 ID 和 IOS (而非套件名稱和 ANDROID)。
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;
範例 4:前 10 大當機裝置
秋天是換新手機的季節!貴公司知道這也代表新手機問題特別多的季節來臨,Android 更是如此。為了提早因應即將到來的相容性問題,您做了一個查詢,找出最近一週 (168 小時) 最常當機的 10 台裝置。
以下是 Android 應用程式的查詢範例。如果是 iOS 應用程式,請使用軟體包 ID 和 IOS (而非套件名稱和 ANDROID)。
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;
範例 5:依自訂鍵篩選
您是遊戲開發人員,想知道遊戲的哪個關卡最常當機。
為了協助追蹤該統計資料,您設定了名為 current_level 的自訂 Crashlytics 鍵,並在使用者每次到達新關卡時更新該鍵。
Swift
Crashlytics.sharedInstance().setIntValue(3, forKey: "current_level");
Objective-C
CrashlyticsKit setIntValue:3 forKey:@"current_level";
Java
Crashlytics.setInt("current_level", 3);
透過匯出至 BigQuery 中的這個鍵,您可以撰寫查詢,回報與每次當機事件相關聯的 current_level 值分佈情況。
以下是 Android 應用程式的查詢範例。如果是 iOS 應用程式,請使用軟體包 ID 和 IOS (而非套件名稱和 ANDROID)。
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範例 6:擷取 User-ID
您有一個處於搶先體驗階段的 Android 應用程式。大部分使用者都對該應用程式感到滿意,但有三位使用者則遇到不尋常的當機次數。為了釐清問題的真正原因,您撰寫查詢,使用這些使用者的 ID 來提取所有當機事件。
以下是 Android 應用程式的查詢範例。如果是 iOS 應用程式,請使用軟體包 ID 和 IOS (而非套件名稱和 ANDROID)。
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
 範例 7:找出所有發生特定當機問題的使用者
您的團隊不慎將重大錯誤發布給一群 Beta 版測試人員。 您的團隊已使用上述「找出最常發生的當機問題」範例中的查詢,找出特定當機問題 ID。現在團隊想執行查詢,擷取受這個當機問題影響的應用程式使用者清單。
以下是 Android 應用程式的查詢範例。如果是 iOS 應用程式,請使用軟體包 ID 和 IOS (而非套件名稱和 ANDROID)。
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;範例 8:按國家/地區劃分,受當機問題影響的使用者人數
您的團隊在推出新版本時發現重大錯誤,您可以使用上述「找出最普遍的當機問題」範例中的查詢,找出特定當機問題 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";- Java- Crashlytics.setUserIdentifier("123456789"); mFirebaseAnalytics.setUserId("123456789");
- 撰寫查詢,使用使用者 ID 欄位將 Google Analytics 資料集中的事件與 Crashlytics 資料集中的當機事件合併。 - 以下是 Android 應用程式的查詢範例。如果是 iOS 應用程式,請使用軟體包 ID 和 - IOS(而非套件名稱和- ANDROID)。- 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 
範例 9:今天目前為止的前 5 大問題
以下是 Android 應用程式的查詢範例。如果是 iOS 應用程式,請使用軟體包 ID 和 IOS (而非套件名稱和 ANDROID)。
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;
範例 10:自「DATE」起 (含今天) 的前 5 大問題
您也可以使用縫合查詢,合併批次和即時資料表,將即時資訊新增至可靠的批次資料。由於 event_id 是主鍵,因此您可以使用 DISTINCT event_id,從這兩個資料表中移除任何常見的重複事件。
以下是 Android 應用程式的查詢範例。如果是 iOS 應用程式,請使用軟體包 ID 和 IOS (而非套件名稱和 ANDROID)。
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 >= PARSE_TIMESTAMP("%Y_%m_%d", "YYYY_MM_DD") GROUP BY issue_id ORDER BY events DESC LIMIT 5;
使用 Looker Studio以視覺化方式呈現匯出的 Crashlytics 資料
Looker Studio 可將 BigQuery 中的 Crashlytics 資料集轉換為報表,方便您閱讀、分享及自訂。
如要進一步瞭解如何使用 Looker Studio,請參閱歡迎指南。
使用 Crashlytics 報表範本
Looker Studio提供 Crashlytics 範例報表,其中包含從匯出的 Crashlytics BigQuery結構定義中取得的一組完整維度和指標。如果您已啟用Crashlytics串流匯出功能BigQuery,即可在Looker Studio範本的「即時趨勢」頁面查看資料。您可以使用該範例做為範本,依據您自己應用程式上的原始當機資料,快速建立新的報表與視覺化效果:
- 按一下右上角的 [Use Template] (使用範本)。 
- 在「新資料來源」下拉式選單中,選取「建立新資料來源」。 
- 按一下「BigQuery」資訊卡上的「選取」。 
- 依序選取「我的專案」> PROJECT_ID >「firebase_crashlytics」> TABLE_NAME,選擇包含匯出 Crashlytics 資料的資料表。 - 你隨時可以選取批次表格。如果啟用Crashlytics串流匯出至 BigQuery,則可改為選取即時資料表。 
- 在「Configuration」(設定) 底下,將「Crashlytics Template level」(範本等級) 設為「Default」(預設)。 
- 按一下 [Connect] (連結) 建立新的資料來源。 
- 按一下「加入報表」,即可返回 Crashlytics 範本。 
- 最後按一下「建立報表」,建立 Crashlytics Looker Studio 資訊主頁範本的副本。 
瞭解 BigQuery 中的結構定義
Firebase 會在 BigQuery 中為匯出的資料建立新資料集:
- Firebase 工作階段資料集 (如果已啟用匯出工作階段資料) 
Crashlytics 個資料集
Crashlytics資料會匯出至名為「」BigQuery的資料集firebase_crashlytics。這個資料集會涵蓋整個專案,即使專案包含多個應用程式亦同。
表格
根據預設,Firebase 會在資料集中為專案中連結至 BigQuery 的每個應用程式建立個別資料表。Crashlytics
資料表會根據應用程式的 ID 命名 (句號會轉換為底線),並附加應用程式的平台 (_IOS 或 _ANDROID)。舉例來說,如果 Android 應用程式的套件名稱為 com.google.test,資料就會位於名為 com_google_test_ANDROID 的資料表中。
- 如果啟用串流匯出至 BigQuery,資料也會即時串流至附加 - _REALTIME的資料表 (例如- com_google_test_ANDROID_REALTIME)。
- 表格中的每一列都代表應用程式中發生的事件,包括當機、非重大錯誤和 ANR。 
- 除了您在應用程式中定義的任何自訂 Crashlytics 鍵之外,這些資料表還包含一組標準的 Crashlytics 資料。 
資料列
每個在資料表中的資料列都代表應用程式遇到的某個錯誤。
欄
對於當機、輕微錯誤和 ANR 來說,資料表中的資料欄都完全相同。
- 如果啟用串流匯出至 BigQuery,即時資料表就會與批次資料表具有相同的資料欄。 
- 您可能在代表事件的資料列中,有不含堆疊追蹤記錄的資料欄。 
下表列出匯出 Crashlytics 資料時的資料欄:
| 欄位名稱 | 資料類型 | 說明 | 
|---|---|---|
| app_orientation | STRING | 例如 PORTRAIT、LANDSCAPE、FACE_UP、FACE_DOWN等。 | 
| application | RECORD | 產生事件的應用程式 | 
| application.build_version | STRING | 應用程式的建構版本 | 
| application.display_version | STRING | |
| blame_frame | RECORD | 導致當機或錯誤的頁框 | 
| blame_frame.address | INT64 | 含有程式碼的二進位映像檔中的位址 Java 框架未設定 | 
| blame_frame.blamed | BOOLEAN | Crashlytics 是否判定這個影格是導致當機或錯誤的原因 | 
| blame_frame.file | STRING | 影格檔案的名稱 | 
| blame_frame.library | STRING | 包含影格的程式庫顯示名稱 | 
| blame_frame.line | INT64 | 框架檔案的行號 | 
| blame_frame.offset | INT64 | 包含程式碼的二進位映像檔中的位元組偏移 未針對 Java 例外狀況設定 | 
| blame_frame.owner | STRING | 例如 DEVELOPER、VENDOR、RUNTIME、PLATFORM或SYSTEM | 
| blame_frame.symbol | STRING | 已補水符號,或無法補水時的原始符號 | 
| breadcrumbs | REPEATED RECORD | 時間戳記 Google Analytics 導覽標記 (如已啟用) | 
| breadcrumbs.name | STRING | 與麵包屑相關聯的名稱 | 
| breadcrumbs.params | REPEATED RECORD | 與麵包屑相關聯的參數 | 
| breadcrumbs.params.key | STRING | 與麵包屑相關聯的參數鍵 | 
| breadcrumbs.params.value | STRING | 與麵包屑相關聯的參數值 | 
| breadcrumbs.timestamp | TIMESTAMP | 與麵包屑相關的時間戳記 | 
| bundle_identifier | STRING | 在 Firebase 專案中註冊的應用程式專屬 ID (例如 com.google.gmail如果是 Apple 平台應用程式,這是指應用程式的套件組合 ID。 如果是 Android 應用程式,這是指應用程式的套件名稱。 | 
| crashlytics_sdk_versions | STRING | 產生事件的 Crashlytics SDK 版本 | 
| custom_keys | REPEATED RECORD | 開發人員定義的鍵/值組合 | 
| custom_keys.key | STRING | 開發人員定義的金鑰 | 
| custom_keys.value | STRING | 開發人員定義的值 | 
| device | RECORD | 發生事件的裝置 | 
| device_orientation | STRING | 例如 PORTRAIT、LANDSCAPE、FACE_UP、FACE_DOWN等。 | 
| device.architecture | STRING | 例如: X86_32、X86_64、ARMV7、ARM64、ARMV7S或ARMV7K | 
| device.manufacturer | STRING | 裝置製造商 | 
| device.model | STRING | 裝置型號 | 
| error | REPEATED RECORD | (僅限 Apple 應用程式) 一般錯誤 | 
| error_type | STRING | 事件的錯誤類型 (例如 FATAL、NON_FATAL、ANR等) | 
| error.blamed | BOOLEAN | Crashlytics 是否判定這個影格是錯誤的原因 | 
| error.code | INT64 | 與應用程式自訂記錄的 NSError 相關聯的錯誤代碼 | 
| error.frames | REPEATED RECORD | 堆疊追蹤的框架 | 
| error.frames.address | INT64 | 含有程式碼的二進位映像檔中的位址 | 
| error.frames.blamed | BOOLEAN | Crashlytics 是否判定這個影格是錯誤的原因 | 
| error.frames.file | STRING | 影格檔案的名稱 | 
| error.frames.library | STRING | 包含影格的程式庫顯示名稱 | 
| error.frames.line | INT64 | 框架檔案的行號 | 
| error.frames.offset | INT64 | 包含程式碼的二進位映像檔中的位元組偏移 | 
| error.frames.owner | STRING | 例如 DEVELOPER、VENDOR、RUNTIME、PLATFORM或SYSTEM | 
| error.frames.symbol | STRING | 已補水符號,或無法補水時的原始符號 | 
| error.queue_name | STRING | 執行緒執行的佇列 | 
| error.subtitle | STRING | 討論串的子標題 | 
| error.title | STRING | 討論串標題 | 
| event_id | STRING | 活動的專屬 ID | 
| event_timestamp | TIMESTAMP | 事件發生時間 | 
| exceptions | REPEATED RECORD | (僅限 Android) 此事件期間發生的例外狀況。巢狀例外狀況會依時間倒序顯示,也就是說,最後一筆記錄是擲回的第一個例外狀況 | 
| exceptions.blamed | BOOLEAN | 如果 Crashlytics 判斷例外狀況是造成錯誤或當機的原因,則為 True | 
| exceptions.exception_message | STRING | 與例外狀況相關的訊息 | 
| exceptions.frames | REPEATED RECORD | 與例外狀況相關的影格 | 
| exceptions.frames.address | INT64 | 含有程式碼的二進位映像檔中的位址 Java 框架未設定 | 
| exceptions.frames.blamed | BOOLEAN | Crashlytics 是否判定這個影格是導致當機或錯誤的原因 | 
| exceptions.frames.file | STRING | 影格檔案的名稱 | 
| exceptions.frames.library | STRING | 包含影格的程式庫顯示名稱 | 
| exceptions.frames.line | INT64 | 框架檔案的行號 | 
| exceptions.frames.offset | INT64 | 包含程式碼的二進位映像檔中的位元組偏移 未針對 Java 例外狀況設定 | 
| exceptions.frames.owner | STRING | 例如 DEVELOPER、VENDOR、RUNTIME、PLATFORM或SYSTEM | 
| exceptions.frames.symbol | STRING | 已補水符號,或無法補水時的原始符號 | 
| exceptions.nested | BOOLEAN | 除了最後擲回的例外狀況 (也就是第一個記錄) 以外,其餘皆為 True | 
| exceptions.subtitle | STRING | 討論串的子標題 | 
| exceptions.title | STRING | 討論串標題 | 
| exceptions.type | STRING | 例外狀況類型 (例如 java.lang.IllegalStateException) | 
| firebase_session_id | STRING | 系統會自動產生 Firebase 工作階段 ID,並將其對應至來自 Crashlytics 的事件 | 
| installation_uuid | STRING | 用於識別不重複的應用程式和裝置安裝作業 | 
| is_fatal | BOOLEAN | 應用程式是否異常終止 | 
| issue_id | STRING | 與事件相關的問題 | 
| logs | REPEATED RECORD | Crashlytics記錄器產生的含時間戳記記錄訊息 (如已啟用) | 
| logs.message | STRING | 記錄的訊息 | 
| logs.timestamp | TIMESTAMP | 記錄建立時間 | 
| memory | RECORD | 裝置的記憶體狀態 | 
| memory.free | INT64 | 剩餘記憶體位元組數 | 
| memory.used | INT64 | 使用的記憶體位元組數 | 
| operating_system | RECORD | 裝置作業系統的詳細資料 | 
| operating_system.device_type | STRING | 裝置類型 (例如 MOBILE、TABLET、TV等),也稱為「裝置類別」 | 
| operating_system.display_version | STRING | 裝置上的作業系統版本 | 
| operating_system.modification_state | STRING | 裝置是否經過修改 (例如,越獄解鎖的應用程式為 MODIFIED,啟用 Root 權限的應用程式為UNMODIFIED) | 
| operating_system.name | STRING | 裝置上的作業系統名稱 | 
| operating_system.type | STRING | (僅限 Apple 應用程式) 裝置執行的作業系統類型 (例如 IOS、MACOS等) | 
| platform | STRING | 在 Firebase 專案中註冊的應用程式平台
(有效值: IOS或ANDROID) | 
| process_state | STRING | BACKGROUND或FOREGROUND | 
| storage | RECORD | 裝置的永久儲存空間 | 
| storage.free | INT64 | 剩餘儲存空間 (位元組) | 
| storage.used | INT64 | 已使用的儲存空間位元組數 | 
| threads | REPEATED RECORD | 事件發生時的執行緒 | 
| threads.blamed | BOOLEAN | Crashlytics 是否判定這個影格是導致當機或錯誤的原因 | 
| threads.code | INT64 | (僅限 Apple 應用程式) 應用程式自訂記錄的 NSError 錯誤碼 | 
| threads.crash_address | INT64 | 導致應用程式停止運作的信號位址;僅適用於停止運作的原生執行緒 | 
| threads.crashed | BOOLEAN | 執行緒是否當機 | 
| threads.frames | REPEATED RECORD | 執行緒的影格 | 
| threads.frames.address | INT64 | 含有程式碼的二進位映像檔中的位址 | 
| threads.frames.blamed | BOOLEAN | Crashlytics 是否判定這個影格是錯誤的原因 | 
| threads.frames.file | STRING | 影格檔案的名稱 | 
| threads.frames.library | STRING | 包含影格的程式庫顯示名稱 | 
| threads.frames.line | INT64 | 框架檔案的行號 | 
| threads.frames.offset | INT64 | 包含程式碼的二進位映像檔中的位元組偏移 | 
| threads.frames.owner | STRING | 例如 DEVELOPER、VENDOR、RUNTIME、PLATFORM或SYSTEM | 
| threads.frames.symbol | STRING | 水合符號,或無法水合的原始符號 | 
| threads.queue_name | STRING | (僅限 Apple 應用程式) 執行執行緒的佇列 | 
| threads.signal_code | STRING | 導致應用程式當機的信號程式碼;僅適用於當機的原生執行緒 | 
| threads.signal_name | STRING | 導致應用程式當機的信號名稱,僅適用於當機的原生執行緒 | 
| threads.subtitle | STRING | 討論串的子標題 | 
| threads.thread_name | STRING | 討論串名稱 | 
| threads.title | STRING | 討論串標題 | 
| unity_metadata.debug_build | BOOLEAN | 如果是偵錯版本 | 
| unity_metadata.graphics_copy_texture_support | STRING | 支援複製圖形紋理,如 Unity API 中所定義 | 
| unity_metadata.graphics_device_id | INT64 | 圖形裝置的 ID | 
| unity_metadata.graphics_device_name | STRING | 顯示裝置的名稱 | 
| unity_metadata.graphics_device_type | STRING | 顯示裝置類型 | 
| unity_metadata.graphics_device_vendor_id | INT64 | 圖形處理器供應商的 ID | 
| unity_metadata.graphics_device_vendor | STRING | 繪圖裝置的供應商 | 
| unity_metadata.graphics_device_version | STRING | 顯示裝置版本 | 
| unity_metadata.graphics_max_texture_size | INT64 | 專用於算繪紋理的大小上限 | 
| unity_metadata.graphics_memory_size_mb | INT64 | 以 MB 為單位的圖形記憶體 | 
| unity_metadata.graphics_render_target_count | INT64 | 圖形算繪目標數量 | 
| unity_metadata.graphics_shader_level | INT64 | 圖像的著色器層級 | 
| unity_metadata.processor_count | INT64 | 處理器 (核心) 數量 | 
| unity_metadata.processor_frequency_mhz | INT64 | 處理器的頻率(以 MHz 為單位) | 
| unity_metadata.processor_type | STRING | 處理器類型 | 
| unity_metadata.screen_refresh_rate_hz | INT64 | 螢幕的刷新率 (以 Hz 為單位) | 
| unity_metadata.screen_resolution_dpi | STRING | 螢幕的 DPI,以浮點數表示 | 
| unity_metadata.screen_size_px | STRING | 螢幕大小 (以像素為單位),格式為「寬 x 高」 | 
| unity_metadata.system_memory_size_mb | INT64 | 系統記憶體大小 (以 MB 為單位) | 
| unity_metadata.unity_version | STRING | 裝置上執行的 Unity 版本 | 
| user | RECORD | (選用) 收集應用程式使用者相關資訊 | 
| user.email | STRING | (選用) 使用者的電子郵件地址 | 
| user.id | STRING | (選用) 與使用者相關聯的應用程式專屬 ID | 
| user.name | STRING | (選用) 使用者名稱 | 
| variant_id | STRING | 與這個事件相關聯的問題變體 請注意,並非所有事件都有相關聯的問題變體。 | 
Firebase 工作階段資料集
Firebase 工作階段資料會匯出至名為「BigQuery」的資料集firebase_sessions。這個資料集會涵蓋整個專案,即使專案包含多個應用程式亦同。
表格
根據預設,Firebase 會在 Firebase 工作階段資料集中,為專案中連結至 BigQuery 的每個應用程式建立個別資料表。
資料表會根據應用程式 ID 命名 (句號會轉換為底線),並附加應用程式平台 (_IOS 或 _ANDROID)。舉例來說,套件名稱為 com.google.test 的 Android 應用程式資料會位於名為 com_google_test_ANDROID 的資料表中。
資料列
表格中的每一列都代表發生的工作階段事件。
欄
如果啟用串流匯出至 BigQuery,即時資料表就會與批次資料表具有相同的資料欄。
下表列出匯出的 Firebase 工作階段資料包含的資料欄:
| 欄位名稱 | 資料類型 | 說明 | 
|---|---|---|
| instance_id | STRING | 裝置的 Firebase 安裝 ID (FID)。識別應用程式和裝置的專屬安裝項目 | 
| session_id | STRING | 這個工作階段的專屬 ID | 
| first_session_id | STRING | 自應用程式冷啟動以來,這個工作階段所屬的一系列工作階段的第一個 ID。這可用於將自冷啟動以來發生的所有工作階段分組。如果這是第一個工作階段,這個欄位會與 session_id相同。 | 
| session_index | INTEGER | 這個工作階段的訂單是在應用程式冷啟動後送達。如果是冷啟動後的第一個工作階段,這個值會是 0。每產生一個工作階段,索引就會遞增,且不會發生冷啟動 (例如閒置 30 分鐘後)。 | 
| event_type | STRING | 工作階段中發生的事件類型 (例如 SESSION_START) | 
| event_timestamp | TIMESTAMP | 事件發生的時間 | 
| received_timestamp | TIMESTAMP | 伺服器從裝置收到事件的時間 | 
| performance_data_collection_enabled | BOOLEAN | 工作階段期間是否已啟用 Firebase 效能監控 SDK 資料收集功能 | 
| crashlytics_data_collection_enabled | BOOLEAN | 工作階段期間是否啟用 Firebase Crashlytics SDK 資料收集功能 | 
| application | RECORD | 說明應用程式 | 
| application.build_version | STRING | 應用程式的版本 (例如 1523456) | 
| application.display_version | STRING | 應用程式的顯示版本 (例如 4.1.7) | 
| device | RECORD | 發生事件的裝置 | 
| device.model | STRING | 裝置型號 | 
| device.manufacturer | STRING | 裝置製造商。如果是 Apple 平台應用程式,則為 NULL。 | 
| operating_system | RECORD | 說明裝置的 OS | 
| operating_system.display_version | STRING | 作業系統的顯示版本 (例如 10.2.1) | 
| operating_system.name | STRING | 作業系統名稱 | 
| operating_system.type | STRING | 作業系統類型 (例如 IOS)。
        這個欄位只會針對 Apple 裝置設定。 | 
| operating_system.device_type | STRING | 裝置類型 (例如 MOBILE、TABLET、TV) | 
升級至新的匯出基礎架構
2024 年 10 月中旬,Crashlytics推出了新基礎架構,可批次將 Crashlytics 資料匯出至 BigQuery。
所有 Firebase 專案最快將於 2025 年 9 月 15 日自動升級至新的批次匯出基礎架構。 您可以在這個日期前升級,但請確認 BigQuery 批次資料表符合升級的必要條件。
您可以升級至新版基礎架構,但請確認批次資料表符合升級的先決條件。BigQuery
判斷是否使用新基礎架構
如果您在 2024 年 10 月中旬以後啟用批次匯出功能,Firebase 專案就會自動使用新的匯出基礎架構。
如要查看專案使用的基礎架構,請前往 Google Cloud 控制台,如果「資料移轉設定」標示為 Firebase Crashlytics with Multi-Region Support,則專案使用新的匯出基礎架構。
舊版和新版匯出基礎架構的重要差異
- 新基礎架構支援Crashlytics美國以外的資料集位置。 - 在 2024 年 10 月中旬前啟用匯出功能並升級至新的匯出基礎架構:您現在可以選擇變更資料匯出位置。 
- 2024 年 10 月中旬後啟用匯出功能:設定時系統會提示你選取資料匯出位置。 
 
- 新基礎架構不支援回填啟用匯出之前的資料。 - 舊版基礎架構支援回填最多 30 天的資料,時間範圍為啟用匯出功能當天之前。 
- 新基礎架構支援回填過去 30 天內的資料或您啟用匯出至 BigQuery 的最新日期 (以較近者為準)。 
 
- 新基礎架構會使用 Firebase 專案中為 Firebase 應用程式設定的 ID,為批次資料表命名。BigQuery - 舊版基礎架構會將資料寫入批次資料表,並根據應用程式二進位檔中的軟體包 ID 或套件名稱命名。 
- 新基礎架構會根據在 Firebase 專案中為已註冊 Firebase 應用程式設定的軟體包 ID 或套件名稱,將資料寫入批次資料表。 
 
步驟 1:升級的必要條件
- 確認現有的 BigQuery 批次資料表使用的 ID 與在 Firebase 專案中為已註冊 Firebase 應用程式設定的軟體包 ID 或套件名稱相符。如果不符,匯出的批次資料可能會中斷。大多數專案都會處於適當且相容的狀態,但升級前請務必檢查。 - 如要查看 Firebase 專案中註冊的所有 Firebase 應用程式,請前往 Firebase 控制台:依序前往「專案設定」,然後捲動至「您的應用程式」資訊卡,即可查看所有 Firebase 應用程式及其資訊。 
- 您可以在 Google Cloud 控制台的BigQuery 頁面中找到所有 BigQuery 批次表格。 
 - 舉例來說,以下是升級時不會發生任何問題的理想狀態: - 您有一個名為 - com_yourcompany_yourproject_IOS的批次資料表,以及在 Firebase 專案中註冊的 Firebase iOS+ 應用程式,軟體包 ID 為- com.yourcompany.yourproject。
- 您有一個名為「 - com_yourcompany_yourproject_ANDROID」的批次資料表,以及在 Firebase 專案中註冊的 Firebase Android 應用程式,套件名稱為「- com.yourcompany.yourproject」。
 
- 如果批次資料表名稱不符合已註冊 Firebase 應用程式的 ID,請按照本頁稍後的說明操作,在手動升級或 2025 年 9 月 15 日前完成設定,以免批次匯出作業中斷。 
步驟 2:手動升級至新基礎架構
如果您在 2024 年 10 月中旬前啟用批次匯出功能,只要在 Firebase 控制台中切換 Crashlytics 資料匯出功能,先關閉再開啟,即可手動升級至新基礎架構。
詳細步驟如下:
- 前往 Firebase 控制台的「整合」頁面。 
- 在 BigQuery 資訊卡中,按一下「管理」。 
- 將 Crashlytics 滑桿切換為關閉,即可停用匯出功能。按照提示確認要停止資料匯出。 
- 立即再次開啟 Crashlytics 滑桿,重新啟用匯出功能。 系統顯示提示時,請確認要匯出資料。 - 您現在使用新的匯出基礎架構,將 Crashlytics 資料匯出至 BigQuery。