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

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

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

Примечание. Убедитесь, что у вас есть необходимый уровень доступа для просмотра или управления настройками экспорта данных в BigQuery .

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

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

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

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

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

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

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

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

• По умолчанию все приложения в вашем проекте связаны с 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 .

Примечание. Вы также можете отказаться от экспорта данных в BigQuery для определенных приложений в вашем проекте из консоли Firebase .

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

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

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

Примечание. Экспорт потоковой передачи Crashlytics в BigQuery недоступен для песочницы BigQuery .

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

Таблица партий	Таблица реального времени
Данные экспортируются один раз в день. События надежно сохраняются до пакетной записи в BigQuery . Данные можно заполнить за 30 дней*.	Данные экспортируются в режиме реального времени. Обратная засыпка невозможна.

Пакетная таблица идеально подходит для долгосрочного анализа и выявления тенденций с течением времени, поскольку мы надежно сохраняем события перед их записью, и их можно повторно заполнить в таблице на срок до 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");

Цель-C

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

Примечание. В этом примере необходимо включить экспорт потоковой передачи Crashlytics в BigQuery .

Вот пример запроса для приложения 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, включая сегодняшний день

Примечание. В этом примере необходимо включить экспорт потоковой передачи Crashlytics в BigQuery .

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

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

Имя поля	Тип данных	Описание
platform	НИТЬ	Платформа приложения, зарегистрированная в проекте Firebase (допустимые значения: IOS или ANDROID ).
bundle_identifier	НИТЬ	Уникальный идентификатор приложения, зарегистрированный в проекте Firebase (например, com.google.gmail ) Для приложений платформы Apple это идентификатор пакета приложения. Для приложений Android это имя пакета приложения.
event_id	НИТЬ	Уникальный идентификатор мероприятия.
is_fatal	БУЛЕВОЕ значение	Это поле устарело. Использовать вместо этого error_type . Сбой приложения
error_type	НИТЬ	Тип ошибки события (например, FATAL , NON_FATAL , ANR и т. д.)
issue_id	НИТЬ	Проблема, связанная с событием
variant_id	НИТЬ	Вариант проблемы, связанный с этим событием Обратите внимание, что не со всеми событиями связан вариант проблемы.
event_timestamp	ВРЕМЯ	Когда произошло событие
device	ЗАПИСЫВАТЬ	Устройство, на котором произошло событие
device.manufacturer	НИТЬ	Производитель устройства
device.model	НИТЬ	Модель устройства
device.architecture	НИТЬ	Например, X86_32 , X86_64 , ARMV7 , ARM64 , ARMV7S или ARMV7K
memory	ЗАПИСЫВАТЬ	Состояние памяти устройства
memory.used	ИНТ64	Использовано байт памяти
memory.free	ИНТ64	Осталось байт памяти
storage	ЗАПИСЫВАТЬ	Постоянное хранилище устройства
storage.used	ИНТ64	Использовано байт памяти
storage.free	ИНТ64	Осталось места в байтах
operating_system	ЗАПИСЫВАТЬ	Подробности об ОС на устройстве
operating_system.display_version	НИТЬ	Версия ОС на устройстве
operating_system.name	НИТЬ	Название ОС на устройстве
operating_system.modification_state	НИТЬ	Было ли устройство модифицировано (например, приложение с джейлбрейком MODIFIED , а приложение с root-правами UNMODIFIED )
operating_system.type	НИТЬ	(Только приложения Apple) Тип ОС, установленной на устройстве (например, IOS , MACOS и т. д.).
operating_system.device_type	НИТЬ	Тип устройства (например, MOBILE , TABLET , TV и т. д.); также известный как «категория устройства»
application	ЗАПИСЫВАТЬ	Приложение, сгенерировавшее событие
application.build_version	НИТЬ	Версия сборки приложения
application.display_version	НИТЬ
user	ЗАПИСЫВАТЬ	(Необязательно) Собранная информация о пользователе приложения.
user.name	НИТЬ	Это поле устарело; не используйте это поле. (Необязательно) Имя пользователя
user.email	НИТЬ	Это поле устарело; не используйте это поле. (Необязательно) Адрес электронной почты пользователя.
user.id	НИТЬ	(Необязательно) Идентификатор приложения, связанный с пользователем.
custom_keys	ПОВТОРНАЯ ЗАПИСЬ	Определенные разработчиком пары ключ-значение
custom_keys.key	НИТЬ	Ключ, определенный разработчиком
custom_keys.value	НИТЬ	Значение, определенное разработчиком
installation_uuid	НИТЬ	Идентификатор, идентифицирующий уникальную установку приложения и устройства.
crashlytics_sdk_versions	НИТЬ	Версия Crashlytics SDK, сгенерировавшая событие.
app_orientation	НИТЬ	Например, PORTRAIT , LANDSCAPE , FACE_UP , FACE_DOWN и т. д.
device_orientation	НИТЬ	Например, PORTRAIT , LANDSCAPE , FACE_UP , FACE_DOWN и т. д.
process_state	НИТЬ	BACKGROUND или FOREGROUND
logs	ПОВТОРНАЯ ЗАПИСЬ	Сообщения журнала с отметкой времени, созданные регистратором Crashlytics , если он включен.
logs.timestamp	ВРЕМЯ	Когда был сделан журнал
logs.message	НИТЬ	Зарегистрированное сообщение
breadcrumbs	ПОВТОРНАЯ ЗАПИСЬ	Хлебные крошки Google Analytics с отметкой времени, если они включены.
breadcrumbs.timestamp	ВРЕМЯ	Временная метка, связанная с навигационной цепочкой
breadcrumbs.name	НИТЬ	Имя, связанное с хлебными крошками
breadcrumbs.params	ПОВТОРНАЯ ЗАПИСЬ	Параметры, связанные с навигационной цепочкой
breadcrumbs.params.key	НИТЬ	Ключ параметра, связанный с навигационной цепочкой
breadcrumbs.params.value	НИТЬ	Значение параметра, связанное с навигационной цепочкой.
blame_frame	ЗАПИСЫВАТЬ	Кадр, определенный как основная причина сбоя или ошибки.
blame_frame.line	ИНТ64	Номер строки файла кадра
blame_frame.file	НИТЬ	Имя файла кадра
blame_frame.symbol	НИТЬ	Гидратированный символ или необработанный символ, если он не гидратируется.
blame_frame.offset	ИНТ64	Смещение байта в двоичном изображении, содержащем код. Не настроено для исключений Java
blame_frame.address	ИНТ64	Адрес в двоичном изображении, содержащем код Не установлено для фреймов Java
blame_frame.library	НИТЬ	Отображаемое имя библиотеки, включающей фрейм.
blame_frame.owner	НИТЬ	Например, DEVELOPER , VENDOR , RUNTIME , PLATFORM или SYSTEM
blame_frame.blamed	БУЛЕВОЕ значение	Определил ли Crashlytics , что этот кадр является причиной сбоя или ошибки
exceptions	ПОВТОРНАЯ ЗАПИСЬ	(Только для Android) Исключения, возникшие во время этого события. Вложенные исключения представлены в обратном хронологическом порядке, что означает, что последняя запись является первым возникшим исключением.
exceptions.type	НИТЬ	Тип исключения (например, java.lang.IllegalStateException)
exceptions.exception_message	НИТЬ	Сообщение, связанное с исключением
exceptions.nested	БУЛЕВОЕ значение	Истинно для всех исключений, кроме последнего (имеется в виду первая запись).
exceptions.title	НИТЬ	Название темы
exceptions.subtitle	НИТЬ	Подзаголовок темы
exceptions.blamed	БУЛЕВОЕ значение	Истинно, если Crashlytics определяет, что исключение является причиной ошибки или сбоя.
exceptions.frames	ПОВТОРНАЯ ЗАПИСЬ	Кадры, связанные с исключением
exceptions.frames.line	ИНТ64	Номер строки файла кадра
exceptions.frames.file	НИТЬ	Имя файла кадра
exceptions.frames.symbol	НИТЬ	Гидратированный символ или необработанный символ, если он не гидратируется.
exceptions.frames.offset	ИНТ64	Смещение байта в двоичном изображении, содержащем код. Не настроено для исключений Java
exceptions.frames.address	ИНТ64	Адрес в двоичном изображении, содержащем код Не установлено для фреймов Java
exceptions.frames.library	НИТЬ	Отображаемое имя библиотеки, включающей фрейм.
exceptions.frames.owner	НИТЬ	Например, DEVELOPER , VENDOR , RUNTIME , PLATFORM или SYSTEM
exceptions.frames.blamed	БУЛЕВОЕ значение	Определил ли Crashlytics , что этот кадр является причиной сбоя или ошибки
error	ПОВТОРНАЯ ЗАПИСЬ	(Только приложения Apple) Нефатальные ошибки
error.queue_name	НИТЬ	Очередь, в которой выполнялся поток
error.code	ИНТ64	Код ошибки, связанный с пользовательской регистрируемой NSError приложения.
error.title	НИТЬ	Название темы
error.subtitle	НИТЬ	Подзаголовок темы
error.blamed	БУЛЕВОЕ значение	Определил ли Crashlytics , что именно этот кадр является причиной ошибки
error.frames	ПОВТОРНАЯ ЗАПИСЬ	Кадры трассировки стека
error.frames.line	ИНТ64	Номер строки файла кадра
error.frames.file	НИТЬ	Имя файла кадра
error.frames.symbol	НИТЬ	Гидратированный символ или необработанный символ, если он не гидратируется.
error.frames.offset	ИНТ64	Смещение байта в двоичном изображении, содержащем код.
error.frames.address	ИНТ64	Адрес в двоичном изображении, содержащем код
error.frames.library	НИТЬ	Отображаемое имя библиотеки, включающей фрейм.
error.frames.owner	НИТЬ	Например, DEVELOPER , VENDOR , RUNTIME , PLATFORM или SYSTEM
error.frames.blamed	БУЛЕВОЕ значение	Определил ли Crashlytics , что именно этот кадр является причиной ошибки
threads	ПОВТОРНАЯ ЗАПИСЬ	Темы, присутствующие на момент события
threads.crashed	БУЛЕВОЕ значение	Разбился ли поток
threads.thread_name	НИТЬ	Название темы
threads.queue_name	НИТЬ	(Только для приложений Apple) Очередь, в которой выполнялся поток
threads.signal_name	НИТЬ	Имя сигнала, вызвавшего сбой приложения, присутствует только в сбойных собственных потоках.
threads.signal_code	НИТЬ	Код сигнала, вызвавшего сбой приложения; присутствует только в поврежденных собственных потоках
threads.crash_address	ИНТ64	Адрес сигнала, вызвавшего сбой приложения; присутствует только в поврежденных собственных потоках
threads.code	ИНТ64	(Только для приложений Apple) Код ошибки пользовательского журнала NSError приложения.
threads.title	НИТЬ	Название темы
threads.subtitle	НИТЬ	Подзаголовок темы
threads.blamed	БУЛЕВОЕ значение	Определил ли Crashlytics , что этот кадр является причиной сбоя или ошибки
threads.frames	ПОВТОРНАЯ ЗАПИСЬ	Кадры из нити
threads.frames.line	ИНТ64	Номер строки файла кадра
threads.frames.file	НИТЬ	Имя файла кадра
threads.frames.symbol	НИТЬ	Гидратированный символ или необработанный символ, если он не гидратируется.
threads.frames.offset	ИНТ64	Смещение байта в двоичном изображении, содержащем код.
threads.frames.address	ИНТ64	Адрес в двоичном изображении, содержащем код
threads.frames.library	НИТЬ	Отображаемое имя библиотеки, включающей фрейм.
threads.frames.owner	НИТЬ	Например, DEVELOPER , VENDOR , RUNTIME , PLATFORM или SYSTEM
threads.frames.blamed	БУЛЕВОЕ значение	Определил ли Crashlytics , что именно этот кадр является причиной ошибки
unity_metadata.unity_version	НИТЬ	Версия Unity, работающая на этом устройстве.
unity_metadata.debug_build	БУЛЕВОЕ значение	Если это отладочная сборка
unity_metadata.processor_type	НИТЬ	Тип процессора
unity_metadata.processor_count	ИНТ64	Количество процессоров (ядер)
unity_metadata.processor_frequency_mhz	ИНТ64	Частота процессора(ов) в МГц
unity_metadata.system_memory_size_mb	ИНТ64	Размер системной памяти в Мб
unity_metadata.graphics_memory_size_mb	ИНТ64	Видеопамять в МБ
unity_metadata.graphics_device_id	ИНТ64	Идентификатор графического устройства
unity_metadata.graphics_device_vendor_id	ИНТ64	Идентификатор производителя графического процессора
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	ИНТ64	Уровень шейдеров графики
unity_metadata.graphics_render_target_count	ИНТ64	Количество целей графического рендеринга
unity_metadata.graphics_copy_texture_support	НИТЬ	Поддержка копирования графической текстуры, как определено в Unity API.
unity_metadata.graphics_max_texture_size	ИНТ64	Максимальный размер, предназначенный для рендеринга текстуры
unity_metadata.screen_size_px	НИТЬ	Размер экрана в пикселях в формате ширина х высота.
unity_metadata.screen_resolution_dpi	НИТЬ	DPI экрана как число с плавающей запятой
unity_metadata.screen_refresh_rate_hz	ИНТ64	Частота обновления экрана в Гц

Визуализация экспортированных данных 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.

Примечание. Если вы связали Crashlytics с BigQuery до 6 декабря 2018 г., ваш набор данных будет называться Мои проекты > PROJECT_ID > Crashlytics > TABLE_NAME .

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

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

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

Эта новая инфраструктура поддерживает местоположения наборов данных 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 перейдите в Project Settings .

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

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

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

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

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

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

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

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

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

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

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