Monitoramento sintético
O monitoramento sintético da HostTracker aciona o seu site em um cronograma, a partir de mais de 300 locais, usando a verificação que combinar com a tarefa: uma jornada de navegador roteirizada, uma chamada de API julgada por regras, ou uma requisição HTTP simples. Escolha uma abaixo e seja alertado no momento em que ela parar de corresponder ao que você espera.
A mesma estrutura por trás dos três: executar, julgar, reverificar, alertar
Monitoramento sintético significa que o tráfego é gerado de propósito. Em vez de esperar que um visitante real esbarre em um problema, um serviço de monitoramento aciona o seu próprio site, em um cronograma fixo, de fora da sua rede, e verifica o que volta contra regras que você define. As ferramentas de monitoramento sintético da HostTracker cobrem três formatos de verificação - monitoramento por navegador para uma jornada roteirizada, uma chamada de API julgada por regras, e uma requisição HTTP simples - cobrindo tudo, de um fluxo completo de checkout até uma simples sondagem de código de status, tudo a partir de mais de 300 locais no mundo todo.
Não é monitoramento de usuário real. A HostTracker gera cada verificação sozinha; ela não coleta dados de tempo ou de erro dos navegadores dos seus visitantes reais. Se você precisa saber o que os seus visitantes reais vivenciaram, isso é uma disciplina diferente com um nome diferente - veja sintético vs. monitoramento de usuário real para a comparação completa. A vantagem do monitoramento sintético vai na direção oposta: ele funciona antes de você ter um único visitante, e continua funcionando às três da manhã, quando ninguém está olhando.
Os três tipos de verificação respondem a perguntas diferentes, e escolher o errado é a forma mais comum de um problema real passar despercebido. Esta tabela relaciona cinco necessidades comuns com a verificação que realmente as cobre.
A maioria das contas acaba rodando mais de uma linha desta tabela ao mesmo tempo - uma verificação HTTP por baixo de tudo, mais uma verificação de transação ou de API nos um ou dois fluxos mais importantes.
Um cenário de transação é uma sequência de ações nomeadas; um pacote de regras de API é um conjunto de asserções sobre uma resposta. Os dois são configurados, nunca programados.
Transação: um cenário de cinco etapas
0 navigate https://shop.example.com/ 1.4 s 1 type #email "[email protected]" 0.2 s 2 click #add-to-cart 0.9 s 3 waitForNavigation /checkout 1.1 s 4 checkContent "Order summary" present 0.1 s
API: um pacote de quatro regras
status isOk header("Content-Type") contains "json" body.json.path("$.count") gt 0 time lt 5s
Cada um responde a uma pergunta diferente. A maioria das contas que usa a HostTracker acaba rodando mais de um.
Abra um navegador Chromium de verdade e percorra até dez etapas - fazer login, pesquisar, adicionar ao carrinho, finalizar a compra - e depois faça asserções sobre o que está na página. Detecta o que um código de status não consegue: um botão removido, um envio de formulário quebrado, um erro de JavaScript no meio do caminho. Monitoramento de transação
Envie uma chamada HTTP e julgue a resposta com até 20 regras de asserção sobre status, cabeçalhos, tempo de resposta e corpo em JSON, XML ou texto simples. Feito para o endpoint do qual outro sistema depende. Monitoramento de API
Requisite uma URL a partir de mais de 300 pontos de verificação em 158 cidades e verifique o status, as palavras-chave do corpo, o tempo de resposta e o TLS. A referência sempre ativa sobre a qual os outros dois se apoiam. Monitoramento HTTP
O formato da verificação muda; os pontos de verificação, a lógica de confirmação e os canais de alerta por trás dela não mudam.
Todo tipo de verificação roda a partir da mesma frota pública de pontos de verificação. Escolha os locais que combinam com onde os seus visitantes, ou os consumidores da sua API, realmente estão.
Um único ponto de verificação com falha nunca abre um incidente sozinho. A verificação é executada novamente a partir de outros pontos independentes, e só um resultado concordante a transforma em um alerta.
Uma verificação de transação guarda uma captura de tela da etapa final, e outra no momento em que uma etapa falha, para que a depuração comece já sabendo como a página realmente estava.
Faça asserções sobre texto renderizado, um valor JSON selecionado por JSONPath ou XPath, ou uma palavra-chave simples - até 20 regras de asserção ou 10 correspondências de palavra-chave por monitor, dependendo do tipo de verificação.
E-mail, SMS, chamada de voz, Slack, Telegram e webhooks, configurados uma vez por contato, são compartilhados entre as verificações de transação, API e HTTP da sua conta.
Adicione qualquer monitor - jornada de navegador, chamada de API ou verificação HTTP - à mesma página de status pública, para que os clientes vejam uma única página em vez de três separadas.
Sites, servidores, APIs, certificados. Um tipo de verificação por página, com as mesmas localidades, alertas e relatórios por trás.
Confiado por equipes de
Cada capítulo abre no próprio lugar, mantendo a página curta.
As duas abordagens respondem a perguntas diferentes. O monitoramento sintético de sites gera o próprio tráfego, a partir dos seus próprios pontos de verificação, em um cronograma que você controla - uma jornada de navegador roteirizada, uma chamada de API, ou uma requisição HTTP simples. O monitoramento de usuário real, em vez disso, observa os navegadores dos seus visitantes reais, o que significa que ele precisa de tráfego de verdade para dizer qualquer coisa, e não consegue prever o que vai acontecer amanhã, só o que já aconteceu hoje.
A HostTracker é um serviço de monitoramento sintético - ela não oferece monitoramento de usuário real, e esta página não vai fingir o contrário. O que o monitoramento sintético compra em troca: um site de staging sem visitante nenhum ainda assim é verificado; uma quebra às três da manhã é detectada do mesmo jeito que uma no horário de pico; e, como o cenário é determinístico, o resultado aponta exatamente a etapa ou a regra que falhou, em vez de um sintoma vago. Para a comparação lado a lado completa, veja sintético vs. monitoramento de usuário real; a página de monitoramento de transação também traz uma tabela detalhada se você quiser entender os mecanismos.
Cada tipo de verificação tem seu próprio piso de intervalo, porque cada uma dá um trabalho diferente para rodar. Uma requisição HTTP é barata e pode rodar em intervalos de até um minuto em um plano pago. Uma chamada de API adiciona análise e avaliação de regras, mas ainda roda de um minuto até 24 horas. Uma verificação de transação abre um navegador de verdade e percorre um cenário do início ao fim, por isso tem um piso de 10 minutos - verificações de navegador são caras para rodar e para processar, e combinar uma com uma verificação HTTP rápida no mesmo site cobre tanto a pergunta "está acessível agora" quanto a pergunta "o fluxo ainda funciona", sem rodar um navegador a cada sessenta segundos.
Os três permitem escolher, entre os mais de 300 pontos de verificação em 158 cidades, de onde um determinado monitor roda - a geografia importa mais do que parece, já que uma CDN ou um balanceador de carga com roteamento geográfico pode estar saudável em uma região e falhando em outra.
A tentação com qualquer tipo novo de verificação é ligá-la direto a algo que acorda alguém. Resista a isso na primeira semana: deixe um monitor novo rodar em silêncio, leia um punhado de resultados reais, e só depois decida quem recebe um aviso imediato e quem recebe um resumo diário. Uma verificação de transação que falha porque o seletor de um banner de marketing mudou não tem a mesma gravidade de uma que falha porque o checkout parou de se completar - escreva suas asserções de conteúdo sobre texto estável e significativo, para que o alerta que você receber valha a pena ser tratado.
Os alertas saem pelos canais que você configura por contato - e-mail, SMS, chamada de voz, Slack, Telegram, webhook e outros - o mesmo conjunto nos três tipos de verificação, então uma falha de transação e uma falha de HTTP chegam à mesma pessoa da mesma forma. Uma mudança de estado só é confirmada quando outros pontos de verificação concordam, então o alerta que você recebe já é ponderado, não uma única observação instável; um aviso de recuperação é enviado assim que a verificação volta a passar, fechando o ciclo sem que você precise ir conferir.
Monitoramento sintético é aquele em que o tráfego é gerado de propósito, em um cronograma, por um serviço fora dos seus próprios sistemas, em vez de esperar que um visitante real esbarre em um problema e torcer para que ele avise você. O monitoramento sintético da HostTracker vem em três formatos: uma jornada de navegador roteirizada que percorre um fluxo de várias etapas, uma chamada de API julgada por regras que você escreve, e uma requisição HTTP simples verificada quanto a status, corpo e tempo de resposta. Os três rodam a partir de mais de 300 locais, usam os mesmos canais de alerta, e seguram um alerta até que outros pontos de verificação confirmem a falha.
Não. A HostTracker gera o próprio tráfego, a partir dos seus próprios pontos de verificação, no cronograma que você definir - ela não coleta dados de tempo ou de erro dos navegadores dos seus visitantes reais. Se você precisa saber o que os seus visitantes de verdade vivenciaram, isso é monitoramento de usuário real, uma disciplina diferente com um nome diferente; veja “sintético vs. monitoramento de usuário real” para a comparação completa. A vantagem do monitoramento sintético é justamente a oposta: ele funciona antes de você ter um único visitante, e continua verificando às três da manhã, quando ninguém está navegando.
Monitoramento de uptime, no sentido estrito do dia a dia, normalmente significa exatamente um destes três formatos: a verificação HTTP simples que requisita uma URL e observa o código de status e o tempo de resposta. Monitoramento sintético é o termo mais amplo, que também cobre o monitoramento por navegador - a jornada roteirizada - e o monitoramento sintético de API, a chamada julgada por regras. Uma verificação HTTP responde “o servidor está no ar”; uma verificação de transação responde “o fluxo de várias etapas realmente se completa”; o monitoramento sintético de API responde “a resposta realmente corresponde ao seu contrato”. Um site pode passar em toda verificação HTTP enquanto o checkout está quebrado, e é exatamente essa lacuna que os outros dois fecham.
Não. Os três tipos de verificação são montados no editor web. Um cenário de transação é uma lista de ações - navigate, click, type e assim por diante - escolhidas em um menu, com um seletor CSS digitado em um campo. As regras de asserção de um monitor de API são, cada uma, uma linha de sintaxe simples e legível, não um script. As palavras-chave e opções de um monitor HTTP são campos de formulário. Nada aqui é uma linguagem de programação, embora toda a superfície de ações e regras também esteja disponível pela API, caso você queira automatizar a própria configuração.
Até dez etapas criadas por você, dentro de um orçamento de 40 segundos para a execução inteira. Uma navegação inicial até a própria URL do monitor é adicionada automaticamente como etapa zero, então as dez etapas que você escreve são dez etapas de trabalho de verdade - cliques, entrada de texto, asserções de conteúdo - e não nove mais o carregamento da página. Um fluxo que realmente precisa de mais de dez etapas geralmente fica melhor dividido em dois monitores; isso também mostra qual metade quebrou.
Comece com uma verificação HTTP no próprio site - é o sinal mais barato e a referência sempre ativa que toda conta deveria ter. Depois adicione qual dos outros dois combinar com o seu risco de maior valor: uma verificação de transação se um checkout ou login quebrado custa dinheiro diretamente, uma verificação de API se outro sistema - o seu próprio aplicativo, a integração de um parceiro - depende de um endpoint respondendo corretamente. A maioria das contas que usa os três roda a verificação HTTP com mais frequência, a de API em seguida, e a de transação no intervalo mais longo, já que é a que dá mais trabalho para rodar.
Depende do tipo de verificação, porque cada uma dá um trabalho diferente para rodar. As verificações HTTP podem rodar em intervalos de até um minuto em um plano pago. As verificações de API rodam de um minuto até 24 horas. As verificações de transação - porque cada execução abre um navegador de verdade e percorre um cenário do início ao fim - têm um piso de 10 minutos. Um padrão comum combina uma verificação HTTP de um minuto para detecção rápida de queda com uma verificação de transação ou de API a cada 10 a 15 minutos para a pergunta mais profunda.
A falha não é confiada de primeira. A HostTracker executa a verificação novamente a partir de outros pontos de verificação independentes, e só confirma a mudança de estado quando um número suficiente deles concorda, então um caminho de rede instável ou um nó lento não vira um alerta sozinho. Uma vez confirmada, a HostTracker alerta os contatos que você configurou pelos canais que você escolheu - e-mail, SMS, chamada de voz, Slack, Telegram, webhook e outros - após o atraso definido para cada contato, e um aviso de recuperação é enviado assim que a verificação volta a passar.
Comece um teste grátis e adicione uma verificação de transação, API ou HTTP à mesma conta - os mesmos mais de 300 locais e os mesmos alertas por trás dos três.
Faz parte do software de monitoramento de sites da HostTracker.
