Exporter les données de surveillance des performances vers BigQuery

Vous pouvez exporter les données Performance Monitoring des applications Apple et Android vers BigQuery pour une analyse plus approfondie. BigQuery vous permet d'analyser les données à l'aide de BigQuery SQL, de les exporter vers un autre fournisseur de services cloud et même de les utiliser pour vos modèles de ML personnalisés.

Activer l'exportation BigQuery

1. Accédez à la page Intégrations de la console Firebase, puis cliquez sur Associer dans la fiche BigQuery.

2. Suivez les instructions à l'écran pour activer BigQuery.

   Lorsque vous activez l'exportation BigQuery pour Performance Monitoring, les événements suivants se produisent :

   • Firebase exporte une copie de vos données existantes vers BigQuery. La propagation initiale des données à exporter peut prendre jusqu'à 48 heures.

     • Vous pouvez planifier manuellement des remplissages de données pour les 30 derniers jours ou pour la date la plus récente à laquelle vous avez activé l'exportation BigQuery (selon la date la plus récente).

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

   • Firebase configure des synchronisations régulières de vos données entre votre projet Firebase et BigQuery. Ces opérations d'exportation quotidiennes se terminent généralement dans les 24 heures suivant leur planification.

   • Par défaut, toutes les applications de votre projet sont associées à BigQuery. Toutes les applications que vous ajouterez ultérieurement au projet seront automatiquement associées à BigQuery. Vous pouvez gérer les applications qui envoient des données.

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

Quelles données sont exportées vers BigQuery ?

Pour chaque application du projet, l'exportation crée une table qui inclut tous les événements de performances capturés. Chaque ligne du tableau correspond à un événement de performances unique, qui peut être l'un des suivants :

• Trace de durée : traces qui collectent, par défaut, la métrique "durée", qui inclut le démarrage de l'application, l'application au premier plan et l'application en arrière-plan, ainsi que toutes les traces de code personnalisé instrumentées par le développeur.

  • event_type : DURATION_TRACE
  • event_name est identique au nom de la trace.

• Métrique de trace : métriques personnalisées associées à des traces de code personnalisées instrumentées par le développeur.

  • event_type : TRACE_METRIC
  • event_name est le nom de la métrique.
  • parent_trace_name est le nom de la trace qui contient cette métrique.

• Trace d'écran : traces couvrant la durée de vie d'un écran (traces de rendu d'écran)

  • event_type : SCREEN_TRACE
  • event_name est le préfixe _st_ suivi du nom réel de l'écran.

• Requête réseau : traces couvrant la durée de vie d'une requête réseau (traces de requête réseau HTTP)

  • event_type : NETWORK_REQUEST
  • event_name est le modèle catégorisé de l'URL de la requête réseau.

Chaque événement de performances contient des attributs de l'événement (tels que le pays et l'opérateur de l'appareil client), ainsi que des informations spécifiques à l'événement :

• Les traces de durée, les métriques de trace et les traces d'écran contiennent trace_info
• Les métriques de trace contiennent trace_info.metric_info
• Les traces d'écran contiennent trace_info.screen_info
• Les traces réseau contiennent network_info

Schéma de données détaillé

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

Les sections suivantes fournissent des exemples de requêtes que vous pouvez exécuter dans BigQuery sur vos données Performance Monitoring exportées.

Faire correspondre les données affichées dans la console

Le tableau de bord Firebase regroupe les données quotidiennes dans le fuseau horaire America/Los_Angeles. Pour correspondre à ce qui a été vu dans la console, les fonctions de date doivent définir explicitement America/Los_Angeles comme fuseau horaire. Sinon, la fonction de date utilisera par défaut le fuseau horaire UTC.

SELECT
  DATE(event_timestamp, 'America/Los_Angeles') AS daily_date,
  APPROX_QUANTILES(trace_info.duration_us, 100)[OFFSET(90)] / 1000000 AS p90_seconds,
FROM `TABLE_NAME`
WHERE
  DATE(event_timestamp, 'America/Los_Angeles')
    >= DATE_SUB( PARSE_DATE('%Y%m%d', 'YYYY-MM-DD'), INTERVAL 7 DAY)
  AND DATE(event_timestamp, 'America/Los_Angeles')
    <= PARSE_DATE('%Y%m%d', 'YYYY-MM-DD')
  AND event_name = '_app_start'
GROUP BY 1
ORDER BY 1 DESC;

Afficher la répartition de la latence moyenne au démarrage de l'application par pays

SELECT AVG(trace_info.duration_us), country
FROM `TABLE_NAME`
WHERE _PARTITIONTIME > TIMESTAMP("YYYY-MM-DD")
AND event_type = "DURATION_TRACE"
AND event_name = "_app_start"
GROUP BY 2;

Vérifier le ratio d'images figées par rapport à différentes conditions

Par exemple, vous pouvez vérifier le ratio d'images figées ainsi que le temps que les utilisateurs passent sur chaque écran de votre application lorsqu'ils utilisent différents types de réseaux (Wi-Fi, 4G, etc.).

SELECT
  AVG(trace_info.duration_us / 1000000) AS seconds_on_screen,
  AVG(trace_info.screen_info.frozen_frame_ratio) AS frozen_frame_ratio,
  event_name,
  radio_type
FROM `TABLE_NAME`
WHERE _PARTITIONTIME > TIMESTAMP("YYYY-MM-DD")
AND event_type = "SCREEN_TRACE"
GROUP BY event_name, radio_type
ORDER BY event_name, radio_type;

Calculer le taux de succès de cache pour le chargement de certains types de fichiers à partir du disque

Cette analyse suppose que vous avez instrumenté une trace de code personnalisée pour le chargement à partir du disque avec un attribut personnalisé nommé file-extension et une métrique personnalisée (un TRACE_METRIC) nommée cache-hit, qui est définie sur 1 en cas de succès de cache et sur 0 en cas d'échec de cache.

Par exemple, vous pouvez calculer le taux de succès de cache pour le chargement de fichiers PNG à partir du disque :

SELECT AVG(trace_info.metric_info.metric_value) AS cache_hit_rate
FROM `TABLE_NAME`
WHERE _PARTITIONTIME > TIMESTAMP("YYYY-MM-DD")
AND event_type = "TRACE_METRIC"
AND event_name = "cache-hit"
AND parent_trace_name = "loadFromDisk"
AND STRUCT("file-extension", "png") IN UNNEST(custom_attributes);

Vérifier l'heure à laquelle les utilisateurs envoient des requêtes réseau

Par exemple, vous pouvez vérifier à quelle heure de la journée les utilisateurs des États-Unis envoient des requêtes réseau depuis votre application :

SELECT
  count(1) AS hourly_count,
  EXTRACT(HOUR FROM event_timestamp) AS hour_of_day
FROM `TABLE_NAME`
WHERE _PARTITIONTIME > TIMESTAMP("YYYY-MM-DD")
AND event_type = "NETWORK_REQUEST"
AND country = "US"
GROUP BY 2 ORDER BY 2;

Emportez vos données Performance Monitoring partout avec vous

Vous pouvez parfois vouloir accéder à vos données Performance Monitoring côté serveur ou les transférer vers une autre solution tierce. L'exportation de données n'entraîne actuellement aucuns frais.

Vous pouvez exporter vos données de plusieurs façons :

• Utiliser l'UI Web BigQuery

• Exécuter la commande CLI bq extract

• En envoyant un job d'extraction via l'API ou les bibliothèques clientes

Tarifs

L'exportation de données depuis Performance Monitoring n'entraîne aucuns frais, et BigQuery offre des limites d'utilisation généreuses sans frais. Pour en savoir plus, consultez la page Tarifs de BigQuery ou le bac à sable BigQuery.