HTTPS
Monitorização de websites e APIs
Uma página ou um endpoint, obtido a partir de quatro continentes.
Experimenta agora
Uma verificação, de um lugar, agora mesmo, e nada é guardado. Um monitor verifica de todas as localizações onde operamos e confirma uma falha a partir de dois outros continentes antes de alguém ser acordado, algo que uma única verificação não pode mostrar.
Para que serve
O teste com que todos começam e onde a maioria dos produtos termina. Pedimos o URL, seguimos ou recusamos redirecionamentos conforme indicas, e lemos o código de status.
Um código de status por si só é uma promessa fraca. Um site pode devolver 200 enquanto serve uma página de erro, um ecrã de login, uma cópia em cache da última terça-feira ou uma estrutura vazia que falhou ao renderizar. Por isso, o teste também pode exigir que uma frase esteja presente, que um redirecionamento vá para um local específico, que um campo JSON tenha um valor específico e que uma resposta chegue dentro de um tempo que defines. Essas são as falhas que um código de status não consegue ver.
Como cada verificação aqui, corre a partir de Amsterdam, New York, Sydney and Singapore, e uma falha é confirmada a partir de dois outros continentes antes de alguém ser acordado. Como funciona isso.
O que podes configurar
Tudo abaixo está no formulário quando adicionas um, em todos os planos.
- Método
- GET, HEAD, POST, PUT, PATCH ou DELETE. HEAD é o padrão educado para uma página que só precisas de saber que existe.
- Status esperado
- Quais códigos contam como saudáveis. Um 401 é correto para um endpoint que deve recusar-te, e dizer isso impede-nos de reportar a tua autenticação como uma falha.
- Palavra-chave
- Uma frase que tem de estar presente ou ausente. A forma mais simples de detetar um 200 que é, na verdade, uma página de erro.
- Asserções JSON
- Um caminho e o valor que deve conter, para uma API que responde 200 com um body que diz o contrário.
- Redirecionamentos
- Seguir a cadeia ou tratar um redirecionamento como a resposta. Com uma localização esperada, isto deteta um site redirecionado silenciosamente para onde não devia.
- Lento é uma falha
- Um tempo de resposta acima do qual o teste conta como degradado em vez de ativo, e quantos consecutivos antes de o dizermos.
- Autenticação
- Basic ou Bearer. Armazenado encriptado, desencriptado pelo plano de controlo e entregue à sonda com a tarefa, em vez de dar a uma máquina alugada a chave para tudo.
- Headers e body
- Tudo o que o pedido precisar. Um header por linha e um body para os métodos que o requerem.
- Timeout
- Quanto tempo esperar antes de considerar uma falha.
- Confirmações
- Quantos outros continentes têm de concordar antes de alguém ser alertado. Zero está disponível e raramente é o que queres.
Perguntas
O que significa um 502 ou 503, e vais alertar sobre isso?
Um 502 é o servidor à frente a dizer que o de trás deu uma resposta que não conseguiu usar, e um 503 é um servidor a dizer que não está a aceitar pedidos, que é o que a maioria dos frameworks devolve enquanto reinicia. Ambos falham o teste por defeito, porque o padrão espera 2xx e 3xx. Se um código for correto para esse endpoint, coloca-o na lista de estados esperados e deixa de ser uma falha.
Verificas a cadeia de certificados SSL/TLS?
Sim. O teste liga-se como um browser, contra o trust store público, por isso um intermediário em falta, um certificado autoassinado, um hostname errado ou um expirado falham o teste com um erro TLS em vez de um código de estado. O que não faz é contar os dias restantes, que é o trabalho do monitor de certificados SSL/TLS. A verificação pode ser desativada por monitor para um host interno que conheças.
Posso monitorizar um endpoint de API em vez de uma página?
É para isso que servem as opções de pedido, e é por isso que não há um tipo de monitor API separado deste. Escolhe POST, PUT, PATCH ou DELETE, adiciona headers e um body, autentica com credenciais básicas ou bearer, aceita os códigos de estado corretos e verifica um caminho no JSON que retorna.
Qual é a diferença entre um timeout e uma resposta lenta?
Um timeout é um teste que nunca obteve resposta dentro dos segundos permitidos, e é reportado como uma falha sem código de estado, exceto uma conexão recusada diretamente. Lento é uma resposta que chegou e demorou demasiado: define um tempo de resposta acima do qual o teste conta como degradado, e quantos seguidos antes de alguém ser notificado.
Segues redirecionamentos?
Não, a menos que o digas, o que surpreende pessoas o suficiente para valer a pena explicar. Um site que começa a responder 302 para uma página de estacionamento está avariado, e um verificador que segue silenciosamente e encontra um 200 reportaria isso como saudável. Ativa o seguimento quando o redirecionamento é o objetivo e indica o local onde esperas terminar.
O teste executa JavaScript ou renderiza a página?
Não, e dizemos isso em vez de sugerir o contrário. Obtém o documento que o servidor envia e lê-o, por isso um teste de palavra-chave tem de corresponder a algo no HTML em vez de algo que um framework pinta depois. Para uma página renderizada no browser, verifica o código de estado, o tempo de resposta e uma frase que esteja genuinamente na resposta.
O tempo de resposta é o que os meus visitantes experienciam?
É o tempo que a nossa sonda esperou, do pedido à resposta, numa conexão sem cache fria e sem browser à frente. Isso faz dele um excelente alerta para um servidor que está a ficar mais lento e um mau modelo de uma pessoa num telemóvel. O monitoramento de utilizadores reais e os Core Web Vitals respondem à outra questão e este teste não finge fazê-lo.
Porque não usar curl num cron job?
Para um URL de uma máquina, um cron job é realmente quase tudo isto, e quem te disser o contrário está a vender algo. O que não te dá é um lugar para correr que não possa morrer silenciosamente: um teste numa máquina que perdeu a rede não reporta nada, o que parece exatamente como se tudo estivesse bem. Também não te diz se o problema é um link quebrado entre ti e o site ou o site avariado, que é para isso que serve testar novamente de dois outros continentes, e ainda te deixa construir a parte que acorda alguém.
Como é que isto é diferente de um teste sintético baseado num browser?
Um teste sintético usa um browser real, por isso vê coisas que nós não conseguimos: uma página que aparece em branco porque um script falhou, um botão que deixou de funcionar, uma fonte que nunca carregou. Este teste faz o pedido e lê a resposta, o que significa que não consegue ver nada disso. O que te dá, em vez disso, é um teste barato o suficiente para correr a cada trinta segundos de três continentes, em todos os URLs que tens, em vez de um punhado de jornadas algumas vezes por hora. Respondem a perguntas diferentes e muita gente quer ambos.