Monitoramento sintético vs de usuário real: o que cada um pega

O que cada um faz

O monitoramento sintético, às vezes chamado de monitoramento ativo ou proativo, envia uma requisição que você definiu a partir de uma máquina que você controla, em um intervalo que você define. Essa requisição pode ser tão pequena quanto um GET HTTP ou tão grande quanto uma sessão de navegador roteirizada que faz login, adiciona um item ao carrinho e finaliza a compra. Cada execução produz um resultado, quer alguém tenha visitado o site ou não.

O monitoramento de usuário real, geralmente abreviado como RUM, é passivo. Um pequeno script nas suas páginas reporta o que o navegador mediu para aquela visita: tempos de navegação, carregamentos de recursos, erros, e os Core Web Vitals como o visitante experimentou. Ele produz dados só na proporção do seu tráfego, e não produz nada quando não há ninguém ali.

O que o sintético pega que o RUM perde

• Indisponibilidades às 4 da manhã, ou em qualquer página com pouco tráfego. Se ninguém carrega a página, o RUM não tem nada para reportar, e uma indisponibilidade total é precisamente o caso em que o sinalizador não consegue ser enviado
• Disponibilidade a partir de lugares onde você ainda não tem usuários, que é como você descobre que um mercado novo não consegue alcançar você
• Uma linha de base limpa. O mesmo script, a partir da mesma localidade, no mesmo intervalo, então uma mudança no número é uma mudança no site, e não em quem por acaso visitou
• Fluxos de várias etapas que você não gostaria que usuários reais executassem, como um checkout que criaria um pedido real, ou um login que você pode rodar contra uma conta de teste
• Falhas de vencimento e configuração que nunca chegam a um navegador: certificados, registros DNS, listagens em blacklist, portas abertas
• A primeira falha depois de uma implantação, antes de o tráfego que a teria revelado chegar

O que o RUM pega que o sintético perde

• A distribuição real de dispositivos, redes e localidades. Uma verificação sintética a partir de uma conexão de data center nunca vai reproduzir um celular de gama média em dados móveis
• Scripts de terceiros, banners de consentimento e personalização que só carregam para sessões reais com cookies reais
• Problemas afetando um subconjunto de usuários: uma versão de navegador, uma região, uma variante de teste A/B
• Quais páginas lentas importam, ponderado por quantas pessoas as veem
• Core Web Vitals de campo, que é o que os buscadores usam, em oposição aos valores de laboratório que uma execução sintética produz

Quando você precisa dos dois

Os dois respondem a perguntas diferentes, então a divisão geralmente é limpa. Use o sintético para qualquer coisa pela qual você acionaria alguém: disponibilidade, tempo de resposta contra um limite, vencimento de certificado e domínio, e os fluxos críticos que geram receita para você. Esses precisam ser verdade às 4 da manhã com zero tráfego, e precisam de uma linha de base estável contra a qual alertar.

Use o RUM para decidir o que corrigir. Quando uma página está lenta para algumas pessoas, o RUM diz quais pessoas e quantas, que é a informação que um argumento de priorização precisa e que uma verificação sintética não consegue fornecer.

Uma configuração prática é verificações sintéticas conduzindo os alertas e o registro de uptime, o RUM conduzindo o backlog de desempenho. Se você só puder rodar um, rode o sintético: uma indisponibilidade não monitorada é mais cara do que uma página lenta não medida, e o RUM não consegue reportar sobre uma página que falhou ao carregar.

Onde o monitoramento de transação se encaixa

Uma verificação de transação é o monitoramento sintético no seu nível mais detalhado: um script de navegador gravado que percorre uma jornada de usuário real etapa por etapa e falha na etapa que quebrou, em vez de no site como um todo. Ele pega a classe de falha que uma verificação simples de disponibilidade reporta como saudável, onde a página inicial devolve 200 enquanto o formulário de login por trás dela está quebrado.

Como é sintético, roda em uma agenda sem precisar de tráfego, e como conduz um navegador real, exercita o JavaScript, as dependências de terceiros e os redirecionamentos que uma verificação HTTP simples pula. O monitoramento de transação da HostTracker funciona dessa forma, e o guia de verificação de transação cobre como um script é gravado e o que cada etapa reporta.

Transformando uma medição em um alerta

Nenhuma das duas abordagens é útil até que algo aja sobre o resultado. Uma verificação sintética vale a pena ter porque roda independentemente de você estar observando, e porque uma falha pode chegar até você imediatamente: a HostTracker roda as verificações dela a partir de mais de 300 pontos de verificação em 158 cidades, em 13 tipos de monitor, e envia alertas por e-mail, SMS, chamada de voz, Slack, Telegram e mais quando um resultado muda. Combine isso com qualquer RUM que você já coleta e você tem as duas metades: um alerta quando o site quebra, e evidência sobre para quem estava lento. O restante da seção de conceitos de monitoramento cobre os termos sobre os quais esses dois se apoiam.