Dépannage et questions fréquentes concernant Performance Monitoring
Cette page fournit des conseils de dépannage pour vous lancer avec Performance Monitoring ou utiliser les fonctionnalités et les outils Performance Monitoring.
Premières vérifications pour le dépannage
Les deux vérifications suivantes sont des bonnes pratiques générales recommandées à tous avant un dépannage plus poussé.
1. Rechercher les événements liés aux performances dans les messages de journal
Vérifiez vos messages de journal pour vous assurer que le SDK Performance Monitoring capture les événements de performances.
Afficher les messages de journal pour les événements de performances
Activez la journalisation du débogage comme suit :
Dans Xcode (version 15.2 ou ultérieure), sélectionnez Product > Scheme > Edit schema (Produit > Schéma > Modifier le schéma).
Sélectionnez Exécuter dans le menu de gauche, puis l'onglet Arguments.
Dans la section Arguments transmis au lancement, ajoutez -FIRDebugEnabled.
Recherchez d'éventuels messages d'erreur dans les messages de journal.
Performance Monitoring tague ses messages de journal avec Firebase/Performance afin que vous puissiez les filtrer.
Recherchez les types de journaux suivants, qui indiquent que Performance Monitoring consigne les événements de performances:
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 ne consigne pas d'événements de performances, consultez les conseils de dépannage.
Si vous débutez avec Performance Monitoring (iOS+ | Android | Web), les conseils de dépannage suivants peuvent vous aider à résoudre les problèmes liés à la détection du SDK par Firebase ou à l'affichage de vos premières données de performances dans la console Firebase.
J'ai ajouté le SDK à l'application, mais la console indique toujours d'ajouter le SDK.
Firebase peut détecter si vous avez correctement 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. Généralement, dans les 10 minutes suivant le démarrage de votre application, le tableau de bord des performances de la console Firebase affiche un message "SDK détecté". Ensuite, dans un délai de 30 minutes, le tableau de bord affiche les données traitées initialement.
Si vous avez ajouté la dernière version du SDK à votre application il y a plus de 10 minutes et que vous ne constatez toujours aucun changement, vérifiez vos messages de journal pour vous assurer que Performance Monitoring consigne les événements. Suivez les étapes de dépannage appropriées décrites ci-dessous pour résoudre le problème d'un message de détection du SDK retardé.
L'application consigne les événements: étapes de dépannage
Si vous développez toujours en local, essayez de générer plus d'événements pour la collecte de données :
Poursuivez le développement de votre application à l'aide d'un simulateur ou d'un appareil de test.
Générez des événements en basculant plusieurs fois votre application entre l'arrière-plan et le premier plan, en interagissant avec votre application en naviguant sur plusieurs écrans et/ou en déclenchant des requêtes réseau.
Assurez-vous que votre fichier de configuration Firebase (Google-Service-Info.plist) est correctement ajouté à votre application et que vous ne l'avez pas modifié.
Vérifiez plus précisément les points suivants :
Le nom du fichier de configuration n'est pas suivi de caractères supplémentaires, comme (2).
Le fichier de configuration se trouve dans la racine de votre projet Xcode et est ajouté aux cibles appropriées.
L'ID d'application Firebase Apple (GOOGLE_APP_ID) indiqué dans le fichier de configuration est correct pour votre application. Vous trouverez votre ID d'application Firebase dans la fiche Vos applications de vos paramètres de projetsettings.
Si le fichier de configuration de votre application semble incorrect, procédez comme suit :
Supprimez le fichier de configuration qui se trouve actuellement dans votre application.
Suivez ces instructions pour télécharger un nouveau fichier de configuration et l'ajouter à votre application Apple.
Si le SDK enregistre les événements et que tout semble être correctement configuré, mais que le message de détection du SDK ou les données traitées ne s'affichent toujours pas (après deux heures), contactez l'assistance Firebase.
L'application ne consigne pas les événements : procédure de dépannage
Console indique que le SDK est détecté, mais qu'aucune donnée ne s'affiche
Performance Monitoring traite les données des événements 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 Firebase pour vérifier si une panne est connue. Si aucune panne n'est signalée, contactez l'assistance Firebase.
Dépannage d'ordre général
Si vous avez correctement ajouté le SDK et que vous utilisez Performance Monitoring dans votre application, les conseils de dépannage suivants peuvent vous aider à résoudre les problèmes généraux liés aux fonctionnalités et aux outils Performance Monitoring.
L'application n'enregistre pas les événements de performances
Données de trace d'écran manquantes dans le tableau de bord des performances
Si des données sont manquantes pour les traces de rendu d'écran, suivez les étapes de dépannage ci-dessous :
Il manque des données de trace personnalisée dans le tableau de bord des performances
Affichez-vous des données de performances pour les traces collectées automatiquement, mais pas pour les traces de code personnalisé ? Suivez les étapes de dépannage ci-dessous:
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ées et des métriques personnalisées doivent respecter les conditions 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. Aucune trace qui n'est pas démarrée, pas arrêtée ou arrêtée avant le démarrage ne sera journalisée.
Vérifiez vos messages de journal pour vous assurer que Performance Monitoring consigne les traces de code personnalisé attendues.
Si Performance Monitoring enregistre des événements, mais qu'aucune donnée ne s'affiche au bout de 24 heures, contactez l'assistance Firebase.
Données de requête réseau manquantes dans le tableau de bord des performances
Si les données de requête réseau sont manquantes, essayez de suivre les étapes de dépannage ci-dessous :
En fonction du comportement de votre code et des bibliothèques réseau utilisées par votre code, Performance Monitoring ne peut signaler que les requêtes réseau terminées. Cela signifie que les connexions HTTP/S laissées ouvertes ne sont pas nécessairement 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 en-têtes Content-Type seront toujours acceptées.
Les données des demandes réseau ne s'agrègent pas comme prévu
Qu'est-il arrivé aux principaux problèmes dans la fiche "Performances" de la page d'accueil du projet ?
Nous avons remplacé Problèmes courants par Alertes récentes, suite à l'introduction récente des alertes, qui vous avertissent automatiquement lorsque les seuils que vous définissez 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.
Qu'est-il arrivé à la possibilité de définir des seuils pour les problèmes dans la console ?
Performance Monitoring est compatible avec les alertes pour les métriques qui dépassent les seuils définis. Afin d'é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 arrivé aux informations "Détails" et "Métriques" dans la console Firebase ?
Nous avons remplacé les pages "Détails" et "Métriques" par une interface utilisateur (UI) centralisée et repensée pour vous permettre de résoudre les problèmes plus efficacement. Cette nouvelle UI de dépannage offre les mêmes fonctionnalités de base que les sections Détails et Métriques. Pour en savoir plus sur le dépannage, consultez la section Afficher plus de données pour une trace spécifique.
Pourquoi le nombre d'échantillons ne correspond-il pas à mes attentes ?
Performance Monitoring collecte des données de performances sur les appareils des utilisateurs de votre application. Si votre application compte de nombreux utilisateurs ou génère une grande quantité d'activité de 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 utilisateur dans votre application.
Pour gérer le volume de données que nous recueillons, Performance Monitoring utilise les options d'échantillonnage suivantes:
Limitation du débit sur l'appareil: pour empêcher un appareil d'envoyer des rafales de traces soudaines, nous limitons le nombre de traces de code et de requêtes réseau envoyées depuis un appareil à 300 événements toutes les 10 minutes. Cette approche protège l'appareil contre les instrumentations en boucle qui peuvent envoyer de grandes quantités de données de performances, et empêche un seul appareil de fausser les mesures de performances.
Échantillonnage dynamique: Performance Monitoring collecte quotidiennement un nombre limité de traces de code et de traces de requête réseau par application pour tous les utilisateurs de l'application. Un taux d'échantillonnage dynamique est extrait 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 non sélectionné pour l'échantillonnage n'envoie aucun événement. Le taux d'échantillonnage dynamique est spécifique à l'application et s'ajuste pour s'assurer que le volume global de données collectées reste inférieur à la limite.
Les projets ayant activé l'intégration BigQuery reçoivent 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 à partir de l'appareil de l'utilisateur, ce qui nécessite plus de ressources pour les capturer et les envoyer. Pour minimiser l'impact des sessions utilisateur, Performance Monitoring peut également limiter le nombre de sessions.
Limitation de 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 de tendances, y compris les suivants:
Le nombre de traces peut différer du nombre de fois qu'un code a été exécuté.
Les traces étroitement couplées dans le code peuvent chacune contenir 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 "Alertes", qui vous avertit automatiquement lorsque les seuils que vous définissez 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 arrivé aux onglets Sur l'appareil et Réseau de la console ?
Comment puis-je consulter 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 dans un même espace. 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 les onglets Sur l'appareil et Réseau affichés, mais avec quelques fonctionnalités supplémentaires, comme la possibilité de trier vos traces en fonction du pourcentage de variation pour une métrique spécifique. Pour afficher toutes les métriques et données d'une trace spécifique, cliquez sur son nom dans le tableau des traces.
Affichez vos traces dans les sous-onglets suivants du tableau des traces:
Traces de requête réseau (prêts à l'emploi et personnalisés) – sous-onglet Demandes réseau
Traces de code personnalisées : sous-onglet Traces personnalisées
Traces de démarrage, 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 de l'écran
Traces de chargement de page : sous-onglet Chargement de la page
Pour en savoir plus sur la table des traces et sur 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 ne correspond-il pas à ce que j'attendais ?
Les images de rendu lent et les images figées sont calculées avec 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, le temps de rendu de chaque frame est plus lent, car moins de frames sont affichés par seconde.
Des temps d'affichage plus lents peuvent entraîner l'affichage de plus de frames lents ou figés, car davantage de frames seront affichés plus lentement ou seront figés. Toutefois, si la fréquence d'actualisation d'un appareil est supérieure à 60 Hz, le délai d'affichage de chaque image est plus court.
Cela peut entraîner moins de rapports sur les images lentes ou figées. 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-ce pas en temps réel ?
Si vous avez activé l'intégration 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 indiquées en heure du Pacifique).
Traitement et affichage des données en quasi-temps réel
Que signifie "quasi en temps réel" ?
Firebase Performance Monitoring traite les données de performances collectées à mesure qu'elles arrivent, ce qui permet d'afficher les données en quasi temps 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 "quasi en temps réel".
Comment obtenir des données sur les performances de mon application en quasi-temps réel ?
Pour profiter du traitement des données en quasi-temps 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 compatibles en temps réel des SDK:
iOS : version 7.3.0 ou ultérieure
tvOS : version 8.9.0 ou ultérieure
Android : version 19.0.10 ou ultérieure (ou Firebase Android BoM v26.1.0 ou version ultérieure)
Web : version 7.14.0 ou ultérieure
Notez que nous vous recommandons toujours d'utiliser la dernière version du SDK, mais n'importe quelle version listée ci-dessus permet à Performance Monitoring de traiter vos données en quasi-temps réel.
Quelles versions du SDK Performance Monitoring sont considérées comme compatibles avec la surveillance en temps réel ?
Voici les versions du SDK compatibles avec le traitement des données en temps réel:
iOS : version 7.3.0 ou ultérieure
tvOS : version 8.9.0 ou ultérieure
Android : version 19.0.10 ou ultérieure (ou Firebase Android BoM v26.1.0 ou version ultérieure)
Web : version 7.14.0 ou ultérieure
Notez que nous vous recommandons toujours d'utiliser la dernière version du SDK, mais n'importe quelle version listée ci-dessus permet à Performance Monitoring de traiter vos données en quasi-temps réel.
Que se passe-t-il si je ne mets pas à jour mon application pour qu'elle utilise une version compatible du SDK en temps réel ?
Si votre application n'utilise pas de version de SDK compatible avec le temps réel, vous verrez toujours toutes les données de performances de votre application dans la console Firebase. Toutefois, l'affichage des données de performances sera retardé d'environ 36 heures à compter de leur collecte.
J'ai mis à jour ma version de SDK vers une version compatible avec la surveillance en temps réel, mais certains de mes utilisateurs utilisent toujours d'anciennes versions de mon application. Vais-je continuer à 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 de performances de tous vos utilisateurs.
Toutefois, si vous consultez des données récentes (datant de moins de 36 heures environ), les données affichées proviennent d'utilisateurs d'instances d'application qui utilisent une version de SDK compatible en temps réel. Les données non récentes incluent toutefois les données de performances de toutes les versions de votre application.
Contacter l'assistance Firebase
Si vous contactez l'assistance Firebase, indiquez toujours votre ID d'application Firebase. Recherchez votre ID d'application Firebase dans la fiche Vos applications de la section Paramètres du projet de settings.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2024/11/11 (UTC).
[null,null,["Dernière mise à jour le 2024/11/11 (UTC)."],[],[]]