Monitorização sintética: medir automaticamente os tempos de carregamento em várias regiões

O que o Synthetic Monitoring revela

O Synthetic Monitoring realiza automaticamente e com regularidade testes predefinidos num site. Um Verificar descreve, entre outros aspetos, o objetivo, o calendário, os pontos de medição e os critérios de sucesso. Cada execução num ponto de medição gera um resultado próprio: a configuração não deve, portanto, ser equiparada a uma única medição.

Por outro lado, um teste de desempenho global único mostra apenas um instantâneo nas condições dessa execução. Repetido Monitorização do sítio Web permite verificar se um desvio volta a ocorrer e como os resultados evoluem ao longo do tempo. Para que essas comparações sejam significativas, é necessário que o objetivo, o ambiente de medição e a localização permaneçam identificáveis.

Um ponto de medição público num centro de dados na nuvem testa o site a partir de uma determinada região e infraestrutura. No entanto, a sua ligação não corresponde automaticamente a uma ligação privada à Internet no local. O encaminhamento, a latência da rede e a distância até à infraestrutura de entrega podem influenciar o resultado; por isso, um desempenho lento reflete, em primeiro lugar, este percurso de medição específico.

A aula particular responde a outra questão: permite verificar se uma aplicação está acessível a partir de uma rede privada. Isto é relevante, por exemplo, para serviços internos, mas não comprova a sua acessibilidade a partir da Internet pública. Por outro lado, uma verificação pública bem-sucedida não indica se o acesso funciona a partir de qualquer rede empresarial.

Para efeitos de planeamento, vale, portanto, a pena formular cada verificação como uma pergunta concreta: é possível aceder à página do produto a partir de uma região-alvo importante e o conteúdo esperado aparece nessa página? A resposta aplica-se aos pontos de medição e às condições de teste selecionados. Trata-se de uma indicação reproduzível, mas não de um retrato completo de todos os visitantes e dos seus dispositivos.

HTTP, navegadores e percursos

A Verificação HTTP consulta um ponto final e avalia, por exemplo, o código de estado ou a resposta. No caso de uma página de produto, pode indicar rapidamente que o servidor não está a responder como esperado. No entanto, se reportar um código HTTP 200, isso significa apenas que o critério de resposta verificado foi cumprido: permanece em aberto se a interface está visível e operacional.

Uma verificação no navegador carrega a mesma página de produto num navegador automatizado. Esta verificação permite verificar se aparece um título esperado e recolher métricas relacionadas com o navegador. Se esta verificação falhar, apesar de o estado HTTP ser bem-sucedido, vale a pena analisar a renderização e o conteúdo da página. No entanto, essa discrepância, por si só, não prova ainda uma causa específica do erro.

A Verificação da viagem vai além do carregamento da página e executa passos definidos. No caso de um início de sessão, por exemplo, abre a página de início de sessão, inicia sessão numa conta de teste adequada e, em seguida, verifica um elemento esperado. Só este último critério demonstra, para o processo testado, que não se limitou a verificar se a página de início de sessão estava acessível.

Mesmo um percurso bem-sucedido apenas confirma os passos e as condições efetivamente executados. Uma redefinição de palavra-passe não testada ou um navegador diferente podem, mesmo assim, apresentar problemas. Por isso, escolhe alguns processos importantes para a empresa e define, para cada passo, um resultado verificável, em vez de concluir que todo o serviço está a funcionar corretamente apenas com base no facto de uma página ter sido carregada com sucesso.

Uma verificação visual complementar permite analisar alterações na apresentação que uma verificação individual de elementos não deteta. Para tal, é possível, por exemplo, comparar capturas de ecrã; as discrepâncias têm de ser posteriormente classificadas, uma vez que nem todas as alterações visíveis constituem um erro. O artigo sobre Verificação visual e verificações automatizadas do local.

Distinguir corretamente os tempos de carregamento

„Sem mais especificações, o termo “tempo de carregamento» não se refere a uma grandeza claramente comparável. Quando se acede a uma página, o que interessa, em primeiro lugar, é o tempo até à primeira resposta do servidor: este ajuda a contextualizar os atrasos antes da chegada da resposta. No entanto, ainda não indica quando é que o navegador apresentou algo visível ou processou a página na totalidade.

A primeira renderização visível descreve uma fase posterior: o navegador apresenta o conteúdo pela primeira vez. Pode tratar-se já de um pequeno texto ou de outro elemento inicial, enquanto o conteúdo principal da página ainda não está disponível. Por isso, um início visível precoce não significa automaticamente que a página do produto esteja pronta a ser utilizada rapidamente.

O Maior tinta com conteúdo (LCP) tem em conta o momento em que o maior elemento de conteúdo relevante se torna visível na área visível. No caso de uma página de produto, pode tratar-se, por exemplo, da imagem grande do produto. Compare o LCP apenas com valores LCP devidamente identificados e registe as condições do navegador e da rede; o tempo até à resposta do servidor é medido noutra fase.

O Duração do guião Por sua vez, não corresponde automaticamente ao tempo de carregamento de uma única página. Um script pode aceder a várias páginas, aguardar a carregamento de elementos e efetuar um início de sessão. Nas verificações do navegador Grafana-k6, a duração do script indicada normalmente não inclui a fase de arranque do k6; esses limites da ferramenta também devem ser tidos em conta na interpretação.

O «Interaction to Next Paint», ou INP, refere-se à resposta às interações. Um fluxo sintético só pode analisar as interações que efetivamente executa. Por conseguinte, um clique automatizado em condições definidas não fornece uma distribuição das experiências de todos os visitantes reais que utilizam outros dispositivos, ligações e percursos de navegação.

Plano de medição para as regiões-alvo

Começa o plano de medição pelas páginas e processos cuja falha teria impacto no teu negócio. Podem ser, por exemplo, uma página de produto, o registo e uma interface. Em seguida, seleciona as regiões de medição de acordo com os teus mercados-alvo: uma localização adicional é particularmente útil se abranger uma região importante de utilizadores ou se complementar uma observação regional já existente.

Para um verificação comparável Regista o navegador e a versão, a configuração do dispositivo, as condições da rede e o estado da cache. Documenta também o intervalo e o limite de tempo, bem como a resposta esperada ou o elemento visível. Desta forma, será possível verificar posteriormente se um desvio poderá estar relacionado com uma alteração no ambiente de medição.

A tabela seguinte é um exemplo conceptual, não sendo um plano de operação medido nem geralmente recomendado. Deverás adaptar os intervalos e as condições de alarme à importância do teu site e às possibilidades do serviço escolhido.

A tabela é apenas o ponto de partida: introduz na configuração de verificação o limite de tempo específico e as restantes condições de medição. Um alarme regional continua a fazer sentido por si só, mesmo que outras localizações estejam a comunicar com sucesso. Tem em conta que um ponto de medição na nuvem não representa automaticamente uma ligação à Internet privada na mesma região.

Configurar verificações e procedimentos de teste

Para uma página de teste própria, podes, em primeiro lugar, criar uma verificação HTTP que verifique o código de estado esperado. Adiciona uma verificação do navegador que aceda à mesma página e aguarde um título esperado. A primeira verificação analisa a resposta do ponto final; a segunda fornece, adicionalmente, uma indicação sobre se o conteúdo esperado aparece no navegador.

Regista, para cada execução, o local da medição, a hora, o resultado e a duração relevante. Se a verificação do navegador falhar apesar de a verificação HTTP ter sido bem-sucedida, analisa o conteúdo e a renderização, em vez de presumir imediatamente que existe um erro específico. Verifique também se o título foi alterado intencionalmente ou se o limite de tempo definido foi demasiado curto.

Para se inscrever, clique num Jornada a chamada do navegador para introduzir dados e uma verificação após o início de sessão. Utiliza uma conta de teste separada com o mínimo possível de direitos e verifica um elemento estável e não pessoal na área de início de sessão. O facto de a página de início de sessão ser carregada com sucesso, por si só, não confirma que o início de sessão funcione.

Escolher seletores estáveis e aguarda especificamente os conteúdos esperados, em vez de te baseares apenas numa pausa fixa. Armazena os dados de acesso na gestão de segredos do serviço utilizado e não no script ou nos registos. Após alterações na interface, verifica se os seletores e os critérios de sucesso ainda se enquadram no fluxo previsto.

Limite os fluxos de teste a ações seguras: um percurso executado regularmente não deve dar origem a encomendas ou pagamentos reais. Se for inevitável uma etapa que implique a gravação de dados, esta deve ser realizada num ambiente de teste especificamente destinado a esse fim ou num processo de teste controlado. Defina também quem irá investigar uma execução com falha e quem será responsável pelos dados de teste.

Comparar ferramentas e modelos operacionais

Na escolha da ferramenta, deves distinguir entre um serviço de monitorização gerido e uma ferramenta que, inicialmente, apenas executa um teste. O fator decisivo não é apenas se um navegador é suportado: precisas também de localizações adequadas, execução regular, armazenamento dos resultados e um sistema de alertas que se adapte ao teu negócio.

Grafana Cloud Monitorização sintética associa configurações de verificação a sondas públicas e privadas e suporta verificações de navegadores baseadas em k6. Os pontos de medição públicos e privados respondem a diferentes questões de acessibilidade. Verifique também antecipadamente as frequências de verificação disponíveis: as verificações de navegador e de script estão sujeitas a limites diferentes dos de algumas verificações simples de terminais.

O que foi executado localmente Módulo do navegador k6 deve ser tratado separadamente. Para isso, precisas do k6 e de um navegador baseado no Chromium; a execução de um script local não configura automaticamente pontos de medição regionais nem um horário fixo. Para uma monitorização distribuída, terias de organizar adicionalmente a execução, a infraestrutura e a gestão dos resultados, ou utilizar um serviço adequado.

O AWS CloudWatch Synthetics executa os «Canaries» programados. O Funcionalidade multilocalização Replica um Canary em regiões selecionadas da AWS e agrega os resultados numa região principal. Antes da implementação, verifique as versões mínimas documentadas para os ambientes de execução Node.js Puppeteer ou Playwright suportados, bem como a disponibilidade regional específica desta funcionalidade.

As sondas geridas pelo próprio utilizador proporcionam-lhe um maior controlo sobre a localização e o ambiente, mas também exigem manutenção, atualizações e monitorização da infraestrutura de medição. Comparar, em todos os modelos de funcionamento, as localizações efetivamente disponibilizadas, os custos dependentes da utilização e as condições de armazenamento de dados. Esclarecer, em particular, onde são guardadas as capturas de ecrã e os registos e se isso está em conformidade com as tuas normas de proteção de dados.

Analisar de forma pertinente os resultados regionais

Compare os resultados regionais para a mesma página e o mesmo período. O navegador, a versão, as condições da rede e o estado da cache devem ser os mesmos; caso contrário, uma diferença pode dever-se ao ambiente de medição e não à entrega. Além disso, um ponto de medição na nuvem representa uma localização e um percurso de rede específicos, e não todas as ligações de uma região.

Para medições repetidas com sucesso, o Mediana o valor médio dos resultados ordenados. Um percentil superior, por exemplo, o 95.º percentil, torna visíveis os percursos mais lentos: 95 por cento dos valores analisados não ultrapassam este valor. Anote o período e o número de medições, para que fique claro qual é a amplitude da análise.

Quando o número de execuções é reduzido, uma única execução mais lenta pode influenciar significativamente o percentil superior. Por isso, analisa a evolução ao longo do tempo e compara várias janelas de medição antes de concluíres que existe um agravamento regional persistente. Uma mudança do ponto de medição ou da versão do navegador também deve ser considerada como um possível fator de alteração na análise.

Pára corridas mal sucedidas visíveis separadamente, por exemplo, como número de erros e percentagem do total de execuções. Caso contrário, uma estatística de tempo de carregamento que inclua apenas chamadas bem-sucedidas pode fazer com que uma região com frequentes timeouts pareça, erroneamente, estar a funcionar bem. No caso de uma falha sem um valor válido de tempo de carregamento, não é possível utilizar simplesmente um tempo de carregamento normal.

O Real User Monitoring complementa os testes controlados com as experiências de visitantes reais. O Relatório de Experiência do Utilizador do Chrome disponibiliza dados de campo num período contínuo de 28 dias; nem todas as páginas ou grupos de utilizadores estão abrangidos. Por conseguinte, esta perspetiva de longo prazo não substitui um alarme sintético atual, nem pode ser equiparada diretamente a um único teste.

Alarmes e resolução de problemas a nível regional

A alarme global pode agrupar erros repetidos em vários locais. Isso ajuda a distinguir um incidente de maior dimensão de uma falha isolada num ponto de medição. Ao mesmo tempo, define uma condição de alarme regional: se um mercado-alvo importante falhar, o sucesso de outras regiões não deve ocultar o problema.

Escolhe o número de repetições e o intervalo de tempo de acordo com a importância do processo. Vários testes falhados consecutivos podem compensar picos pontuais de curta duração, mas atrasam a notificação. Monitorize também os próprios pontos de medição e verifique se uma amostra falhou ou se outros testes do mesmo local também foram afetados.

Se uma página de produto estiver lenta apenas num local, comece por comparar execuções semelhantes e identificar o momento em que ocorreu o desvio. Em seguida, analise a resolução de DNS, a entrega via CDN, os tempos de carregamento dos recursos e a resposta do servidor. As diferentes rotas de rede e a proximidade da infraestrutura podem influenciar os níveis de referência regionais; o valor medido, por si só, ainda não identifica a causa.

No caso de recursos de outras origens, os detalhes da medição do navegador podem estar limitados. Sem o correspondente Timing-Allow-Origin- Os valores individuais do cabeçalho da API Resource Timing podem ser nulos. Isso não significa automaticamente que a ligação tenha sido extremamente rápida; verifica primeiro quais os dados que o servidor externo disponibiliza para a medição.

Para o próximo nível de análise, associa o momento, a região e o processo afetado aos registos e traços disponíveis. Desta forma, é possível, por exemplo, procurar uma consulta lenta, sem considerar uma correlação como prova da causa. A forma como as métricas, os registos e os traços interagem é explicada no artigo sobre Observabilidade na hospedagem.

Realizar o monitorização de forma contínua

Começa por realizar verificações simples de pontos finais para destinos importantes acessíveis ao público e complementa com percursos específicos no navegador para páginas ou inícios de sessão essenciais para o negócio. Uma verificação HTTP pode ser executada com maior frequência, enquanto o teste de navegador, mais complexo, verifica funcionalidades selecionadas. Deve definir os intervalos de acordo com o tempo de deteção pretendido, os limites do serviço e os custos, e não com base num valor fixo por minuto.

Determina, para cada verificação, uma Competência: Quem recebe o alarme, quem verifica o serviço afetado e quem é responsável pelo ponto de medição? Regista também quando um alarme é reencaminhado e onde se podem encontrar os resultados correspondentes. Uma verificação sem reação a erros repetidos fornece, sim, dados, mas não resolve o incidente.

Após alterações na interface, verifica se os seletores e os conteúdos esperados continuam a corresponder ao fluxo do script. No script, aguarda o elemento necessário, em vez de te baseares apenas num atraso fixo. Documenta as alterações no navegador, no perfil de rede ou nas definições da cache, para que comparações posteriores não misturem, sem que se perceba, condições de medição diferentes.

Trate as capturas de ecrã e os registos como dados potencialmente sensíveis: podem conter o conteúdo de uma sessão ou informações da aplicação. Limite o acesso e a conservação de acordo com a finalidade e verifique o que o teste regista efetivamente. Para os inícios de sessão, utiliza uma conta de teste com acesso restrito e gere os dados de acesso como «Secrets», em vez de os incluir no script.

Verifica regularmente se Locais de medição se ainda se adequam aos teus mercados-alvo e se as tarifas, a gestão de dados e os requisitos de proteção de dados continuam a permitir o funcionamento. No caso de ambientes de teste geridos internamente, acrescentam-se ainda a atualização e a monitorização do ambiente. Um script do navegador k6 iniciado localmente, por si só, não constitui uma infraestrutura de monitorização distribuída de forma permanente.