Este tópico responde às perguntas mais frequentes sobre o subserviço Browser Monitoring do Application Real-Time Monitoring Service (ARMS).
Perguntas frequentes sobre faturamento
Perguntas frequentes sobre uso
Por que os nomes de algumas páginas ou APIs monitoradas contêm asteriscos (*)?
Por que a lista de PVs difere da lista de velocidade de página?
Quais são as diferenças entre as configurações do console e o método setConfig?
É possível capturar erros JS retornados pelo método console.error?
No ambiente Weex, por que um UID definido para um mini program não entra em vigor?
Após ativar o ARMS Pro Edition, posso continuar usando os sites criados durante o período de teste?
Por que os PVs da mesma página diferem entre os módulos no console do ARMS?
Por que o valor do parâmetro duration é menor que o do parâmetro connect download?
O que fazer se houver dúvida sobre o carregamento do SDK ao chamar o método __bl.performance()?
O Browser Monitoring do ARMS suporta a captura automática de erros de requisição gRPC?
O que fazer se a página do console do ARMS não abrir ou aparecer em branco?
O Browser Monitoring do ARMS (RUM) suporta filtragem e consulta de dados por campos personalizados?
Por que algumas URLs ou APIs monitoradas contêm asteriscos (*)?
As estatísticas de página do Browser Monitoring são obtidas com base nas URLs reais das páginas e calculadas por dimensão. Os asteriscos () nos nomes das páginas ou APIs monitoradas não fazem parte das URLs originais. Eles indicam o resultado da convergência de URLs. Portanto, um nome contendo asterisco () não representa uma URL específica, mas sim um grupo de URLs semelhantes.
Por exemplo, no console do ARMS, acesse a página Page Satisfaction Ranking no grupo Application do painel de navegação à esquerda. Essa página exibe a contagem de satisfação para cada URL de página. As URLs que passaram pelo processo de convergência conterão um asterisco (*).
Funcionamento da convergência de URLs
Problema: Variáveis dificultam o monitoramento ou a análise de URLs semelhantes.
Objetivo: Agrupar URLs semelhantes substituindo variáveis por asteriscos (*).
-
Solução: Utilizar o algoritmo proprietário de convergência de URLs da Alibaba Cloud para agrupar URLs semelhantes e reduzir a quantidade total de URLs. Dessa forma, preserva-se o máximo de informações semânticas possível enquanto se diminui o volume de URLs. Esse processo ocorre em duas etapas:
Agregação: Reúne URLs semelhantes em um único grupo.
Identificação de variáveis: Extrai as variáveis das URLs do mesmo grupo e as substitui por asteriscos (*).
Solução
Para obter informações sobre como desativar a convergência de URLs, consulte urlHelper.
Por que a lista de PVs difere da lista de velocidade de página?
Isso ocorre porque sua aplicação é uma single-page application (SPA) e o recurso de resolução automática de SPA está ativado. Em cenários de SPA, as visualizações de página (PVs) e a velocidade da página são medidas pelos seguintes métodos:
PVs: Quando um evento hashchange é acionado, os dados de PV são reportados automaticamente para registrar as visualizações da página com base no valor do hash. Assim, ao visualizar a lista de PVs de uma SPA, você vê os PVs exatos das páginas de hash.
Velocidade da página: Quando o valor do hash de uma SPA muda, a velocidade da página permanece inalterada. Por isso, a velocidade não é registrada com base no hash. Isso evita relatórios desnecessários e mantém a clareza do desempenho da página.
Nenhum trace ID foi encontrado nos logs de API e, consequentemente, o redirecionamento para a página de monitoramento de aplicações falha. Por que isso acontece?
Faça login no console do ARMS.
No painel de navegação à esquerda, escolha Frontend Monitoring > Browser Monitoring e clique em no nome da aplicação desejada.
No painel de navegação à esquerda, escolha .
-
Na aba Access Steps, verifique se a opção Associate with Application Monitoring está selecionada na configuração do seu agente ARMS. Caso contrário, selecione-a e reinstale o agente ARMS na sua aplicação frontend.
Essa opção encontra-se na seção SDK Extension Configuration da aba Advanced Settings.
Verifique se os trace IDs estão sendo gerados nos logs de API. Se nenhum trace ID for gerado, prossiga para a Etapa 5.
-
Verifique se o nome de domínio usado na requisição da página é igual ao nome de domínio usado na requisição da API. Se forem diferentes, trata-se de acesso cross-domain. Nesse caso, os trace IDs não são gerados para evitar falhas na requisição da API causadas por autenticação cross-domain.
Para obter informações sobre como resolver esse problema, consulte Usar o recurso de rastreamento front-to-back para diagnosticar erros de API.
Por que o erro de arquivo Source Map é exibido durante a solução de problemas de erros JavaScript (JS)?
Certifique-se de que o sufixo do arquivo seja .js.map.
Garanta que sua conta tenha permissões de escrita no ARMS. Se não possuir essas permissões, entre em contato com o administrador.
Quais são as diferenças entre as configurações do console e o método setConfig?
As configurações do console apenas aceleram a geração do código de configuração, e o código gerado só entra em vigor após a publicação. No entanto, as modificações feitas ao chamar o método setConfig têm efeito imediato.
A página Application Settings no console do Browser Monitoring oferece várias opções de configuração, como Enable FMP Collection for First Screen, Enable Page Resource Reporting, Associate with Application Monitoring, Enable User Behavior Replay e Enable Console Tracking. O console gera automaticamente o código do agente correspondente com base nas suas seleções e suporta três métodos de integração: asynchronous loading, synchronous loading e NPM package.
Além disso, as configurações do console são válidas apenas quando você inicializa o ARMS para monitorar uma aplicação. Quando a aplicação já estiver sendo monitorada pelo ARMS, será necessário chamar o método setConfig para modificar as configurações.
Como configurar o ambiente e a versão em um SDK?
Defina o parâmetro release para comparar versões. Para mais informações, consulte Referência do SDK. Também é possível definir o parâmetro environment para distinguir ambientes diferentes. Para mais detalhes, veja Referência do SDK.
O valor prod indica um ambiente de produção.
O valor gray indica um ambiente de lançamento gradual.
O valor pre indica um ambiente de staging.
O valor daily indica um ambiente diário.
O valor local indica um ambiente local.
Como visualizar o número da versão de uma configuração?
Faça login no console do ARMS.
No painel de navegação à esquerda, escolha Frontend Monitoring > Browser Monitoring e clique em no nome da aplicação desejada.
-
No painel de navegação à esquerda, escolha .
O número da versão de cada log é exibido na coluna Version Number da seção Logs. Na página View Details, visualize a coluna Version Number correspondente a cada log. Se nenhuma versão estiver configurada, essa coluna exibirá Not specified.
Também é possível filtrar logs por ambiente e versão na menu bar. O filtro de versão só pode ser utilizado após a definição de um número de versão para seus logs de PV.
Como visualizar o TP de um usuário em uma página?
Faça login no console do ARMS.
No painel de navegação à esquerda, escolha Frontend Monitoring > Browser Monitoring e clique em no nome da aplicação desejada.
No painel de navegação à esquerda, escolha .
Na lista de sessões, clique em no Session ID da sessão desejada para visualizar a página Session Tracking Details.
Passe o ponteiro do mouse sobre a área Timeline na coluna Visit Timeline para visualizar o tempo na página (TP).
Como visualizar as métricas de desempenho personalizadas do Browser Monitoring?
Faça login no console do ARMS.
No painel de navegação à esquerda, escolha Frontend Monitoring > Browser Monitoring e clique em no nome da aplicação desejada.
No painel de navegação à esquerda, escolha .
As métricas de desempenho personalizadas aparecem na seção Page Speed.
O que fazer se a configuração do ARMS não entrar em vigor?
Uma causa provável é o cache do navegador não estar atualizado. Para resolver esse problema, execute as seguintes operações: No painel de navegação à esquerda do console do ARMS, escolha Application > View Details. Alterne para a versão mais recente para visualizar o gráfico de tendências. Se o número da versão não estiver configurado, defina o parâmetro release do SDK do ARMS. Para mais informações, consulte Referência do SDK. Após definir o parâmetro release, verifique se o valor especificado aparece como a versão mais recente.
Se o console não exibir nenhum dado de monitoramento após a integração do SDK, verifique se o script de inicialização do ARMS RUM SDK está posicionado dentro da tag <body> do seu arquivo HTML. Se o script estiver na tag <head> ou em outro local, o reporte de dados pode falhar. Ajuste a posição do script e faça uma nova implantação para validar.
Por que erros JS em mini programs não são reportados?
Isso pode ocorrer porque mensagens de erro são capturadas pela instrução trycatch na camada subjacente dos mini programs em modo assíncrono, impedindo o upload das mensagens. É possível reportar manualmente as mensagens de erro. Para mais informações, consulte Referência da API.
É possível capturar erros JS retornados pelo método console.error?
Sim, erros JS retornados pelo método console.error podem ser capturados. Os navegadores web reportam as mensagens de erro que atendem aos requisitos de formato de erros JS.
No mini program, você pode reportar mensagens de erro manualmente. Para mais informações, consulte Referência da API.
No ambiente Weex, por que um UID definido para um mini program não entra em vigor?
Se você não chamou o método setConfig, verifique se especificou um UID durante a configuração de inicialização. Caso não tenha especificado, defina um.
Se já tiver chamado o método setConfig, especifique outro UID e chame o método novamente.
Por quanto tempo os logs podem ser armazenados?
ARMS Basic Edition: Os logs podem ser armazenados por até sete dias.
ARMS Pro Edition: Os logs podem ser armazenados por até 30 dias.
Após ativar o ARMS Pro Edition, posso continuar usando os sites criados durante o período de teste?
Não, não é possível continuar usando esses sites. Dentro de 15 dias após o término do período de teste, os sites são suspensos devido a pagamentos pendentes. Você pode tentar reiniciar a aplicação.
Se o ARMS Pro Edition não for ativado dentro de 15 dias após o fim do período de teste, os sites serão excluídos para economizar seus recursos de computação e armazenamento. Os recursos relevantes são liberados e os dados neles contidos não podem ser recuperados.
Quais números de versão são usados pela edição de aplicação e pela edição host do ARMS?
A edição de aplicação utiliza o número de versão do projeto online atual. Defina o parâmetro release do SDK do ARMS para especificar o número de versão da edição de aplicação. Para mais informações, consulte Referência do SDK.
A edição host utiliza o número de versão do app onde o projeto atual reside. O SDK obtém automaticamente o número de versão da edição host. A versão de um app hospedado não pode ser resolvida. Apenas as versões do Taobao, Alipay ou WeChat são resolvidas.
Por que os PVs da mesma página diferem entre os módulos no console do ARMS?
Na página Page Speed, o número de PVs equivale ao número de entradas no log de desempenho multiplicado pela taxa de amostragem.
Na página Page, em Dimensions, o número de PVs corresponde ao valor mostrado no log de PV.
Os logs de desempenho com reporte automático são enviados somente após o carregamento das páginas. Um log de desempenho é reportado sempre que a página é atualizada.
Após ativar o modo SPA, os logs de PV são reportados cada vez que as rotas são alternadas. No modo SPA, o número de logs de desempenho é menor que o número de logs de PV. Isso resulta em uma grande diferença nos PVs entre os diferentes módulos.
Por que o valor do parâmetro duration é menor que o do parâmetro connect download?
Os dados de desempenho de carregamento de recursos do ARMS são obtidos de performance.getEntriesByType('resource'). Por padrão, quando existem restrições de cross-origin para acessar detalhes de temporização de recursos da página, os valores obtidos de performance.getEntriesByType('resource') para os seguintes campos nos dados de desempenho de recursos cross-origin são 0.
redirectStart
redirectEnd
domainLookupStart
domainLookupEnd
connectStart
connectEnd
secureConnectionStart
requestStart
responseStartIsso pode causar imprecisão em algumas propriedades de tempo. Por exemplo, no cálculo connect download: responseEnd - responseStart, como o timestamp responseStart é 0, o valor de connect download torna-se maior que duration.
Para resolver esse problema em recursos CDN autogerenciados, configure o cabeçalho de resposta Timing-Allow-Origin para especificar o tempo permitido para obtenção dos recursos.
Para recursos de terceiros, recomendamos usar o valor do parâmetro duration como referência principal.
O que fazer se houver dúvida sobre o carregamento do SDK ao chamar o método __bl.performance()?
Para mais informações, consulte Reporte de dados de página de SPAs.
O Browser Monitoring do ARMS suporta a captura automática de erros de requisição gRPC?
O Browser Monitoring do ARMS não suporta a captura automática de logs de erros de requisição gRPC enviados por meio de um Bridge no lado do cliente. Isso ocorre porque o gRPC é um protocolo de requisição HTTP não padrão que depende de capacidades nativas e está fora do escopo de coleta automática de dados do SDK do Browser Monitoring.
O que fazer se a página do console do ARMS não abrir ou aparecer em branco?
Se uma página do console do ARMS (como um painel ou uma página de análise) não abrir ou aparecer em branco, realize as seguintes verificações:
Problemas de cache ou configuração do navegador: Tente acessar o console em uma janela anônima (navegação privada) para descartar interferências de cache ou extensões do navegador.
Problemas de permissão ou status de ativação: Visite a página de ativação do Application Monitoring para verificar se há avisos sobre permissões ausentes ou ativação de serviço.
Solução de problemas com ferramentas de desenvolvedor: Abra as ferramentas de desenvolvedor do seu navegador pressionando F12. Verifique a aba Console em busca de erros JavaScript e a aba Network em busca de requisições falhas, e utilize as informações de erro para identificar a causa raiz.
O Browser Monitoring do ARMS (RUM) suporta filtragem e consulta de dados por campos personalizados (como status_code ou userId)?
Por padrão, o Browser Monitoring do ARMS não suporta diretamente a filtragem e consulta de dados por campos de negócio personalizados, como status_code ou userId. Se você tiver essa necessidade, considere as seguintes alternativas:
Integre o Application Monitoring do ARMS (APM) e use o recurso Extract Business Parameters para habilitar consultas de campos personalizados para parâmetros de requisição backend, como códigos de status e IDs de usuário.
Exporte seus dados de negócio para o Log Service (SLS) e utilize o sistema de consulta de logs do SLS para análises e consultas flexíveis.