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

  1. Dans la console Firebase, accédez à la page Intégrations.

  2. Sur la fiche BigQuery, cliquez sur Associer.

  3. 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.

  • 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 a lieu 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 pendant 30 jours maximum*. 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 en arrière-plan, consultez Passer à la nouvelle infrastructure d'exportation.

Activer l'exportation en streaming Crashlytics vers BigQuery

  1. Dans la console Firebase, accédez à la page Intégrations.

  2. Sur la fiche BigQuery, cliquez sur Gérer.

  3. 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 le schéma de la 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 l'adorent, mais trois d'entre eux 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:

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

  2. 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");

  3. É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 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 Nombre d'octets de stockage utilisés
storage.free INT64 Octets d'espace de stockage 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 (Facultatif) Nom de l'utilisateur
user.email STRING (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:

  1. Ouvrez le modèle de tableau de bord Data Studio Crashlytics.

  2. Cliquez sur Utiliser le modèle dans l'angle supérieur droit.

  3. Dans la liste déroulante Nouvelle source de données, sélectionnez Créer une source de données.

  4. Cliquez sur Sélectionner dans la fiche BigQuery.

  5. 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.

  6. Sous Configuration, définissez le champ Niveau du modèle Crashlytics sur Par défaut.

  7. Cliquez sur Associer pour créer la source de données.

  8. Cliquez sur Ajouter au rapport pour revenir au modèle Crashlytics.

  9. 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:

  1. Dans la console Firebase, accédez à vos Paramètres du projet .

  2. 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:

  1. Dans la console Firebase, accédez à la page Intégrations.

  2. Sur la fiche BigQuery, cliquez sur Gérer.

  3. 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.

  4. 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.