Comme c’est l’expérience de la plupart des équipes d’ingénierie B2B SaaS, une question qui nous est souvent posée est la suivante : “Utilisez-vous Bugsnag vous-même ?” La réponse est : « Nous le faisons ». De plus, chez Bugsnag, nous pensons que pour fournir la meilleure solution de surveillance des erreurs et de gestion de la stabilité, nous devons également être les pionniers et les leaders d’opinion en matière de dette technique, d’application de santé et de workflows de débogage efficaces.
Alors oui, nous utilisons Bugsnag pour surveiller Bugsnag – tout, de notre API Rails à notre tableau de bord React. Et en tant qu’experts de la surveillance des erreurs d’application, nous aimerions partager avec vous nos sept meilleures pratiques pour surveiller les erreurs dans les applications JavaScript. Les applications JavaScript ont leurs propres défis lorsqu’il s’agit d’intercepter des exceptions. Compte tenu de la pléthore de navigateurs Internet, de versions, de bots et d’autres variables, il est souvent tentant de simplement ignorer le bruit.
Bien que le débogage des applications soit notre pain quotidien, nous savons également, en tant qu’ingénieurs logiciels, qu’une expérience utilisateur réussie repose sur plus que la stabilité du logiciel, y compris les performances et la fiabilité. Il est judicieux de prendre en compte la taille de votre application JavaScript car elle peut affecter la vitesse et les temps de chargement. Vous pouvez lire notre blog sur Comment rendre votre bundle JS vraiment petit en 4 étapes faciles pour obtenir des conseils utiles de notre ingénieur en plates-formes, Ben Gourley !
Très bien, passons à côté de cette introduction et entrons dans les bonnes choses. Ce guide vous est fourni par notre ingénieur solutions, Rosty Sokolov. Il travaille en étroite collaboration avec nos clients qui vont des PME aux grandes organisations d’ingénierie d’entreprise, et il a recueilli plusieurs conseils pour optimiser votre surveillance des erreurs pour les applications JS. Nous espérons que vous apprécierez la lecture de ce guide sur les meilleures pratiques pour la surveillance des erreurs JavaScript.
- Configurer les domaines autorisés
La configuration des domaines autorisés est un moyen puissant d’éliminer de nombreuses erreurs JavaScript bruyantes dont vous ne vous souciez pas. Bugsnag vous permet d’ajouter votre domaine à une liste de domaines autorisés, afin que vous puissiez automatiquement ignorer les erreurs qui se produisent sur d’autres domaines, même s’ils utilisent votre clé API. De cette façon, vous pouvez vous concentrer sur les erreurs que vous savez provenir de votre code JavaScript.
Par exemple, si vous chargez des scripts de débogage ou des scripts tiers à partir d’un autre domaine, la configuration des domaines autorisés vous permet d’ignorer automatiquement les erreurs de ces scripts. Cela vous évite également des ennuis si quelqu’un copie-colle tout votre JavaScript sur un autre site Web ou un fichier local et commence à faire des choses étranges avec lui qui génèrent des erreurs – quelque chose qui est malheureusement courant pour les grands sites.
- Supprimer les exceptions des extensions de navigateur
Les extensions de navigateur sont un défi lorsqu’il s’agit de mettre en place une bonne surveillance frontale. Au-delà de la multitude de navigateurs parmi lesquels choisir, chacun est également unique en raison du large éventail d’extensions de navigateur que vos utilisateurs peuvent installer. Certains feront probablement planter votre JavaScript, créant du bruit que vous voudrez ignorer. Étant donné que ces plantages seront pour la plupart sans rapport avec votre code, les supprimer est une bonne stratégie pour configurer votre surveillance des erreurs frontales.
Dans Bugsnag, nous ignorons automatiquement les erreurs avec les fichiers d’extension de navigateur dans la trace de la pile, donc aucune configuration n’est nécessaire pour gérer les extensions de navigateur dans la plupart des cas.
- Ignorer les anciens navigateurs
Les anciennes versions des navigateurs sont beaucoup plus difficiles à gérer car elles sont plus susceptibles de planter, et beaucoup ne vous donnent même pas de traces de pile avec des rapports d’erreurs. Étant donné que moins d’utilisateurs exécutent encore ces anciennes versions, elles peuvent être moins importantes à prendre en charge. En désactivant les notifications de plantages dans les anciennes versions de navigateur, vous pouvez vous concentrer sur la correction des erreurs affectant la majorité des utilisateurs.
- Utiliser des cartes sources
L’information la plus utile que vous utiliserez probablement pour déboguer en JavaScript – et dans n’importe quel langage, d’ailleurs – est la ligne de code spécifique qui s’est écrasée. La plupart d’entre vous minimisent probablement votre code JavaScript. Si tel est le cas, vous devrez configurer des cartes source. Les cartes source, comme leur nom l’indique, mappent votre code minifié à vos lignes de code réelles. Ils suppriment automatiquement les erreurs afin que ce que vous voyez dans Bugsnag soit instantanément lisible et reconnaissable.
Un autre avantage de l’utilisation des cartes source est lié à la façon dont Bugsnag regroupe vos erreurs. Bugsnag regroupe les erreurs par la même cause première et les cartes sources nous permettent d’appliquer notre logique de regroupement à votre code. Par exemple, en JavaScript, nous pouvons regrouper en fonction du code environnant en utilisant des arbres de syntaxe abstraite qui remplacent les éventuels identifiants (noms de variables, noms de fonctions, etc.) et en appliquant une structure générale qui regroupe le code de manière fiable.
- Hiérarchiser les erreurs des utilisateurs concernés
La surveillance JavaScript peut être bruyante, donc regarder le nombre d’erreurs brutes seul ne vous donnera pas un aperçu complet de la santé de votre application. Dans certains cas, un grave pic d’erreurs peut n’affecter qu’un seul utilisateur. Bien que vous puissiez certainement passer du temps à enquêter sur cette erreur, cela ne vaut probablement pas votre temps. Si vous pouvez commencer à hiérarchiser les erreurs en fonction du nombre d’utilisateurs concernés, vous pouvez commencer à prendre des décisions basées sur les données et adopter une approche pragmatique du débogage.
En prenant du recul par rapport à l’objectif d’une seule erreur et en tenant compte de la santé globale de votre application, vous voudrez prendre en compte la stabilité de l’utilisateur, qui est l’une des deux façons de mesurer la stabilité de l’application. Alerte spoiler : Bugsnag mesure les deux ! La stabilité peut être calculée sous la forme d’un pourcentage de sessions réussies sur une période donnée (stabilité de la session) ou sous la forme d’un pourcentage d’utilisateurs ayant connu des sessions réussies sur une période donnée (stabilité de l’utilisateur). Vous pouvez facilement afficher ces scores dans le centre de stabilité et basculer entre les calculs de stabilité que vous préférez afficher par défaut.
- Filtrer le trafic des bots
Le trafic de bot décrit tout trafic non humain vers un site Web ou une application. Bien qu’une partie du trafic de robots soit bénéfique, le trafic de robots abusif peut être très perturbateur. La distinction entre les robots et les utilisateurs réels est importante lorsqu’il s’agit de surveiller les erreurs. Par exemple, si votre site Web connaît un énorme pic d’erreurs provenant d’utilisateurs réels, cela nécessite probablement une attention immédiate. D’autre part, si un pic d’erreurs est attribué aux bots, l’attention doit être portée sur la gestion du trafic des bots. Cela peut faire économiser à votre équipe une quantité importante de temps perdu en débogage.
Il est courant que les équipes JS aient des outils en place pour identifier le trafic des bots. En utilisant les filtres personnalisés de Bugsnag, vous pouvez comprendre l’impact des bots sur la stabilité de votre application. À l’aide de métadonnées personnalisées, votre équipe peut tirer parti des diagnostics de bot pour identifier si un utilisateur est un bot.
Vous pouvez même créer un signet pour accéder facilement aux erreurs excluant le trafic de robots.
sept. Attribuez des numéros de version à votre JS
Les gens peuvent garder une seule fenêtre de navigateur ouverte pendant des jours sans l’actualiser, il n’y a donc aucune garantie que votre déploiement actuel inclut le code qui a provoqué une erreur. Dans Bugsnag, nous vous permettons de suivre facilement les déploiements JavaScript en attribuant des numéros de version.
Attribuer à votre JavaScript un numéro de version unique vous permet de savoir si vous avez vraiment corrigé un bogue avec le dernier déploiement (et peut-être remarquez-vous une poignée d’erreurs provenant d’anciennes versions), ou si vous voyez toujours le même bogue qui traîne dans votre nouveau code.
Nous espérons que vous avez apprécié la lecture de ce guide sur les meilleures pratiques pour la surveillance des erreurs JavaScript. Y a-t-il de nouveaux conseils ci-dessus que vous n’avez pas essayés auparavant ? Il y a beaucoup plus à découvrir et à discuter en ce qui concerne les erreurs JavaScript. Pour commencer, vous pouvez lire notre blog sur l’anatomie d’une erreur JavaScript. Si vous êtes nouveau sur Bugsnag, nous vous encourageons à explorer notre site Web et à en savoir plus sur la surveillance des erreurs JavaScript de Bugsnag.
Si vous vous retrouvez avec d’autres questions ou si vous souhaitez faire appel à nos cerveaux, faites-nous signe sur Twitter @bugsnag, et nous serons heureux de discuter avec vous !
Également publié ici.
CHARGEMENT EN COURS
. . . & commentaires Suite!