Monitoring HTTP frente a TCP frente a Ping: ¿qué protocolo debes usar?

Al configurar uptime monitoring, una de las primeras decisiones es qué protocolo usar en tus checks. HTTP, TCP y Ping (ICMP) prueban capas distintas de tu infraestructura, y elegir bien determina qué problemas puedes detectar.

Entender las capas

Tu stack tiene varias capas, y cada protocolo de monitoring prueba una profundidad distinta:

```
┌─────────────────────────┐
│ Aplicación (HTTP) │ ← El monitoring HTTP prueba aquí
├─────────────────────────┤
│ Servicio (puertos TCP)│ ← El monitoring TCP prueba aquí
├─────────────────────────┤
│ Red (ICMP) │ ← El monitoring Ping prueba aquí
├─────────────────────────┤
│ Físico / Cloud │
└─────────────────────────┘
```

Una capa puede fallar mientras las inferiores siguen sanas. El servidor puede responder al ping (la red está bien) mientras el proceso web ha caído (HTTP fallaría, el TCP al puerto 80 también). Entender esto ayuda a elegir el protocolo adecuado para cada servicio.

Monitoring HTTP / HTTPS

Cómo funciona

Un Monitor HTTP envía una petición HTTP completa (normalmente GET) a una URL y evalúa la respuesta. Comprueba:

• Conexión: ¿podemos establecer TCP y completar el handshake TLS?
• Código de estado: ¿el servidor devolvió el estado esperado (200, 301, etc.)?
• Cuerpo de la respuesta: ¿contiene (o no) el contenido indicado?
• Tiempo de respuesta: ¿cuánto tardó todo el ciclo petición/respuesta?
• Certificado SSL: ¿es válido y no caduca pronto?

Cuándo usar monitoring HTTP

Sitios y aplicaciones web: cualquier URL accesible desde el navegador. Es la opción por defecto para la mayoría de necesidades.

APIs REST: monitoriza endpoints de health (/health, /api/status) para verificar que la API responde bien.

Webhooks: verifica que los endpoints aceptan peticiones.

Verificación de contenido: cuando necesitas comprobar no solo que carga la página, sino que muestra el contenido correcto. Un servidor puede devolver 200 OK con una página de error — el monitoring por palabras clave lo detecta.

Ventajas

• Prueba el stack completo, incluido el código de aplicación
• Puede verificar el cuerpo de la respuesta, no solo conectividad
• Monitoriza validez y caducidad del certificado SSL
• Mide tiempos de respuesta cercanos a lo que ve el usuario
• Soporta autenticación (cabeceras, cookies)

Limitaciones

• Solo sirve para servicios HTTP/HTTPS
• Mayor coste por check que TCP o Ping
• No monitoriza servicios no web (bases de datos, correo, servidores de juegos)

Ejemplos de uso

| Objetivo | URL | Esperado |
|----------|-----|----------|
| Inicio | https://example.com | Estado 200 |
| Health de API | https://api.example.com/health | Estado 200, cuerpo contiene "ok" |
| Login | https://app.example.com/login | Estado 200 |
| Webhook | https://hooks.example.com/ingest | Estado 200 o 405 |

Monitoring TCP

Cómo funciona

Un Monitor TCP intenta abrir una conexión a una IP y un puerto. Verifica:

• Puerto abierto: ¿se puede establecer la conexión TCP?
• Tiempo de conexión: ¿cuánto tarda el puerto en aceptar?
• Respuesta del puerto: ¿el servicio responde dentro del timeout?

El monitoring TCP no envía datos de aplicación: solo comprueba si el puerto escucha y acepta conexiones.

Cuándo usar monitoring TCP

Bases de datos: PostgreSQL (5432), MySQL (3306), MongoDB (27017), Redis (6379) para verificar que aceptan conexiones.

Servidores de correo: SMTP (25/587), IMAP (143/993), POP3 (110/995).

Servicios personalizados: cualquier servicio TCP que no hable HTTP — juegos, brokers MQTT, FTP, SSH.

Balanceadores: verificar que el puerto del balanceador está abierto y acepta conexiones.

Ventajas

• Funciona con cualquier servicio TCP, no solo HTTP
• Menor sobrecarga que los checks HTTP
• No requiere configuración a nivel de aplicación
• Detecta problemas de puerto (proceso caído, firewall mal configurado)

Limitaciones

• Solo prueba que el puerto está abierto, no que la aplicación funciona bien
• No verifica el contenido de la respuesta
• No prueba la lógica de aplicación (una base puede aceptar conexiones y fallar todas las consultas)

Ejemplos de uso

| Objetivo | Host:Puerto | Propósito |
|----------|-------------|-----------|
| PostgreSQL | db.internal:5432 | Disponibilidad de base de datos |
| Redis | cache.internal:6379 | Disponibilidad de caché |
| SSH | bastion.example.com:22 | Acceso al bastión |
| SMTP | mail.example.com:587 | Entrega de correo |
| API personalizada | service.internal:8080 | Salud del microservicio |

Monitoring Ping (ICMP)

Cómo funciona

Ping envía paquetes ICMP Echo Request y espera Echo Reply. Prueba:

• Alcanzabilidad del host: ¿responde a nivel de red?
• Tiempo de ida y vuelta: ¿cuánto tarda el paquete?
• Pérdida de paquetes: ¿se pierden paquetes?

Cuándo usar monitoring Ping

Infraestructura de red: routers, switches, firewalls y dispositivos que no ejecutan servicios de aplicación.

Disponibilidad del servidor: comprobación rápida de que está encendido y conectado a la red, independientemente de los servicios.

Rendimiento de red: tiempos de ping y pérdida indican la salud entre tu ubicación de monitoring y el objetivo.

Monitoring de referencia: como complemento de HTTP/TCP, el Ping ayuda a distinguir «el servidor no responde en absoluto» de «responde pero la aplicación está rota».

Ventajas

• Menor sobresfuerzo de todos los protocolos
• Prueba el nivel más básico de conectividad
• Útil para dispositivos sin servicios de aplicación
• Ayuda a diagnosticar si el problema es de red o de aplicación

Limitaciones

• Solo prueba alcanzabilidad de red, no salud de aplicación
• Muchos hosts y firewalls bloquean ICMP: el ping puede ser poco fiable
• En cloud a veces no hay soporte ICMP hacia ciertos recursos
• No verifica que un servicio concreto esté en marcha

Ejemplos de uso

| Objetivo | Host | Propósito |
|----------|------|-----------|
| Puerta VPN | vpn.example.com | Acceso de red |
| Router | 10.0.0.1 | Infraestructura de red |
| Servidor | web-1.internal | Alcanzabilidad básica |
| Salto ISP | isp-gateway.net | Salud del camino de red |

Elegir el protocolo adecuado

Marco de decisión:

¿Es un sitio, una app web o una API REST?
→ Usa monitoring HTTP. Prueba el stack completo y da los datos más útiles.

¿Es un servicio que escucha en TCP pero no habla HTTP?
→ Usa monitoring TCP. Bases de datos, correo, juegos, servicios a medida.

¿Es un dispositivo de red o solo necesitas alcanzabilidad básica?
→ Usa monitoring Ping. Routers, switches, puertas VPN, salud básica del servidor.

¿No estás seguro?
→ Empieza con HTTP para todo lo que tenga URL, TCP para todo lo que tenga puerto y Ping para infraestructura.

Combinar protocolos para cobertura total

Las mejores estrategias usan varios protocolos para cubrir distintos modos de fallo. Para un stack web típico:

| Componente | Protocolo | Check |
|------------|-----------|-------|
| Sitio web | HTTP | https://example.com → 200 |
| API | HTTP | https://api.example.com/health → 200 |
| Base de datos | TCP | db.internal:5432 |
| Caché Redis | TCP | cache.internal:6379 |
| Servidor | Ping | web-1.internal |

Si falla HTTP pero pasan TCP y Ping, sabes que el servidor está arriba y el puerto abierto: el problema está en el código de aplicación. Si falla todo, es un problema de servidor o de red. Este enfoque por capas acelera mucho el diagnóstico.

Conclusión

No hay un protocolo de monitoring «mejor» único: cada uno prueba una capa distinta. El monitoring HTTP es el más completo para servicios web, el TCP cubre servicios no HTTP y el Ping da visibilidad básica a nivel de red.

Para la mayoría de equipos, la respuesta es «usa los tres, en los objetivos correctos». Empieza con HTTP para lo que ve el usuario, añade TCP para infraestructura y Ping para salud de red.

Monitoriza cada capa de tu stack. Empieza gratis — monitoring HTTP, TCP y Ping en todos los planes.