在 2024 年演示日活动中，观看有关如何使用 Firebase 构建和运行 AI 赋能应用的演示。立即观看。

Cette page a été traduite par l'API Cloud Translation.

Exporter des données Firebase Crashlytics vers BigQuery

Vous pouvez exporter vos données Firebase Crashlytics vers BigQuery pour une analyse plus approfondie. BigQuery vous permet d'analyser les données à l'aide de SQL BigQuery, de les exporter vers un autre fournisseur de services cloud et de les utiliser pour la visualisation et les tableaux de bord personnalisés avec Google Data Studio.

Activer l'exportation vers BigQuery

Dans la console Firebase, accédez à la page Intégrations.
Sur la fiche BigQuery, cliquez sur Associer.
Suivez les instructions à l'écran pour activer l'exportation vers BigQuery.

Si vous souhaitez accéder à vos données Crashlytics en quasi temps réel dans BigQuery, envisagez de passer à l'exportation en streaming.

Que se passe-t-il lorsque vous activez l'exportation ?

Vous sélectionnez l'emplacement de l'ensemble de données. Une fois l'ensemble de données créé, son emplacement ne peut plus être modifié, mais vous pouvez le copier dans un autre emplacement ou le déplacer manuellement (recréer) dans un autre emplacement. Pour en savoir plus, consultez Modifier l'emplacement des exportations existantes.

Cet emplacement ne s'applique qu'aux données exportées vers BigQuery et n'a aucune incidence sur l'emplacement des données stockées pour être utilisées dans le tableau de bord Crashlytics de la console Firebase ou dans Android Studio.

Remarque :La possibilité de sélectionner et de modifier l'emplacement d'exportation des données n'est disponible que si vous avez activé l'exportation après la mi-octobre 2024 ou si vous passez à la nouvelle infrastructure d'exportation.
Par défaut, toutes les applications de votre projet sont associées à BigQuery. Si vous en ajoutez d'autres ensuite, elles seront également automatiquement associées à BigQuery. Vous pouvez gérer les applications qui envoient des données.
Firebase configure la synchronisation quotidienne de vos données avec BigQuery.
- Une fois que vous avez associé votre projet, vous devez généralement attendre la synchronisation du jour suivant pour que votre premier ensemble de données soit exporté vers BigQuery.
- La synchronisation quotidienne est effectuée une fois par jour, quelle que soit l'exportation planifiée que vous avez peut-être configurée dans BigQuery. Notez que le calendrier et la durée de la tâche de synchronisation peuvent changer. Nous vous recommandons donc de ne pas planifier d'opérations ou de tâches en aval en fonction d'un calendrier spécifique d'exportation.
Firebase exporte une copie de vos données existantes vers BigQuery. La propagation initiale des données à exporter peut prendre jusqu'à 48 heures.
- Pour chaque application associée, cette exportation inclut un tableau de lot contenant les données de la synchronisation quotidienne.
- Vous pouvez planifier manuellement le remplissage des données pour le tableau par lot jusqu'aux 30 derniers jours ou jusqu'à la date la plus récente à laquelle vous avez activé l'exportation vers BigQuery (selon la date la plus récente).
Notez que si vous avez activé l'exportation des données Crashlytics avant la mi-octobre 2024, vous pouvez également effectuer un remplissage rétroactif 30 jours avant le jour où vous avez activé l'exportation.
Si vous activez l'exportation en flux continu Crashlytics vers BigQuery, toutes les applications associées disposeront également d'un tableau en temps réel contenant des données en constante évolution.

Pour désactiver l'exportation vers BigQuery, dissociez votre projet dans la console Firebase.

Quelles données sont exportées vers BigQuery ?

Les données Firebase Crashlytics sont exportées vers un ensemble de données BigQuery nommé firebase_crashlytics. Par défaut, des tables individuelles sont créées dans l'ensemble de données Crashlytics pour chaque application de votre projet. Firebase nomme les tables d'après l'identifiant de l'application, en remplaçant les points par des traits de soulignement et en ajoutant un nom de plate-forme à la fin.

Par exemple, les données d'une application Android dont le nom de package est com.google.test se trouvent dans une table nommée com_google_test_ANDROID. Cette table de lot est mise à jour une fois par jour. Si vous activez l'exportation en flux continu Crashlytics vers BigQuery, les données Crashlytics seront également diffusées en temps réel vers une table nommée com_google_test_ANDROID_REALTIME.

Chaque ligne d'un tableau représente un événement qui s'est produit dans l'application, y compris les plantages, les erreurs non fatales et les erreurs ANR.

Exportation en flux continu Crashlytics vers BigQuery

Vous pouvez diffuser vos données Crashlytics en temps réel avec la diffusion BigQuery. Vous pouvez l'utiliser à toutes fins nécessitant des données en direct, par exemple pour présenter des informations dans un tableau de bord en direct, regarder un déploiement en direct ou surveiller les problèmes d'application qui déclenchent des alertes et des workflows personnalisés.

Lorsque vous activez l'exportation en streaming Crashlytics vers BigQuery, en plus de la table par lot, vous disposez également d'une table en temps réel. Voici les différences à prendre en compte entre les tableaux:

Tableau de lot	Tableau en temps réel
Les données sont exportées une fois par jour. Les événements sont stockés de manière durable avant l'écriture par lot dans BigQuery. Les données peuvent être remplies jusqu'à 30 jours avant*.	Les données sont exportées en temps réel. Aucune mise à jour n'est disponible.

Le tableau de lot est idéal pour l'analyse à long terme et l'identification des tendances au fil du temps, car nous stockons de manière durable les événements avant de les écrire, et ils peuvent être renseignés dans le tableau jusqu'à 30 jours*. Lorsque nous écrivons des données dans votre table en temps réel, nous les écrivons immédiatement dans BigQuery. Il est donc idéal pour les tableaux de bord en direct et les alertes personnalisées. Ces deux tables peuvent être combinées à une requête de couture pour profiter des avantages des deux.

Par défaut, la table en temps réel a un délai d'expiration de partition de 30 jours. Pour savoir comment modifier ce paramètre, consultez la section Définir l'expiration de la partition dans la documentation BigQuery.

^{* Pour en savoir plus sur la prise en charge du remplissage, consultez Passer à la nouvelle infrastructure d'exportation.}

Activer l'exportation en streaming Crashlytics vers BigQuery

Dans la console Firebase, accédez à la page Intégrations.
Sur la fiche BigQuery, cliquez sur Gérer.
Cochez la case Inclure le streaming.

Cette action active le streaming pour toutes vos applications associées.

Que pouvez-vous faire avec les données exportées ?

Les exportations vers BigQuery contiennent des données brutes sur les plantages, y compris le type d'appareil, le système d'exploitation, les exceptions (applications Android) ou les erreurs (applications Apple), ainsi que les journaux Crashlytics et d'autres données.

Consultez plus loin sur cette page les données Crashlytics exportées et leur schéma de table.

Utiliser un modèle Data Studio

Pour activer les données en temps réel dans votre modèle Data Studio, suivez les instructions de la section Visualiser les données Crashlytics exportées avec Data Studio.

Créer des vues

Vous pouvez transformer des requêtes en vues à l'aide de l'interface utilisateur BigQuery. Pour obtenir des instructions détaillées, consultez la section Créer des vues dans la documentation BigQuery.

Exécuter des requêtes

Les exemples suivants illustrent les requêtes que vous pouvez exécuter sur vos données Crashlytics pour générer des rapports qui agrègent les données d'événement de plantage sous une forme synthétique plus facilement exploitable. Étant donné que ces types de rapports ne sont pas disponibles dans le tableau de bord Crashlytics de la console Firebase, ils peuvent compléter votre analyse et votre compréhension des données de plantage.

Exemple 1: Accidents par jour

Après avoir travaillé pour corriger autant de bugs que possible, vous pensez que votre équipe est enfin prête à lancer votre nouvelle application de partage de photos. Avant de le faire, vous souhaitez vérifier le nombre de plantages par jour au cours du mois écoulé afin de vous assurer que vos actions de débogage ont progressivement réussi à stabiliser l'application.

Voici un exemple de requête pour une application Android. Pour une application iOS, utilisez son ID de bundle et IOS (au lieu du nom du package et de 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;

Exemple 2: Trouver les plantages les plus courants

Pour hiérarchiser correctement les plans de production, vous souhaitez identifier les 10 plantages les plus courants dans votre application. Vous créez une requête qui fournit les points de données pertinents.

Voici un exemple de requête pour une application Android. Pour une application iOS, utilisez son ID de bundle et IOS (au lieu du nom du package et de 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;

Exemple 3: Top 10 des appareils qui plantent

L'automne est la saison idéale pour changer de téléphone ! Votre entreprise sait que cette saison annonce également une foule de problèmes inédits liés à tous ces nouveaux appareils, en particulier pour Android. Pour anticiper les problèmes de compatibilité à venir, vous avez mis en place une requête qui identifie les 10 appareils ayant subi le plus de plantages au cours de la semaine écoulée (168 heures).

Voici un exemple de requête pour une application Android. Pour une application iOS, utilisez son ID de bundle et IOS (au lieu du nom du package et de 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;

Exemple 4: Filtrer par clé personnalisée

Vous êtes développeur de jeux vidéo et vous souhaitez savoir quel niveau de votre jeu connaît le plus de plantages.

Pour suivre cette statistique, vous devez définir une clé Crashlytics personnalisée appelée current_level et la mettre à jour chaque fois que l'utilisateur atteint un nouveau niveau.

Swift

Crashlytics.sharedInstance().setIntValue(3, forKey: "current_level");

Objective-C

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Java

Crashlytics.setInt("current_level", 3);

Une fois cette clé incluse dans votre exportation vers BigQuery, vous pouvez rédiger une requête pour indiquer la distribution des valeurs current_level associées à chaque événement de plantage.

Voici un exemple de requête pour une application Android. Pour une application iOS, utilisez son ID de bundle et IOS (au lieu du nom du package et de 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

Exemple 5: Extraction de l'ID utilisateur

Vous disposez d'une application Android en accès anticipé. La plupart de vos utilisateurs adorent cette application, mais trois ont subi un nombre inhabituel de plantages. Pour aller au fond du problème, vous rédigez une requête qui extrait tous les événements de plantage qu'ont connu ces utilisateurs en s'appuyant sur leurs ID utilisateur.

Voici un exemple de requête pour une application Android. Pour une application iOS, utilisez son ID de bundle et IOS (au lieu du nom du package et de 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

Exemple 6: Rechercher tous les utilisateurs confrontés à un problème de plantage spécifique

Votre équipe a accidentellement publié un bug critique auprès d'un groupe de testeurs bêta. Votre équipe a pu utiliser la requête de l'exemple "Trouver les plantages les plus courants" ci-dessus pour identifier l'ID de problème de plantage spécifique. Votre équipe souhaite maintenant exécuter une requête pour extraire la liste des utilisateurs de l'application concernés par ce plantage.

Voici un exemple de requête pour une application Android. Pour une application iOS, utilisez son ID de bundle et IOS (au lieu du nom du package et de 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;

Exemple 7: Nombre d'utilisateurs concernés par un problème de plantage, par pays

Votre équipe a détecté un bug critique lors du déploiement d'une nouvelle version. Vous avez pu utiliser la requête de l'exemple "Trouver les plantages les plus courants" ci-dessus pour identifier l'ID de problème de plantage spécifique. Votre équipe souhaite maintenant savoir si ce plantage s'est propagé aux utilisateurs de différents pays à travers le monde.

Pour écrire cette requête, votre équipe doit procéder comme suit:

Activez l'exportation des données Google Analytics vers BigQuery. Consultez Exporter les données du projet vers BigQuery.

Mettez à jour votre application pour transmettre un ID utilisateur au SDK Google Analytics et au SDK Crashlytics.

Swift

Crashlytics.sharedInstance().setUserIdentifier("123456789");
Analytics.setUserID("123456789");

Objective-C

CrashlyticsKit setUserIdentifier:@"123456789";
FIRAnalytics setUserID:@"12345678 9";

Java

Crashlytics.setUserIdentifier("123456789");
mFirebaseAnalytics.setUserId("123456789");

Écrivez une requête qui utilise le champ d'ID utilisateur pour joindre les événements de l'ensemble de données Google Analytics aux plantages de l'ensemble de données Crashlytics.

Voici un exemple de requête pour une application Android. Pour une application iOS, utilisez son ID de bundle et IOS (au lieu du nom du package et de 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

Exemple 8: Top 5 des problèmes jusqu'à présent

Voici un exemple de requête pour une application Android. Pour une application iOS, utilisez son ID de bundle et IOS (au lieu du nom du package et de 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;

Exemple 9: 5 principaux problèmes depuis DATE, y compris aujourd'hui

Vous pouvez également combiner les tables par lot et en temps réel avec une requête de couture pour ajouter des informations en temps réel aux données par lot fiables. Étant donné que event_id est une clé primaire, vous pouvez utiliser DISTINCT event_id pour dédupliquer les événements communs des deux tables.

Voici un exemple de requête pour une application Android. Pour une application iOS, utilisez son ID de bundle et IOS (au lieu du nom du package et de 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;

Comprendre le schéma Crashlytics dans BigQuery

Lorsque vous configurez l'exportation des données Crashlytics vers BigQuery, Firebase exporte les événements récents (plantages, erreurs non fatales et erreurs ANR), y compris les événements remontant jusqu'à deux jours avant l'association, avec la possibilité de remplir jusqu'à 30 jours.

À partir de ce moment et jusqu'à ce que vous désactiviez l'exportation, Firebase exporte quotidiennement les événements Crashlytics. Plusieurs minutes peuvent être nécessaires pour que les données soient disponibles dans BigQuery après chaque exportation.

Ensembles de données

Crashlytics crée un ensemble de données dans BigQuery pour les données Crashlytics. Cet ensemble de données couvre la totalité de votre projet, même si celui-ci comporte plusieurs applications.

Tables

Crashlytics crée une table distincte dans l'ensemble de données pour chacune des applications de votre projet, à l'exception de celles pour lesquelles vous avez désactivé les exportations de données. Firebase nomme les tables d'après l'identifiant de l'application, en remplaçant les points par des traits de soulignement et en ajoutant un nom de plate-forme à la fin.

Par exemple, les données d'une application Android dont le nom de package est com.google.test se trouvent dans une table nommée com_google_test_ANDROID, et les données en temps réel (si elles sont activées) se trouvent dans une table nommée com_google_test_ANDROID_REALTIME.

Les tables contiennent un ensemble standard de données Crashlytics en plus de toutes les clés Crashlytics personnalisées que vous avez définies dans votre application.

Lignes

Chaque ligne d'une table représente une erreur rencontrée par l'application.

Colonnes

La table comprend les mêmes colonnes pour les plantages, les erreurs non fatales et les erreurs ANR. Si l'exportation en streaming Crashlytics vers BigQuery est activée, la table en temps réel aura les mêmes colonnes que la table par lot. Notez que des colonnes de lignes peuvent représenter des événements qui ne comportent pas de traces de pile.

Les colonnes incluses dans l'exportation sont répertoriées dans ce tableau:

Nom du champ	Type de données	Description
`platform`	STRING	Plate-forme de l'application telle qu'enregistrée dans le projet Firebase (valeurs valides: `IOS` ou `ANDROID`)
`bundle_identifier`	STRING	Identifiant unique de l'application enregistrée dans le projet Firebase (par exemple, `com.google.gmail`) Pour les applications de la plate-forme Apple, il s'agit de l'ID du bundle de l'application. Pour les applications Android, il s'agit du nom du package de l'application.
`event_id`	STRING	ID unique de l'événement
`is_fatal`	BOOLÉEN	Ce champ est obsolète. Utilisez plutôt `error_type`. Indique si l'application a planté
`error_type`	STRING	Type d'erreur de l'événement (par exemple, `FATAL`, `NON_FATAL`, `ANR`, etc.)
`issue_id`	STRING	Problème associé à l'événement
`variant_id`	STRING	Variante du problème associée à cet événement Notez que tous les événements n'ont pas de variante de problème associée.
`event_timestamp`	TIMESTAMP	Quand l'événement a eu lieu
`device`	ENREGISTREMENT	Appareil sur lequel l'événement s'est produit
`device.manufacturer`	STRING	Le fabricant de l'appareil
`device.model`	STRING	Modèle de l'appareil
`device.architecture`	STRING	Par exemple, `X86_32`, `X86_64`, `ARMV7`, `ARM64`, `ARMV7S` ou `ARMV7K`
`memory`	ENREGISTREMENT	État de la mémoire de l'appareil
`memory.used`	INT64	Octets de mémoire utilisés
`memory.free`	INT64	Octets de mémoire restants
`storage`	ENREGISTREMENT	Stockage persistant de l'appareil
`storage.used`	INT64	Octets de stockage utilisés
`storage.free`	INT64	Octets d'espace restant
`operating_system`	ENREGISTREMENT	Informations sur le système d'exploitation de l'appareil
`operating_system.display_version`	STRING	Version de l'OS sur l'appareil
`operating_system.name`	STRING	Nom du système d'exploitation de l'appareil
`operating_system.modification_state`	STRING	Indique si l'appareil a été modifié (par exemple, une application jailbreakée est `MODIFIED` et une application en mode root est `UNMODIFIED`)
`operating_system.type`	STRING	(Applications Apple uniquement) Type de système d'exploitation exécuté sur l'appareil (par exemple, `IOS`, `MACOS`, etc.)
`operating_system.device_type`	STRING	Type d'appareil (par exemple, `MOBILE`, `TABLET`, `TV`, etc.) ; également appelé "catégorie d'appareil"
`application`	ENREGISTREMENT	Application ayant généré l'événement
`application.build_version`	STRING	Version de compilation de l'application
`application.display_version`	STRING
`user`	ENREGISTREMENT	(Facultatif) Informations collectées sur l'utilisateur de l'application
`user.name`	STRING	Ce champ est obsolète. N'utilisez pas ce champ. (Facultatif) Nom de l'utilisateur
`user.email`	STRING	Ce champ est obsolète. N'utilisez pas ce champ. (Facultatif) Adresse e-mail de l'utilisateur
`user.id`	STRING	(Facultatif) ID spécifique à l'application associé à l'utilisateur
`custom_keys`	ENREGISTREMENT RÉPÉTÉ	Paires clé-valeur définies par le développeur
`custom_keys.key`	STRING	Une clé définie par le développeur
`custom_keys.value`	STRING	Valeur définie par le développeur
`installation_uuid`	STRING	Identifiant qui identifie une installation d'application et d'appareil unique
`crashlytics_sdk_versions`	STRING	Version du SDK Crashlytics ayant généré l'événement
`app_orientation`	STRING	Par exemple, `PORTRAIT`, `LANDSCAPE`, `FACE_UP`, `FACE_DOWN`, etc.
`device_orientation`	STRING	Par exemple, `PORTRAIT`, `LANDSCAPE`, `FACE_UP`, `FACE_DOWN`, etc.
`process_state`	STRING	`BACKGROUND` ou `FOREGROUND`
`logs`	ENREGISTREMENT RÉPÉTÉ	Messages de journal horodatés générés par le journalisateur Crashlytics, si activé
`logs.timestamp`	TIMESTAMP	Date et heure de création du journal
`logs.message`	STRING	Message consigné
`breadcrumbs`	ENREGISTREMENT RÉPÉTÉ	Fils d'Ariane Google Analytics avec code temporel, si cette option est activée
`breadcrumbs.timestamp`	TIMESTAMP	Code temporel associé au fil d'Ariane
`breadcrumbs.name`	STRING	Nom associé au fil d'Ariane
`breadcrumbs.params`	ENREGISTREMENT RÉPÉTÉ	Paramètres associés au fil d'Ariane
`breadcrumbs.params.key`	STRING	Clé de paramètre associée au fil d'Ariane
`breadcrumbs.params.value`	STRING	Valeur de paramètre associée au fil d'Ariane
`blame_frame`	ENREGISTREMENT	Frame identifié comme étant la cause du plantage ou de l'erreur
`blame_frame.line`	INT64	Numéro de ligne du fichier du frame
`blame_frame.file`	STRING	Nom du fichier de frame
`blame_frame.symbol`	STRING	Symbole hydraté ou symbole brut s'il ne peut pas être hydraté
`blame_frame.offset`	INT64	Décalage d'octet dans l'image binaire contenant le code Non défini pour les exceptions Java
`blame_frame.address`	INT64	Adresse dans l'image binaire contenant le code Non défini pour les frames Java
`blame_frame.library`	STRING	Nom à afficher de la bibliothèque qui inclut le frame
`blame_frame.owner`	STRING	Par exemple, `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM` ou `SYSTEM`
`blame_frame.blamed`	BOOLÉEN	Indique si Crashlytics a déterminé que ce frame est à l'origine du plantage ou de l'erreur
`exceptions`	ENREGISTREMENT RÉPÉTÉ	(Android uniquement) Exceptions survenues lors de cet événement. Les exceptions imbriquées sont présentées dans l'ordre chronologique inverse, ce qui signifie que le dernier enregistrement est la première exception générée.
`exceptions.type`	STRING	Type d'exception (par exemple, `java.lang.IllegalStateException)`
`exceptions.exception_message`	STRING	Message associé à l'exception
`exceptions.nested`	BOOLÉEN	"True" pour toutes les exceptions, sauf la dernière (c'est-à-dire la première enregistrement)
`exceptions.title`	STRING	Titre du fil de discussion
`exceptions.subtitle`	STRING	Sous-titre du fil de discussion
`exceptions.blamed`	BOOLÉEN	"True" si Crashlytics détermine que l'exception est responsable de l'erreur ou du plantage
`exceptions.frames`	ENREGISTREMENT RÉPÉTÉ	Les cadres associés à l'exception
`exceptions.frames.line`	INT64	Numéro de ligne du fichier du frame
`exceptions.frames.file`	STRING	Nom du fichier de frame
`exceptions.frames.symbol`	STRING	Symbole hydraté ou symbole brut s'il ne peut pas être hydraté
`exceptions.frames.offset`	INT64	Décalage d'octet dans l'image binaire contenant le code Non défini pour les exceptions Java
`exceptions.frames.address`	INT64	Adresse dans l'image binaire contenant le code Non défini pour les frames Java
`exceptions.frames.library`	STRING	Nom à afficher de la bibliothèque qui inclut le frame
`exceptions.frames.owner`	STRING	Par exemple, `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM` ou `SYSTEM`
`exceptions.frames.blamed`	BOOLÉEN	Indique si Crashlytics a déterminé que ce frame est à l'origine du plantage ou de l'erreur
`error`	ENREGISTREMENT RÉPÉTÉ	(Applications Apple uniquement) Erreurs non fatales
`error.queue_name`	STRING	File d'attente sur laquelle le thread s'exécutait
`error.code`	INT64	Code d'erreur associé à l'NSError enregistré de manière personnalisée par l'application
`error.title`	STRING	Titre du fil de discussion
`error.subtitle`	STRING	Sous-titre du fil de discussion
`error.blamed`	BOOLÉEN	Indique si Crashlytics a déterminé que ce frame est à l'origine de l'erreur
`error.frames`	ENREGISTREMENT RÉPÉTÉ	Les blocs de la trace de la pile
`error.frames.line`	INT64	Numéro de ligne du fichier du frame
`error.frames.file`	STRING	Nom du fichier de frame
`error.frames.symbol`	STRING	Symbole hydraté ou symbole brut s'il ne peut pas être hydraté
`error.frames.offset`	INT64	Décalage d'octet dans l'image binaire contenant le code
`error.frames.address`	INT64	Adresse dans l'image binaire contenant le code
`error.frames.library`	STRING	Nom à afficher de la bibliothèque qui inclut le frame
`error.frames.owner`	STRING	Par exemple, `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM` ou `SYSTEM`
`error.frames.blamed`	BOOLÉEN	Indique si Crashlytics a déterminé que ce frame est à l'origine de l'erreur
`threads`	ENREGISTREMENT RÉPÉTÉ	Threads présents au moment de l'événement
`threads.crashed`	BOOLÉEN	Indique si le thread a planté
`threads.thread_name`	STRING	Nom du fil de discussion
`threads.queue_name`	STRING	(Applications Apple uniquement) File d'attente sur laquelle le thread s'exécutait
`threads.signal_name`	STRING	Nom du signal à l'origine du plantage de l'application, uniquement présent sur les threads natifs plantés
`threads.signal_code`	STRING	Code du signal à l'origine du plantage de l'application. Uniquement présent sur les threads natifs en panne
`threads.crash_address`	INT64	Adresse du signal à l'origine du plantage de l'application. Présente uniquement sur les threads natifs plantés
`threads.code`	INT64	(Applications Apple uniquement) Code d'erreur de l'NSError enregistré de manière personnalisée par l'application
`threads.title`	STRING	Titre du fil de discussion
`threads.subtitle`	STRING	Sous-titre du fil de discussion
`threads.blamed`	BOOLÉEN	Indique si Crashlytics a déterminé que ce frame est à l'origine du plantage ou de l'erreur
`threads.frames`	ENREGISTREMENT RÉPÉTÉ	Les frames du thread
`threads.frames.line`	INT64	Numéro de ligne du fichier du frame
`threads.frames.file`	STRING	Nom du fichier de frame
`threads.frames.symbol`	STRING	Symbole hydraté ou symbole brut s'il n'est pas hydratable
`threads.frames.offset`	INT64	Décalage d'octet dans l'image binaire contenant le code
`threads.frames.address`	INT64	Adresse dans l'image binaire contenant le code
`threads.frames.library`	STRING	Nom à afficher de la bibliothèque qui inclut le frame
`threads.frames.owner`	STRING	Par exemple, `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM` ou `SYSTEM`
`threads.frames.blamed`	BOOLÉEN	Indique si Crashlytics a déterminé que ce frame est à l'origine de l'erreur
`unity_metadata.unity_version`	STRING	Version d'Unity exécutée sur cet appareil
`unity_metadata.debug_build`	BOOLÉEN	S'il s'agit d'un build de débogage
`unity_metadata.processor_type`	STRING	Type de processeur
`unity_metadata.processor_count`	INT64	Nombre de processeurs (cœurs)
`unity_metadata.processor_frequency_mhz`	INT64	Fréquence du ou des processeurs en MHz
`unity_metadata.system_memory_size_mb`	INT64	Taille de la mémoire du système en Mo
`unity_metadata.graphics_memory_size_mb`	INT64	Mémoire graphique (en Mo)
`unity_metadata.graphics_device_id`	INT64	Identifiant du périphérique graphique
`unity_metadata.graphics_device_vendor_id`	INT64	Identifiant du fournisseur du processeur graphique
`unity_metadata.graphics_device_name`	STRING	Nom du périphérique graphique
`unity_metadata.graphics_device_vendor`	STRING	Fournisseur du périphérique graphique
`unity_metadata.graphics_device_version`	STRING	Version du périphérique graphique
`unity_metadata.graphics_device_type`	STRING	Type du périphérique graphique
`unity_metadata.graphics_shader_level`	INT64	Niveau du nuanceur des graphiques
`unity_metadata.graphics_render_target_count`	INT64	Nombre de cibles de rendu graphique
`unity_metadata.graphics_copy_texture_support`	STRING	Prise en charge de la copie de la texture graphique telle que définie dans l'API Unity
`unity_metadata.graphics_max_texture_size`	INT64	Taille maximale dédiée au rendu de la texture
`unity_metadata.screen_size_px`	STRING	Taille de l'écran en pixels, au format largeur x hauteur
`unity_metadata.screen_resolution_dpi`	STRING	PPP de l'écran sous forme de nombre à virgule flottante
`unity_metadata.screen_refresh_rate_hz`	INT64	Fréquence d'actualisation de l'écran en Hz

Visualiser les données Crashlytics exportées avec Data Studio

Google Data Studio transforme vos ensembles de données Crashlytics dans BigQuery en rapports plus faciles à lire et à partager, et entièrement personnalisables.

Pour en savoir plus sur l'utilisation de Data Studio, consultez le guide de démarrage rapide intitulé Bienvenue dans Data Studio.

Utiliser un modèle de rapport Crashlytics

Data Studio propose un exemple de rapport pour Crashlytics qui comprend un ensemble complet de dimensions et de métriques issues du schéma BigQuery Crashlytics exporté. Si vous avez activé l'exportation de streaming Crashlytics vers BigQuery, vous pouvez afficher ces données sur la page Tendances en temps réel du modèle Data Studio.Vous pouvez utiliser cet exemple comme modèle pour créer rapidement des rapports et des visualisations basés sur les données de plantage brutes de votre propre application:

Ouvrez le modèle de tableau de bord Data Studio Crashlytics.
Cliquez sur Utiliser le modèle dans l'angle supérieur droit.
Dans la liste déroulante Nouvelle source de données, sélectionnez Créer une source de données.
Cliquez sur Sélectionner dans la fiche BigQuery.
Sélectionnez une table contenant des données Crashlytics exportées en accédant à Mes projets > PROJECT_ID > firebase_crashlytics > TABLE_NAME.

Vous pouvez toujours sélectionner votre table de lot. Si l'exportation en flux continu Crashlytics vers BigQuery est activée, vous pouvez sélectionner votre table en temps réel à la place.
Sous Configuration, définissez le champ Niveau du modèle Crashlytics sur Par défaut.
Cliquez sur Associer pour créer la source de données.
Cliquez sur Ajouter au rapport pour revenir au modèle Crashlytics.
Enfin, cliquez sur Créer un rapport pour créer votre copie du modèle de tableau de bord Data Studio Crashlytics.

Passer à la nouvelle infrastructure d'exportation

Mi-octobre 2024, Crashlytics a lancé une nouvelle infrastructure pour exporter les données Crashlytics vers BigQuery. Pour le moment, la migration vers cette nouvelle infrastructure est facultative.

Cette nouvelle infrastructure est compatible avec les emplacements d'ensembles de données Crashlytics en dehors des États-Unis.

Si vous avez activé l'exportation avant la mi-octobre 2024, vous pouvez désormais modifier l'emplacement de l'exportation des données vers n'importe quel emplacement d'ensemble de données compatible avec BigQuery.
Si vous avez activé l'exportation à la mi-octobre 2024 ou plus tard, vous pouvez sélectionner n'importe quel emplacement d'ensemble de données compatible avec BigQuery lors de la configuration.

Autre différence de la nouvelle infrastructure : elle n'est pas compatible avec le remplissage des données avant l'activation de l'exportation. (Avec l'ancienne infrastructure, vous pouviez effectuer un remplissage jusqu'à 30 jours avant la date d'activation.) La nouvelle infrastructure prend en charge les remplissages jusqu'aux 30 derniers jours ou à la date la plus récente à laquelle vous avez activé l'exportation vers BigQuery (selon la date la plus récente).

Conditions préalables à la mise à niveau

Avant de passer à la nouvelle infrastructure, vérifiez que vous remplissez la condition préalable suivante: vos tables BigQuery de lot actuelles disposent d'identifiants correspondant aux ID de bundle ou aux noms de package définis pour vos applications Firebase enregistrées.

Exemple :

Si vous disposez d'une table BigQuery nommée com_yourcompany_yourproject_IOS, vous devez disposer d'une application Firebase iOS+ enregistrée dans votre projet Firebase avec l'ID de bundle com.yourcompany.yourproject.
Si vous disposez d'une table BigQuery nommée com_yourcompany_yourproject_ANDROID, vous devez disposer d'une application Android Firebase enregistrée dans votre projet Firebase avec le nom de package com.yourcompany.yourproject.

Voici comment trouver toutes les applications Firebase enregistrées dans votre projet Firebase:

Dans la console Firebase, accédez à vos Paramètres du projet .
Faites défiler la page jusqu'à la fiche Vos applications, puis cliquez sur l'application Firebase souhaitée pour afficher ses informations, y compris son identifiant.

La nouvelle infrastructure d'exportation exportera les données de chaque application en fonction du nom du package ou de l'ID de bundle défini pour l'application Firebase enregistrée. Pour ne pas perturber votre workflow BigQuery, il est important de vous assurer que vos tables de lot actuelles portent déjà les noms appropriés afin que la nouvelle infrastructure puisse ajouter toutes les nouvelles données aux tables existantes. Si les noms de tables de lot ne correspondent pas à vos applications Firebase enregistrées, mais que vous souhaitez tout de même effectuer la mise à niveau, contactez l'assistance Firebase.

Mettre à niveau vers la nouvelle infrastructure

Si vous avez déjà activé l'exportation, vous pouvez passer à la nouvelle infrastructure en désactivant, puis en réactivant l'exportation de données Crashlytics dans la console Firebase.

Voici la procédure détaillée:

Dans la console Firebase, accédez à la page Intégrations.
Dans la fiche BigQuery, cliquez sur Gérer.
Désactivez le curseur Crashlytics pour désactiver l'exportation. Lorsque vous y êtes invité, confirmez que vous souhaitez arrêter l'exportation des données.
Réactivez immédiatement le curseur Crashlytics pour réactiver l'exportation. Lorsque vous y êtes invité, confirmez que vous souhaitez exporter les données.

L'exportation de vos données Crashlytics vers BigQuery utilise désormais la nouvelle infrastructure d'exportation.