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.
Un breadcrumb est une entrée dans une piste chronologique de ce qui s’est passé dans le navigateur avant une erreur. Reconstituer un bug front-end à partir d’une seule stack trace relève souvent de la devinette. Elle montre la route précédente et sur quoi l’utilisateur a cliqué. Elle montre aussi les requêtes et les avertissements ou erreurs de la console. Les breadcrumbs sont collectés automatiquement après init(). Jusqu’à 25 breadcrumbs du tampon de contexte d’erreur accompagnent chaque erreur rapportée, y compris un breadcrumb pour cette erreur elle-même. Vous les lisez dans le sample de l’issue.

​
Ce qui est collecté

Ces catégories automatiques peuvent apparaître avec un rapport d’erreur : Les options breadcrumbs permettent de désactiver la collecte de network, console, click et long_task. Les breadcrumbs navigation, visibility et error n’ont pas d’interrupteur séparé.

​
Nommer les éléments

Les breadcrumbs de sélection décrivent l’élément comme une personne le reconnaîtrait, plutôt que par sa position dans la page. AppSignal cherche d’abord un attribut data-breadcrumb. Sinon, il utilise le type d’élément et son texte, par exemple button "Submit". Si rien de tout cela n’aide, il utilise la balise et l’ID, par exemple input#cvc. Quand le libellé automatique n’aide pas, ou quand le texte visible est quelque chose que vous préférez ne pas envoyer, définissez le vôtre :
L’attribut est lu sur l’élément ou sur n’importe lequel de ses ancêtres : nommer un conteneur couvre donc tout ce qu’il contient.

​
Ajouter vos propres breadcrumbs

Enregistrez tout ce qui mérite d’être connu avec addBreadcrumb() :
Vos propres breadcrumbs accompagnent les erreurs, quelle que soit la catégorie que vous leur donnez.

​
Ce que le SDK ne capture pas automatiquement

  • Les corps de requête et de réponse. Le SDK ne les lit pas depuis les appels réseau. Si une charge utile compte pour le débogage, ajoutez uniquement les parties dont vous avez besoin avec addBreadcrumb().
  • Les cookies. Le SDK n’en lit ni n’en écrit aucun.
  • Les paramètres de requête dans la plupart des champs d’URL créés par le SDK. privacy.queryParamsAllowlist les supprime par défaut des breadcrumbs de navigation et de fetch/XMLHttpRequest. Le breadcrumb du chargement initial du document fait exception.
  • Les appels fetch et XMLHttpRequest bloqués. Les appels correspondant à privacy.networkBlocklist, ainsi que les appels vers l’endpoint d’AppSignal, ne laissent aucun breadcrumb. Ils ne sont jamais rapportés comme des requêtes échouées non plus. Le breadcrumb du chargement initial du document n’est pas couvert par la liste de blocage.
  • Le texte et les éléments que vous avez masqués. Pour en savoir plus, consultez masquer et bloquer des éléments de page.
Pour filtrer ou expurger des breadcrumbs individuels au moment de leur enregistrement, utilisez beforeBreadcrumb.

​
Lire les breadcrumbs réseau

Un breadcrumb réseau se lit comme une méthode, une URL et un statut dès qu’une réponse est arrivée, y compris les réponses 404 et 500. Un suffixe (error) signifie qu’aucune réponse n’est arrivée. La cause peut être un échec DNS, une connexion refusée ou une requête bloquée. Une requête qui a envoyé un en-tête traceparent enregistre aussi son trace ID dans le breadcrumb. Le service qui la reçoit doit poursuivre la trace pour que les spans back-end apparaissent sous cet ID. Les requêtes cross-origin ne rapportent aucun détail de temps, sauf si le serveur envoie un en-tête Timing-Allow-Origin. C’est une restriction du navigateur, pas d’AppSignal.