Вы можете экспортировать данные Firebase Crashlytics в BigQuery для дальнейшего анализа. BigQuery позволяет анализировать данные с помощью BigQuery SQL, экспортировать их в другой облачный сервис и использовать для визуализации и создания пользовательских панелей мониторинга с помощью Looker Studio .
Что можно сделать с экспортированными данными?
Экспорт в BigQuery содержит необработанные данные о сбоях, включая тип устройства, операционную систему, исключения (приложения Android) или ошибки (приложения Apple), а также журналы Crashlytics и другие данные. Подробнее о том, какие именно данные Crashlytics экспортируются, и схему их таблиц, вы можете узнать далее на этой странице.
Вот несколько примеров того, что вы можете сделать с экспортированными данными Crashlytics :
Выполнять запросы
Вы можете выполнять запросы к данным Crashlytics для создания отчётов, объединяющих данные о сбоях в более понятные сводки. Поскольку такие отчёты недоступны на панели управления Crashlytics в консоли Firebase , они могут дополнить ваш анализ и понимание данных о сбоях. Далее на этой странице вы найдёте примеры запросов .Используйте шаблон Looker Studio
Crashlytics предоставляет готовый шаблон Looker Studio для визуализации экспортированных данных.Создать представления
Используя BigQuery UI, вы можете создать «представление» — виртуальную таблицу, определяемую SQL-запросом. Подробные инструкции о различных типах представлений и их создании см. в документации BigQuery .
Экспорт потоковой передачи Crashlytics в BigQuery
Вы можете транслировать данные Crashlytics в режиме реального времени с помощью потоковой передачи BigQuery . Вы можете использовать её для любых целей, требующих актуальных данных, например, для представления информации на панели мониторинга, отслеживания процесса внедрения в режиме реального времени или мониторинга проблем в приложениях, которые запускают оповещения и настраиваемые рабочие процессы.
При включении потокового экспорта Crashlytics в BigQuery , помимо пакетной таблицы, вы также получите таблицу в реальном времени. Вот различия между этими таблицами, о которых следует знать:
Таблица партий | Таблица в реальном времени |
---|---|
|
|
Пакетная таблица идеально подходит для долгосрочного анализа и выявления тенденций, поскольку мы надежно храним события до их записи, и их можно заполнять в таблицу до 30 дней*. При записи данных в вашу таблицу в режиме реального времени они немедленно записываются в BigQuery , поэтому она идеально подходит для динамических панелей мониторинга и пользовательских оповещений. Эти две таблицы можно объединить с помощью запроса на сшивание, чтобы получить преимущества обоих вариантов.
По умолчанию срок действия раздела таблицы в реальном времени составляет 30 дней. Чтобы узнать, как изменить этот срок, см. раздел «Установка срока действия раздела» в документации BigQuery .
* Подробную информацию о поддержке обратного заполнения см. в разделе Переход на новую экспортную инфраструктуру .
Включить экспорт в BigQuery
В консоли Firebase перейдите на страницу Интеграции .
На карточке BigQuery нажмите Ссылка .
Следуйте инструкциям на экране, чтобы включить экспорт в BigQuery .
Если вам нужен доступ к данным Crashlytics в 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 , и не влияет на расположение данных, хранящихся для использования на панели управления Crashlytics консоли Firebase или в Android Studio.
По умолчанию все приложения в вашем проекте связаны с BigQuery , и любые приложения, которые вы позже добавляете в проект, автоматически связаны с BigQuery . Вы можете управлять тем, какие приложения отправляют данные .
Firebase настраивает ежедневную синхронизацию ваших данных с BigQuery .
После привязки проекта вам обычно придется дождаться синхронизации следующего дня, чтобы первый набор данных был экспортирован в BigQuery .
Ежедневная синхронизация выполняется один раз в день, независимо от запланированного экспорта, настроенного в BigQuery . Обратите внимание, что время и продолжительность задания синхронизации могут меняться, поэтому мы не рекомендуем планировать последующие операции или задания на основе конкретного времени экспорта.
Firebase экспортирует копию ваших данных в BigQuery . Первоначальное распространение данных для экспорта может занять до 48 часов.
Для каждого связанного приложения этот экспорт включает пакетную таблицу, содержащую данные ежедневной синхронизации.
Вы можете вручную запланировать заполнение данных для пакетной таблицы за последние 30 дней или на самую последнюю дату, когда вы включили экспорт в BigQuery (в зависимости от того, что наступило позже).
Обратите внимание: если вы включили экспорт данных Crashlytics до середины октября 2024 года, вы также можете выполнить обратное заполнение за 30 дней до дня, когда вы включили экспорт.
Если включить потоковый экспорт Crashlytics в BigQuery , все связанные приложения также будут иметь таблицу в реальном времени, содержащую постоянно обновляемые данные.
Чтобы отключить экспорт в BigQuery , отключите свой проект в консоли 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 >= PARSE_TIMESTAMP("%Y_%m_%d", "YYYY_MM_DD") GROUP BY issue_id ORDER BY events DESC LIMIT 5;
Визуализируйте экспортированные данные Crashlytics с помощью Looker Studio
Looker Studio преобразует ваши наборы данных Crashlytics в BigQuery в отчеты, которые легче читать, которыми легче делиться и которые можно полностью настраивать.
Чтобы узнать больше об использовании Looker Studio , ознакомьтесь с их приветственным руководством .
Используйте шаблон отчета Crashlytics
Looker Studio есть пример отчёта для Crashlytics , включающий полный набор измерений и метрик из экспортированной схемы Crashlytics BigQuery . Если вы включили потоковый экспорт Crashlytics в BigQuery , вы можете просматривать эти данные на странице «Тенденции в реальном времени» шаблона Looker Studio . Вы можете использовать этот пример в качестве шаблона для быстрого создания новых отчётов и визуализаций на основе необработанных данных о сбоях вашего приложения:
Откройте шаблон панели инструментов Crashlytics Looker Studio .
Нажмите «Использовать шаблон» в правом верхнем углу.
В раскрывающемся списке Новый источник данных выберите Создать новый источник данных .
Нажмите Выбрать на карточке BigQuery .
Выберите таблицу, содержащую экспортированные данные Crashlytics , выбрав Мои проекты > PROJECT_ID > firebase_crashlytics > TABLE_NAME .
Ваша пакетная таблица всегда доступна для выбора. Если включен потоковый экспорт Crashlytics в BigQuery , вы можете выбрать таблицу в режиме реального времени.
В разделе «Конфигурация» установите уровень шаблона Crashlytics на «По умолчанию» .
Нажмите Подключиться , чтобы создать новый источник данных.
Нажмите «Добавить в отчет» , чтобы вернуться к шаблону Crashlytics .
Наконец, нажмите «Создать отчет» , чтобы создать копию шаблона панели мониторинга Crashlytics Looker Studio .
Понимание схемы Crashlytics в BigQuery
Данные Firebase Crashlytics экспортируются в набор данных BigQuery с именем firebase_crashlytics
. Этот набор данных охватывает весь ваш проект, даже если он состоит из нескольких приложений.
Таблицы
По умолчанию Firebase создаёт отдельные таблицы в наборе данных Crashlytics для каждого приложения в вашем проекте, связанном с BigQuery . Имена таблиц формируются на основе идентификатора приложения (точки заменяются подчёркиваниями) с добавлением платформы приложения ( _IOS
или _ANDROID
). Например, данные для приложения Android с именем пакета com.google.test
будут находиться в таблице с именем com_google_test_ANDROID
.
Если включить потоковый экспорт Crashlytics в BigQuery , то данные Crashlytics также будут передаваться в режиме реального времени в таблицу с добавлением _REALTIME
(например, com_google_test_ANDROID_REALTIME
).
Каждая строка в таблице представляет собой событие, произошедшее в приложении, включая сбои, нефатальные ошибки и ANR.
Таблицы содержат стандартный набор данных Crashlytics в дополнение к любым пользовательским ключам Crashlytics , определенным вами в вашем приложении.
Ряды
Каждая строка в таблице представляет собой ошибку, с которой столкнулось приложение.
Колонны
Столбцы в таблице идентичны для сбоев, нефатальных ошибок и ошибок ANR. Если включен потоковый экспорт Crashlytics в BigQuery , таблица в реальном времени будет содержать те же столбцы, что и пакетная таблица. Обратите внимание, что в строках могут быть столбцы, представляющие события без трассировки стека.
Вот столбцы в таблице для экспортированных данных Crashlytics :
Имя поля | Тип данных | Описание |
---|---|---|
app_orientation | НИТЬ | Например, PORTRAIT , LANDSCAPE , FACE_UP , FACE_DOWN и т. д. |
application | ЗАПИСЫВАТЬ | Приложение, сгенерировавшее событие |
application.build_version | НИТЬ | Версия сборки приложения |
application.display_version | НИТЬ | |
blame_frame | ЗАПИСЫВАТЬ | Кадр, определенный как основная причина сбоя или ошибки |
blame_frame.address | INT64 | Адрес в двоичном изображении, содержащий код Не установлено для фреймов Java |
blame_frame.blamed | БУЛЕВ | Определил ли Crashlytics , что этот кадр является причиной сбоя или ошибки |
blame_frame.file | НИТЬ | Имя файла кадра |
blame_frame.library | НИТЬ | Отображаемое имя библиотеки, в которую входит фрейм |
blame_frame.line | INT64 | Номер строки файла кадра |
blame_frame.offset | INT64 | Смещение байта в двоичном изображении, содержащем код Не установлено для исключений Java |
blame_frame.owner | НИТЬ | Например, DEVELOPER , VENDOR , RUNTIME , PLATFORM или SYSTEM |
blame_frame.symbol | НИТЬ | Символ гидратированного продукта или символ сырого продукта, если продукт не гидратируется. |
breadcrumbs | ПОВТОРНАЯ ЗАПИСЬ | Навигационная цепочка Google Analytics с отметкой времени, если включена |
breadcrumbs.name | НИТЬ | Название, связанное с хлебными крошками |
breadcrumbs.params | ПОВТОРНАЯ ЗАПИСЬ | Параметры, связанные с хлебными крошками |
breadcrumbs.params.key | НИТЬ | Параметр ключа, связанный с хлебными крошками |
breadcrumbs.params.value | НИТЬ | Значение параметра, связанное с хлебными крошками |
breadcrumbs.timestamp | МЕТКА ВРЕМЕНИ | Метка времени, связанная с хлебными крошками |
bundle_identifier | НИТЬ | Уникальный идентификатор приложения, зарегистрированный в проекте Firebase (например,com.google.gmail )Для приложений платформы Apple это идентификатор пакета приложения. Для приложений Android это имя пакета приложения. |
crashlytics_sdk_versions | НИТЬ | Версия Crashlytics SDK, сгенерировавшая событие |
custom_keys | ПОВТОРНАЯ ЗАПИСЬ | Пары «ключ-значение», определяемые разработчиком |
custom_keys.key | НИТЬ | Ключ, определенный разработчиком |
custom_keys.value | НИТЬ | Значение, определенное разработчиком |
device | ЗАПИСЫВАТЬ | Устройство, на котором произошло событие |
device_orientation | НИТЬ | Например, PORTRAIT , LANDSCAPE , FACE_UP , FACE_DOWN и т. д. |
device.architecture | НИТЬ | Например, X86_32 , X86_64 , ARMV7 , ARM64 , ARMV7S или ARMV7K |
device.manufacturer | НИТЬ | Производитель устройства |
device.model | НИТЬ | Модель устройства |
error | ПОВТОРНАЯ ЗАПИСЬ | (только приложения Apple) нефатальные ошибки |
error_type | НИТЬ | Тип ошибки события (например, FATAL , NON_FATAL , ANR и т. д.) |
error.blamed | БУЛЕВ | Определил ли Crashlytics , что этот кадр является причиной ошибки |
error.code | INT64 | Код ошибки, связанный с пользовательским регистрируемым событием NSError приложения |
error.frames | ПОВТОРНАЯ ЗАПИСЬ | Кадры трассировки стека |
error.frames.address | INT64 | Адрес в двоичном изображении, содержащий код |
error.frames.blamed | БУЛЕВ | Определил ли Crashlytics , что этот кадр является причиной ошибки |
error.frames.file | НИТЬ | Имя файла кадра |
error.frames.library | НИТЬ | Отображаемое имя библиотеки, в которую входит фрейм |
error.frames.line | INT64 | Номер строки файла кадра |
error.frames.offset | INT64 | Смещение байта в двоичном изображении, содержащем код |
error.frames.owner | НИТЬ | Например, DEVELOPER , VENDOR , RUNTIME , PLATFORM или SYSTEM |
error.frames.symbol | НИТЬ | Символ гидратированного продукта или символ сырого продукта, если продукт не гидратируется. |
error.queue_name | НИТЬ | Очередь, в которой работал поток |
error.subtitle | НИТЬ | Подзаголовок темы |
error.title | НИТЬ | Название темы |
event_id | НИТЬ | Уникальный идентификатор события |
event_timestamp | МЕТКА ВРЕМЕНИ | Когда произошло событие |
exceptions | ПОВТОРНАЯ ЗАПИСЬ | (Только для Android) Исключения, произошедшие во время этого события. Вложенные исключения представлены в обратном хронологическом порядке, то есть последняя запись соответствует первому возникшему исключению. |
exceptions.blamed | БУЛЕВ | True, если Crashlytics определяет, что исключение является причиной ошибки или сбоя. |
exceptions.exception_message | НИТЬ | Сообщение, связанное с исключением |
exceptions.frames | ПОВТОРНАЯ ЗАПИСЬ | Кадры, связанные с исключением |
exceptions.frames.address | INT64 | Адрес в двоичном изображении, содержащий код Не установлено для фреймов Java |
exceptions.frames.blamed | БУЛЕВ | Определил ли Crashlytics , что этот кадр является причиной сбоя или ошибки |
exceptions.frames.file | НИТЬ | Имя файла кадра |
exceptions.frames.library | НИТЬ | Отображаемое имя библиотеки, в которую входит фрейм |
exceptions.frames.line | INT64 | Номер строки файла кадра |
exceptions.frames.offset | INT64 | Смещение байта в двоичном изображении, содержащем код Не установлено для исключений Java |
exceptions.frames.owner | НИТЬ | Например, DEVELOPER , VENDOR , RUNTIME , PLATFORM или SYSTEM |
exceptions.frames.symbol | НИТЬ | Символ гидратированного продукта или символ сырого продукта, если продукт не гидратируется. |
exceptions.nested | БУЛЕВ | Верно для всех исключений, кроме последнего (то есть первой записи) |
exceptions.subtitle | НИТЬ | Подзаголовок темы |
exceptions.title | НИТЬ | Название темы |
exceptions.type | НИТЬ | Тип исключения (например,java.lang.IllegalStateException) |
installation_uuid | НИТЬ | Идентификатор, который идентифицирует уникальную установку приложения и устройства. |
is_fatal | БУЛЕВ | Произошёл ли сбой приложения |
issue_id | НИТЬ | Проблема, связанная с событием |
logs | ПОВТОРНАЯ ЗАПИСЬ | Сообщения журнала с метками времени, сгенерированные регистратором Crashlytics , если он включен |
logs.message | НИТЬ | Зарегистрированное сообщение |
logs.timestamp | МЕТКА ВРЕМЕНИ | Когда был сделан журнал |
memory | ЗАПИСЫВАТЬ | Состояние памяти устройства |
memory.free | INT64 | Осталось байтов памяти |
memory.used | INT64 | Байты используемой памяти |
operating_system | ЗАПИСЫВАТЬ | Подробная информация об ОС на устройстве |
operating_system.device_type | НИТЬ | Тип устройства (например, MOBILE , TABLET , TV и т. д.); также известный как «категория устройства» |
operating_system.display_version | НИТЬ | Версия ОС на устройстве |
operating_system.modification_state | НИТЬ | Было ли устройство изменено (например, взломанное приложение — MODIFIED , а рутированное приложение — UNMODIFIED ) |
operating_system.name | НИТЬ | Название ОС на устройстве |
operating_system.type | НИТЬ | (Только приложения Apple) Тип ОС, работающей на устройстве (например, IOS , MACOS и т. д.) |
platform | НИТЬ | Платформа приложения, зарегистрированная в проекте Firebase (допустимые значения: IOS или ANDROID ) |
process_state | НИТЬ | BACKGROUND или FOREGROUND |
storage | ЗАПИСЫВАТЬ | Постоянное хранилище устройства |
storage.free | INT64 | Осталось байтов памяти |
storage.used | INT64 | Использовано байтов памяти |
threads | ПОВТОРНАЯ ЗАПИСЬ | Темы, присутствующие на момент события |
threads.blamed | БУЛЕВ | Определил ли Crashlytics , что этот кадр является причиной сбоя или ошибки |
threads.code | INT64 | (Только для приложений Apple) Код ошибки NSError, зарегистрированный пользователем в приложении |
threads.crash_address | INT64 | Адрес сигнала, вызвавшего сбой приложения; присутствует только в аварийно завершившихся собственных потоках. |
threads.crashed | БУЛЕВ | Произошел ли сбой потока |
threads.frames | ПОВТОРНАЯ ЗАПИСЬ | Рамки нити |
threads.frames.address | INT64 | Адрес в двоичном изображении, содержащий код |
threads.frames.blamed | БУЛЕВ | Определил ли Crashlytics , что этот кадр является причиной ошибки |
threads.frames.file | НИТЬ | Имя файла кадра |
threads.frames.library | НИТЬ | Отображаемое имя библиотеки, в которую входит фрейм |
threads.frames.line | INT64 | Номер строки файла кадра |
threads.frames.offset | INT64 | Смещение байта в двоичном изображении, содержащем код |
threads.frames.owner | НИТЬ | Например, DEVELOPER , VENDOR , RUNTIME , PLATFORM или SYSTEM |
threads.frames.symbol | НИТЬ | Символ гидратации или символ сырости, если вещество не подлежит гидратации |
threads.queue_name | НИТЬ | (Только для приложений Apple) Очередь, в которой работал поток |
threads.signal_code | НИТЬ | Код сигнала, вызвавшего сбой приложения; присутствует только в аварийно завершившихся собственных потоках. |
threads.signal_name | НИТЬ | Имя сигнала, вызвавшего сбой приложения, присутствует только в аварийно завершенных собственных потоках. |
threads.subtitle | НИТЬ | Подзаголовок темы |
threads.thread_name | НИТЬ | Название темы |
threads.title | НИТЬ | Название темы |
unity_metadata.debug_build | БУЛЕВ | Если это отладочная сборка |
unity_metadata.graphics_copy_texture_support | НИТЬ | Поддержка копирования графической текстуры, как определено в API Unity. |
unity_metadata.graphics_device_id | INT64 | Идентификатор графического устройства |
unity_metadata.graphics_device_name | НИТЬ | Название графического устройства |
unity_metadata.graphics_device_type | НИТЬ | Тип графического устройства |
unity_metadata.graphics_device_vendor_id | INT64 | Идентификатор поставщика графического процессора |
unity_metadata.graphics_device_vendor | НИТЬ | Поставщик графического устройства |
unity_metadata.graphics_device_version | НИТЬ | Версия графического устройства |
unity_metadata.graphics_max_texture_size | INT64 | Максимальный размер, выделенный для рендеринга текстуры |
unity_metadata.graphics_memory_size_mb | INT64 | Графическая память в МБ |
unity_metadata.graphics_render_target_count | INT64 | Количество целей графического рендеринга |
unity_metadata.graphics_shader_level | INT64 | Уровень шейдера графики |
unity_metadata.processor_count | INT64 | Количество процессоров (ядер) |
unity_metadata.processor_frequency_mhz | INT64 | Частота процессора(ов) в МГц |
unity_metadata.processor_type | НИТЬ | Тип процессора |
unity_metadata.screen_refresh_rate_hz | INT64 | Частота обновления экрана в Гц |
unity_metadata.screen_resolution_dpi | НИТЬ | DPI экрана как число с плавающей запятой |
unity_metadata.screen_size_px | НИТЬ | Размер экрана в пикселях, отформатированный как ширина x высота |
unity_metadata.system_memory_size_mb | INT64 | Размер системной памяти в Мб |
unity_metadata.unity_version | НИТЬ | Версия Unity, работающая на этом устройстве |
user | ЗАПИСЫВАТЬ | (Необязательно) Информация, собранная о пользователе приложения |
user.email | НИТЬ | (Необязательно) Адрес электронной почты пользователя |
user.id | НИТЬ | (Необязательно) Идентификатор приложения, связанный с пользователем |
user.name | НИТЬ | (Необязательно) Имя пользователя |
variant_id | НИТЬ | Вариант выпуска, связанный с этим событием Обратите внимание, что не все события имеют связанный с ними вариант выпуска. |
Переход на новую экспортную инфраструктуру
В середине октября 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 .
Шаг 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 в вашем проекте 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
) приложения с несовпадающим именем пакетной таблицы и идентификатором:
Перейдите в Project Settings , затем прокрутите до карточки «Ваши приложения», чтобы просмотреть все ваши приложения Firebase и их информацию.В консоли Firebase обновите новую инфраструктуру экспорта , отключив и снова включив экспорт для связанного приложения.
Это действие выполняет две задачи:
Создает новую пакетную таблицу с именем, основанным на идентификаторе пакета или имени пакета , установленном для вашего зарегистрированного приложения Firebase в вашем проекте Firebase . (В конечном итоге вы удалите эту таблицу, но пока не удаляйте ее.)
Создает «конфигурацию передачи данных» BigQuery с исходным кодом
Firebase Crashlytics with Multi-Region Support
.
В консоли Google Cloud измените новую «конфигурацию передачи данных», чтобы данные продолжали записываться в существующую таблицу:
Перейдите в BigQuery > Передача данных , чтобы просмотреть «конфигурацию передачи данных».
Выберите конфигурацию, в которой есть исходный
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 должно вместо этого выполнять запись (обычно это имя устаревшей таблицы, в которую приложение записывало с помощью устаревшей инфраструктуры экспорта).
Сохраните изменение конфигурации.
Запланируйте повторное заполнение на те дни, когда в существующей таблице отсутствуют данные.
После завершения заполнения удалите новую таблицу , которая была автоматически создана новой инфраструктурой экспорта.
Вы можете экспортировать данные Firebase Crashlytics в BigQuery для дальнейшего анализа. BigQuery позволяет анализировать данные с помощью BigQuery SQL, экспортировать их другому облачному провайдеру и использовать для визуализации и создания пользовательских информационных панелей с помощью Looker Studio .
Что можно делать с экспортированными данными?
Экспорт в BigQuery содержит необработанные данные о сбоях, включая тип устройства, операционную систему, исключения (приложения Android) или ошибки (приложения Apple), журналы Crashlytics , а также другие данные. Вы можете просмотреть, какие именно данные Crashlytics экспортируются, и их схему таблицы позже на этой странице.
Вот несколько примеров того, что вы можете сделать с экспортированными данными Crashlytics :
Запуск запросов
Вы можете выполнять запросы к своим данным Crashlytics , чтобы создавать отчеты, которые объединяют данные о событиях сбоя в более понятные сводки. Поскольку эти типы отчетов недоступны на панели управления Crashlytics консоли Firebase , они могут дополнить ваш анализ и понимание данных о сбоях. Далее на этой странице вы найдете подборку примеров запросов .Используйте шаблон Looker Studio
Crashlytics предоставляет готовый шаблон Looker Studio для визуализации экспортированных данных.Создание представлений
Используя пользовательский интерфейс BigQuery , вы можете создать «представление», которое представляет собой виртуальную таблицу, определенную SQL-запросом. Подробные инструкции о различных типах представлений и о том, как их создавать, можно найти в документации BigQuery .
Экспорт потоковой передачи Crashlytics в BigQuery
Вы можете осуществлять потоковую передачу данных Crashlytics в режиме реального времени с помощью потоковой передачи BigQuery . Вы можете использовать его для любых целей, требующих оперативных данных, например для представления информации на интерактивной информационной панели, просмотра развертывания в реальном времени или мониторинга проблем приложений, которые вызывают оповещения и настраиваемые рабочие процессы.
Когда вы включаете потоковый экспорт Crashlytics в BigQuery , помимо пакетной таблицы у вас также будет таблица реального времени. Вот различия, о которых вам следует знать между таблицами:
Таблица партий | Таблица реального времени |
---|---|
|
|
Пакетная таблица идеально подходит для долгосрочного анализа и выявления тенденций с течением времени, поскольку мы надежно сохраняем события перед их записью, и их можно повторно заполнить в таблице на срок до 30 дней*. Когда мы записываем данные в вашу таблицу реального времени, мы немедленно записываем их в BigQuery , поэтому они идеально подходят для интерактивных информационных панелей и пользовательских оповещений. Эти две таблицы можно объединить с запросом на сшивание, чтобы получить преимущества обеих.
По умолчанию срок действия раздела таблицы реального времени составляет 30 дней. Чтобы узнать, как это изменить, см. раздел «Установка срока действия раздела» в документации BigQuery .
* Подробности о поддержке обратной засыпки см. в разделе Обновление до новой экспортной инфраструктуры .
Включить экспорт в BigQuery
В консоли Firebase перейдите на страницу «Интеграции» .
На карточке BigQuery нажмите «Ссылка» .
Следуйте инструкциям на экране, чтобы включить экспорт в BigQuery .
Если вам нужен доступ к данным Crashlytics в 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 , и не влияет на расположение данных, хранящихся для использования на панели управления Crashlytics консоли Firebase или в Android Studio.
По умолчанию все приложения в вашем проекте связаны с BigQuery , и все приложения, которые вы позже добавите в проект, автоматически связываются с BigQuery . Вы можете управлять тем, какие приложения отправляют данные .
Firebase настраивает ежедневную синхронизацию ваших данных с BigQuery .
После связывания проекта вам обычно нужно дождаться синхронизации на следующий день, чтобы первый набор данных был экспортирован в BigQuery .
Ежедневная синхронизация происходит один раз в день, независимо от запланированного экспорта, который вы могли настроить в BigQuery . Обратите внимание, что время и продолжительность задания синхронизации могут измениться, поэтому мы не рекомендуем планировать последующие операции или задания на основе определенного времени экспорта.
Firebase экспортирует копию существующих данных в BigQuery . Первоначальное распространение данных для экспорта может занять до 48 часов.
Для каждого связанного приложения этот экспорт включает пакетную таблицу, содержащую данные ежедневной синхронизации.
Вы можете вручную запланировать заполнение данных для пакетной таблицы за последние 30 дней или до самой последней даты, когда вы включили экспорт в BigQuery (в зависимости от того, что наступит позже).
Обратите внимание: если вы включили экспорт данных Crashlytics до середины октября 2024 года, вы также можете выполнить обратное заполнение за 30 дней до дня включения экспорта.
Если вы включите экспорт потоковой передачи Crashlytics в BigQuery , все связанные приложения также будут иметь таблицу в реальном времени, содержащую постоянно обновляемые данные.
Чтобы деактивировать экспорт в BigQuery , отсоедините свой проект в консоли 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 >= PARSE_TIMESTAMP("%Y_%m_%d", "YYYY_MM_DD") GROUP BY issue_id ORDER BY events DESC LIMIT 5;
Визуализация экспортированных данных Crashlytics с помощью Looker Studio
Looker Studio превращает ваши наборы данных Crashlytics в BigQuery в отчеты, которые легче читать, которыми легче делиться и которые полностью настраиваемы.
Чтобы узнать больше об использовании Looker Studio , ознакомьтесь с их приветственным руководством .
Используйте шаблон отчета Crashlytics
Looker Studio есть образец отчета для Crashlytics , который включает полный набор параметров и показателей из экспортированной схемы Crashlytics BigQuery . Если вы включили потоковый экспорт Crashlytics в BigQuery , вы можете просмотреть эти данные на странице тенденций в реальном времени шаблона Looker Studio Вы можете использовать образец в качестве шаблона для быстрого создания новых отчетов и визуализаций на основе необработанных данных о сбоях вашего собственного приложения:
Откройте шаблон панели мониторинга Crashlytics Looker Studio .
Нажмите «Использовать шаблон» в правом верхнем углу.
В раскрывающемся списке «Новый источник данных» выберите «Создать новый источник данных» .
Нажмите «Выбрать» на карточке BigQuery .
Выберите таблицу, содержащую экспортированные данные Crashlytics , выбрав Мои проекты > PROJECT_ID > firebase_crashlytics > TABLE_NAME .
Ваш пакетный стол всегда доступен для выбора. Если включен экспорт потоковой передачи Crashlytics в BigQuery , вместо этого вы можете выбрать таблицу реального времени.
В разделе «Конфигурация» установите для уровня шаблона Crashlytics значение «По умолчанию» .
Нажмите «Подключиться» , чтобы создать новый источник данных.
Нажмите «Добавить в отчет» , чтобы вернуться к шаблону Crashlytics .
Наконец, нажмите «Создать отчет» , чтобы создать копию шаблона панели инструментов Crashlytics Looker Studio .
Понимание схемы Crashlytics в BigQuery
Данные Firebase Crashlytics экспортируются в набор данных BigQuery с именем firebase_crashlytics
. Набор данных охватывает весь ваш проект, даже если в нем имеется несколько приложений.
Таблицы
По умолчанию Firebase создает отдельные таблицы внутри набора данных Crashlytics для каждого приложения в вашем проекте, связанного с BigQuery . Таблицы именуются на основе идентификатора приложения (точки преобразуются в символы подчеркивания) и добавляются к ним с указанием платформы приложения ( _IOS
или _ANDROID
). Например, данные для приложения Android с именем пакета com.google.test
будут находиться в таблице с именем com_google_test_ANDROID
.
Если вы включите потоковый экспорт Crashlytics в BigQuery , данные Crashlytics также будут передаваться в режиме реального времени в таблицу, к которой добавлен атрибут _REALTIME
(например, com_google_test_ANDROID_REALTIME
).
Каждая строка в таблице представляет событие, произошедшее в приложении, включая сбои, нефатальные ошибки и ошибки ANR.
Таблицы содержат стандартный набор данных Crashlytics в дополнение к любым пользовательским ключам Crashlytics , определенным вами в вашем приложении.
Ряды
Каждая строка в таблице представляет ошибку, с которой столкнулось приложение.
Колонны
Столбцы в таблице идентичны для сбоев, нефатальных ошибок и ошибок ANR. Если включен потоковый экспорт Crashlytics в BigQuery , таблица реального времени будет иметь те же столбцы, что и пакетная таблица. Обратите внимание, что в строках могут быть столбцы, представляющие события, не имеющие трассировки стека.
Вот столбцы таблицы экспортированных данных Crashlytics :
Имя поля | Тип данных | Описание |
---|---|---|
app_orientation | НИТЬ | Например, PORTRAIT , LANDSCAPE , FACE_UP , FACE_DOWN и т. д. |
application | ЗАПИСЫВАТЬ | Приложение, сгенерировавшее событие |
application.build_version | НИТЬ | Версия сборки приложения |
application.display_version | НИТЬ | |
blame_frame | ЗАПИСЫВАТЬ | Кадр, определенный как основная причина сбоя или ошибки. |
blame_frame.address | ИНТ64 | Адрес в двоичном изображении, содержащем код Не установлено для фреймов Java |
blame_frame.blamed | БУЛЕВ | Определил ли Crashlytics , что этот кадр является причиной сбоя или ошибки |
blame_frame.file | НИТЬ | Имя файла кадра |
blame_frame.library | НИТЬ | Отображаемое имя библиотеки, включающей фрейм. |
blame_frame.line | ИНТ64 | Номер строки файла кадра |
blame_frame.offset | ИНТ64 | Смещение байта в двоичном изображении, содержащем код. Не настроено для исключений Java |
blame_frame.owner | НИТЬ | Например, DEVELOPER , VENDOR , RUNTIME , PLATFORM или SYSTEM |
blame_frame.symbol | НИТЬ | Гидратированный символ или необработанный символ, если он не гидратируется. |
breadcrumbs | ПОВТОРНАЯ ЗАПИСЬ | Хлебные крошки Google Analytics с отметкой времени, если они включены. |
breadcrumbs.name | НИТЬ | Имя, связанное с хлебными крошками |
breadcrumbs.params | ПОВТОРНАЯ ЗАПИСЬ | Параметры, связанные с навигационной цепочкой |
breadcrumbs.params.key | НИТЬ | Ключ параметра, связанный с навигационной цепочкой |
breadcrumbs.params.value | НИТЬ | Значение параметра, связанное с навигационной цепочкой. |
breadcrumbs.timestamp | МЕТКА ВРЕМЕНИ | Временная метка, связанная с навигационной цепочкой |
bundle_identifier | НИТЬ | Уникальный идентификатор приложения, зарегистрированный в проекте Firebase (например,com.google.gmail )Для приложений платформы Apple это идентификатор пакета приложения. Для приложений Android это имя пакета приложения. |
crashlytics_sdk_versions | НИТЬ | Версия Crashlytics SDK, сгенерировавшая событие. |
custom_keys | ПОВТОРНАЯ ЗАПИСЬ | Определенные разработчиком пары ключ-значение |
custom_keys.key | НИТЬ | Ключ, определенный разработчиком |
custom_keys.value | НИТЬ | Значение, определенное разработчиком |
device | ЗАПИСЫВАТЬ | Устройство, на котором произошло событие |
device_orientation | НИТЬ | Например, PORTRAIT , LANDSCAPE , FACE_UP , FACE_DOWN и т. д. |
device.architecture | НИТЬ | Например, X86_32 , X86_64 , ARMV7 , ARM64 , ARMV7S или ARMV7K |
device.manufacturer | НИТЬ | Производитель устройства |
device.model | НИТЬ | Модель устройства |
error | ПОВТОРНАЯ ЗАПИСЬ | (Только приложения Apple) Нефатальные ошибки |
error_type | НИТЬ | Тип ошибки события (например, FATAL , NON_FATAL , ANR и т. д.) |
error.blamed | БУЛЕВ | Определил ли Crashlytics , что именно этот кадр является причиной ошибки |
error.code | ИНТ64 | Код ошибки, связанный с зарегистрированной в приложении NSError. |
error.frames | ПОВТОРНАЯ ЗАПИСЬ | Кадры трассировки стека |
error.frames.address | ИНТ64 | Адрес в двоичном изображении, содержащем код |
error.frames.blamed | БУЛЕВ | Определил ли Crashlytics , что именно этот кадр является причиной ошибки |
error.frames.file | НИТЬ | Имя файла кадра |
error.frames.library | НИТЬ | Отображаемое имя библиотеки, включающей фрейм. |
error.frames.line | ИНТ64 | Номер строки файла кадра |
error.frames.offset | ИНТ64 | Смещение байта в двоичном изображении, содержащем код. |
error.frames.owner | НИТЬ | Например, DEVELOPER , VENDOR , RUNTIME , PLATFORM или SYSTEM |
error.frames.symbol | НИТЬ | Гидратированный символ или необработанный символ, если он не гидратируется. |
error.queue_name | НИТЬ | Очередь, в которой выполнялся поток |
error.subtitle | НИТЬ | Подзаголовок темы |
error.title | НИТЬ | Название темы |
event_id | НИТЬ | Уникальный идентификатор мероприятия. |
event_timestamp | МЕТКА ВРЕМЕНИ | Когда произошло событие |
exceptions | ПОВТОРНАЯ ЗАПИСЬ | (Только для Android) Исключения, возникшие во время этого события. Вложенные исключения представлены в обратном хронологическом порядке, что означает, что последняя запись является первым возникшим исключением. |
exceptions.blamed | БУЛЕВ | Истинно, если Crashlytics определяет, что исключение является причиной ошибки или сбоя. |
exceptions.exception_message | НИТЬ | Сообщение, связанное с исключением |
exceptions.frames | ПОВТОРНАЯ ЗАПИСЬ | Кадры, связанные с исключением |
exceptions.frames.address | ИНТ64 | Адрес в двоичном изображении, содержащем код Не установлено для фреймов Java |
exceptions.frames.blamed | БУЛЕВ | Определил ли Crashlytics , что этот кадр является причиной сбоя или ошибки |
exceptions.frames.file | НИТЬ | Имя файла кадра |
exceptions.frames.library | НИТЬ | Отображаемое имя библиотеки, включающей фрейм. |
exceptions.frames.line | ИНТ64 | Номер строки файла кадра |
exceptions.frames.offset | ИНТ64 | Смещение байта в двоичном изображении, содержащем код. Не настроено для исключений Java |
exceptions.frames.owner | НИТЬ | Например, DEVELOPER , VENDOR , RUNTIME , PLATFORM или SYSTEM |
exceptions.frames.symbol | НИТЬ | Гидратированный символ или необработанный символ, если он не гидратируется. |
exceptions.nested | БУЛЕВ | Истинно для всех исключений, кроме последнего (имеется в виду первая запись). |
exceptions.subtitle | НИТЬ | Подзаголовок темы |
exceptions.title | НИТЬ | Название темы |
exceptions.type | НИТЬ | Тип исключения (например,java.lang.IllegalStateException) |
installation_uuid | НИТЬ | Идентификатор, идентифицирующий уникальную установку приложения и устройства. |
is_fatal | БУЛЕВ | Сбой приложения |
issue_id | НИТЬ | Проблема, связанная с событием |
logs | ПОВТОРНАЯ ЗАПИСЬ | Сообщения журнала с отметкой времени, созданные регистратором Crashlytics , если он включен. |
logs.message | НИТЬ | Зарегистрированное сообщение |
logs.timestamp | МЕТКА ВРЕМЕНИ | Когда был сделан журнал |
memory | ЗАПИСЫВАТЬ | Состояние памяти устройства |
memory.free | ИНТ64 | Осталось байт памяти |
memory.used | ИНТ64 | Использовано байт памяти |
operating_system | ЗАПИСЫВАТЬ | Подробности об ОС на устройстве |
operating_system.device_type | НИТЬ | Тип устройства (например, MOBILE , TABLET , TV и т. д.); также известная как «категория устройства» |
operating_system.display_version | НИТЬ | Версия ОС на устройстве |
operating_system.modification_state | НИТЬ | Было ли устройство модифицировано (например, приложение с джейлбрейком MODIFIED , а приложение с root-правами НЕ UNMODIFIED ) |
operating_system.name | НИТЬ | Название ОС на устройстве |
operating_system.type | НИТЬ | (Только приложения Apple) Тип ОС, установленной на устройстве (например, IOS , MACOS и т. д.). |
platform | НИТЬ | Платформа приложения, зарегистрированная в проекте Firebase (допустимые значения: IOS или ANDROID ). |
process_state | НИТЬ | BACKGROUND или FOREGROUND |
storage | ЗАПИСЫВАТЬ | Постоянное хранилище устройства |
storage.free | ИНТ64 | Осталось места в байтах |
storage.used | ИНТ64 | Использовано байт памяти |
threads | ПОВТОРНАЯ ЗАПИСЬ | Темы, присутствующие на момент события |
threads.blamed | БУЛЕВ | Определил ли Crashlytics , что этот кадр является причиной сбоя или ошибки |
threads.code | ИНТ64 | (Только для приложений Apple) Код ошибки пользовательского журнала NSError приложения. |
threads.crash_address | ИНТ64 | Адрес сигнала, вызвавшего сбой приложения; присутствует только в поврежденных собственных потоках |
threads.crashed | БУЛЕВ | Разбился ли поток |
threads.frames | ПОВТОРНАЯ ЗАПИСЬ | Кадры из нити |
threads.frames.address | ИНТ64 | Адрес в двоичном изображении, содержащем код |
threads.frames.blamed | БУЛЕВ | Определил ли Crashlytics , что именно этот кадр является причиной ошибки |
threads.frames.file | НИТЬ | Имя файла кадра |
threads.frames.library | НИТЬ | Отображаемое имя библиотеки, включающей фрейм. |
threads.frames.line | ИНТ64 | Номер строки файла кадра |
threads.frames.offset | ИНТ64 | Смещение байта в двоичном изображении, содержащем код. |
threads.frames.owner | НИТЬ | Например, DEVELOPER , VENDOR , RUNTIME , PLATFORM или SYSTEM |
threads.frames.symbol | НИТЬ | Гидратированный символ или необработанный символ, если он не гидратируется. |
threads.queue_name | НИТЬ | (Только для приложений Apple) Очередь, в которой выполнялся поток |
threads.signal_code | НИТЬ | Код сигнала, вызвавшего сбой приложения; присутствует только в поврежденных собственных потоках |
threads.signal_name | НИТЬ | Имя сигнала, вызвавшего сбой приложения, присутствует только в сбойных собственных потоках. |
threads.subtitle | НИТЬ | Подзаголовок темы |
threads.thread_name | НИТЬ | Название темы |
threads.title | НИТЬ | Название темы |
unity_metadata.debug_build | БУЛЕВ | Если это отладочная сборка |
unity_metadata.graphics_copy_texture_support | НИТЬ | Поддержка копирования графической текстуры, как определено в Unity API. |
unity_metadata.graphics_device_id | ИНТ64 | Идентификатор графического устройства |
unity_metadata.graphics_device_name | НИТЬ | Имя графического устройства |
unity_metadata.graphics_device_type | НИТЬ | Тип графического устройства |
unity_metadata.graphics_device_vendor_id | ИНТ64 | Идентификатор производителя графического процессора |
unity_metadata.graphics_device_vendor | НИТЬ | Поставщик графического устройства |
unity_metadata.graphics_device_version | НИТЬ | Версия графического устройства |
unity_metadata.graphics_max_texture_size | ИНТ64 | Максимальный размер, предназначенный для рендеринга текстуры |
unity_metadata.graphics_memory_size_mb | ИНТ64 | Графическая память в МБ |
unity_metadata.graphics_render_target_count | ИНТ64 | Количество целей графического рендеринга |
unity_metadata.graphics_shader_level | ИНТ64 | Уровень шейдеров графики |
unity_metadata.processor_count | ИНТ64 | Количество процессоров (ядер) |
unity_metadata.processor_frequency_mhz | ИНТ64 | Частота процессора(ов) в МГц |
unity_metadata.processor_type | НИТЬ | Тип процессора |
unity_metadata.screen_refresh_rate_hz | ИНТ64 | Частота обновления экрана в Гц |
unity_metadata.screen_resolution_dpi | НИТЬ | DPI экрана как число с плавающей запятой |
unity_metadata.screen_size_px | НИТЬ | Размер экрана в пикселях в формате ширина х высота. |
unity_metadata.system_memory_size_mb | ИНТ64 | Размер системной памяти в Мб |
unity_metadata.unity_version | НИТЬ | Версия Unity, работающая на этом устройстве. |
user | ЗАПИСЫВАТЬ | (Необязательно) Собранная информация о пользователе приложения. |
user.email | НИТЬ | (Необязательно) Адрес электронной почты пользователя. |
user.id | НИТЬ | (Необязательно) Идентификатор приложения, связанный с пользователем. |
user.name | НИТЬ | (Необязательно) Имя пользователя |
variant_id | НИТЬ | Вариант проблемы, связанный с этим событием Обратите внимание, что не со всеми событиями связан вариант проблемы. |
Переход на новую экспортную инфраструктуру
В середине октября 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 .
Шаг 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
и Android-приложение Firebase с именем пакетаcom.yourcompany.yourproject
, зарегистрированное в вашем проекте Firebase.
Если у вас есть имена пакетных таблиц, которые не соответствуют идентификаторам, установленным для ваших зарегистрированных приложений Firebase, следуйте инструкциям ниже на этой странице перед обновлением вручную или до 15 сентября 2025 года, чтобы избежать сбоев в пакетном экспорте.
Шаг 2. Обновление до новой инфраструктуры вручную.
Если вы включили пакетный экспорт до середины октября 2024 года, вы можете вручную перейти на новую инфраструктуру, просто выключив и снова включив экспорт данных Crashlytics в консоли Firebase .
Вот подробные шаги:
В консоли Firebase перейдите на страницу «Интеграции» .
На карточке BigQuery нажмите «Управление» .
Отключите ползунок Crashlytics , чтобы отключить экспорт. При появлении запроса подтвердите, что вы хотите остановить экспорт данных.
Немедленно снова включите ползунок Crashlytics , чтобы снова включить экспорт. При появлении запроса подтвердите, что вы хотите экспортировать данные.
Для экспорта данных Crashlytics в BigQuery теперь используется новая инфраструктура экспорта.
Имя существующей пакетной таблицы не соответствует вашему идентификатору приложения Firebase.
Если у вас есть существующие пакетные таблицы BigQuery в этом состоянии, это означает, что они несовместимы с новой инфраструктурой пакетного экспорта в BigQuery от Firebase. Обратите внимание, что все проекты Firebase будут автоматически перенесены в новую экспортную инфраструктуру уже 15 сентября 2025 года.
Следуйте инструкциям в этом разделе перед обновлением вручную или до 15 сентября 2025 г., чтобы избежать сбоев в пакетном экспорте данных Crashlytics в BigQuery .
Перейдите к инструкциям по выбору вариантов, чтобы избежать сбоев
Узнайте, как инфраструктура экспорта использует идентификаторы для записи данных в таблицы BigQuery
Вот как две экспортные инфраструктуры записывают данные Crashlytics в пакетные таблицы BigQuery :
Устаревшая инфраструктура экспорта : записывает данные в таблицу с именем, основанным на идентификаторе пакета или имени пакета в двоичном файле вашего приложения .
Новая инфраструктура экспорта : записывает данные в таблицу с именем, основанным на идентификаторе пакета или имени пакета , установленном для вашего зарегистрированного приложения 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 и т. д.). | Creates** затем записывает данные каждого приложения в одну таблицу, названную в честь идентификатора, установленного для приложения Firebase ( bar ). | Ни один из вариантов не может быть реализован. You can still differentiate data from each app within the single table by using the app's |
* If the identifier in your app's binary matched one of the identifiers set for a Firebase App, then the new export infrastructure won't create a new table for that identifier. Instead, it will continue writing data for that specific app to it. All other apps will be written to new tables.
** If one of the identifiers in your app's binary matched the identifier set for the Firebase App, then the new export infrastructure won't create a new table. Instead, it will maintain that table and start writing data for all apps to it.
Options to avoid disruption
To avoid any disruptions, follow the instructions for one of the options described below before you manually upgrade or before September 15, 2025.
OPTION 1 :
Use the new table created by the new export infrastructure. You'll copy data from your existing table to the new table.In the Firebase console, upgrade to the new export infrastructure by turning export off and then on again for the linked app.
This action creates a new batch table with a name that's based on the bundle ID or package name set for your registered Firebase App in your Firebase project .
In the Google Cloud console, copy all the data from your legacy table to the new table that was just created.
If you have any downstream dependencies that depend on your batch table, change them to use the new table.
OPTION 2 :
Continue writing to your existing table. You'll override some defaults in a BigQuery config to achieve this.In the Firebase console, find and take note of the Firebase App ID (for example,
1:1234567890:ios:321abc456def7890
) of the app with the mismatched batch table name and identifier:
Go to your Project settings , then scroll to the Your apps card to see all your Firebase Apps and their information.In the Firebase console, upgrade to the new export infrastructure by turning export off and then on again for the linked app.
This action does two things:
Creates a new batch table with a name that's based on the bundle ID or package name set for your registered Firebase App in your Firebase project . (You'll eventually delete this table, but do not delete it yet.)
Creates a BigQuery "data transfer config" with the source
Firebase Crashlytics with Multi-Region Support
.
In the Google Cloud console, change the new "data transfer config" so that data will continue to write to your existing table:
Go to BigQuery > Data transfers to view your "data transfer config".
Select the config that has the source
Firebase Crashlytics with Multi-Region Support
.Click Edit in the top-right corner.
In the Data source details section, find a list for gmp_app_id and a list for client_namespace .
In BigQuery , the Firebase App ID is called the
gmp_app_id
. By default, theclient_namespace
value in BigQuery is the corresponding unique bundle ID / package name of the app, but you'll be overriding this default configuration.BigQuery uses the
client_namespace
value for the name of the batch table that each linked Firebase App writes to.Find the gmp_app_id of the Firebase App for which you want to override default settings. Change its client_namespace value to the name of the table you want the Firebase App to write to instead (usually this is the name of the legacy table the app was writing to with the legacy export infrastructure).
Save the config change.
Schedule a backfill for the days that your existing table is missing data.
Once the backfill is done, delete the new table that was automatically created by the new export infrastructure.