Sentry-javascript: [Appel à commentaires] Feuille de route vers Sentry JavaScript SDK v7

Créé le 13 août 2020  ·  18Commentaires  ·  Source: getsentry/sentry-javascript

Salut les amis!

Sentry aide chaque développeur à diagnostiquer et à corriger son code. Nous prévoyons de commencer à travailler sur une nouvelle version majeure du SDK JavaScript et nous voulons en faire notre meilleur logiciel à ce jour.

Cependant, pour ce faire, nous avons besoin de vos commentaires.

_Quels sont les plus gros problèmes lors de l'utilisation du SDK ?_
_Quelles fonctionnalités vous manquent le plus ?_
_Qu'aimeriez-vous changer ?_

Nous prévoyons déjà de résoudre certains des problèmes énumérés ci-dessous :

  • suppression de la prise en charge d'IE10 et des versions de Node officiellement dépréciées
  • réduire considérablement la taille globale du paquet
  • rendre le SDK plus modulaire
  • améliorer la compatibilité avec le tremblement des arbres
  • retravailler les intégrations/extensions pour mieux fonctionner avec plusieurs clients

Aidez-nous à vous aider et faites-nous part de vos commentaires ! Nous nous assurerons de répondre à tous les commentaires, donc chaque voix compte.

Acclamations!
Kamil

Breaking Discussion

Commentaire le plus utile

Pour moi, l'objectif drastically reduce overall bundle size est aussi le plus important.

Tous les 18 commentaires

Mon plus gros reproche a toujours été que ma bibliothèque de journalisation des erreurs est l'une de mes plus grandes bibliothèques tierces. J'ai souvent envisagé de charger Sentry paresseux 5 à 10 secondes après le chargement de la première page pour obtenir un meilleur score de vitesse de page, donc je suis très heureux que vous vous penchiez sur ce problème ❤️

Pour moi, l'objectif drastically reduce overall bundle size est aussi le plus important.

Salut,

réduire considérablement la taille globale du paquet

Je donne +1 à cela, au cas où cela changerait quelque chose. Et j'ajouterai ceci : dans mon application Web , l'initialisation de Sentry prend 30 ms (sur un ordinateur rapide), ce qui est beaucoup trop pour un enregistreur de diagnostic, et dans l'application React Native, c'est nettement pire, car son bundler (Metro) n'est pas capable de secouer les arbres, Sentry importe donc un énorme _78 fichiers_, et contribue également de manière mesurable (quelques %) au temps de démarrage.

Salut, juste quelques données de React Native :

image

Ceci est profilé sur un iPhone X. Sentry prend 54 ms au lancement - ~ 40 juste pour importer la majeure partie des fichiers, ~ 15 pour initialiser le code JS. Ajoutez à cela ~ 30 ms bloquant le thread principal pour initialiser le côté _natif_, et il y a un certain temps non pris en compte dans le lexing/parsing JS de Sentry (dont il y en a beaucoup) - je soupçonne 5-15 ms, mais je n'ai pas mesuré avec précision. Au total - 90-100ms - c'est 15% du temps total pour lancer mon application !

Excellente question ! J'aimerais voir des options de journalisation plus flexibles (ou comment documenter) pour les applications de production où vous ne voulez pas exposer l'utilisateur à des consoles.log, mais vous voulez qu'elles soient capturées sous forme de fil d'Ariane. Cela pourrait résoudre des problèmes tels que https://github.com/getsentry/sentry/issues/12618 et https://github.com/getsentry/sentry-javascript/issues/1883.

Peut-être que les fils d'Ariane Sentry pourraient s'intégrer à une bibliothèque de journalisation telle que debug ou loglevel . Cela semble être un cas d'utilisation courant pour les applications de production, et peut-être qu'il est déjà pris en charge par certaines approches de bricolage, mais il n'est pas vraiment clair si cela est possible sur la base de la documentation actuelle. (Ou si c'est le cas et que je l'ai manqué d'une manière ou d'une autre, alors je vous serais reconnaissant de tout conseil). Merci!

Salut, j'ai une recommandation sur l'initialisation du SDK.

Au lieu d'appeler Sentry.init avec des options, le SDK peut vérifier automatiquement une SentryOptions comme une variable globale nommée pour récupérer l'identifiant DSN et d'autres options.

Nous chargeons dynamiquement les fichiers JS lorsque cela est nécessaire et il est difficile de suivre l'événement de chargement du bundle js dans les demandes inter-domaines ou les problèmes de mise en réseau. La vérification automatique de cette variable serait utile pour cela et il n'est pas nécessaire d'appeler exclusivement la fonction init.

_SDK n'a pas réussi à envoyer l'indication d'événement_

J'aimerais avoir une sorte d'indication que le capureEvent n'a pas réussi à envoyer une demande - afin qu'il puisse être mis en file d'attente et réessayé plus tard.

Ce serait vraiment utile pour les premières applications hors ligne (applications Web progressives).

Il existe des situations dans lesquelles le navigateur est en ligne, mais la demande de réseau échoue en raison d'une connexion/d'un délai d'attente irréguliers (c'est-à-dire de déplacements dans des zones avec une mauvaise couverture réseau).

Il existe une intégration hors ligne, mais elle repose sur les événements en ligne et hors ligne, ce qui n'est pas suffisant pour couvrir ce cas.

Les erreurs de réseau peuvent amener une application qui ne considère pas une telle situation à générer des erreurs qui ne sont pas enregistrées par Sentry et qui disparaissent simplement dans le vide.

J'ai un projet qui est un PWA et je ne reçois pas d'événements lorsque l'application est hors ligne, et il n'y a aucun moyen d'effectuer une synchronisation en arrière-plan dans le service worker, car il n'est pas enregistré pour le domaine d'ingestion de sentinelle.

@edelvalle
Cela devrait être possible avec Workbox et son plugin Background Sync ~, mais je ne l'ai pas encore testé ~
Cela semble bien fonctionner, la date de l'événement est également celle à laquelle l'erreur s'est produite.

// service-worker.js
import { registerRoute } from 'workbox-routing'
import { NetworkOnly } from 'workbox-strategies'
import { BackgroundSyncPlugin } from 'workbox-background-sync'

registerRoute(
  new RegExp('^https://[^\\.]+\\.ingest\\.sentry\\.io/api/.*$'),
  new NetworkOnly({
    plugins: [
      new BackgroundSyncPlugin('project-name/sentry-event-queue', {
        maxRetentionTime: 7 * 24 * 60, // 7 days
      })
    ],
  }),
  'POST'
)

Salut, l'amour de voir drastically reduce overall bundle size est prévu. Nous avons un projet gatsby+preact et sentinelle occupe environ 28 % de la taille de notre paquet principal (27 ko sur 95 ko). Nous essayons de ramener notre bundle js par page sous 90 Ko afin que notre application puisse mieux fonctionner dans les zones rurales avec de mauvaises connexions. Une taille de SDK sentinelle considérablement plus petite aiderait beaucoup.

Pourquoi ne pas abandonner la prise en charge d'IE11 non plus ? De nombreux grands sites, dont Microsoft, cesseront de prendre en charge ce navigateur d'ici la fin de l'année. Bien sûr, la question est de savoir si cela affecte vraiment la taille de la bibliothèque.

@kamilogorek une idée de la date de sortie de la v6 ?

Je suis également d'accord avec @xr0master et pense que la prise en charge d'IE devrait être entièrement supprimée, y compris IE11 dans la nouvelle version.

Quels sont les plus gros problèmes lors de l'utilisation du SDK ?

  • Importation. Mais je suppose que cela va de pair avec la « maniabilité de l'arbre », ou la modularité.
// This is not nice, as it doesn't get auto-completion when importing
import * as Sentry from '@sentry/browser'

// This is better, but has given me problems on Sentry 5.x
import { captureException } from '@sentry/browser'
  • Débogage de la pile d'appels. Cela peut être évident du point de vue de la façon dont Sentry est implémenté, mais chaque console.log semble provenir de instruments.js:1 , ce qui n'est pas utile lors du débogage. Étant donné que console.trace est exagéré, je finis par écrire des fils d'Ariane manuellement dans mon console.log pour obtenir des informations sur ce qui est actuellement enregistré.

Quelles fonctionnalités vous manquent le plus ?

Soutien à la santé .

Existe-t-il des projets d'utilisation d'AsyncLocalStorage sur les versions de nœud qui le prennent en charge ?

Nous avons donc expédié 6.0.0 aujourd'hui, sans aucun changement majeur à part l'envoi des données de session par défaut. cc @OmgImAlexis
J'ai changé le titre de ce numéro en v7, ce qui devrait mieux refléter cela.

Ce serait génial d'exposer les intégrations du framework séparément de Sentry.init . Cela adresserait #3232 , dans lequel Vue est chargé paresseusement, et n'est donc pas garanti d'exister au moment de l'initialisation de la sentinelle. Quelque chose comme Sentry.configureVue(Vue) qui peut être appelé au moment du chargement de Vue.

Intégration de react-router pour prendre en charge le chargement et le déchargement d'une application de réaction secondaire dans le même document avec une invocation paresseuse, en utilisant son propre routeur et des itinéraires plus spécifiques

Cette page vous a été utile?
0 / 5 - 0 notes