El equilibrador de carga marca el backend como "en buen estado": el puerto 443 responde. Mientras tanto, PostgreSQL rechaza conexiones: cada solicitud de API devuelve 503. Los usuarios ven una interrupción; la supervisión del host se muestra en verde. El equipo pierde veinte minutos buscando "red" a pesar de que la verificación de estado nunca probó la base.
Este escenario se repite cada semana en pilas aparentemente bien configuradas: certificado TLS válido, proceso web activo, aprobación de la sonda TCP. El problema no es el host, es la pregunta formulada por la sonda.
Una verificación del estado de la aplicación responde a una pregunta específica: ¿puede esta instancia procesar una solicitud de representante ahora? No: ¿hay alguien escuchando en un puerto? La distinción cambia todo cuando una dependencia crítica cae sin que el servidor web se detenga.
TCP, HTTP ligero y verificación profunda
Los equipos suelen dudar entre tres niveles de investigación. Cada uno tiene su lugar, pero sólo el tercer nivel protege al usuario final.
| Tipo | Consultar | Límite |
|---|---|---|
| Conexión TCP | Proceso de escucha | Rápido, ciego |
HTTP 200 / | Página de inicio | Puede estar oculto en CDN |
HTTP /salud/en vivo | Proceso + tiempo de ejecución | Mínimo |
HTTP /salud/listo | Base de datos, caché, departamentos | Retirada del tráfico si falla |
/health/live sirve vivacidad (Kubernetes): sin base de datos; esto evita un ciclo de reinicios cuando Postgres no está disponible pero la aplicación en sí aún se está ejecutando. /health/ready sirve para preparación: incluye dependencias críticas únicamente: base, caché y cola si son esenciales.
Un control que pasa cuando la base está muerta envía el tráfico a un sumidero. Este es el caso más frustrante: todo es verde en el lado de la infraestructura, todo es rojo en el lado del cliente.
Diseñe controles rápidos y confiables
Un criterio de valoración de buena salud respeta cuatro reglas. Primero, un tiempo de espera de menos de uno o dos segundos, alineado entre el balanceador de carga y el kubelet: una verificación lenta bloquea la eliminación del tráfico cuando más lo necesita.
Entonces, sin efectos secundarios: sin creación de pedidos de prueba en producción, sin envío de correos electrónicos, sin escritura en la base de datos. La sonda lee el estado; ella no lo modifica.
En tercer lugar, una respuesta estable en JSON: { "status": "ok", "checks": { "db": "ok" } }: analizable mediante monitoreo y legible por un humano en el incidente.
Finalmente, un caché de dos a cinco segundos en la memoria si las sondas son agresivas. Evite reutilizar una página pesada (administración de WordPress, panel completo) como sonda: desperdicia procesador con cada encuesta.
Distribuidor de hosting, Kubernetes y compartido
OVHcloud, Hetzner y Scaleway ofrecen divisores con sonda HTTP configurable. Establezca la verificación en /health/ready, un intervalo razonable (de cinco a diez segundos) y umbrales de error y éxito consecutivos para evitar conmutaciones por error permanentes.
En Kubernetes, alinee las rutas de sondeo con el despachador externo: una doble verificación inconsistente provoca cambios permanentes entre correcto y no saludable.
En compartido sin sonda personalizada, monitoree una URL externa (UptimeRobot, etc.) con alerta. Es un complemento, no un sustituto de una sonda interna que prueba las dependencias.
Seguridad y fuga de información
Una invitación es una lista pública /health de versiones, entorno y nombre del clúster. Límite de velocidad, red interna, lista blanca de IP. En infraestructura sensible, autenticación mTLS entre el despachador y la aplicación.
Un atacante que investiga /health a veces descubre el estado de su base de datos, la versión de su marco o la topología interna: toda información útil para atacar.
La cumbre: verde para el seguimiento, rojo para el cliente
La sonda debe ceñirse al recorrido mínimo del usuario, no a la capa de transporte.
Decide y avanza sin puntos ciegos
Implemente puntos finales separados en vivo y listos, cada uno con una responsabilidad clara: el primero decide si el proceso debe reiniciarse y el segundo si la instancia puede recibir tráfico. Incluya solo las dependencias críticas en la lista, no toda la pila empresarial. Asegure el punto final en la red interna o en la lista blanca de IP. Alinear el balanceador de carga y Kubernetes en las mismas rutas y umbrales. Validar en preproducción: cortar la base → el tráfico debe eliminarse sin un reinicio masivo de los pods. Compare las ofertas de los operadores a través del directorio y del comparador.
Preguntas frecuentes
¿Por qué rara vez es suficiente una comprobación de TCP en el puerto 80?
Una verificación de TCP solo verifica que un socket esté abierto, no que la aplicación esté respondiendo correctamente ni que se pueda acceder a la base de datos. El puerto puede estar abierto mientras PHP-FPM está lleno, la aplicación devuelve 500 errores o PostgreSQL rechaza conexiones. En un incidente, se pierde un tiempo valioso diagnosticando la “red” aunque el problema esté relacionado con la aplicación.
¿Qué debe contener un punto final /health/ready?
Verificaciones ligeras de dependencias críticas: ping de base de datos, Redis PING, cola si es esencial, sin iniciar toda la lógica empresarial. El tiempo de espera debe ser breve (de uno a dos segundos). En caso de falla, la instancia se elimina del tráfico; no necesariamente se reinicia, lo que evita agravar un incidente en la base de datos.
¿Control de salud público o interno?
Favorezca un punto final interno: red privada, lista blanca de IP o autenticación mutua. Un /health público no autenticado puede convertirse en una sonda para un atacante o una fuga de información (versión de software, estado de la base de datos). Si un punto final público es inevitable, limite la información expuesta y aplique un límite de velocidad estricto.
¿Cómo evitar que el control de estado sobrecargue la aplicación?
Guarde en caché el resultado durante unos segundos en la memoria, limite las comprobaciones paralelas y utilice un punto final dedicado sin registros detallados. En compartido, un despachador que sondea cada segundo multiplica la carga: configure un intervalo de cinco a diez segundos y un punto final liviano.
Saludable significa "listo para servir", no "el puerto responde a telnet".