Monitoring de servidor vs monitoring de site: a diferença

Duas equipas podem ambas dizer que "monitorizam a sua infraestrutura" e quererem dizer com isso coisas completamente diferentes. Uma observa gráficos de CPU num painel. A outra recebe uma mensagem no momento em que um cliente não consegue carregar a página de pagamento. Ambas as abordagens são úteis. Nenhuma substitui a outra.

Este artigo explica a diferença prática entre monitoring de servidor e monitoring de site, quando precisa de cada um e como uma configuração saudável usa ambos.

Monitoring de servidor: observar a máquina por dentro

O monitoring de servidor (muitas vezes chamado host-level ou monitoring de infraestrutura) corre um agente na máquina e reporta o que se passa lá dentro:

• utilização de CPU e carga média
• utilização de RAM e swap
• espaço livre em disco e I/O
• débito de rede
• processos e serviços em execução

Como o agente está diretamente no host, vê coisas que nenhuma verificação externa consegue. Sabe que o disco está a 95% antes de a base de dados recusar escritas. Sabe que uma fuga de memória sobe durante horas antes de o sistema terminar o processo. Isto é monitoring white-box (tem visão total do interior).

O preço a pagar: o agente só lhe fala da máquina onde corre. Se o servidor está bem, mas falha uma regra de firewall, um registo DNS ou um load balancer a montante, o agente reporta tranquilamente "tudo verde" enquanto os utilizadores veem uma página de erro.

Monitoring de site: observar o serviço por fora

O monitoring de site (também chamado monitoring externo, black-box ou sintético) verifica o seu serviço tal como o faria um visitante real: de fora da sua rede, através da internet pública.

As verificações externas típicas incluem:

• HTTP/HTTPS - a página devolve 200 e o conteúdo esperado
• TCP - a porta está aberta e aceita ligações
• Ping/ICMP - o host está acessível
• Certificado SSL - é válido e não expira em breve
• DNS - o nome resolve corretamente

Isto é monitoring black-box. Não sabe porquê algo falhou, apenas que, do ponto de vista do cliente, falhou. E é precisamente esse ponto de vista que importa. Apanha classes inteiras de falhas para as quais o agente no host é cego: certificados expirados, má configuração de DNS, problemas de CDN, falhas de routing e até quedas totais do servidor, em que o próprio agente cai com ele.

Lado a lado

Não são concorrentes, são camadas

O erro é encará-los como uma escolha ou-um-ou-outro. As configurações mais fortes correm ambos:

1. As verificações externas dizem-lhe rapidamente e a partir de vários pontos que os utilizadores estão afetados.
2. As métricas do servidor dizem-lhe porquê, para que possa remover a verdadeira causa.

Exemplo real: o monitoring externo dispara um alerta de que a sua API está a dar timeout. Abre as métricas do servidor e vê que o I/O do disco está fixo em 100%, porque um ficheiro de log encheu a partição. A verificação externa encontrou o sintoma, o agente interno explicou-o. Juntos transformaram um vago "o site está lento" num incidente claro e resolúvel.

Onde se encaixa o ePulz.io

O ePulz.io é construído em torno de monitoring externo black-box feito como deve ser. As verificações correm a partir de três sondas independentes na UE e uma falha só é declarada quando pelo menos duas das três concordam, por isso um único caminho de rede defeituoso não o acorda às três da manhã. Tem 9 tipos de monitores (HTTP, TCP, ping, SSL, DNS e mais) com intervalos até 1 minuto, conforme o plano.

Para os casos em que realmente precisa de uma visão para dentro da sua própria rede (um servidor, NAS, impressora ou serviço que não está exposto à internet), o ePulz.io oferece um agente LAN. Corre dentro da sua rede e reporta a acessibilidade dos hosts internos para o mesmo painel, sem expor nada à internet pública. Assim tem a visão pelos olhos do cliente e a visão interna num só lugar.

Uma regra sensata:

• Use monitoring externo para tudo aquilo em que o cliente toca. Sempre.
• Adicione métricas ao nível do servidor (através do seu fornecedor de hosting, de um agente próprio ou do nosso agente LAN para alvos internos) quando precisa de detalhe sobre a causa ou quer aviso precoce de limites de recursos.

Como começar

Se hoje não tem nada, comece pela visão externa, porque é a que importa aos seus clientes. Configure uma verificação HTTP no domínio principal e uma verificação SSL no certificado. Depois acrescente visibilidade interna onde compensa.

Quer confirmar já se uma porta está acessível, antes mesmo de configurar um monitor. Experimente o verificador de portas gratuito. Quando estiver pronto para cobertura permanente, veja como funciona o monitoring de uptime e os nossos planos. O período experimental de 7 dias é gratuito e não precisa de cartão.