Skip to main content
Browser monitoring é uma funcionalidade em beta do AppSignal Labs. O pacote @appsignal/browser é publicado sob a tag beta no npm, e sua configuração e API ainda podem mudar entre releases beta. Compartilhe seu feedback na nossa comunidade no Discord.
A visualização Errors lista os erros que seu front end relatou, agrupados em issues. É o mesmo modelo de issues que seus erros de back-end usam, então tudo o que você já faz com uma exceção de Ruby ou Node.js funciona aqui também.

Como os erros são agrupados

Ocorrências do mesmo tipo de erro na mesma rota se tornam uma issue. Um bug que dispara dez mil vezes é uma coisa para triar, em vez de dez mil notificações. A rota é aquela que o SDK relatou por meio de setRouteTemplate(), ou o caminho da página quando nada foi declarado. É por isso que declarar templates importa: sem eles, /orders/1 e /orders/2 são rotas diferentes, e um bug se fragmenta em uma issue por pedido.

Lendo a lista de issues

Cada issue na lista traz:
  • A classe do erro e a mensagem, com a rota em que aconteceu.
  • A versão em que foi introduzido, que muitas vezes é a forma mais rápida de identificar uma regressão: uma issue nova no seu release mais recente é um release que você provavelmente quer examinar.
  • Uma tendência para o período selecionado, para que um pico se leia de forma diferente de um fluxo constante.
  • O número total de ocorrências no período.
  • Quando foi visto pela última vez.
  • Para quem está atribuído.
Você pode ordenar pela ocorrência mais recente ou por volume, dependendo se está triando o que acabou de quebrar ou o que quebra mais.

Filtrando por tempo e versão

  • Intervalo de tempo. Predefinições de uma hora a 30 dias, ou um intervalo personalizado.
  • Versão. Restrinja a lista aos erros relatados por um único release. Combinado com a coluna de introdução, é assim que você confirma se um deploy é o responsável.

Investigando uma issue

Abrir uma issue mostra um sample do erro: quando aconteceu, a página em que aconteceu e o deploy em que apareceu primeiro, junto com quatro coisas a partir das quais você depura.
  • A mensagem de erro, completa. É aí que está o significado. TypeError quase nada diz por si só, enquanto Failed to fetch dynamically imported module informa que um chunk carregado sob demanda nunca chegou.
  • As tags que você definiu com setTags(), exibidas ao lado do user agent e da revisão, se você definiu appVersion. Alguns nomes de tag fazem mais do que filtrar. Marque com country_code ou browser e você obtém distribuições de atributos, que mostram quais países ou navegadores veem mais erros. Templates de link transformam uma tag em link, de modo que uma tag user_id pode abrir aquele usuário no seu próprio painel administrativo.
  • O backtrace, que você pode ler completo ou restrito à sua própria aplicação. Stacks de front-end são muitas vezes quase inteiramente frames de framework. Uma falha de removeChild vinda do React chega como uma parede de frames react-dom sem nada seu à vista, e a visualização da aplicação é o que corta esse ruído.
  • A linha do tempo de breadcrumbs que levou ao erro, que geralmente é a parte que te salva.
Cada breadcrumb carrega seus próprios detalhes. Uma entrada de rede mostra o método, a URL, o status da resposta e quanto tempo a requisição levou. Uma entrada de seleção mostra qual elemento o usuário selecionou. Uma entrada de long task nomeia o script que bloqueou a thread principal, e por quanto tempo. Um rastro que vai de uma seleção, passando por uma requisição GraphQL que levou quase três segundos, até o próprio erro é muitas vezes a explicação inteira, sem reproduzir nada. Backtraces de um bundle minificado são resolvidos por meio de sourcemaps, correspondidos pela versão da aplicação. Sem uma versão definida, os backtraces permanecem minificados. Um sample pode ser exportado como JSON ou Markdown, que é a maneira mais rápida de anexá-lo a um ticket ou entregá-lo a um assistente. Cada issue também tem um registro, onde você e seu time deixam notas em Markdown sobre o que encontraram.

Triagem e notificações

Issues podem ser atribuídas, receber um estado, ser silenciadas e configuradas com suas próprias configurações de notificação, e o restante das ferramentas de incidentes do AppSignal também funciona com elas. Leia mais em Errors. Como erros de front-end ficam no namespace browser (veja namespaces), essas configurações são separadas das do seu back end. Se você está migrando do @appsignal/javascript, note que os erros dele eram relatados em frontend, então as configurações de notificação que você fez lá não são transferidas. Leia mais no guia de migração.

Erros que você não vai encontrar aqui

Alguns erros nunca chegam ao SDK, incluindo os lançados antes da inicialização dele, os de scripts cross-origin servidos sem cabeçalhos CORS e os dentro de iframes. Cada um tem uma solução alternativa, listada em erros que não são relatados. Se um erro que você esperava está faltando, percorra a solução de problemas.