Erros de front-end no AppSignal

A visualização Errors lista os erros que seu front end relatou, agrupados em issues. Ela usa o mesmo modelo de issues que os erros de back-end. Você pode triar e atribuir essas issues da mesma forma.

​

Como os erros são agrupados

O AppSignal agrupa erros relacionados em issues com base na rota relatada e nas configurações de agrupamento da sua aplicação. Ocorrências repetidas podem aparecer como uma única issue para triar. A rota é aquela que o SDK relatou por meio de setRouteTemplate(), ou o caminho da página quando nada foi declarado. Sem um template, /orders/1 e /orders/2 são rotas de erro diferentes. Um mesmo bug pode assim virar duas issues.

​

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. Se ele aparecer primeiro no seu release mais recente, examine esse deploy.
• 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.

Ordene pela ocorrência mais recente para encontrar falhas novas. Ordene por volume para encontrar as mais frequentes.

​

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

Abra uma issue para inspecionar um sample: uma vez em que o erro aconteceu no navegador de um usuário. O sample traz a mensagem de erro e o que aconteceu ao redor dela.

1. Leia a mensagem. Ela diz o que falhou. Por exemplo, POST https://api.example.com/orders: HTTP 503 significa que a API de checkout retornou um erro de servidor.
2. Verifique o backtrace em busca de erros JavaScript. Ele mostra onde o erro aconteceu no seu código. Se você ver código minificado em vez de nomes de arquivo e linhas legíveis, envie os sourcemaps da versão definida em appVersion.
3. Leia os breadcrumbs. Eles mostram eventos antes do erro, como a seleção de um botão ou uma requisição de rede. Se o usuário selecionou Pay pouco antes de /orders levar três segundos, verifique primeiro essa requisição à API.
4. Verifique a versão e as tags. Compare a versão do sample com seus deploys recentes. Use tags definidas com setTags() para restringir quem foi afetado.

Uma requisição à API malsucedida relatada como HTTPError ou TimeoutError não tem backtrace de JavaScript. Na página completa da issue, selecione Traces e, em seguida, Fullscreen no card Trace timeline para inspecionar seu span de navegador. Se o back end continuou o trace, os spans dele aparecem ali também. No painel lateral “Browser Errors”, use Open full trace page para chegar à página completa da issue. Você pode exportar um sample como JSON ou Markdown para compartilhá-lo com seu time. Use o registro da issue para anotar o que encontrou.

​

Triagem e notificações

Você pode atribuir, silenciar e mudar o estado dessas issues. Elas também têm suporte a configurações de notificação. 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ê migrar do @appsignal/javascript, configure as notificações para browser. As configurações para frontend 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. Por exemplo, erros antes de init() e erros dentro de iframes não instrumentados. Erros opacos de script cross-origin são descartados. 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.