Экспорт данных 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 , помимо пакетной таблицы, вы также получите таблицу в реальном времени. Вот различия между этими таблицами, о которых следует знать:

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

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

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

* Подробную информацию о поддержке обратного заполнения см. в разделе Переход на новую экспортную инфраструктуру .

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

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

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

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

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

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

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

Подробности экспорта данных Crashlytics и схему их таблиц см. далее на этой странице.

Используйте шаблон Data Studio

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

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

Вы можете преобразовывать запросы в представления с помощью BigQuery UI. Подробные инструкции см. в разделе «Создание представлений» документации 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");

Objective-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");
    

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

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

Имя поля Тип данных Описание
platform НИТЬ Платформа приложения, зарегистрированная в проекте Firebase (допустимые значения: IOS или ANDROID )
bundle_identifier НИТЬ Уникальный идентификатор приложения, зарегистрированный в проекте Firebase (например, com.google.gmail )
Для приложений платформы Apple это идентификатор пакета приложения.
Для приложений Android это имя пакета приложения.
event_id НИТЬ Уникальный идентификатор события
is_fatal БУЛЕВ Произошёл ли сбой приложения
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 INT64 Байты используемой памяти
memory.free INT64 Осталось байтов памяти
storage ЗАПИСЫВАТЬ Постоянное хранилище устройства
storage.used INT64 Использовано байтов памяти
storage.free INT64 Осталось байтов памяти
operating_system ЗАПИСЫВАТЬ Подробная информация об ОС на устройстве
operating_system.display_version НИТЬ Версия ОС на устройстве
operating_system.name НИТЬ Название ОС на устройстве
operating_system.modification_state НИТЬ Было ли устройство изменено (например, взломанное приложение — MODIFIED , а рутированное приложение — 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 INT64 Номер строки файла кадра
blame_frame.file НИТЬ Имя файла кадра
blame_frame.symbol НИТЬ Символ гидратированного продукта или символ сырого продукта, если продукт не гидратируется.
blame_frame.offset INT64 Смещение байта в двоичном изображении, содержащем код
Не установлено для исключений Java
blame_frame.address INT64 Адрес в двоичном изображении, содержащий код
Не установлено для фреймов 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 БУЛЕВ True, если Crashlytics определяет, что исключение является причиной ошибки или сбоя.
exceptions.frames ПОВТОРНАЯ ЗАПИСЬ Кадры, связанные с исключением
exceptions.frames.line INT64 Номер строки файла кадра
exceptions.frames.file НИТЬ Имя файла кадра
exceptions.frames.symbol НИТЬ Символ гидратированного продукта или символ сырого продукта, если продукт не гидратируется.
exceptions.frames.offset INT64 Смещение байта в двоичном изображении, содержащем код
Не установлено для исключений Java
exceptions.frames.address INT64 Адрес в двоичном изображении, содержащий код
Не установлено для фреймов Java
exceptions.frames.library НИТЬ Отображаемое имя библиотеки, в которую входит фрейм
exceptions.frames.owner НИТЬ Например, DEVELOPER , VENDOR , RUNTIME , PLATFORM или SYSTEM
exceptions.frames.blamed БУЛЕВ Определил ли Crashlytics , что этот кадр является причиной сбоя или ошибки
error ПОВТОРНАЯ ЗАПИСЬ (только приложения Apple) нефатальные ошибки
error.queue_name НИТЬ Очередь, в которой работал поток
error.code INT64 Код ошибки, связанный с пользовательским регистрируемым событием NSError приложения
error.title НИТЬ Название темы
error.subtitle НИТЬ Подзаголовок темы
error.blamed БУЛЕВ Определил ли Crashlytics , что этот кадр является причиной ошибки
error.frames ПОВТОРНАЯ ЗАПИСЬ Кадры трассировки стека
error.frames.line INT64 Номер строки файла кадра
error.frames.file НИТЬ Имя файла кадра
error.frames.symbol НИТЬ Символ гидратированного продукта или символ сырого продукта, если продукт не гидратируется.
error.frames.offset INT64 Смещение байта в двоичном изображении, содержащем код
error.frames.address INT64 Адрес в двоичном изображении, содержащий код
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 INT64 Адрес сигнала, вызвавшего сбой приложения; присутствует только в аварийно завершившихся собственных потоках.
threads.code INT64 (Только для приложений Apple) Код ошибки NSError, зарегистрированный пользователем в приложении
threads.title НИТЬ Название темы
threads.subtitle НИТЬ Подзаголовок темы
threads.blamed БУЛЕВ Определил ли Crashlytics , что этот кадр является причиной сбоя или ошибки
threads.frames ПОВТОРНАЯ ЗАПИСЬ Рамки нити
threads.frames.line INT64 Номер строки файла кадра
threads.frames.file НИТЬ Имя файла кадра
threads.frames.symbol НИТЬ Символ гидратации или символ сырости, если вещество не подлежит гидратации
threads.frames.offset INT64 Смещение байта в двоичном изображении, содержащем код
threads.frames.address INT64 Адрес в двоичном изображении, содержащий код
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 INT64 Количество процессоров (ядер)
unity_metadata.processor_frequency_mhz INT64 Частота процессора(ов) в МГц
unity_metadata.system_memory_size_mb INT64 Размер системной памяти в Мб
unity_metadata.graphics_memory_size_mb INT64 Графическая память в МБ
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 НИТЬ Поддержка копирования графической текстуры, как определено в API Unity.
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 Частота обновления экрана в Гц



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

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

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

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

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

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

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

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

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

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

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