"O site está funcionando" é uma frase sem conteúdo se a checagem foi feita de um único ponto. Provedor, rota de backbone, peering local e até as configurações da CDN mudam de região para região, e uma falha invisível do seu escritório pode estar afetando há horas usuários em outra parte do mundo. Vamos ver por que o monitoramento a partir de vários países é necessário, por que um endereço de datacenter barato basta para ele e o que registrar no relatório de cada checagem.

Por que "o site está funcionando" a partir de um único ponto não prova nada

A disponibilidade de um site não é um estado único de "no ar" ou "fora do ar", e sim a soma de estados locais nas rotas a partir de diferentes pontos do mundo. A CDN entrega o conteúdo pelo nó mais próximo do usuário, e uma falha em um deles afeta apenas parte do público. Uma falha de backbone em uma operadora específica derruba a rota para os assinantes dela, mas não para os demais. Servidores DNS de regiões diferentes podem devolver um registro desatualizado por causa do atraso na propagação das mudanças, e assim parte do mundo chega ao endereço antigo e parte ao novo.

A checagem a partir de um servidor responde apenas à pergunta "o site está acessível de lá?", e não "o site está acessível de modo geral?". Para um serviço com público internacional, essa diferença é fundamental: uma falha local em uma região específica atinge a receita real exatamente como uma falha global, só que passa despercebida sem o ponto de controle correspondente.

Checagem de disponibilidade e velocidade de resposta a partir de várias regiões

O monitoramento a partir de diferentes países resolve duas tarefas ao mesmo tempo. A primeira é o fato da disponibilidade: o servidor responde? Um firewall local o bloqueia? A rota se perdeu após a última mudança de DNS ou da configuração da CDN? A segunda é a velocidade de resposta: o tempo de resposta do servidor e o tempo total de carregamento da página podem variar várias vezes entre uma região próxima e uma distante, mesmo com o site saudável, simplesmente pela distância física e pelo número de nós intermediários.

Isso é especialmente importante para sites com versões localizadas e infraestrutura de entrega diferente por região: uma resposta lenta em um país específico pode indicar não um problema do site como um todo, mas de um dos nós regionais da CDN, algo impossível de ver checando apenas a partir da sede da empresa.

Aqui um endereço de datacenter basta, e é mais barato

Ao contrário das tarefas em que importa o que um usuário real enxerga com um IP residencial ou móvel, o monitoramento de disponibilidade não tem a ver com personalização de conteúdo: ele trata do caminho de rede e do tempo de resposta. Para o site tanto faz quem o acessa; o essencial é que a conexão saia do nó geográfico desejado. Para isso serve um endereço de datacenter, cobrado mensalmente a preço fixo, e não por gigabyte, o que para requisições curtas e regulares compensa mais do que qualquer pacote de tráfego. Saiba mais sobre quando o IP de datacenter basta e quando não basta no artigo proxy móvel versus residencial.

A única exceção é quando o site aplica filtragem geográfica e, pelo ASN, distingue o tráfego de um provedor de hospedagem do de um usuário comum, mostrando uma página de bloqueio ou um captcha aos endereços de datacenter. Nessa situação, o próprio monitoramento de disponibilidade passa a exigir um canal residencial, e vale consultar o artigo sobre o que é ASN e por que ele importa.

Frequência das checagens e consumo de tráfego

A frequência da checagem deve corresponder ao custo da indisponibilidade: para uma vitrine com vendas diretas, um intervalo razoável é de uma a cinco minutos por região; para uma seção secundária, de 15 a 30 minutos. Cada consulta costuma ser uma única página de texto sem mídia, com 0,3 a 1 MB, de modo que o monitoramento diário de cem pontos cabe em cerca de 1,5 a 3 GB de tráfego por mês, um consumo mínimo em comparação com checagens que carregam imagens e vídeos.

A economia de tráfego no monitoramento não vem de escolher o canal mais barato, mas da metodologia correta de requisição: não carregar arquivos estáticos e mídia se o objetivo é verificar que o servidor respondeu, e não a renderização completa da página. Checagens quebradas por causa de um endereço barato e instável saem mais caras do que a diferença de preço entre os canais.

O que registrar no relatório

Três parâmetros são obrigatórios em cada registro. O código de resposta do servidor, que não é apenas "200 ou não 200": um 3xx pode indicar um redirecionamento despercebido para o domínio errado, um 5xx, um erro do servidor, e um timeout sem código algum, uma rota interrompida. O tempo até o primeiro byte mostra a rapidez com que o servidor responde antes de começar a transmitir o conteúdo e separa bem um problema de backend de um problema de rede. O tempo total de carregamento é o tempo somado até a página ficar pronta, aquele que o usuário real percebe e que depende não só do servidor, mas também da CDN, dos scripts e dos recursos externos da página.

Vale guardar cada registro com a marcação de região, data e hora: sem o histórico no tempo, é impossível distinguir uma falha de rede pontual na rota de uma degradação sistemática em um país específico, que exige intervenção.

Perguntas frequentes

Dá para monitorar a partir de um ou dois países em vez de uma dezena?

Se o seu público está concentrado em poucas regiões, bastam pontos de controle justamente nelas, mais um ponto neutro para comparação. Vale ampliar a lista conforme o público cresce ou quando houver reclamações de usuários de uma região onde ainda não há monitoramento.

É preciso usar endereços diferentes a cada checagem ou basta um por país?

Para monitorar a disponibilidade, basta um endereço estável por país: a constância do ponto é justamente o que permite comparar os indicadores ao longo do tempo e enxergar a tendência, e não o ruído causado pela troca de endereço.

O que fazer se de um país o site é sempre mais lento do que dos demais?

Primeiro, confirme o fato: repita a checagem a partir de outro endereço no mesmo país. Se o resultado se confirmar, o problema provavelmente está no nó regional da CDN ou na rota até ele, e não no servidor principal.

Endereços de datacenter para monitorar o site por país estão na seção de proxy.