Dépannage de browser monitoring

​

Aucune donnée n’arrive

Parcourez ces points dans l’ordre. Chacun est un arrêt complet : rien n’est envoyé quand il s’applique.

1. active vaut false. Journalisez la valeur que vous passez, plutôt que l’expression. Un bundler qui ne remplace pas process.env.NODE_ENV laisse la comparaison à false dans le navigateur.
2. init() n’a jamais été exécuté. Définir la configuration ne suffit pas. Vérifiez que votre point d’entrée importe le module qui appelle init(). Vérifiez que votre build l’inclut.
3. La clé est incorrecte. Une mauvaise clé renvoie 401. Utilisez la Front-end API key de cette app, pas une Push key. Vérifiez qu’elle appartient au bon environnement.
4. Les requêtes sont bloquées. Ouvrez le panneau réseau de votre navigateur et cherchez une requête vers /ingest/browser/errors pour les erreurs, ou /ingest/browser pour les web vitals. Une requête bloquée apparaît comme une violation de Content Security Policy dans la console : ajoutez https://appsignal-endpoint.net à votre directive connect-src.
5. endpoint n’est pas défini. Sans endpoint, le SDK envoie vers l’origine courante. Cela nécessite un proxy sur votre domaine. Sinon, définissez-le sur https://appsignal-endpoint.net.

​

Les erreurs arrivent, les web vitals non

Les web vitals sont envoyées par lots, et non à chaque mesure. Elles sont envoyées quand la page est masquée, quand elle est fermée, et lors d’un changement de route côté client. Quittez la page ou changez d’onglet, puis regardez à nouveau la vue Performance. Si elles n’apparaissent toujours pas, vérifiez si les métriques manquantes sont précisément CLS et INP. Ces deux-là nécessitent des performance entries du navigateur qui peuvent être indisponibles.

​

Une erreur manque

• Elle s’est produite avant l’exécution d’init(). Rien de ce qui est levé avant n’est capturé. Importez votre configuration AppSignal en premier import de votre point d’entrée.
• C’était une répétition. Vérifiez les limites de débit sur les erreurs identiques et sur le total.
• Elle a été écartée par l’échantillonnage. Vérifiez si errors.sampleRate est inférieur à 1.0.
• beforeError l’a écartée. Un callback qui retourne null écarte l’erreur. Journalisez l’événement en début de callback pour confirmer ce qu’il reçoit.
• Elle a été levée dans un iframe. Un iframe de même origine a besoin de son propre appel à init().
• C’était une erreur de rendu React. React ne laisse pas les erreurs de rendu atteindre window. Ajoutez une error boundary.
• Elle venait d’un script sur un autre domaine. Lisez la section suivante.

​

Les erreurs de scripts cross-origin manquent

Si des erreurs provenant d’un script hébergé sur une autre origine manquent, vérifiez ses réglages cross-origin. Le navigateur peut n’exposer que Script error. pour les scripts cross-origin. Le SDK écarte ces erreurs opaques. Corrigez-le en servant ces scripts avec des en-têtes CORS, comme décrit dans les assets hébergés sur un CDN.

​

Les backtraces sont minifiées

Les backtraces sont résolues avec les sourcemaps, mises en correspondance sur la chaîne de révision. Définissez appVersion avec la même valeur que celle utilisée par votre build pour ses sourcemaps. Sans appVersion, il n’y a rien sur quoi établir la correspondance et les backtraces restent minifiées.

​

Une route produit des centaines de groupes d’erreurs

Le template de route est absent, donc les erreurs utilisent le chemin brut de chaque page. Appelez setRouteTemplate("/orders/:id") à chaque navigation de votre routeur. Les nouvelles erreurs se regroupent alors sous ce template. Le serveur déduit un template approximatif pour les web vitals. Un template explicite est plus fiable et aide à éviter la limite de routes distinctes.

​

La navigation côté client n’est pas rapportée

Le SDK et certains routeurs modifient tous les deux history.pushState. Le SDK se compose avec un patch déjà existant. Un routeur qui remplace ensuite le patch du SDK peut casser le suivi de la navigation. Importez votre configuration AppSignal avant votre routeur. Les routeurs à hash ne sont traités comme des routeurs que si le hash ressemble à une route, par exemple #/orders. Un simple #orders est indiscernable d’une ancre dans la page et n’est pas traité comme une navigation.

​

Les requêtes API échouent après l’activation du tracing distribué

Une requête cross-origin transportant traceparent peut nécessiter un preflight CORS. Si votre navigateur signale une erreur CORS mentionnant traceparent, autorisez cet en-tête dans le Access-Control-Allow-Headers de votre API. Pour en savoir plus, consultez le tracing distribué pour Browser.

​

Une requête échouée n’affiche aucun span back-end

L’erreur est bien arrivée, mais sa trace ne contient que le span du navigateur. Vérifiez que le service qui reçoit la requête rapporte via un collector hébergé. Son serveur HTTP a aussi besoin du bon package d’instrumentation pour lire traceparent.

​

Aucune requête échouée n’est rapportée

Les requêtes vers votre API échouent, mais aucun issue HTTPError ou TimeoutError n’apparaît. Vérifiez que chaque requête correspond à un motif dans tracePropagationTargets. Un motif doit comporter un hôte et un chemin : /api/** comme api.example.com ne correspondent à rien. Certains échecs ne sont jamais rapportés :

• Une requête effectuée en mode no-cors.
• Une réponse 4xx.
• Une requête correspondant à privacy.networkBlocklist.
• Un timeout alors que l’appareil est hors ligne.

Pour en savoir plus, consultez ce qui est rapporté.

​

Les breadcrumbs réseau n’ont pas de mesures de temps

La requête était cross-origin et le serveur n’a pas envoyé d’en-tête Timing-Allow-Origin. Pour en savoir plus, consultez lire les breadcrumbs réseau.

​

Obtenir de l’aide

Indiquez le nom de votre app, la version de @appsignal/browser, ainsi que le navigateur et la version où vous constatez le problème. Contactez-nous via nos canaux de support, ou dans notre communauté Discord pour les retours sur la beta.