Monitoramento de Websites

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado out/2020Atualizado set/2026

Monitoramento de websites é a verificação automática de que um site responde, responde a tempo e devolve o conteúdo certo. A sonda roda de fora da sua rede. Assim, ela percorre o mesmo caminho do usuário: resolve o nome, abre a conexão, negocia o TLS e lê a resposta. Cada uma dessas etapas, porém, falha de um jeito diferente.

O problema aparece quando a verificação olha só o código de status. Uma loja pode devolver HTTP 200 com o catálogo fora do ar. Nesse caso, contudo, o check registra tudo em ordem. Montamos a situação em laboratório e os dois vereditos aparecem mais abaixo.

Todos os números deste artigo saíram de um laboratório em Docker. Ele subiu em 3 de setembro de 2026, com blackbox exporter 0.28.0, Prometheus 3.7.3 e nginx 1.29. Além disso, nenhum limiar aqui é chute: ou foi medido, ou tem a fonte linkada.

Como funciona o monitoramento de websites?

O monitoramento de websites funciona por sondagem: um agente externo repete a mesma requisição em intervalo fixo e registra o resultado de cada fase. São cinco fases, na ordem em que acontecem: resolução de nome, conexão TCP, handshake TLS, espera pelo primeiro byte e download do corpo.

Separar as fases é o que transforma um alerta em diagnóstico. Um site lento por causa do DNS e um site lento porque o banco travou produzem o mesmo sintoma na tela. Na madrugada, entretanto, eles acionam times diferentes.

Abaixo estão as medianas de 30 execuções contra o alvo do laboratório, com 25,8 ms de latência entre as pontas. Os tempos absolutos são do laboratório. Em contrapartida, a proporção entre as fases vale para o seu ambiente.

# 30 execuções contra o mesmo alvo, RTT medido de 25,8 ms
curl -sk -o /dev/null -w "%{time_connect} %{time_appconnect} %{time_starttransfer}" https://alvo/

fase                          TLS 1.3      TLS 1.2
resolução de nome (DNS)      0,62 ms     0,62 ms
conexão TCP                 25,21 ms    25,18 ms
handshake TLS               30,13 ms    54,90 ms
resposta do servidor        76,11 ms    76,20 ms
---------------------------------------------
até o primeiro byte        132,07 ms   156,90 ms

Repare que a resposta do servidor não muda entre as duas colunas: 76,11 ms contra 76,20 ms. Toda a diferença de 24,8 ms está no handshake. Portanto, ela reaparece em cada conexão nova que um visitante abre.

Vale um aviso sobre a primeira linha. A resolução de nome do laboratório é local, logo 0,62 ms não serve de referência. Na internet, esse tempo depende do TTL do seu registro e do cache do resolvedor de quem acessa.

A última fase, a resposta do servidor, é a que os times de aplicação costumam olhar sozinha. Ela é, inclusive, a única fase presente nas métricas de experiência de carregamento que o Google usa para ranquear.

Um HTTP 200 não prova que o site funciona

O código 200 diz que o servidor devolveu uma resposta, não que a resposta serve. Quando o backend do catálogo cai, a aplicação entrega a própria página de erro. Dessa forma, o status continua 200 e o tamanho do corpo muda pouco. Apenas a verificação de conteúdo separa os dois casos.

No laboratório, a rota /quebrado devolve 200 com a mensagem de falha no lugar da lista de produtos. Dois módulos do blackbox exporter sondam esse mesmo endereço. Entre eles, contudo, a única diferença são as três linhas do final.

modules:
  # o check que a maioria dos ambientes tem
  http_status:
    prober: http
    http:
      valid_status_codes: [200]

  # o mesmo check, exigindo o marcador na resposta
  http_conteudo:
    prober: http
    http:
      valid_status_codes: [200]
      fail_if_body_not_matches_regexp:
        - 'id="status-carrinho"'

alvo                    módulo          probe_success   status HTTP
-----------------------------------------------------------------
/                       http_status     1               200
/                       http_conteudo   1               200
/quebrado               http_status     1               200   <- o alarme decorativo
/quebrado               http_conteudo   0               200

Na terceira linha está o alarme decorativo: o catálogo saiu do ar, mas o painel segue verde. Trocar o módulo custa três linhas de configuração e muda o que o alerta significa.

Escolha como marcador o elemento que só existe quando a função funciona. Serve o botão de finalizar compra, o saldo da conta ou o número do protocolo. Apontar para o <title> da página, no entanto, não adianta, porque a tela de erro também tem título.

O custo do handshake TLS e a armadilha de medir de dentro

O handshake TLS custa uma ida e volta na versão 1.3 e duas na versão 1.2. Essa diferença só aparece quando existe distância entre o cliente e o servidor. Para isolar o efeito, medimos as duas contra o mesmo nginx, com o mesmo certificado, mudando apenas a diretiva ssl_protocols.

# mediana de 30 handshakes, mesmo servidor, mesmo certificado
                        RTT 25,8 ms    RTT ~0 (mesmo host)
handshake TLS 1.3        30,13 ms         4,40 ms
handshake TLS 1.2        54,90 ms         3,99 ms
-----------------------------------------------------
diferença                +24,77 ms        -0,41 ms

Com 25,8 ms entre as pontas, a versão 1.2 cobra 24,77 ms a mais em toda conexão nova. Medida do próprio host, porém, a diferença some. A 1.2 chega, inclusive, a parecer mais rápida por 0,41 ms.

Daí vem uma armadilha comum de projeto. Sonda instalada no mesmo datacenter do site aprova a configuração que o usuário paga todo dia. Por isso, coloque pelo menos um ponto de verificação fora da sua rede.

O que cada tipo de verificação detecta

Contar quantos checks a plataforma oferece não diz nada sobre cobertura. Quem define isso é o que cada verificação enxerga. Em seguida vêm o limiar que faz sentido para ela e a condição que autoriza acordar alguém.

 
A transação de navegador da quarta linha é o que o mercado chama de monitoração sintética. Ela é a única da tabela que exige um navegador de verdade rodando o fluxo inteiro.

Dezessete itens apareciam na lista original deste artigo, com repetição entre eles. Havia transação na web e transações da web, API REST e transações de API REST, website e URL. Em resumo, a tabela acima consolida apenas o que produz sinais diferentes.

Certificado e domínio: quando o alerta deve disparar

O alerta de certificado não dispara na hora de renovar. Ele dispara quando a renovação já deveria ter acontecido e não aconteceu. Essa distinção, no entanto, deixou de ser detalhe: a validade dos certificados públicos está encolhendo por decisão do setor.

Em abril de 2025, o CA/Browser Forum aprovou um calendário de redução da validade em três etapas. Desde 15 de março de 2026, o teto é de 200 dias. Em seguida, março de 2027 leva o limite a 100 dias. Por fim, março de 2029 chega a 47.

Do outro lado, a Let’s Encrypt orienta renovar o certificado de 90 dias a cada 60. O de seis dias, a cada três. Nos dois casos a renovação acontece com um terço a metade da validade ainda pela frente. Portanto, o alerta é o que vem depois dela.

Essa conta vem pronta da sonda. O laboratório serve dois certificados no mesmo servidor, um de 365 dias e outro de 12. Logo, a métrica traz a data de expiração do mais próximo.

# a metrica crua vem em epoch:
probe_ssl_earliest_cert_expiry 1.789514689e+09

# em dias restantes:
(probe_ssl_earliest_cert_expiry - time()) / 86400

  https://alvo/        365,00   # certificado de 365 dias, emitido hoje
  https://alvo:9443/    12,00   # certificado de 12 dias, emitido hoje

O certificado da segunda linha nasceu com 12,00 dias de validade. Ou seja, uma regra fixa de avisar 30 dias antes teria disparado no instante da emissão, num certificado recém-trocado e saudável.

É o que vai acontecer com todo mundo em 2029, quando 47 dias virar o teto. Amarre o limiar à validade emitida em vez de a um número redondo. No final das contas, o número redondo é herança da época em que certificado durava dois anos.

De quanto em quanto tempo verificar

O intervalo de verificação define o tamanho da queda que você consegue enxergar. Uma indisponibilidade menor que o intervalo passa inteira entre duas sondagens. Dessa forma, ela não deixa registro nenhum. Para medir isso, derrubamos o backend por 181 segundos, com duas sondas idênticas olhando o mesmo endereço.

# queda do backend: 23:18:06 -> 23:21:07  (181 s)

sonda a cada 15 s     25 amostras, 12 com falha
  primeira falha em 23:18:15, 9 s depois do inicio
  ... 23:18:00=1  23:18:15=0  [ 12 amostras em 0 ]  23:21:15=1 ...

sonda a cada 300 s    2 amostras, 0 com falha
  23:16:30=1   23:21:30=1
  a queda inteira caiu entre duas raspagens

A sonda de 15 segundos registrou a falha nove segundos depois do início. Ela devolveu doze amostras ruins seguidas. Para a sonda de cinco minutos, no entanto, o site nunca saiu do ar.

Escolha o intervalo pela janela que você precisa provar. Um contrato de 99,9% ao mês dá um orçamento de 43 minutos de indisponibilidade. Assim, uma única queda de cinco minutos consome 12% dele sem aparecer no relatório.

Intervalo curto também tem preço, pago pelo seu servidor. Verificar 40 endereços a cada 15 segundos gera 230 mil requisições por dia, com carga de TLS em cada uma. Por isso, reserve o intervalo curto para o caminho crítico do negócio.

Vale a mesma disciplina dos limiares de infraestrutura. Ou seja, o número que dispara o alerta sai da linha de base do próprio ambiente, nunca do valor que veio marcado na instalação.

Por onde começar na segunda-feira

Comece pela verificação de conteúdo no caminho que dá dinheiro, porque é a mudança mais barata com o maior efeito. Escolha um marcador que só aparece quando a função está viva. Em seguida, troque o módulo. Assim, o painel para de mentir sobre o 200.

Depois disso, revise dois limiares que quase sempre chegam herdados. O de certificado precisa sair do número redondo e virar uma fração da validade emitida. O de intervalo se justifica pela janela do contrato, nunca pelo padrão que veio na instalação.

Por fim, mova pelo menos um ponto de verificação para fora da sua rede. Sonda no mesmo datacenter aprova o que o usuário paga, como o custo do handshake medido aqui mostra.

Se o seu painel está verde e o telefone toca mesmo assim, o problema não é a ferramenta. É o que ela foi configurada para olhar. Fale com nossos especialistas para revisar a cobertura do seu ambiente.