Exporter les données de surveillance des performances vers BigQuery

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

Activer l'exportation BigQuery

1. Accédez à la page _Integrations_ (Intégrations) de la Firebase console, puis cliquez sur Link (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 jusqu'aux 30 derniers jours ou jusqu'à 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 d'un ensemble de données.

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

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

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 est 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 de "durée", qui incluent 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 est DURATION_TRACE
  • event_name est identique au nom de la trace

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

  • event_type est 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 est 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 est 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 détaillé des données

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

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

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

Le tableau de bord Firebase agrège les données quotidiennes dans le fuseau horaire America/Los_Angeles. Pour que les données correspondent à celles affichées 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 de 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 radio (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 réussite du cache pour le chargement de certains types de fichiers à partir du disque

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

Par exemple, vous pouvez calculer le taux de réussite du 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 émettent des requêtes réseau

Par exemple, vous pouvez vérifier à quelle heure les utilisateurs des États-Unis émettent 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;

Utiliser vos données Performance Monitoring où vous le souhaitez

Vous pouvez parfois 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 :

• À l'aide de l'interface utilisateur Web BigQuery

• En exécutant la commande CLI bq extract

• En envoyant une tâche extract 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 BigQuery Tarifs ou le BigQuery bac à sable.