Dépannage et questions fréquentes concernant Performance Monitoring

Afficher les messages de journal pour les événements de performances

1. Activez la journalisation du débogage comme suit :

   1. Dans Xcode (v26.2 minimum), sélectionnez Product > Scheme > Edit scheme (Produit > Schéma > Modifier le schéma).
   2. Sélectionnez Run (Exécuter) dans le menu de gauche, puis l'onglet Arguments.
   3. Dans la section Arguments Passed On Launch (Arguments transmis au lancement), ajoutez -FIRDebugEnabled.

2. Recherchez d'éventuels messages d'erreur dans vos messages de journal.

3. Performance Monitoring ajoute le tag Firebase/Performance à ses messages de journal afin que vous puissiez les filtrer.

4. Recherchez les types de journaux suivants, qui indiquent que Performance Monitoring consigne les événements de performances :

   • Logging trace metric: TRACE_NAME, FIREBASE_PERFORMANCE_CONSOLE_URL
   • Logging network request trace: URL

5. Cliquez sur l'URL pour afficher vos données dans la console Firebase. La mise à jour des données dans le tableau de bord peut prendre quelques instants.

Si votre application n'enregistre pas d'événements de performances, consultez les conseils de dépannage.

Le SDK a été ajouté à l'application, mais la console indique toujours qu'il faut l'ajouter

Firebase peut détecter si vous avez bien ajouté le SDK Performance Monitoring à votre application lorsqu'il reçoit des informations sur les événements (comme les interactions avec l'application) de votre application. En général, dans les 10 minutes suivant le démarrage de votre application, le tableau de bord Performances de la console Firebase affiche un message "SDK détecté". Ensuite, dans les 30 minutes, le tableau de bord affiche les données initiales traitées.

Si plus de 10 minutes se sont écoulées depuis que vous avez ajouté la dernière version du SDK à votre application et que vous ne voyez toujours aucun changement, vérifiez vos messages de journal pour vous assurer que Performance Monitoring consigne les événements. Essayez les étapes de dépannage appropriées, comme décrit ci-dessous, pour résoudre un message de détection de SDK retardée.

La console indique que le SDK est détecté, mais aucune donnée ne s'affiche

Performance Monitoring traite les données d'événement de performances avant de les afficher dans le tableau de bord Performances.

Si plus de 24 heures se sont écoulées depuis l'apparition du message "SDK détecté" et que vous ne voyez toujours pas de données, consultez le tableau de bord d'état de Firebase pour vérifier s'il y a une panne connue. Si aucune panne n'est signalée, contactez l'assistance Firebase.

L'application n'enregistre pas les événements de performances

Si vous ne voyez pas de messages de journal pour les événements de performances, essayez les étapes de dépannage suivantes :

1. Assurez-vous que le SDK Performance Monitoring n'est pas désactivé par l'un des indicateurs suivants dans votre fichier Info.plist :

   • firebase_performance_collection_enabled
   • firebase_performance_collection_deactivated

2. Assurez-vous que Performance Monitoring n'est pas désactivé au moment de l'exécution (Swift | Obj-C).

3. Si vous ne trouvez rien de désactivé dans votre application, contactez l'assistance Firebase.

Le Performance Dashboard ne contient pas de données de trace d'écran

Si des données sont manquantes pour les traces de rendu d'écran, essayez les étapes de dépannage suivantes :

1. Assurez-vous d'utiliser la dernière version du SDK pour les plates-formes Apple (v13.0.0). Les traces de rendu d'écran ne sont disponibles qu'avec la version 5.0.0 ou ultérieure.

2. Performance Monitoring ne crée pas de traces de rendu d'écran pour les contrôleurs de vue de conteneur (tels que UINavigationController et UITabBarController). Si les données ne sont manquantes que pour ces écrans, il s'agit d'un comportement attendu.

Le tableau de bord des performances ne contient pas de données de trace personnalisées

Vous voyez les données sur les performances pour les traces collectées automatiquement, mais pas pour les traces de code personnalisé ? Essayez les étapes de dépannage suivantes :

1. Vérifiez la configuration des traces de code personnalisées instrumentées via l'API Trace, en particulier les éléments suivants :

   • Les noms des traces de code personnalisé et des métriques personnalisées doivent respecter les exigences suivantes : pas d'espace blanc au début ni à la fin, pas de caractère de soulignement (_) au début et longueur maximale de 32 caractères.
   • Toutes les traces doivent être démarrées et arrêtées. Toute trace qui n'est pas démarrée, qui n'est pas arrêtée ou qui est arrêtée avant d'être démarrée ne sera pas consignée.

2. Vérifiez vos messages de journal pour vous assurer que Performance Monitoring consigne les traces de code personnalisé attendues.

3. Si Performance Monitoring consigne des événements, mais qu'aucune donnée ne s'affiche après 24 heures, contactez l'assistance Firebase.

Données de requête réseau manquantes dans le tableau de bord des performances

Si des données de requête réseau sont manquantes, suivez les étapes de dépannage ci-dessous :

1. Vérifiez l'incompatibilité de la bibliothèque réseau. Performance Monitoring collecte automatiquement les métriques pour les requêtes réseau qui utilisent les bibliothèques réseau suivantes :

   • Pour Swift : URLSession et URLConnection
   • Pour Objective-C : NSURLSession et NSURLConnection

   Notez que vous pouvez ajouter une surveillance personnalisée pour les requêtes réseau.

2. Important :

   • Selon le comportement de votre code et des bibliothèques réseau utilisées par votre code, Performance Monitoring peut ne signaler que les requêtes réseau terminées. Cela signifie que les connexions HTTP/S laissées ouvertes peuvent ne pas être signalées.

   • Performance Monitoring ne signale pas les requêtes réseau avec des en-têtes Content-Type non valides. Toutefois, les requêtes réseau sans les en-têtes Content-Type seront toujours acceptées.

Les données des requêtes réseau ne sont pas agrégées comme prévu

Découvrez comment Performance Monitoring agrège les données de requêtes réseau sous les formats d'URL.

Vous pouvez également essayer les formats d'URL personnalisés.

Qu'est-il arrivé à la section "Principaux problèmes" de la fiche "Performances" sur la page d'accueil du projet ?

Nous avons remplacé Principaux problèmes par Alertes récentes, suite à l'introduction récente des alertes, qui vous avertissent automatiquement lorsque les seuils que vous avez définis sont dépassés. Les problèmes sont désormais obsolètes et remplacés par des alertes.

Le sélecteur d'applications en haut de la fiche "Performances" filtre les entrées d'alerte sous Alertes récentes. Seules les trois alertes les plus récentes pour les applications sélectionnées sont affichées.

Pour en savoir plus sur les alertes, consultez Configurer des alertes pour les problèmes de performances.

Qu'est-il advenu de la possibilité de définir des seuils pour les problèmes dans la console ?

Performance Monitoring accepte les alertes pour les métriques qui dépassent les seuils définis. Pour éviter toute confusion avec ces seuils configurables pour les métriques de performances, nous avons supprimé la possibilité de configurer des seuils pour les problèmes.

Qu'est-il advenu des informations "Détails" et "Métriques" dans la console Firebase ?

Nous avons remplacé les pages "Détails" et "Métriques" par une nouvelle interface utilisateur centralisée pour vous aider à résoudre les problèmes plus efficacement. Cette nouvelle UI de dépannage offre les mêmes fonctionnalités de base que les onglets "Détails" et "Métriques". Pour en savoir plus sur le dépannage, consultez Afficher plus de données pour une trace spécifique.

Pourquoi le nombre d'échantillons ne correspond-il pas à ce que j'attends ?

Performance Monitoring collecte les données sur les performances des appareils des utilisateurs de votre application. Si votre application compte de nombreux utilisateurs ou si elle génère une grande quantité d'activité liée aux performances, Performance Monitoring peut limiter la collecte de données à un sous-ensemble d'appareils afin de réduire le nombre d'événements traités. Ces limites sont suffisamment élevées pour que, même avec moins d'événements, les valeurs des métriques restent représentatives de l'expérience de vos utilisateurs dans l'application.

Pour gérer le volume de données que nous collectons, Performance Monitoring utilise les options d'échantillonnage suivantes :

• Limitation du débit sur l'appareil : pour éviter qu'un appareil n'envoie des pics soudains de traces, nous limitons le nombre de traces de code et de requêtes réseau envoyées par un appareil à 300 événements toutes les 10 minutes. Cette approche protège l'appareil des instrumentations en boucle qui peuvent envoyer de grandes quantités de données sur les performances, et empêche un seul appareil de fausser les mesures de performances.

• Échantillonnage dynamique : Performance Monitoring collecte chaque jour un nombre limité de traces de code et de traces de requêtes réseau par application pour tous les utilisateurs de l'application. Un taux d'échantillonnage dynamique est récupéré sur les appareils (à l'aide de Firebase Remote Config) pour déterminer si un appareil aléatoire doit capturer et envoyer des traces. Un appareil qui n'est pas sélectionné pour l'échantillonnage n'envoie aucun événement. Le taux d'échantillonnage dynamique est spécifique à l'application et s'ajuste pour que le volume global de données collectées reste inférieur à la limite.

  Les projets pour lesquels l'intégration de BigQuery est activée bénéficient d'une limite plus élevée pour le nombre de traces de requêtes réseau.

  Les sessions utilisateur envoient des données détaillées supplémentaires depuis l'appareil d'un utilisateur, ce qui nécessite plus de ressources pour capturer et envoyer les données. Pour minimiser l'impact des sessions utilisateur, Performance Monitoring peut également limiter le nombre de sessions.

• Limitation du débit côté serveur : pour s'assurer que les applications ne dépassent pas la limite d'échantillonnage, Performance Monitoring peut utiliser l'échantillonnage côté serveur pour supprimer certains événements reçus des appareils. Bien que ce type de limitation ne modifie pas l'efficacité de nos métriques, il peut entraîner des changements mineurs dans les tendances, y compris les suivants :

  • Le nombre de traces peut différer du nombre de fois où un morceau de code a été exécuté.
  • Les traces étroitement couplées dans le code peuvent chacune avoir un nombre d'échantillons différent.

Qu'est-il arrivé à l'onglet Problèmes de la console ?

Nous avons remplacé l'onglet "Problèmes" par les alertes, qui vous avertissent automatiquement lorsque les seuils que vous avez définis sont dépassés. Vous n'avez plus besoin de vérifier manuellement la console Firebase pour déterminer l'état d'un seuil. Pour en savoir plus sur les alertes, consultez Configurer des alertes pour les problèmes de performances.

Qu'est-il advenu des onglets On Device (Sur l'appareil) et Network (Réseau) de la console ? Comment afficher les traces qui se trouvaient sur ces pages ?

Nous avons repensé la section Performance Monitoring de la console Firebase afin que l'onglet Tableau de bord affiche vos métriques clés et toutes vos traces au même endroit. Dans le cadre de cette refonte, nous avons supprimé les pages Sur l'appareil et Réseau.

Le tableau des traces en bas de l'onglet Tableau de bord contient les mêmes informations que celles affichées dans les onglets Sur l'appareil et Réseau, mais avec des fonctionnalités supplémentaires, y compris la possibilité de trier vos traces en fonction de la variation en pourcentage d'une métrique spécifique. Pour afficher toutes les métriques et données d'une trace spécifique, cliquez sur le nom de la trace dans le tableau des traces.

Affichez vos traces dans les sous-onglets suivants du tableau des traces :

• Traces de requêtes réseau (prêtes à l'emploi et personnalisées) : sous-onglet Requêtes réseau
• Traces de code personnalisées : sous-onglet Traces personnalisées
• Traces de démarrage de l'application, d'application au premier plan et d'application en arrière-plan : sous-onglet Traces personnalisées
• Traces de rendu d'écran : sous-onglet Rendu d'écran
• Traces de chargement de page : sous-onglet Chargement de page

Pour en savoir plus sur le tableau des traces et l'affichage des métriques et des données, consultez la page de présentation de la console (iOS+ | Android | Web).

Pourquoi le nombre d'images lentes et figées n'est-il pas celui auquel je m'attendais ?

Les frames figés et à affichage lent sont calculés en fonction d'une fréquence d'actualisation de l'appareil supposée de 60 Hz. Si la fréquence d'actualisation d'un appareil est inférieure à 60 Hz, chaque frame aura un délai d'affichage plus long, car moins de frames sont affichés par seconde. Des délais d'affichage plus lents peuvent entraîner le signalement d'un plus grand nombre d'images lentes ou figées, car davantage d'images seront affichées plus lentement ou se figeront. Toutefois, si la fréquence d'actualisation d'un appareil est supérieure à 60 Hz, chaque frame aura un délai d'affichage plus rapide. Cela peut entraîner une diminution du nombre d'images lentes ou de cadres figés signalés. Il s'agit d'une limitation actuelle du SDK Performance Monitoring.

L'exportation de mes données Performance Monitoring vers BigQuery prend plus de temps que prévu. N'est-il pas en temps réel ?

Si vous avez activé l'intégration de BigQuery pour Firebase Performance Monitoring, vos données seront exportées vers BigQuery 12 à 24 heures après la fin de la journée (heure du Pacifique).

Par exemple, les données du 19 avril seront disponibles dans BigQuery le 20 avril entre midi et minuit (toutes les dates et heures sont exprimées au format Pacific Time).

Combien de formats d'URL personnalisés puis-je créer ?

Vous pouvez créer jusqu'à 400 formats d'URL personnalisés par application et jusqu'à 100 formats d'URL personnalisés par domaine pour cette application.

Que signifient les données sur les performances "en temps quasi réel" ?

Firebase Performance Monitoring traite les données sur les performances collectées au fur et à mesure de leur arrivée, ce qui permet d'afficher les données en temps quasi réel dans la console Firebase. Les données traitées s'affichent dans la console quelques minutes après leur collecte, d'où le terme "en temps quasi réel".

Pour profiter du traitement des données en temps quasi réel, assurez-vous que votre application utilise une version du SDK compatible avec le temps réel.

Comment obtenir des données sur les performances de mon application en temps quasi réel ?

Pour profiter du traitement des données en temps quasi réel, il vous suffit de vous assurer que votre application utilise une version du SDK Performance Monitoring compatible avec le traitement des données en temps réel.

Voici les versions du SDK compatibles en temps réel :

• iOS : v7.3.0 ou version ultérieure
• tvOS : v8.9.0 ou version ultérieure
• Android : v19.0.10 ou version ultérieure (ou Firebase Android BoM v26.1.0 ou version ultérieure)
• Web : v7.14.0 ou version ultérieure

Notez que nous vous recommandons de toujours utiliser la dernière version du SDK, mais que toutes les versions listées ci-dessus permettront à Performance Monitoring de traiter vos données en temps quasi réel.

Quelles versions du SDK Performance Monitoring sont considérées comme compatibles en temps réel ?

Voici les versions du SDK compatibles avec le traitement des données en temps réel :

• iOS : v7.3.0 ou version ultérieure
• tvOS : v8.9.0 ou version ultérieure
• Android : v19.0.10 ou version ultérieure (ou Firebase Android BoM v26.1.0 ou version ultérieure)
• Web : v7.14.0 ou version ultérieure

Notez que nous vous recommandons de toujours utiliser la dernière version du SDK, mais que n'importe quelle version listée ci-dessus permettra à Performance Monitoring de traiter vos données en temps quasi réel.

Que se passe-t-il si je ne mets pas à jour mon application pour utiliser une version du SDK compatible avec le temps réel ?

Si votre application n'utilise pas de version du SDK compatible avec le temps réel, vous verrez toujours toutes les données sur les performances de votre application dans la console Firebase. Toutefois, l'affichage des données sur les performances sera retardé d'environ 36 heures à compter de leur collecte.

Je suis passé à une version du SDK compatible avec le temps réel, mais certains de mes utilisateurs utilisent encore d'anciennes versions de mon application. Est-ce que je continuerai à voir leurs données de performances dans la console Firebase ?

Oui. Quelle que soit la version du SDK utilisée par une instance d'application, vous verrez les données sur les performances de tous vos utilisateurs.

Toutefois, si vous examinez des données récentes (datant de moins de 36 heures environ), les données affichées proviennent d'utilisateurs d'instances d'application utilisant une version du SDK compatible avec le temps réel. En revanche, les données non récentes incluent les données sur les performances de toutes les versions de votre application.

Pourquoi les données sur les performances ne s'affichent-elles pas en temps réel ?

Pour afficher les données sur les performances en temps réel, assurez-vous que votre application utilise une version du SDK Performance Monitoring compatible avec le traitement des données en temps réel.

• iOS : v7.3.0 ou version ultérieure
• tvOS : v8.9.0 ou version ultérieure
• Android : v19.0.10 ou version ultérieure (ou Firebase Android BoM v26.1.0 ou version ultérieure)
• Web : v7.14.0 ou version ultérieure

Notez que nous vous recommandons de toujours utiliser la dernière version du SDK, mais que toutes les versions listées ci-dessus permettront à Performance Monitoring de traiter vos données en temps quasi réel.