Экспорт данных Firebase Crashlytics в BigQuery

Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

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 используйте его идентификатор пакета и 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;

Пример 3: 10 устройств с наибольшими отказами

Осень — сезон новых телефонов! Ваша компания знает, что это также означает сезон новых проблем, связанных с устройствами, особенно для Android. Чтобы опередить надвигающиеся проблемы совместимости, вы составляете запрос, который определяет 10 устройств, на которых за последнюю неделю (168 часов) произошло больше всего сбоев.

Вот пример запроса для приложения Android. Для приложения iOS используйте его идентификатор пакета и 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;

Пример 4: Фильтрация по пользовательскому ключу

Вы — разработчик игр, который хочет знать, на каком уровне вашей игры происходит больше всего сбоев.

Чтобы отслеживать эту статистику, вы устанавливаете пользовательский ключ Crashlytics под названием current_level и обновляете его каждый раз, когда пользователь достигает нового уровня.

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

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Crashlytics.setInt("current_level", 3);

Используя этот ключ в вашем экспорте в BigQuery , вы можете написать запрос для отчета о распределении значений current_level , связанных с каждым событием сбоя.

Вот пример запроса для приложения Android. Для приложения iOS используйте его идентификатор пакета и 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

Пример 5: Извлечение идентификатора пользователя

У вас есть приложение Android в раннем доступе. Большинству ваших пользователей оно нравится, но трое столкнулись с необычным количеством сбоев. Чтобы добраться до сути проблемы, вы пишете запрос, который извлекает все события сбоев для этих пользователей, используя их идентификаторы пользователей.

Вот пример запроса для приложения Android. Для приложения iOS используйте его идентификатор пакета и 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
 

Пример 6: Найти всех пользователей, столкнувшихся с определенной проблемой сбоя

Ваша команда случайно выпустила критическую ошибку для группы бета-тестеров. Ваша команда смогла использовать запрос из примера «Найти наиболее распространенные сбои» выше, чтобы определить конкретный идентификатор проблемы сбоя. Теперь ваша команда хотела бы выполнить запрос, чтобы извлечь список пользователей приложения, на которых повлиял этот сбой.

Вот пример запроса для приложения Android. Для приложения iOS используйте его идентификатор пакета и 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;

Пример 7: Количество пользователей, пострадавших от сбоя, с разбивкой по странам

Ваша команда обнаружила критическую ошибку во время развертывания нового релиза. Вы смогли использовать запрос из примера «Найти наиболее распространенные сбои» выше, чтобы определить конкретный идентификатор проблемы сбоя. Теперь ваша команда хотела бы узнать, распространился ли этот сбой на пользователей в разных странах мира.

Чтобы написать этот запрос, вашей команде необходимо будет сделать следующее:

1. Включить экспорт данных Google Analytics в BigQuery . См. Экспорт данных проекта в BigQuery .

2. Обновите свое приложение, чтобы передавать идентификатор пользователя как в Google Analytics SDK, так и в Crashlytics SDK.

   Быстрый

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

   Objective-C

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

   Ява

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

3. Напишите запрос, который использует поле идентификатора пользователя для объединения событий в наборе данных Google Analytics со сбоями в наборе данных Crashlytics .

   Вот пример запроса для приложения Android. Для приложения iOS используйте его идентификатор пакета и 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

Пример 8: 5 главных проблем на сегодняшний день

Вот пример запроса для приложения Android. Для приложения iOS используйте его идентификатор пакета и 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;

Пример 9: 5 главных проблем с ДАТЫ, включая сегодняшний день

Вы также можете объединить таблицы batch и realtime с помощью запроса на сшивание, чтобы добавить информацию realtime к надежным данным batch. Поскольку event_id является первичным ключом, вы можете использовать DISTINCT event_id для дедупликации любых общих событий из двух таблиц.

Вот пример запроса для приложения Android. Для приложения iOS используйте его идентификатор пакета и 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 >= "YYYY_MM_DD"
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

Понять схему Crashlytics в BigQuery

При настройке экспорта данных Crashlytics в BigQuery Firebase экспортирует последние события (сбои, нефатальные ошибки и ANR), включая события за два дня до ссылки, с возможностью обратного заполнения до 30 дней.

С этого момента и до тех пор, пока вы не деактивируете экспорт, Firebase экспортирует события Crashlytics ежедневно. Может потребоваться несколько минут, чтобы данные стали доступны в BigQuery после каждого экспорта.

Наборы данных

Crashlytics создает новый набор данных в BigQuery для данных Crashlytics . Набор данных охватывает весь ваш проект, даже если в нем есть несколько приложений.

Таблицы

Crashlytics создает таблицу в наборе данных для каждого приложения в вашем проекте, если вы не отказались от экспорта данных для этого приложения. Firebase называет таблицы на основе идентификатора приложения, с точками, преобразованными в подчеркивания, и именем платформы, добавленным в конец.

Например, данные для приложения Android с именем пакета com.google.test будут находиться в таблице с именем com_google_test_ANDROID , а данные в реальном времени (если они включены) будут находиться в таблице с именем com_google_test_ANDROID_REALTIME

Таблицы содержат стандартный набор данных Crashlytics в дополнение к любым пользовательским ключам Crashlytics , определенным вами в вашем приложении.

Ряды

Каждая строка в таблице представляет собой ошибку, обнаруженную приложением.

Колонны

Столбцы в таблице идентичны для сбоев, нефатальных ошибок и ANR. Если включен потоковый экспорт Crashlytics в BigQuery , то таблица в реальном времени будет иметь те же столбцы, что и пакетная таблица. Обратите внимание, что у вас могут быть столбцы в строках, которые представляют события, не имеющие трассировки стека.

Столбцы экспорта перечислены в следующей таблице:

Визуализируйте экспортированные данные Crashlytics с помощью Data Studio

Google Data Studio превращает ваши наборы данных Crashlytics в BigQuery в отчеты, которые легче читать, которыми легче делиться и которые полностью настраиваются.

Чтобы узнать больше об использовании Data Studio, ознакомьтесь с кратким руководством по Data Studio « Добро пожаловать в Data Studio» .

Используйте шаблон отчета Crashlytics

Data Studio имеет пример отчета для Crashlytics , который включает полный набор измерений и метрик из экспортированной схемы Crashlytics BigQuery . Если вы включили потоковый экспорт Crashlytics в BigQuery , то вы можете просматривать эти данные на странице Realtime trends шаблона Data Studio. Вы можете использовать пример в качестве шаблона для быстрого создания новых отчетов и визуализаций на основе необработанных данных о сбоях вашего собственного приложения:

1. Откройте шаблон панели мониторинга Crashlytics Data Studio .

2. Нажмите «Использовать шаблон» в правом верхнем углу.

3. В раскрывающемся списке Новый источник данных выберите Создать новый источник данных .

4. Нажмите «Выбрать» на карточке BigQuery .

5. Выберите таблицу, содержащую экспортированные данные Crashlytics , выбрав Мои проекты > PROJECT_ID > firebase_crashlytics > TABLE_NAME .

   Ваша пакетная таблица всегда доступна для выбора. Если включен потоковый экспорт Crashlytics в BigQuery , то вместо этого вы можете выбрать свою таблицу в реальном времени.

6. В разделе «Конфигурация» установите уровень шаблона Crashlytics на «По умолчанию» .

7. Нажмите «Подключиться» , чтобы создать новый источник данных.

8. Нажмите «Добавить в отчет» , чтобы вернуться к шаблону Crashlytics .

9. Наконец, нажмите «Создать отчет» , чтобы создать копию шаблона панели мониторинга Crashlytics Data Studio.

Переход на новую экспортную инфраструктуру

В середине октября 2024 года Crashlytics запустила новую инфраструктуру для пакетного экспорта данных Crashlytics в BigQuery .

Вы можете перейти на новую инфраструктуру, но убедитесь, что ваши пакетные таблицы BigQuery соответствуют предварительным условиям для обновления.

Определите, находитесь ли вы в новой инфраструктуре

Если вы включили пакетный экспорт в середине октября 2024 года или позже, ваш проект Firebase автоматически использует новую инфраструктуру экспорта.

Вы можете проверить, какую инфраструктуру использует ваш проект: перейдите в консоль Google Cloud , и если ваша «конфигурация передачи данных» помечена как Firebase Crashlytics with Multi-Region Support , то ваш проект использует новую инфраструктуру экспорта.

Важные различия между старой и новой экспортной инфраструктурой

• Новая инфраструктура поддерживает расположения наборов данных Crashlytics за пределами США.

  • Экспорт был включен до середины октября 2024 года и обновлен до новой инфраструктуры экспорта. Теперь вы можете по желанию изменить место для экспорта данных .

  • Экспорт включен в середине октября 2024 года или позже. Во время настройки вам было предложено выбрать место для экспорта данных.

• Новая инфраструктура не поддерживает обратную загрузку данных, которые были до включения экспорта.

  • Старая инфраструктура поддерживала заполнение данных за 30 дней до даты включения экспорта.

  • Новая инфраструктура поддерживает обратные заполнения за последние 30 дней или за последнюю дату, когда вы включили экспорт в BigQuery (в зависимости от того, что наступило позже).

• Новая инфраструктура именует пакетные таблицы BigQuery , используя идентификаторы, заданные для ваших приложений Firebase в вашем проекте Firebase.

  • Старая инфраструктура записывала данные в пакетные таблицы с именами, основанными на идентификаторах пакетов или именах пакетов в конфигурации Firebase в кодовой базе вашего приложения .

  • Новая инфраструктура записывает данные в пакетные таблицы с именами на основе идентификаторов пакетов или имен пакетов , заданных для зарегистрированных приложений Firebase в вашем проекте Firebase .

Шаг 1 : Предварительные условия для обновления

1. Проверьте, что ваши существующие таблицы пакетов BigQuery используют соответствующие идентификаторы для идентификаторов пакетов или имен пакетов , установленных для ваших зарегистрированных приложений Firebase в вашем проекте Firebase . Если они не совпадают, то вы можете столкнуться с перебоями в экспортированных пакетных данных. Большинство проектов будут в надлежащем и совместимом состоянии, но важно проверить это перед обновлением.

   • Все приложения Firebase, зарегистрированные в вашем проекте Firebase, можно найти в консоли Firebase : перейдите в настройки settings проекта , затем прокрутите до карточки Ваши приложения , чтобы увидеть все ваши приложения Firebase и их информацию.

   • Все ваши пакетные таблицы BigQuery можно найти на странице BigQuery в консоли Google Cloud .

   Например, вот идеальные штаты, в которых у вас не возникнет проблем с обновлением:

   • У вас есть пакетная таблица с именем com_yourcompany_yourproject_IOS и приложение Firebase iOS+ с идентификатором пакета com.yourcompany.yourproject , зарегистрированным в вашем проекте Firebase.

   • У вас есть пакетная таблица с именем com_yourcompany_yourproject_ANDROID и приложение Firebase Android с именем пакета com.yourcompany.yourproject , зарегистрированное в вашем проекте Firebase.

2. Если имена ваших пакетных таблиц не соответствуют идентификаторам, установленным для ваших зарегистрированных приложений Firebase, то перед выполнением обновления вручную следуйте инструкциям, приведенным далее на этой странице, чтобы избежать сбоев в пакетном экспорте.

Шаг 2 : Выполните обновление до новой инфраструктуры вручную

Если вы включили пакетный экспорт до середины октября 2024 года, то вы можете вручную перейти на новую инфраструктуру, просто отключив и снова включив экспорт данных Crashlytics в консоли Firebase .

Вот подробные шаги:

1. В консоли Firebase перейдите на страницу «Интеграции» .

2. На карточке BigQuery нажмите «Управление» .

3. Выключите ползунок Crashlytics , чтобы отключить экспорт. При появлении запроса подтвердите, что хотите остановить экспорт данных.

4. Немедленно снова включите ползунок Crashlytics , чтобы снова включить экспорт. При появлении запроса подтвердите, что вы хотите экспортировать данные.

   Экспорт данных Crashlytics в BigQuery теперь использует новую инфраструктуру экспорта.

Имя существующей пакетной таблицы не соответствует идентификатору вашего приложения Firebase