Monitoramento de endpoints

O que é um "endpoint"?

Endpoint é tudo o que é endereçável na internet e pode ser consultado para verificar a disponibilidade. O caso clássico é o URL de um site — mas nas infraestruturas modernas, os recursos de que cuidas são muito mais diversificados: REST API, endpoints GraphQL, servidores de email, listeners de bases de dados, filas de mensagens, portas de health-check de contentores, painéis internos de administração, destinatários de webhooks. O DiagnoSEO Uptime Monitoring trata todos de forma uniforme: defines o que significa "saudável" para esse endpoint, defines o agendamento das verificações e recebes um alerta em caso de falha.

Esta página descreve cada tipo de endpoint suportado pela ferramenta, para que serve cada um e que sinal oferece o seu monitoramento.

Endpoints HTTP / HTTPS (sites web)

O caso padrão. Introduzes https://example.com e o monitor executa um pedido GET em determinado intervalo (1 minuto, 5, 10, 30, ou 60 minutos conforme o plano). Uma verificação bem-sucedida significa: ligação TCP estabelecida, handshake TLS concluído (para HTTPS), resposta HTTP recebida com o código de estado esperado (por defeito: 2xx ou 3xx), e opcionalmente uma palavra-chave presente (ou ausente) no corpo da resposta. A verificação regista Time To First Byte, tempo total de resposta, tamanho do conteúdo, cadeia de redirecionamentos e o conjunto completo de cabeçalhos da resposta.

Endpoints HTTP são a escolha certa para: sites institucionais, blogs, lojas e-commerce, dashboards SaaS, portais de documentação — em todo o lado onde pessoas acedem com um navegador.

Endpoints de API (REST / GraphQL / JSON-RPC)

APIs necessitam de algo mais do que "respondeu?" — precisam de "respondeu corretamente". Configuras o monitor com um método HTTP personalizado (GET, POST, PUT, DELETE, PATCH), cabeçalhos personalizados (tokens de auth, content-type), body do pedido (payload JSON para POST/PUT), bem como asserções JSON na resposta (data.status deve ser igual a "ok", result.count deve ser maior que 0, errors[] deve estar vazio). Uma API que devolve HTTP 200 com payload corrompido é o pior tipo de falha — parece estar saudável para um monitor ingénuo, mas falha para todos os clientes. As asserções JSON detectam esses casos.

Vê o guia dedicado ao monitoramento de APIs para detalhes de configuração e da sintaxe de asserção.

Endpoints de portas TCP

Para serviços não-HTTP: SMTP (porta 25 / 587 / 465), POP3 (110 / 995), IMAP (143 / 993), listeners de bases de dados (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), portas personalizadas de aplicações. O monitor estabelece ligação TCP ao host:port indicado e reporta sucesso se a ligação for aceite dentro do tempo limite. Sem handshake ao nível do protocolo — literalmente apenas "o serviço está a escutar".

Este é o monitor certo para qualquer serviço baseado em TCP cujo objectivo seja garantir disponibilidade e não necessite de verificações com conhecimento do protocolo. Para verificar banner de SMTP ou para verificações ao nível de query em bases de dados, usa o monitor heartbeat (o teu serviço contacta-nos quando está saudável, vê monitorização de cron-job/heartbeat).

Endpoints ping (ICMP)

Verificação de disponibilidade na camada 3. O monitor envia um pedido ICMP echo para o hostname ou IP de destino e aguarda resposta. Útil para routers, switches, dispositivos IoT, tudo o que responde a ping mas não corre HTTP. Nota que muitos fornecedores de cloud (AWS, GCP, Azure) bloqueiam ICMP por defeito ao nível do security group mesmo quando o host está saudável — para workloads em cloud prefere verificações HTTP ou portas TCP.

Endpoints hostname / DNS

Monitorização da resolução DNS. A ferramenta resolve periodicamente os registos A, AAAA, MX, NS, TXT e CNAME do teu domínio, tira um snapshot dos resultados e alerta se algum mudar. Detecta: tomadas de controlo de DNS não autorizadas, erros acidentais de configuração durante a migração de fornecedor DNS, serviços externos a atualizar endpoints sem aviso (como o teu CDN alterar blocos de IP, por exemplo), registos MX removidos por erro de digitação.

Monitoring DNS não é sobre disponibilidade — o teu fornecedor DNS é quase de certeza mais fiável que o origin server. É sobre a detecção de alterações. Vê monitorização de alterações DNS para uma explicação completa.

Endpoints de certificados SSL

Cada endpoint HTTPS recebe monitorização SSL automática sobre a sua verificação de uptime. A ferramenta lê o certificado, analisa a validade e a entidade emissora, e avisa 30, 14, 7, 3 e 1 dia antes da expiração. Vê monitorização de certificados SSL para detalhes.

Endpoints de expiração de domínio

Para cada URL monitorizado, a ferramenta também consulta WHOIS uma vez por dia e acompanha a data de expiração do domínio. Os alertas são disparados nos mesmos prazos do SSL (30/14/7/3/1 dias). Falhas de renovação podem ser catastróficas — o domínio fica sem proprietário e pode ser registado por outrem assim que terminar o período de grace. Vê monitorização de expiração de domínio.

Escolher o tipo correto de endpoint

Se não souberes que tipo de monitor usar, começa por HTTP/HTTPS para tudo o que tenha interface web, porta TCP para o resto e adiciona verificações heartbeat para tarefas batch que não expõem qualquer superfície de rede. Podes monitorizar o mesmo destino com vários tipos — por exemplo uma verificação TCP na porta 443 deteta "servidor está ativo, mas handshake TLS com erro" o que também seria sinalizado pela verificação HTTP no mesmo URL, enquanto o heartbeat do teu agente interno de monitorização confirma que a lógica da aplicação está a funcionar.

Perguntas frequentes

• O que é um endpoint?

  Tudo o que é endereçável na internet: URLs HTTP/HTTPS, REST API, portas TCP (SMTP, MySQL, personalizadas), hostnames para ping, registos DNS, certificados SSL e entradas de registo de domínio. Configura um monitor por tipo de endpoint.

• Devo usar a verificação HTTP ou porta TCP?

  HTTP é uma boa escolha por defeito para qualquer serviço web. A porta TCP é melhor para serviços não-HTTP (bases de dados, servidores de email, protocolos personalizados) onde só te interessa "se o serviço aceita ligações". Usa TCP para disponibilidade a baixo nível, HTTP para "se a aplicação realmente está a responder corretamente".

• Qual a diferença dos monitores heartbeat (cron-job)?

  O heartbeat é invertido — em vez de nós consultarmos o teu serviço, é o teu serviço que nos contacta num URL conhecido. Se não recebermos o ping na janela esperada, alertamos. Usado para cron jobs, processos batch e tudo o que corre de acordo com um agendamento sem superfície de rede para verificar.

• Um URL pode ter vários monitores?

  Sim. Podes monitorizar o mesmo destino com diferentes tipos de verificações — por exemplo, verificação HTTP para disponibilidade total mais verificação na porta TCP 443 que apanha problemas de handshake TLS. Cada monitor funciona e alerta de forma independente.

• Preciso monitorizar SSL e domínio em separado?

  Não — cada endpoint HTTPS recebe automaticamente monitorização SSL além da verificação de uptime e cada URL monitorizado inclui acompanhamento diário da expiração do domínio. Ambos estão incluídos, sem configuração adicional. O monitoring de domínio é por domínio — vários monitores no mesmo domínio partilham os dados WHOIS.