將 Firebase Crashlytics 資料匯出到 BigQuery

您可以將 Crashlytics 資料匯出到BigQuery中以進行進一步分析。 BigQuery 允許您使用 BigQuery SQL 分析數據,將其匯出到另一個雲端供應商,並透過 Google Data Studio 將其用於視覺化和自訂儀表板。

啟用 BigQuery 匯出

  1. 前往 Firebase 控制台中的整合頁面。
  2. BigQuery卡片中,點擊連結
  3. 請依照螢幕上的指示啟用 BigQuery。

當您將項目連結到 BigQuery 時:

  • Firebase 設定每日將資料從 Firebase 專案同步到 BigQuery。
  • 預設情況下,專案中的所有應用程式都會連結到 BigQuery,並且您以後新增到專案中的任何應用程式都會自動連結到 BigQuery。您可以管理哪些應用程式發送資料
  • Firebase將現有資料的副本匯出到 BigQuery。對於每個連結的應用程序,這包括一個包含每日同步資料的批次表。
  • 如果您啟用 Crashlytics BigQuery 串流匯出,所有連結的應用程式還將有一個包含不斷更新資料的即時表

若要停用 BigQuery 匯出,請在 Firebase 控制台中取消連結您的專案

哪些資料會匯出到 BigQuery?

Firebase Crashlytics 資料匯出到名為firebase_crashlytics的 BigQuery 資料集。預設情況下,將為專案中的每個應用程式在 Crashlytics 資料集中建立單獨的表格。 Firebase 根據應用程式的套件標識符命名表,其中句點轉換為下劃線,並在末尾附加平台名稱。

例如,ID 為com.google.test的應用程式的資料將位於名為com_google_test_ANDROID的表中。此批次表每天更新一次。如果您啟用 Crashlytics BigQuery 串流匯出,Firebase Crashlytics 資料也會即時串流到com_google_test_ANDROID_REALTIME

表中的每一行代表應用程式中發生的一個事件,包括崩潰、非致命錯誤和 ANR。

啟用 Crashlytics BigQuery 串流匯出

您可以使用BigQueryStreaming即時串流 Crashlytics 資料。您可以將其用於需要即時資料的任何目的,例如在即時儀表板中呈現資訊、即時觀看部署或監控觸發警報和自訂工作流程的應用程式問題。

Crashlytics BigQuery 串流匯出不適用於 BigQuery 沙盒。

當您啟用 Crashlytics BigQuery 串流匯出時,除了批次表之外,您還將擁有即時表格。以下是您應該注意的表格之間的差異:

批次表即時表
  • 每天匯出一次數據
  • 在批次寫入 BigQuery 之前持久性儲存事件
  • 最多可提前 90 天回填
  • 數據即時導出
  • 無可用回填

批次表非常適合長期分析和識別一段時間內的趨勢,因為我們在寫入事件之前會持久儲存事件,並且它們可以回填到表中長達 90 天。當我們將資料寫入即時表時,我們會立即將其寫入 BigQuery,因此它非常適合即時儀表板和自訂警報。這兩個表格可以與拼接查詢結合起來,以獲得兩者的好處。請參閱下面的查詢範例 9

預設情況下,實時表的分區過期時間為30天。若要了解如何修改此設置,請參閱更新分割區過期時間

啟用 Crashlytics BigQuery 串流

若要啟用串流傳輸,請導覽至 BigQuery整合頁面的 Crashlytics 部分,然後選擇包含串流複選框。

資料工作室模板

若要在 Data Studio 範本中啟用即時數據,請依照使用 Data Studio 視覺化匯出的 Crashlytics 資料中的說明進行操作。

意見

您可以使用 BigQuery UI 將下面的範例查詢轉換為檢視。有關詳細說明,請參閱建立視圖

您可以使用匯出的資料做什麼?

BigQuery 匯出包含原始崩潰數據,包括設備類型、作業系統、異常(Android 應用程式)或錯誤(Apple 應用程式)、Crashlytics 日誌以及其他數據。

在 BigQuery 中使用 Firebase Crashlytics 數據

以下範例示範了您可以對 Crashlytics 資料執行的查詢。這些查詢會產生 Crashlytics 儀表板中不可用的報表。

Crashlytics 查詢範例

以下範例示範如何產生將崩潰事件資料聚合為更易於理解的摘要的報告。

範例 1:白天崩潰

在努力修復盡可能多的錯誤後,一位首席開發人員認為她的團隊終於準備好推出他們的新照片共享應用程式。在此之前,他們想要檢查過去一個月每天的崩潰次數,以確保他們的 bug 重擊使應用程式隨著時間的推移變得更加穩定:

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

範例 2:找出最普遍的崩潰

為了正確確定生產計劃的優先級,專案經理思考如何指出其產品中最常見的 10 種崩潰。他們產生一個提供相關數據點的查詢:

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
  `projectId.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 個崩潰設備

秋天是新手機季節!開發人員知道,這也意味著新的設備特定問題季節即將到來。為了解決迫在眉睫的兼容性問題,他們整理了一個查詢,識別過去一周崩潰次數最多的 10 台設備:

SELECT
  device.model,
COUNT(DISTINCT event_id) AS number_of_crashes
FROM
  `projectId.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:按自訂鍵過濾

遊戲開發者想知道他們的遊戲哪個關卡崩潰最多。為了幫助他們追蹤該統計數據,他們設定了一個自訂 Crashlytics 鍵current_level ,並在使用者每次達到新等級時更新它。

Objective-C

CrashlyticsKit setIntValue:3 forKey:@"current_level";

迅速

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

爪哇

Crashlytics.setInt("current_level", 3);

然後,他們使用 BigQuery 匯出中的該鍵編寫一個查詢來報告與每個崩潰事件關聯的current_level值的分佈:

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

範例5:用戶ID提取

開發者有一個處於早期訪問階段的應用程式。他們的大多數用戶都喜歡它,但其中三個用戶經歷了異常數量的崩潰。為了找出問題的根源,他們編寫了一個查詢,使用這些使用者的使用者 ID 來提取所有崩潰事件:

SELECT *
FROM
  `projectId.firebase_crashlytics.package_name_ANDROID`
WHERE
  user.id IN ("userid1", "userid2", "userid3")
ORDER BY
  user.id
 

範例 6:尋找所有面臨特定崩潰問題的用戶

開發人員向一組 Beta 測試人員發布了一個嚴重錯誤。該團隊能夠使用上面範例 2 中的查詢來識別特定的崩潰問題 ID。現在他們想要執行一個查詢來提取受此崩潰影響的應用程式使用者清單:

SELECT user.id as user_id
FROM
  `projectId.firebase_crashlytics.package_name_ANDROID`
WHERE
  issue_id = "YOUR_ISSUE_ID"
  AND application.display_version = ""
  AND user.id != ""
ORDER BY
  user.id;

範例 7:受崩潰問題影響的使用者數量(按國家/地區細分)

現在,該團隊在新版本的推出過程中檢測到了一個嚴重錯誤。他們能夠使用上面範例 2 中的查詢來識別特定的崩潰問題 ID。團隊現在想看看這次崩盤是否蔓延到世界各地不同國家的用戶。

要編寫此查詢,團隊需要:

  1. 為 Google Analytics 啟用 BigQuery 匯出。請參閱將項目資料匯出至 BigQuery

  2. 更新他們的應用程式以將使用者 ID 傳遞到 Google Analytics SDK 和 Crashlytics SDK 中。

    Objective-C
    CrashlyticsKit setUserIdentifier:@"123456789";
    FIRAnalytics setUserID:@"12345678 9";
    
    迅速
    Crashlytics.sharedInstance().setUserIdentifier("123456789");
    Analytics.setUserID("123456789");
    
    爪哇
    Crashlytics.setUserIdentifier("123456789");
    mFirebaseAnalytics.setUserId("123456789");
    
  3. 編寫一個查詢,使用使用者 ID 欄位將 Google Analytics BigQuery 資料集中的事件與 Crashlytics BigQuery 資料集中的崩潰連接起來:

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

範例 8:今天迄今為止最重要的 5 個問題

需要啟用 Crashlytics BigQuery 串流匯出

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

範例 9:自 DATE(包括今天)以來排名前 5 的問題

需要啟用 Crashlytics BigQuery 串流匯出。

在此範例中,我們將批量表和即時表結合起來,將即時資訊添加到可靠的批量資料中。由於event_id是主鍵,因此我們可以使用DISTINCT event_id從兩個表中刪除任何公共事件。

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM (
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `your_project.firebase_crashlytics.package_name_ANDROID_REALTIME`
  UNION ALL
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `your_project.firebase_crashlytics.package_name_ANDROID`)
WHERE
  event_timestamp >= "2020-01-13"
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

了解 BigQuery 中的 Firebase Crashlytics 架構

當您將 Crashlytics 與 BigQuery 關聯時,Firebase 會匯出最近的事件(當機、非致命錯誤和 ANR),包括連結前最多兩天的事件,並且可以選擇回填最多 90 天。

從那時起,直到您停用連結為止,Firebase 每天都會匯出 Crashlytics 事件。每次匯出後,資料可能需要幾分鐘的時間才能在 BigQuery 中可用。

數據集

Firebase Crashlytics 在 BigQuery 中為 Crashlytics 資料建立一個新資料集。該資料集涵蓋您的整個項目,即使它有多個應用程式。

表格

Firebase Crashlytics 在資料集中為專案中的每個應用程式建立一個表,除非您選擇不匯出該應用程式的資料。 Firebase 根據應用程式的套件標識符命名表,其中句點轉換為下劃線,並在末尾附加平台名稱。

例如,ID 為com.google.test的 Android 應用程式的資料將位於名為com_google_test_ANDROID的表中,即時資料(如果啟用)將位於名為com_google_test_ANDROID_REALTIME的表中

除了開發人員定義的任何自訂 Crashlytics 鍵之外,表格還包含一組標準的 Crashlytics 資料。

行數

表中的每一行代表應用程式遇到的錯誤。

對於崩潰、非致命錯誤和 ANR,表中的欄位是相同的。如果啟用了 Crashlytics BigQuery 串流匯出,則即時表格將具有與批次表相同的欄位。下面列出了匯出中的列。

沒有堆疊追蹤

行中存在的列表示沒有堆疊追蹤的事件。

欄位名稱資料類型描述
平台細繩蘋果或安卓應用程式
捆綁包標識符細繩捆綁 ID,例如 com.google.gmail
事件ID細繩事件的唯一 ID
是致命的布林值應用程式是否崩潰
錯誤類型細繩事件的錯誤類型(FATAL、NON_FATAL、AN​​R)
問題ID細繩與事件相關的問題
變體_id細繩與此事件相關的問題變體
請注意,並非所有事件都有關聯的問題變體。
事件時間戳時間戳事件發生時
裝置記錄發生事件的設備
設備製造商細繩設備製造商
設備型號細繩設備型號
裝置架構細繩X86_32、X86_64、ARMV7、ARM64、ARMV7S 或 ARMV7K
記憶記錄設備的記憶體狀態
已用記憶體INT64使用的記憶體位元組數
無記憶體INT64剩餘記憶體位元組數
貯存記錄設備的持久性存儲
儲存.已使用INT64使用的儲存位元組數
免儲存INT64剩餘儲存位元組數
作業系統記錄設備上作業系統的詳細信息
作業系統.顯示版本細繩裝置上作業系統的版本
作業系統名稱細繩設備上作業系統的名稱
作業系統修改狀態細繩設備是否已被修改,例如越獄/root(修改或未修改)
作業系統類型細繩設備上運行的作業系統類型(例如 IOS、MACOS);僅適用於Apple平台應用程式
作業系統.設備類型細繩設備類型(例如,手機、平板電腦、電視等);也稱為“設備類別”
應用記錄生成事件的應用程式
應用程式.build_version細繩應用程式的建置版本
應用程式.display_version細繩
使用者記錄可選:收集有關應用程式使用者的信息
使用者名稱細繩可選:用戶名
使用者信箱細繩可選:使用者的電子郵件地址
使用者身分細繩可選:與使用者關聯的應用程式特定 ID
自訂鍵重複記錄開發者定義的鍵值對
自訂鍵.key細繩開發者定義的金鑰
自訂鍵值細繩開發者定義的值
安裝uuid細繩標識唯一應用程式和裝置安裝的 ID
crashlytics_sdk_版本細繩產生事件的 Crashlytics SDK 版本
應用方向細繩肖像、風景、正面朝上或正面朝下
設備方向細繩肖像、風景、正面朝上或正面朝下
行程狀態細繩背景或前景
紀錄重複記錄由 Crashlytics 記錄器產生的帶有時間戳記的日誌訊息(如果啟用)
日誌.時間戳時間戳日誌何時製作
日誌訊息細繩記錄的消息
麵包屑重複記錄帶有時間戳記的 Google Analytics 麵包屑(如果已啟用)
麵包屑.時間戳時間戳與麵包屑關聯的時間戳
麵包屑.name細繩與麵包屑相關的名稱
麵包屑.params重複記錄與麵包屑相關的參數
麵包屑.params.key細繩與麵包屑關聯的參數鍵
breadcrumbs.params.value細繩與麵包屑相關的參數值
責怪框架記錄被確定為崩潰或錯誤根本原因的幀
怪罪框架.line INT64幀文件的行號
Blame_frame.file細繩幀文件的名稱
Blame_frame.symbol細繩水合符號,或原始符號(如果不可水合)
Blame_frame.offset INT64包含程式碼的二進位映像的位元組偏移量,未設定 Java 異常
Blame_frame.地址INT64包含程式碼的二進位映像中的位址,未針對 Java 幀設置
Blame_frame.library細繩包含框架的庫的顯示名稱
責任框架.所有者細繩開發人員、供應商、運行時、平台或系統
責備框架.責備布林值Crashlytics 的分析是否確定該幀是導致崩潰或錯誤的原因
例外情況重複記錄僅限 Android:此事件期間發生的異常。嵌套異常依時間倒序排列(閱讀:最後一筆記錄是第一個拋出的例外)
異常類型細繩異常類型,例如java.lang.IllegalStateException
異常.exception_message細繩與異常相關的訊息
例外嵌套布林值對於除最後拋出的異常(即第一筆記錄)之外的所有異常均為 true
例外.標題細繩線程的標題
異常.subtitle細繩線程的副標題
例外.指責布林值如果 Crashlytics 確定異常是導致錯誤或崩潰的原因,則為 True
異常.frames重複記錄與異常相關的幀
異常.frames.line INT64幀文件的行號
異常.frames.文件細繩幀文件的名稱
異常.frames.symbol細繩水合符號,或原始符號(如果不可水合)
異常.frames.offset INT64包含程式碼的二進位映像的位元組偏移量,未設定 Java 異常
異常.幀.地址INT64包含程式碼的二進位映像中的位址,未針對 Java 幀設置
異常.frames.庫細繩包含框架的庫的顯示名稱
異常.frames.owner細繩開發人員、供應商、運行時、平台或系統
異常.框架.指責布林值Crashlytics 的分析是否確定該幀是導致崩潰或錯誤的原因
錯誤重複記錄僅限 Apple 應用程式:非致命錯誤
錯誤.queue_name細繩線程正在運行的隊列
錯誤代碼INT64與應用程式的自訂記錄的 NSError 關聯的錯誤代碼
錯誤.標題細繩線程的標題
錯誤.字幕細繩線程的副標題
錯誤歸咎於布林值Crashlytics 的分析是否確定此框架是導致錯誤的原因
錯誤訊框重複記錄堆疊追蹤的幀
錯誤.幀.行INT64框架文件的行號
錯誤.幀.文件細繩幀文件的名稱
錯誤.幀.符號細繩水合符號,或原始符號(如果不可水合)
錯誤.幀.偏移量INT64包含程式碼的二進位影像的位元組偏移量
錯誤.幀.位址INT64包含程式碼的二進位映像中的位址
錯誤.frames.庫細繩包含框架的庫的顯示名稱
錯誤.幀.所有者細繩開發人員、供應商、運行時、平台或系統
錯誤.幀.指責布林值Crashlytics 的分析是否確定此框架是導致錯誤的原因
執行緒重複記錄事件發生時存在的線程
線程崩潰布林值線程是否崩潰
線程.線程名稱細繩線程的名稱
線程.queue_name細繩僅限Apple應用程式:線程正在其上運行的隊列
線程.signal_name細繩導致應用程式崩潰的訊號名稱,僅出現在崩潰的本機執行緒上
線程.signal_code細繩導致應用崩潰的信號代碼;僅存在於崩潰的本機執行緒上
線程.crash_地址INT64導致應用程式崩潰的信號的位址;僅存在於崩潰的本機執行緒上
執行緒程式碼INT64僅限 Apple 應用程式:應用程式的自訂記錄 NSError 的錯誤代碼
線程.標題細繩線程的標題
線.subtitle細繩線程的副標題
線被指責布林值Crashlytics 的分析是否確定該幀是導致崩潰或錯誤的原因
執行緒.框架重複記錄線程的幀
線程.框架.線INT64框架文件的行號
執行緒.框架.文件細繩幀文件的名稱
線程.框架.符號細繩水合符號,或原始符號(如果不可水合)
線程.幀.偏移量INT64包含程式碼的二進位影像的位元組偏移量
線程.幀.位址INT64包含程式碼的二進位映像中的位址
執行緒.框架.庫細繩包含框架的庫的顯示名稱
執行緒.框架.所有者細繩開發人員、供應商、運行時、平台或系統
線程.幀.指責布林值Crashlytics 的分析是否確定此框架是導致錯誤的原因
unity_metadata.unity_version細繩該裝置上執行的 Unity 版本
unity_metadata.debug_build布林值如果這是調試版本
unity_metadata.processor_type細繩處理器類型
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細繩圖形設備的名稱
unity_metadata.graphics_device_vendor細繩圖形設備的供應商
unity_metadata.graphics_device_version細繩圖形設備的版本
unity_metadata.graphics_device_type細繩圖形設備的類型
unity_metadata.graphics_shader_level INT64圖形的著色器級別
unity_metadata.graphics_render_target_count INT64圖形渲染目標的數量
unity_metadata.graphics_copy_texture_support細繩支援複製Unity API中定義的圖形紋理
unity_metadata.graphics_max_texture_size INT64專用於渲染紋理的最大尺寸
unity_metadata.screen_size_px細繩螢幕大小(以像素為單位),格式為寬度 x 高度
unity_metadata.screen_resolution_dpi細繩螢幕的 DPI(浮點數)
unity_metadata.screen_refresh_rate_hz INT64螢幕更新率(以 Hz 為單位)

使用 Data Studio 視覺化導出的 Crashlytics 數據

Google Data Studio將 BigQuery 中的 Crashlytics 資料集轉換為易於閱讀、易於共享且完全可自訂的報告。

要了解有關使用 Data Studio 的更多信息,請嘗試 Data Studio 快速入門指南歡迎使用 Data Studio

使用 Crashlytics 報告模板

Data Studio 有一個 Crashlytics 範例報告,其中包含匯出的 Crashlytics BigQuery 架構中的一組全面的維度和指標。如果您已啟用 Crashlytics BigQuery 串流匯出,則可以在 Data Studio 模板的即時趨勢頁面上查看該資料。您可以使用範例作為模板,根據您自己的應用程式的原始崩潰資料快速建立新的報表和視覺化效果:

  1. 開啟Crashlytics Data Studio 儀表板範本
  2. 點選右上角的「使用模板」
  3. 「新資料來源」下拉清單中,選擇「建立新資料來源」
  4. 點選BigQuery卡上的「選擇」
  5. 透過選擇My Projects > [your-project-name] > firebase_crashlytics > [your-table-name]選擇包含匯出的 Crashlytics 資料的表。您的批次表始終可供選擇;如果啟用了 Crashlytics BigQuery 串流匯出,您可以選擇即時表格。
  6. 「配置」下,將「Crashlytics 模板層級」設定為「預設」
  7. 按一下「連接」以建立新的資料來源。
  8. 按一下「新增至報表」返回 Crashlytics 範本。
  9. 最後,按一下「建立報表」以建立 Crashlytics Data Studio 儀表板範本的副本。