將 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 流式導出時，除了批處理表之外，您還將擁有一個實時表。以下是您應該注意的表之間的差異：

批處理表非常適合長期分析和識別隨時間推移的趨勢，因為我們在寫入事件之前會持久存儲事件，並且它們可以回填到表中長達 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-bash 使應用程序隨著時間的推移變得更加穩定：

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 ，並在用戶每次達到新級別時更新它。

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。

   目標-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），包括鏈接前最多兩天的事件，並可選擇回填最多九十天。

從那時起，直到您禁用該鏈接，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 流式導出，則實時表將具有與批處理表相同的列。下面列出了導出中的列。

沒有堆棧跟踪

行中的列表示沒有堆棧跟踪的事件。

使用 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. 在Configuration下，將Crashlytics Template level設置為Default 。
7. 單擊“連接”以創建新的數據源。
8. 單擊添加到報告以返回到 Crashlytics 模板。
9. 最後，單擊“創建報告”以創建 Crashlytics Data Studio 儀表板模板的副本。