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 à Page Intégrations.
  2. Dans la fiche BigQuery, cliquez sur Associer.
  3. Suivez les instructions à l'écran pour activer l'exportation vers BigQuery.

Voici ce qui se passe lorsque vous activez l'exportation vers BigQuery:

Pour désactiver l'exportation vers BigQuery, procédez comme suit : dissocier votre projet dans la console Firebase.

Quelles données sont exportées vers BigQuery ?

Les données Firebase Crashlytics sont exportées dans 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 aussi diffusées en temps réel à 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 ANR.

Exportation en flux continu de Crashlytics vers BigQuery

Vous pouvez diffuser vos données Crashlytics en temps réel avec Streaming BigQuery. Vous pouvez l'utiliser à toute fin qui nécessite des données en direct, par exemple pour présenter des informations dans un tableau de bord en direct, suivre un déploiement en direct, surveiller les problèmes d'application déclenchant 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 dont vous devez tenir compte entre les tables:

Table par 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.
  • Aucun remplissage n'est disponible.

Le tableau par 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 tableaux peuvent être associée à une requête d'assemblage pour obtenir les 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 la modifier, consultez Définir le délai d'expiration de la partition dans la documentation BigQuery.

Activer l'exportation en flux continu de 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 la diffusion en 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 de plantage brutes, y compris le type d'appareil, le système d'exploitation, les exceptions (applications Android) ou les erreurs (applications Apple), et les journaux Crashlytics et d'autres données.

Examiner précisément les données Crashlytics exportées et leur table schéma plus loin sur cette page.

Utiliser un modèle Data Studio

Pour activer les données en temps réel dans votre modèle Data Studio, suivez les les instructions fournies dans Visualiser des 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 corrigé le plus de bugs possible, vous pensez que votre équipe prêt à lancer votre nouvelle application de partage de photos. Avant cela, vous devez vérifier le nombre de plantages par jour au cours du dernier mois, pour être sûr que votre bug-bash stable au fil du temps.

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: Identifier les plantages les plus répandus

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 c'est aussi spécifiques aux 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 bas de la vous écrivez une requête qui récupère tous les événements de plantage pour ces utilisateurs, à l'aide de 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 du "Identifier les plantages les plus fréquents" exemple ci-dessus pour identifier l'ID du problème de plantage spécifique. Votre équipe souhaite maintenant réaliser pour extraire la liste des utilisateurs de l'application affecté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. Toi ont pu utiliser la requête "Identifier les plantages les plus fréquents" exemple ci-dessus pour identifier l'ID du 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. Activer 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 du bundle et IOS (au lieu du nom du package et 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: Les cinq principaux problèmes du jour

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 problèmes principaux depuis le DATE, aujourd'hui inclus

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. event_id étant une adresse principale vous pouvez utiliser DISTINCT event_id pour dédupliquer les événements courants des deux tableaux.

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.

Ensuite, jusqu'à ce que vous désactiviez l'exportation, Firebase exporte Crashlytics événements par jour. 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 Crashlytics. données. 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 avec le nom de package com.google.test se trouverait dans une table nommée com_google_test_ANDROID, et "realtime data" (si cette option est activée) se trouve 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

Les colonnes d'une table sont identiques pour les plantages, les erreurs non fatales et les ANR. Si L'exportation en flux continu de Crashlytics vers BigQuery est activée, alors le 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'elle est enregistrée dans le projet Firebase (valeurs valides: IOS ou ANDROID)
bundle_identifier STRING Identifiant unique de l'application tel qu'enregistré 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 Plantage de l'application
error_type STRING Type d'erreur de l'événement (par exemple, FATAL, NON_FATAL, ANR, etc.)
issue_id STRING Le 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 Le 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 de stockage restants
operating_system ENREGISTREMENT Informations sur l'OS de l'appareil
operating_system.display_version STRING Version de l'OS de l'appareil
operating_system.name STRING Nom de l'OS 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'appareils"
application ENREGISTREMENT Application qui a 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 ID 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 Le message journalisé
breadcrumbs ENREGISTREMENT RÉPÉTÉ Horodatage Google Analytics fil d'Ariane, si la fonctionnalité 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 Une clé de paramètre associée au fil d'Ariane
breadcrumbs.params.value STRING Une valeur de paramètre associée au fil d'Ariane
blame_frame ENREGISTREMENT La trame identifiée comme étant la cause première du plantage ou de l'erreur
blame_frame.line INT64 Numéro de ligne du fichier du cadre
blame_frame.file STRING Le nom du fichier de cadre
blame_frame.symbol STRING Symbole d'hydraté, ou symbole brut s'il est non hydraté
blame_frame.offset INT64 Décalage des octets 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 cadre
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 Vrai pour toutes les exceptions sauf la dernière (c'est-à-dire le premier 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 frames associés à l'exception
exceptions.frames.line INT64 Numéro de ligne du fichier du cadre
exceptions.frames.file STRING Le nom du fichier de cadre
exceptions.frames.symbol STRING Symbole d'hydraté, ou symbole brut s'il est non hydraté
exceptions.frames.offset INT64 Décalage des octets 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 cadre
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 cadre
error.frames.file STRING Le nom du fichier de cadre
error.frames.symbol STRING Symbole d'hydraté, ou symbole brut s'il est non hydraté
error.frames.offset INT64 Décalage des octets 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 cadre
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 était exécuté
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 ayant entraîné le plantage de l'application uniquement présent en cas de plantage threads natifs
threads.crash_address INT64 Adresse du signal ayant entraîné le plantage de l'application. uniquement présent sur les threads natifs qui ont planté
threads.code INT64 (Applications Apple uniquement) Code d'erreur du journal personnalisé de l'application NSError
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 cadre
threads.frames.file STRING Le nom du fichier de cadre
threads.frames.symbol STRING Symbole d'hydratation, ou symbole brut s'il est non hydratant
threads.frames.offset INT64 Décalage des octets 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 cadre
threads.frames.owner STRING Par exemple, DEVELOPER, VENDOR, RUNTIME, PLATFORM ou SYSTEM
threads.frames.blamed BOOLÉEN Indique si Crashlytics a déterminé que cette trame est la cause de la 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 Le 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 La version du périphérique graphique
unity_metadata.graphics_device_type STRING Le type de périphérique graphique
unity_metadata.graphics_shader_level INT64 Niveau du nuanceur des graphiques
unity_metadata.graphics_render_target_count INT64 Le 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 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 Crashlytics ensembles de données dans BigQuery en rapports plus faciles à plus faciles à partager et entièrement personnalisables.

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

Utilisez 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 en flux continu Crashlytics à BigQuery, vous pouvez consulter ces données dans les tendances en temps réel du modèle Data Studio.Vous pouvez utiliser l'exemple comme modèle pour Créez des rapports et des visualisations basés sur les données de plantage brutes de votre propre application:

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

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

  3. Dans le menu déroulant Nouvelle source de données, sélectionnez Créer une source de données.

  4. Cliquez sur Sélectionner sur 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 le rapport pour créer votre copie du Crashlytics. Modèle de tableau de bord Data Studio.