Skip to main content
Browser monitoring est une fonctionnalité en beta d’AppSignal Labs. Le package @appsignal/browser est publié sous le tag beta sur npm, et sa configuration ainsi que son API peuvent encore changer d’une release beta à l’autre. Partagez vos retours dans notre communauté Discord.
La vue Errors répertorie les erreurs que votre front end a rapportées, regroupées en issues. Elle utilise le même modèle d’issues que les erreurs back-end. Vous pouvez les trier et les assigner de la même façon.

​
Comment les erreurs sont regroupées

AppSignal regroupe les erreurs liées en issues à partir de la route rapportée et des réglages de regroupement de votre application. Des occurrences répétées peuvent apparaître comme une seule issue à trier. La route est celle que le SDK a rapportée via setRouteTemplate(), ou le chemin de la page si rien n’a été déclaré. Sans template, /orders/1 et /orders/2 sont des routes d’erreur différentes. Un même bug peut ainsi devenir deux issues.

​
Lire la liste des issues

Chaque issue de la liste porte :
  • La classe d’erreur et le message, avec la route sur laquelle l’erreur s’est produite.
  • La version dans laquelle elle a été introduite. Si elle apparaît d’abord dans votre release la plus récente, examinez ce deploy.
  • Une tendance sur la période sélectionnée, pour qu’un pic se lise différemment d’un filet continu.
  • Le nombre total d’occurrences sur la période.
  • La date de la dernière occurrence.
  • La personne à qui elle est assignée.
Triez par occurrence récente pour repérer les nouvelles pannes. Triez par volume pour repérer les plus fréquentes.

​
Filtrer par période et par version

  • Période. Des préréglages d’une heure à 30 jours, ou une plage personnalisée.
  • Version. Restreignez la liste aux erreurs rapportées par une seule release. Combiné à la colonne d’introduction, c’est ainsi que vous confirmez si un deploy est responsable.

​
Enquêter sur une issue

Ouvrez une issue pour examiner un sample : une fois où l’erreur s’est produite dans le navigateur d’un utilisateur. Le sample vous donne le message d’erreur et ce qui s’est passé autour.
  1. Lisez le message. Il vous dit ce qui a échoué. Par exemple, POST https://api.example.com/orders: HTTP 503 signifie que l’API checkout a renvoyé une erreur serveur.
  2. Vérifiez la backtrace pour les erreurs JavaScript. Elle montre où l’erreur s’est produite dans votre code. Si vous voyez du code minifié au lieu de noms de fichiers et de lignes lisibles, envoyez les sourcemaps pour la version définie dans appVersion.
  3. Lisez les breadcrumbs. Elles montrent les événements avant l’erreur, comme une sélection de bouton ou une requête réseau. Si l’utilisateur a sélectionné Pay juste avant que /orders ne prenne trois secondes, vérifiez d’abord cette requête API.
  4. Vérifiez la version et les tags. Comparez la version du sample avec vos deploys récents. Utilisez les tags définis avec setTags() pour cerner qui a été affecté.
Une requête API en échec rapportée comme HTTPError ou TimeoutError n’a pas de backtrace JavaScript. Sur la page complète de l’issue, sélectionnez Traces, puis Fullscreen dans la carte Trace timeline pour examiner son span navigateur. Si le back end a poursuivi la trace, ses spans y apparaissent aussi. Depuis le panneau latéral « Browser Errors », utilisez Open full trace page pour atteindre la page complète de l’issue. Vous pouvez exporter un sample en JSON ou en Markdown pour le partager avec votre équipe. Utilisez le journal de l’issue pour noter ce que vous avez trouvé.

​
Tri et notifications

Vous pouvez assigner ces issues, les mettre en sourdine et changer leur état. Elles prennent aussi en charge des réglages de notification. Pour en savoir plus, consultez Errors. Comme les erreurs front-end vivent dans le namespace browser (voir les namespaces), ces réglages sont distincts de ceux de votre back end. Si vous migrez depuis @appsignal/javascript, configurez les notifications pour browser. Les réglages pour frontend ne sont pas repris. Pour en savoir plus, consultez le guide de migration.

​
Les erreurs que vous ne trouverez pas ici

Certaines erreurs n’atteignent jamais le SDK. Par exemple, les erreurs avant init() et les erreurs à l’intérieur d’iframes non instrumentées. Les erreurs de script cross-origin opaques sont écartées. Chacune a une solution de contournement, répertoriée dans les erreurs qui ne sont pas rapportées. S’il manque une erreur que vous attendiez, parcourez le dépannage.