Вы можете экспортировать данные Firebase Crashlytics в BigQuery для дальнейшего анализа. BigQuery позволяет анализировать данные с помощью BigQuery SQL, экспортировать их в другой облачный сервис и использовать для визуализации и создания пользовательских панелей мониторинга в Google Data Studio.
Включить экспорт в BigQuery
В консоли Firebase перейдите на страницу Интеграции .
На карточке BigQuery нажмите Ссылка .
Следуйте инструкциям на экране, чтобы включить экспорт в 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
В консоли Firebase перейдите на страницу Интеграции .
На карточке BigQuery нажмите Управление .
Установите флажок Включить потоковую передачу .
Это действие включает потоковую передачу для всех связанных приложений.
Убедитесь, что вы отправили как минимум два события из своего приложения в Crashlytics и подождали пару минут после их отправки.
Убедитесь, что ваш проект Firebase включен в тарифный план Blaze с оплатой по факту использования.
Вы можете проверить это, посмотрев в левый нижний угол консоли Firebase .Если после отправки двух событий и ожидания в течение нескольких минут в таблице реального времени по-прежнему нет данных:
Перейдите на карточку BigQuery в консоли Firebase .
Отключите и снова включите потоковый экспорт.
Убедитесь, что учетная запись службы
service- PROJECT_NUMBER @gcp-sa-crashlytics.iam.gserviceaccount.com
находится в вашем проекте Firebase и имеет роль агента службы Firebase Crashlytics .
Вы можете проверить это на странице IAM консоли Google Cloud (убедитесь, что установлен флажок Включить предоставленные Google гранты ролей ).Отправьте как минимум два события в Crashlytics и подождите пару минут.
Если вы по-прежнему не видите данные в таблице в реальном времени, обратитесь в службу поддержки Firebase .
Что можно сделать с экспортированными данными?
Экспорт в 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: Количество пользователей, пострадавших от сбоя, по странам
Ваша команда обнаружила критическую ошибку во время выпуска новой версии. Вы смогли использовать запрос из примера «Найти наиболее распространённые сбои» выше, чтобы определить конкретный идентификатор проблемы, вызвавшей сбой. Теперь ваша команда хочет проверить, распространился ли этот сбой на пользователей в разных странах мира.
Чтобы написать этот запрос, вашей команде необходимо будет сделать следующее:
Включите экспорт данных Google Analytics в BigQuery . См. раздел Экспорт данных проекта в BigQuery .
Обновите свое приложение, чтобы передавать идентификатор пользователя как в 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");
Напишите запрос, который использует поле идентификатора пользователя для объединения событий в наборе данных 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. Вы можете использовать этот пример в качестве шаблона для быстрого создания новых отчётов и визуализаций на основе необработанных данных о сбоях вашего приложения:
Откройте шаблон панели мониторинга Crashlytics Data Studio .
Нажмите «Использовать шаблон» в правом верхнем углу.
В раскрывающемся списке Новый источник данных выберите Создать новый источник данных .
Нажмите Выбрать на карточке BigQuery .
Выберите таблицу, содержащую экспортированные данные Crashlytics , выбрав Мои проекты > PROJECT_ID > firebase_crashlytics > TABLE_NAME .
Ваша пакетная таблица всегда доступна для выбора. Если включен потоковый экспорт Crashlytics в BigQuery , вы можете выбрать таблицу в режиме реального времени.
В разделе «Конфигурация» установите уровень шаблона Crashlytics на «По умолчанию» .
Нажмите Подключиться , чтобы создать новый источник данных.
Нажмите «Добавить в отчет» , чтобы вернуться к шаблону Crashlytics .
Наконец, нажмите «Создать отчет» , чтобы создать копию шаблона панели мониторинга 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 : Предварительное условие для обновления
Убедитесь, что в ваших существующих пакетных таблицах 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.
Если имена ваших пакетных таблиц не соответствуют идентификаторам, установленным для ваших зарегистрированных приложений Firebase, следуйте инструкциям, приведенным далее на этой странице , прежде чем выполнять обновление вручную или до 15 сентября 2025 г., чтобы избежать сбоев в пакетном экспорте.
Шаг 2 : Выполните обновление до новой инфраструктуры вручную
Если вы включили пакетный экспорт до середины октября 2024 года, то вы можете вручную перейти на новую инфраструктуру, просто отключив и снова включив экспорт данных Crashlytics в консоли Firebase .
Вот подробные шаги:
В консоли Firebase перейдите на страницу Интеграции .
На карточке BigQuery нажмите Управление .
Чтобы отключить экспорт, отключите ползунок Crashlytics . При появлении запроса подтвердите, что хотите остановить экспорт данных.
Немедленно переведите ползунок Crashlytics в положение «Вкл.», чтобы снова включить экспорт. При появлении запроса подтвердите экспорт данных.
Экспорт данных Crashlytics в BigQuery теперь использует новую инфраструктуру экспорта.
Имя существующей пакетной таблицы не соответствует идентификатору вашего приложения Firebase.
Если у вас есть существующие пакетные таблицы BigQuery в таком состоянии, это означает, что они несовместимы с новой инфраструктурой экспорта пакетных данных Firebase в BigQuery . Обратите внимание, что все проекты Firebase будут автоматически перенесены в новую инфраструктуру экспорта уже 15 сентября 2025 года.
Следуйте инструкциям в этом разделе перед ручным обновлением или до 15 сентября 2025 г., чтобы избежать сбоев в пакетном экспорте данных Crashlytics в BigQuery .
Перейти к инструкциям по избежанию сбоев
Понять, как инфраструктура экспорта использует идентификаторы для записи данных в таблицы BigQuery
Вот как две экспортные инфраструктуры записывают данные Crashlytics в пакетные таблицы BigQuery :
Устаревшая инфраструктура экспорта : записывает данные в таблицу с именем, основанным на идентификаторе пакета или имени пакета в конфигурации Firebase в кодовой базе вашего приложения (обычно из файла
GoogleService-Info.plist
или файлаgoogle-services.json
).Новая инфраструктура экспорта : записывает данные в таблицу с именем, основанным на идентификаторе пакета или имени пакета , заданном для зарегистрированного приложения Firebase в вашем проекте Firebase .
К сожалению, иногда идентификатор пакета или имя пакета в конфигурации вашей кодовой базы не совпадают с идентификатором пакета или именем пакета , заданными для зарегистрированного приложения Firebase в вашем проекте Firebase . Обычно это происходит, если кто-то вручную изменил файл конфигурации в кодовой базе вашего приложения или не указал действительный идентификатор при регистрации приложения.
Что произойдет, если это не исправить перед обновлением?
Если идентификаторы в этих двух местах не совпадают, то после перехода на новую экспортную инфраструктуру произойдет следующее:
Ваши данные Crashlytics начнут записываться в новую пакетную таблицу BigQuery — то есть в новую таблицу с именем, основанным на идентификаторе пакета или имени пакета , заданном для вашего зарегистрированного приложения Firebase в вашем проекте Firebase .
В любую существующую «устаревшую» таблицу с именем, основанным на идентификаторе в конфигурации вашей кодовой базы, больше не будут записываться данные.
Примеры сценариев несовпадения идентификаторов
Обратите внимание, что к именам таблиц пакета BigQuery автоматически добавляется _IOS
или _ANDROID
для указания платформы приложения.
Идентификатор(ы) в кодовой базе вашего приложения | Идентификатор(ы), установленный(е) для вашего(их) приложения(й) Firebase | Устаревшее поведение | Поведение после обновления к новой экспортной инфраструктуре | Решение |
---|---|---|---|---|
foo | bar | Записывает данные в одну таблицу, названную по идентификатору в кодовой базе приложения ( foo ). | Создает, а затем записывает данные в одну таблицу, названную по идентификатору, установленному для приложения Firebase ( bar ). | Реализуйте вариант 1 или 2, описанный ниже. |
foo | bar , qux и т. д. | Записывает данные в одну таблицу, названную по идентификатору в кодовой базе приложения ( foo ). | Создает*, а затем записывает данные в несколько таблиц, названных в соответствии с идентификаторами, установленными для приложений Firebase ( bar , qux и т. д.). | Реализуйте вариант 2, описанный ниже. |
foo , baz т. д. | bar | Записывает данные в несколько таблиц, названных в честь нескольких идентификаторов в кодовой базе приложения ( foo , baz и т. д.) | Создает**, а затем записывает данные каждого приложения в одну таблицу, названную по идентификатору, установленному для приложения Firebase ( bar ). | Ни один из вариантов не может быть реализован. Вы по-прежнему можете различать данные из каждого приложения в пределах одной таблицы, используя |
* Если идентификатор в кодовой базе вашего приложения совпадает с одним из идентификаторов, установленных для приложения Firebase, то новая инфраструктура экспорта не создаст новую таблицу для этого идентификатора. Вместо этого она продолжит записывать данные для этого конкретного приложения в неё. Данные всех остальных приложений будут записаны в новые таблицы.
** Если один из идентификаторов в кодовой базе вашего приложения совпадает с идентификатором, установленным для приложения Firebase, то новая инфраструктура экспорта не создаст новую таблицу. Вместо этого она будет поддерживать эту таблицу и записывать в неё данные для всех приложений.
Варианты избежания сбоев
Чтобы избежать каких -либо сбоев, следуйте инструкциям по одному из вариантов, описанных ниже , до обновления вручную или до 15 сентября 2025 года.
Вариант 1 :
Используйте новую таблицу, созданную новой экспортной инфраструктурой. Вы скопируете данные из существующей таблицы в новую таблицу.В консоли Firebase перейти на новую экспортную инфраструктуру , выключив экспорт, а затем снова для приложения.
Это действие создает новую пакетную таблицу с именем, основанным на идентификаторе пакета или имени пакета , установленного для вашего зарегистрированного приложения Firebase в вашем проекте Firebase .
В консоли Google Cloud скопируйте все данные из вашей таблицы устаревших в новую только что созданную таблицу.
Если у вас есть какие -либо нисходящие зависимости, которые зависят от вашей пакетной таблицы, измените их на использование новой таблицы.
Вариант 2 :
Продолжайте писать в своем существующем столе. Вы переопределяете некоторые значения по умолчанию в конфигурации BigQuery , чтобы достичь этого.В консоли Firebase найдите и обратите внимание на идентификатор приложения Firebase (например,
1:1234567890:ios:321abc456def7890
) приложения с номером и идентификатором таблицы несоответствия: идентификатор:
Перейдите в проекта настроек , затем прокрутите на карту ваших приложений , чтобы увидеть все ваши приложения Firebase и их информацию.В консоли Firebase перейти на новую экспортную инфраструктуру , выключив экспорт, а затем снова для приложения.
Это действие делает две вещи:
Создает новую пакетную таблицу с именем, основанным на идентификаторе пакета или имени пакета , установленного для вашего зарегистрированного приложения Firebase в вашем проекте Firebase . (В конце концов вы удалите эту таблицу, но еще не удалите ее.)
Создает BigQuery «конфигурацию передачи данных» с исходной
Firebase Crashlytics with Multi-Region Support
.
В Google Cloud измените новую «конфигурацию передачи данных», чтобы данные продолжали писать в вашей существующей таблице:
Перейдите в BigQuery > Transfers Data для просмотра «конфигурации передачи данных».
Выберите конфигурацию, которая имеет исходную
Firebase Crashlytics with Multi-Region Support
.Нажмите «Редактировать в правом верхнем углу».
В разделе «Подробности источника данных» найдите список для GMP_APP_ID и список для client_namespace .
В BigQuery идентификатор приложения Firebase называется
gmp_app_id
. По умолчанию значениеclient_namespace
в BigQuery - это соответствующий уникальный идентификатор пакета / имени пакета приложения, но вы будете переоценить эту конфигурацию по умолчанию.BigQuery использует значение
client_namespace
для имени пакетной таблицы, которое пишет каждое связанное приложение Firebase.Найдите GMP_APP_ID приложения Firebase, для которого вы хотите переопределить настройки по умолчанию. Измените его значение client_namespace на имя таблицы, которую вы хотите, чтобы приложение Firebase написало вместо этого (обычно это название таблицы устаревшей, которую приложение писало с инфраструктурой Export Legacy).
Сохранить изменение конфигурации.
Запланируйте обратную засылку на те дни, когда в вашей существующей таблице отсутствуют данные.
После того, как засыпание будет сделано, удалите новую таблицу , которая была автоматически создана новой экспортной инфраструктурой.