Sentry-javascript: [Call for Feedback] Roteiro para o SDK do Sentry JavaScript v7

Criado em 13 ago. 2020  ·  18Comentários  ·  Fonte: getsentry/sentry-javascript

Olá amigos!

O Sentry ajuda cada desenvolvedor a diagnosticar e corrigir seu código. Estamos planejando começar a trabalhar em uma nova versão principal do SDK do JavaScript e queremos torná-lo nosso melhor software até hoje.

No entanto, para isso, precisamos de um feedback seu.

_Quais são os maiores pontos problemáticos ao usar o SDK?_
_Quais são os recursos que você mais sente falta?_
_O que você gostaria que mudasse?_

Já planejamos resolver alguns dos problemas listados abaixo:

  • descartar o suporte para IE10 e versões Node oficialmente obsoletas
  • reduzir drasticamente o tamanho geral do pacote
  • tornar o SDK mais modularizado
  • melhorar a compatibilidade de trepidação de árvores
  • retrabalhe integrações/extensões para trabalhar melhor com vários clientes

Ajude-nos a ajudá-lo, e deixe-nos saber seus pensamentos! Nós nos certificaremos de responder a todos os comentários, para que cada voz seja importante.

Felicidades!
Kamil

Breaking Discussion

Comentários muito úteis

Para mim, o objetivo drastically reduce overall bundle size também é o mais importante.

Todos 18 comentários

Minha maior reclamação sempre foi que minha biblioteca de log de erros é uma das minhas maiores bibliotecas de terceiros. Muitas vezes considero o carregamento lento do Sentry 5-10 segundos após o carregamento da primeira página para obter uma melhor pontuação de velocidade da página, por isso estou muito animado por você estar abordando isso ❤️

Para mim, o objetivo drastically reduce overall bundle size também é o mais importante.

Oi,

reduzir drasticamente o tamanho geral do pacote

Estou marcando isso com +1, caso isso mude alguma coisa. E vou adicionar isso: no meu aplicativo web , a inicialização do Sentry leva 30ms (em um computador rápido), o que é muito para um logger de diagnóstico, e no aplicativo React Native, é significativamente pior, porque seu bundler (Metro) não é capaz de sacudir a árvore, então o Sentry importa um enorme _78 arquivos_, e também contribui de forma mensurável (algumas %) para o tempo de inicialização.

Olá, apenas alguns dados do React Native:

image

Isso é perfilado em um iPhone X. O Sentry leva 54ms colossais no lançamento - ~40 apenas para importar a maior parte dos arquivos, ~15 para inicializar o código JS. Adicione a isso ~ 30ms bloqueando o thread principal para inicializar o lado _native_, e há algum tempo não contabilizado no lexing/parsing do JS do Sentry (do qual há muito) - suspeito de 5-15ms, mas não medi com precisão. No total - 90-100ms - são 15% do tempo total para iniciar meu aplicativo!

Ótima pergunta! Gostaria de ver opções de log mais flexíveis (ou como documentar) para aplicativos de produção em que você não deseja expor o usuário a nenhum console.log, mas deseja capturá-los como migalhas de pão. Isso pode resolver problemas como https://github.com/getsentry/sentry/issues/12618 e https://github.com/getsentry/sentry-javascript/issues/1883.

Talvez os breadcrumbs do Sentry possam se integrar a uma biblioteca de log como debug ou loglevel . Este parece ser um caso de uso comum para aplicativos de produção e talvez já seja compatível com algumas abordagens DIY, mas não está claro se isso é possível com base nos documentos atuais. (Ou se é e de alguma forma eu perdi, então eu ficaria grato por qualquer dica). Obrigado!

Oi, eu tenho uma recomendação sobre a inicialização do SDK.

Em vez de chamar Sentry.init com opções, o SDK pode verificar automaticamente uma SentryOptions como variável global nomeada para buscar id de DSN e outras opções.

Estamos carregando arquivos JS dinamicamente quando necessário e é difícil rastrear o evento de carregamento do pacote js em solicitações de domínio cruzado ou problemas de rede. A verificação automática dessa variável seria útil para isso e não há necessidade de chamar exclusivamente a função init.

_SDK falhou ao enviar indicação de evento_

Eu gostaria de ter algum tipo de indicação de que o capureEvent falhou ao enviar uma solicitação - para que ela possa ser enfileirada e tentada novamente mais tarde.

Isso seria realmente útil para aplicativos offline (aplicativos da Web progressivos).

Há situações em que o navegador está no estado online, mas a solicitação de rede falha devido a conexão/tempo limite instáveis ​​(ou seja, viajando por áreas com baixa cobertura de rede).

Existe uma integração Offline, mas depende dos eventos Online e Offline, o que não é suficiente para cobrir esse caso.

Erros de rede podem fazer com que aplicativos que não considerem tal situação lancem erros que não são registrados pelo Sentry e simplesmente desaparecem no vazio.

Tenho um projeto que é um PWA e não recebo eventos quando o aplicativo está offline, e não há como fazer uma sincronização em segundo plano no service worker, pois não está registrado para o domínio sentry ingest.

@edelvalle
Isso deve ser possível com o Workbox e seu plugin Background Sync ~, mas ainda não testei~
Parece funcionar bem, também a data do evento é a partir de quando ocorreu o erro.

// 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'
)

Oi, adoro ver drastically reduce overall bundle size está planejado. Temos um projeto gatsby+preact e o sentry ocupa aproximadamente 28% do tamanho do nosso pacote principal (27kb de 95kb). Estamos tentando trazer nosso pacote js por página para menos de 90kb para que nosso aplicativo possa ter um desempenho melhor em áreas rurais com conexões ruins. Um tamanho de SDK sentry drasticamente menor ajudaria muito.

Por que não abandonar o suporte ao IE11 também? Muitos sites grandes, incluindo a Microsoft, encerrarão o suporte a esse navegador até o final do ano. Claro que a questão é se isso realmente afeta o tamanho da biblioteca.

@kamilogorek alguma ideia de quando a v6 pode estar chegando?

Também concordo com @xr0master e acho que o suporte ao IE deve ser totalmente descartado, incluindo o IE11 na nova versão.

Quais são os maiores pontos problemáticos ao usar o SDK?

  • Importando. Mas eu acho que isso vai junto com a "agitabilidade da árvore", ou modularidade.
// 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'
  • Depuração da pilha de chamadas. Pode ser óbvio da perspectiva de como o Sentry é implementado, mas cada console.log parece se originar de instruments.js:1 , o que não é útil durante a depuração. Como console.trace é um exagero, acabo escrevendo breadcrumbs manualmente no meu console.log para obter informações sobre o que está sendo registrado no momento.

Quais recursos você mais sente falta?

Apoio à saúde .

Existem planos para usar o AsyncLocalStorage em versões do Node que o suportam?

Então nós enviamos 6.0.0 hoje, sem grandes mudanças além de enviar dados de sessão por padrão. cc @OmgImAlexis
Mudei o título desta edição para v7, o que deve refletir melhor isso.

Seria incrível expor as integrações do framework separadamente de Sentry.init . Isso endereçaria #3232 , no qual o Vue é carregado lentamente e, portanto, não é garantido que exista no momento da inicialização do sentry. Algo como Sentry.configureVue(Vue) que pode ser chamado no tempo de carregamento do Vue.

integração react-router para suportar o carregamento e descarregamento de um aplicativo react secundário dentro do mesmo documento com invocação lenta, usando seu próprio roteador e rotas mais específicas

Esta página foi útil?
0 / 5 - 0 avaliações