Traduit de l’anglais à l’aide de l’IA
Veuillez noter que cet article a été traduit à l’aide de la technologie IA. Bien que nous travaillions à maintenir l’exactitude, certains détails peuvent ne pas refléter parfaitement le texte original. Si vous avez un doute sur une information, veuillez vous référer à la version anglaise.
Notez que cet article fait référence à la Console DevTools qui est distincte de la Console Contentsquare (utilisée pour la gestion back-office de votre/vos projet(s) Contentsquare). Pour plus d’informations sur la Console Contentsquare, consultez cet article à la place.
À propos de la Console DevTools
La Console DevTools est un outil développeur disponible sur les navigateurs web, couramment utilisé pour comprendre ce qui se passe dans le code de votre site web. Elle affiche les messages enregistrés par le navigateur, ou ajoutés par les développeurs web eux-mêmes, ce qui aide à identifier et dépanner les problèmes, tels que les erreurs ou les problèmes réseau.
Dans Error Analysis, vous pouvez consulter les messages de la console ajoutés par les développeurs, pour vous aider à trouver et résoudre plus rapidement tout problème.
Niveaux de journalisation des messages de la console
Chaque message se voit attribuer un niveau de journalisation, pour aider à comprendre son importance. Il y a 5 niveaux de journalisation qui peuvent être suivis avec les messages de la console dans Contentsquare :
- Erreur : utilisé pour enregistrer les erreurs critiques qui peuvent empêcher un site web de fonctionner comme prévu. Il est recommandé d’enquêter et de résoudre ces erreurs rapidement.
- Avertissement : utilisé pour enregistrer des anomalies pouvant entraîner des problèmes futurs. Il est recommandé de les examiner périodiquement pour prévenir les problèmes.
- Info : utilisé pour enregistrer des informations générales sur le fonctionnement d’un site web. Ces messages sont utiles pour comprendre le flux normal des activités et le comportement.
- Log : souvent utilisé pour enregistrer des informations qui ne sont pas nécessairement critiques, mais utiles pour le débogage et le traçage.
- Debug : typiquement utilisé pendant le développement à des fins de débogage. Ces journaux sont temporaires et doivent être retirés du code de production.
Analyser les messages de la console dans Error Analysis
Les messages de la console sont identifiables comme des « erreurs custom » dans Error Analysis. Lors du filtrage sur les erreurs custom, les messages de la console et les erreurs custom seront affichés, car ils partagent la même infrastructure.
Chaque erreur inclut les labels suivants :
- Un label de type d’erreur « CST » (erreur custom).
- Le niveau de journalisation (Avertissement, Erreur, Debug, Info, Log).
- Le message de la console, par exemple : « Les événements d’orientation du device sont bloqués par une politique de permission ».
Bon à savoir : Messages de la console et performance d’Error Analysis
Selon votre site, vous pouvez rencontrer un volume élevé de messages de console. Cela peut affecter la rapidité avec laquelle Error Analysis peut charger les données et les métriques.
Pour vous aider à vous concentrer sur d'autres erreurs, vous pouvez exclure les messages de console d'Error Analysis à tout moment. Cela ne les exclut pas pour les autres utilisateurs de votre projet et n'affecte que ce projet en particulier.
Il vous suffit d'accéder à Error Analysis, de cliquer sur le bouton Paramètres (en haut à droite) et d'activer le bouton bascule Ignorer les messages de console.
Comment filtrer les messages de console depuis l'Explorateur d'erreurs
Explorez plus en profondeur tous les messages de console en utilisant l'Explorateur d'erreurs - appliquez des filtres avancés, triez les colonnes et recherchez des erreurs spécifiques.
- Depuis Error Analysis, dans le widget Rechercher des erreurs, cliquez sur Rechercher.
-
Sélectionnez Erreurs personnalisées et cliquez sur Appliquer.
-
Ouvrez les Filtres avancés.
- Cliquez sur +ajouter des attributs personnalisés et saisissez 'csLogLevel' dans la clé :
- utilisez l'opérateur "existe" pour voir tous les niveaux de journalisation
- utilisez l'opérateur "égal à" pour filtrer un niveau de journalisation spécifique et saisissez l'une des valeurs suivantes : Error / Warning / Info / Log / Debug
Comment consulter et agir sur les détails des messages de console depuis le panneau latéral des erreurs
Comme pour tous les types d'erreurs, vous pouvez trouver des détails supplémentaires et prendre des mesures depuis le panneau latéral de l'erreur.
1. Depuis Error Analysis, cliquez sur un message de console pour ouvrir le panneau latéral de l'erreur.
2. Depuis le panneau latéral, vous pouvez consulter les détails individuels de l'erreur :
- Type d'erreur et niveau de journalisation.
- ID d'erreur groupée.
- Message de console.
Depuis les détails de l'erreur, vous pouvez :
- Voir les détails généraux de l'erreur.
- Ignorer l'erreur (réservé aux fonctions Administrateur ou expert utilisateur).
- Envoyer vers JIRA (réservé aux utilisateurs Administrateur) ou consulter le ticket Jira si un a déjà été créé.
- Utilisez le menu « ... » à trois points pour Copier les détails de l'erreur ou configurer des détails supplémentaires.
- Utilisez les boutons « Voir les replays », « Voir l'Impact » et « Voir Journey Analysis » pour approfondir l'Impact de l'erreur.
Comment voir et agir sur les messages de la console dans Session Replay
1. Depuis le panneau latéral de l'erreur, cliquez sur le bouton « Voir les replays ».
2. Session Replay s'ouvrira et vous pourrez regarder un replay où l'erreur s'est produite.
3. Les détails de l'erreur seront visibles dans le flux d'événements et dans l'infobulle de l'icône de la chronologie.
4. Cliquez sur l'infobulle de la chronologie et utilisez le bouton « Quantifier » pour analyser plus en détail l'Impact de l'erreur.
FAQ
Pourquoi vois-je des erreurs/avertissements provenant du tag ?
Pour suivre les arguments passés aux fonctions de la console, le tag de suivi doit modifier ces fonctions par monkey patching. Le monkey patching est une technique connue pour étendre le code des fonctions sans altérer le code source original. Ce faisant, le tag de suivi apparaîtra dans la stack trace même s'il n'est pas à l'origine de l'appel. Le tag de suivi n'appellera jamais la console pour enregistrer des erreurs.