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

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

Включить экспорт в BigQuery

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

2. На карточке BigQuery нажмите «Ссылка» .

3. Следуйте инструкциям на экране, чтобы включить экспорт в BigQuery .

   Если вам нужен доступ к данным Crashlytics в BigQuery практически в реальном времени, рассмотрите возможность перехода на потоковый экспорт .

Что произойдет, если вы включите экспорт?

• Вы выбираете местоположение набора данных. После создания набора данных его местоположение невозможно изменить, но вы можете скопировать набор данных в другое место или вручную переместить (воссоздать) набор данных в другом месте. Дополнительные сведения см. в разделе Изменение местоположения существующих экспортированных файлов .

  Это местоположение применимо только для данных, экспортированных в BigQuery , и не влияет на расположение данных, хранящихся для использования на панели управления Crashlytics консоли Firebase или в Android Studio.

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

• Firebase настраивает ежедневную синхронизацию ваших данных с BigQuery .

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

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

• Firebase экспортирует копию существующих данных в BigQuery . Первоначальное распространение данных для экспорта может занять до 48 часов.

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

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

  Обратите внимание: если вы включили экспорт данных Crashlytics до середины октября 2024 года, вы также можете выполнить обратное заполнение за 30 дней до дня включения экспорта.

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

Чтобы деактивировать экспорт в BigQuery , отсоедините свой проект в консоли Firebase .

Какие данные экспортируются в BigQuery ?

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

Например, данные для приложения Android с именем пакета com.google.test будут находиться в таблице с именем com_google_test_ANDROID . Эта пакетная таблица обновляется один раз в день. Если вы включите потоковый экспорт Crashlytics в BigQuery , данные Crashlytics также будут передаваться в режиме реального времени в таблицу с именем com_google_test_ANDROID_REALTIME .

Каждая строка в таблице представляет событие, произошедшее в приложении, включая сбои, нефатальные ошибки и ошибки ANR.

Экспорт потоковой передачи Crashlytics в BigQuery

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

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

Пакетная таблица идеально подходит для долгосрочного анализа и выявления тенденций с течением времени, поскольку мы надежно сохраняем события перед их записью, и их можно повторно заполнить в таблице на срок до 30 дней*. Когда мы записываем данные в вашу таблицу реального времени, мы немедленно записываем их в BigQuery , поэтому они идеально подходят для интерактивных информационных панелей и пользовательских оповещений. Эти две таблицы можно объединить с запросом на сшивание, чтобы получить преимущества обеих.

По умолчанию срок действия раздела таблицы реального времени составляет 30 дней. Чтобы узнать, как это изменить, см. раздел «Установка срока действия раздела» в документации BigQuery .

^{* Подробности о поддержке обратной засыпки см. в разделе Обновление до новой экспортной инфраструктуры .}

Включить экспорт потоковой передачи Crashlytics в BigQuery

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

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

3. Установите флажок Включить потоковую передачу .

Это действие включает потоковую передачу для всех связанных приложений.

Что можно делать с экспортированными данными?

Экспорт в BigQuery содержит необработанные данные о сбоях, включая тип устройства, операционную систему, исключения (приложения Android) или ошибки (приложения Apple), журналы Crashlytics , а также другие данные.

Узнайте, какие именно данные Crashlytics экспортируются, и схему их таблиц далее на этой странице.

Используйте шаблон Студии данных

Чтобы включить данные в реальном времени в шаблоне Data Studio, следуйте инструкциям в разделе Визуализация экспортированных данных Crashlytics с помощью Data Studio .

Создание представлений

Вы можете преобразовать запросы в представления с помощью пользовательского интерфейса BigQuery . Подробные инструкции см. в разделе Создание представлений документации BigQuery .

Запуск запросов

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

Пример 1: Сбои по дням

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

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

Пример 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");
   

   Цель-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 основных проблем с DATE, включая сегодняшний день

Вы также можете объединить пакетные таблицы и таблицы реального времени с помощью запроса на сшивку, чтобы добавить информацию в реальном времени к надежным пакетным данным. Поскольку 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 , вы можете просмотреть эти данные на странице тенденций в реальном времени шаблона 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 . На данный момент обновление до этой новой инфраструктуры не является обязательным.

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

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

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

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

Обязательное условие для обновления

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

Например:

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

• Если у вас есть таблица BigQuery с именем com_yourcompany_yourproject_ANDROID , то в вашем проекте Firebase должно быть зарегистрировано Android-приложение Firebase с именем пакета com.yourcompany.yourproject .

Вот как найти все приложения Firebase, зарегистрированные в вашем проекте Firebase:

1. В консоли Firebase перейдите в settings Project Settings .

2. Прокрутите вниз до карточки «Ваши приложения» , затем нажмите нужное приложение Firebase, чтобы просмотреть информацию о приложении, включая его идентификатор.

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

Как перейти на новую инфраструктуру

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

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

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

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

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

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

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