Supervisión de endpoints

¿Qué es un "endpoint"?

Un endpoint es cualquier cosa direccionable en Internet a la que se le puede hacer una consulta para verificar la disponibilidad. El caso clásico es la URL de una página web, pero en la infraestructura moderna, los recursos bajo tu responsabilidad son mucho más variados: REST API, endpoints de GraphQL, servidores de correo, listeners de bases de datos, colas de mensajes, puertos de health-check de contenedores, paneles internos de administración, receptores de webhooks. DiagnoSEO Monitorización de Uptime los trata de manera uniforme: defines lo que significa "saludable" para ese endpoint, configuras el cronograma de verificaciones y recibes alertas en caso de fallo.

Esta página describe cada tipo de endpoint que admite la herramienta, para qué sirve cada uno y qué señal aporta el monitoreo.

Endpoints HTTP / HTTPS (páginas web)

El caso por defecto. Introduces https://example.com y el monitor realiza una solicitud GET en el intervalo especificado (1 minuto, 5, 10, 30 o 60 minutos según el plan). Un check exitoso significa: se ha establecido la conexión TCP, el handshake TLS ha finalizado (para HTTPS), se ha recibido la respuesta HTTP con el código de estado esperado (por defecto: 2xx o 3xx), y opcionalmente la palabra clave está presente (o ausente) en el body de la respuesta. El check registra Time To First Byte, tiempo total de respuesta, tamaño del contenido, cadena de redireccionamientos y el conjunto completo de cabeceras de respuesta.

Los endpoints HTTP son la opción adecuada para: páginas de marketing, blogs, tiendas e-commerce, paneles SaaS, portales de documentación, es decir, todo lo que visitan personas a través del navegador.

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

Las API requieren algo más que "¿respondió?" — necesitan "¿respondió correctamente?". Configuras el monitor con un método HTTP personalizado (GET, POST, PUT, DELETE, PATCH), cabeceras personalizadas (tokens de auth, content-type), body de la solicitud (payload JSON para POST/PUT) y aserciones JSON sobre la respuesta (data.status debe ser igual a "ok", result.count debe ser mayor que 0, errors[] debe estar vacío). Una API que devuelve HTTP 200 con un payload roto es el peor tipo de fallo: parece correcto para un monitor ingenuo pero falla para todos los clientes. Las aserciones JSON lo detectan.

Consulta la guía específica de monitorización de API para detalles de configuración y sintaxis de aserciones.

Endpoints de puertos TCP

Para servicios que no son HTTP: SMTP (puerto 25 / 587 / 465), POP3 (110 / 995), IMAP (143 / 993), listeners de bases de datos (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), puertos personalizados de aplicaciones. El monitor abre una conexión TCP al host:port indicado y reporta éxito si la conexión ha sido aceptada antes del timeout. Sin handshake a nivel de protocolo — simplemente "¿el demonio está escuchando?".

Este es el monitor adecuado para cualquier servicio basado en TCP donde solo te importa la disponibilidad y no necesitas verificaciones a nivel de protocolo. Para comprobar el banner de SMTP o verificaciones a nivel de consulta de base de datos, utiliza el monitor de heartbeat (tu servicio nos hace ping cuando está saludable; consulta monitorización para cron-job / heartbeat).

Endpoints de ping (ICMP)

Verificación de disponibilidad en la capa 3. El monitor envía una solicitud ICMP echo al hostname o IP de destino y espera respuesta. Útil para routers, switches, dispositivos IoT, cualquier cosa que responde a ping pero no ejecuta HTTP. Ten en cuenta que muchos proveedores cloud (AWS, GCP, Azure) bloquean ICMP por defecto a nivel de security-group, incluso si el host por lo demás está saludable — para cargas de trabajo en la nube, prioriza los checks HTTP o puertos TCP.

Endpoints de hostname / DNS

Monitorización de resoluciones DNS. La herramienta resuelve periódicamente los registros A, AAAA, MX, NS, TXT y CNAME de tu dominio, toma una instantánea de los resultados y alerta cuando alguno cambia. Detecta: tomas de control de DNS no autorizadas, errores accidentales en la configuración durante migraciones entre proveedores DNS, servicios externos que actualizan sus endpoints sin avisar (tu CDN cambia bloques IP, por ejemplo), registros MX borrados por un error tipográfico.

El monitoreo DNS no trata sobre disponibilidad — casi seguro que tu proveedor DNS es más fiable que el origen. Se trata de detectar cambios. Consulta monitorización de cambios DNS para la descripción completa.

Endpoints de certificados SSL

Cada endpoint HTTPS recibe monitorización SSL automática además del check de uptime. La herramienta lee el certificado, analiza su periodo de validez y emisor, y avisa 30, 14, 7, 3 y 1 día antes de que expire. Consulta monitorización de certificados SSL para más detalles.

Endpoints de expiración de dominio

Para cada URL monitorizada, la herramienta también consulta WHOIS una vez al día y sigue la fecha de expiración del registro del dominio. Las alertas se envían en los mismos umbrales que para SSL (30/14/7/3/1 días). Las renovaciones impagadas pueden ser catastróficas: el dominio queda sin titular y alguien podría registrarlo en el momento de finalizar el periodo de gracia. Consulta monitorización de expiración de dominio.

Elección del tipo correcto de endpoint

Si no sabes qué tipo de monitor usar, empieza por HTTP/HTTPS para todo lo que tenga interfaz web, puertos TCP para el resto y añade checks de heartbeat para procesos batch que no exponen ningún servicio en red. Puedes monitorizar un mismo objetivo con varios tipos — por ejemplo, un check de puerto TCP en el 443 detecta "el servidor está activo, pero el handshake TLS está roto", lo que también vería un check HTTP en la misma URL, mientras que un heartbeat desde tu propio agente de monitorización interno confirmará que la lógica de tu aplicación realmente funciona.

Preguntas frecuentes

• ¿Qué es un endpoint?

  Cualquier cosa direccionable en Internet: URLs HTTP/HTTPS, REST API, puertos TCP (SMTP, MySQL, personalizados), hostnames para hacer ping, registros DNS, certificados SSL y entradas de registro de dominio. Configura un monitor por cada tipo de endpoint.

• ¿Debería usar un check HTTP o un puerto TCP?

  HTTP es una buena elección por defecto para cualquier servicio web. El puerto TCP es mejor para servicios que no son HTTP (bases de datos, servidores de correo, protocolos personalizados) donde solo te importa "si el demonio acepta conexiones". Usa TCP para disponibilidad de bajo nivel, HTTP para saber "si la aplicación realmente responde correctamente".

• ¿En qué se diferencian los monitores heartbeat (cron-job)?

  Heartbeat es al revés — en vez de que nosotros interroguemos tu servicio, tu servicio nos hace ping a una URL conocida. Si no recibimos un ping dentro del tiempo esperado, alertamos. Se emplea para cron jobs, procesos batch y cualquier cosa que funcione bajo horario sin superficie de red que monitorizar.

• ¿Puede una URL tener varios monitores?

  Sí. Puedes monitorizar el mismo objetivo con distintos tipos de checks — por ejemplo, un check HTTP para la disponibilidad completa más un check TCP en el puerto 443 que detecta problemas con el handshake TLS. Cada monitor funciona y alerta de forma independiente.

• ¿Tengo que monitorizar SSL y el dominio por separado?

  No — cada endpoint HTTPS recibe monitorización SSL automática junto a su check de uptime, y cada URL monitorizada recibe seguimiento diario de la expiración de dominio. Ambos incluidos, sin configuración adicional. La monitorización de dominios es por dominio — varios monitores sobre el mismo dominio comparten los datos WHOIS.