Una comprobación de salud típica envía una solicitud a un endpoint, ve una respuesta 200 y marca el servicio como saludable. En las aplicaciones modernas esto no es suficiente. La página de inicio de la aplicación puede responder mientras la conexión a la base de datos es lenta, la capa de caché está rota, una dependencia downstream ha caído o el flujo de inicio de sesión ha dejado de funcionar. Si el balanceador de carga no puede ver esta diferencia, sigue enrutando tráfico a backends que responden pero no pueden hacer trabajo real.
Las comprobaciones de un solo paso se quedan aún más cortas para los protocolos basados en sesión. Para FTP, LDAP, Oracle o protocolos TCP personalizados, tener el puerto abierto no significa que el servicio esté saludable. Una comprobación de salud real debe iniciar sesión, enviar un comando, recibir la respuesta esperada, cerrar sesión si es necesario y validar el contenido de la respuesta. De lo contrario, el servicio parece alcanzable mientras las operaciones reales de usuario fallan.
La validación de contenido se vuelve frágil cuando se limita a la coincidencia de texto plano. Una API puede siempre devolver la palabra "OK" mientras el estado de dependencia, la métrica de latencia o la regla de negocio dentro del JSON está fallando. Cuando una comprobación de salud no puede consultar el significado de la respuesta, las degradaciones a nivel de aplicación se detectan tarde.
El enfoque correcto es abordar las comprobaciones de salud con profundidad de protocolo, escenarios multi-paso, consultas de contenido y umbrales rise/fall configurables. Las operaciones de sonda deben ejecutarse aisladas del flujo de tráfico principal para que las comprobaciones de salud lentas o bloqueadas no retrasen el tráfico de usuarios.
TR7 Monitoreo Activo de Salud entrega este modelo: monitorea 11 protocolos desde una única configuración, ejecuta escenarios multi-paso, valida el significado del contenido con JSONata y mantiene solo los objetivos genuinamente saludables en rotación.
TR7 transforma la comprobación de salud de un control de protocolo único en un sistema de decisión multi-protocolo, basado en escenarios y con validación de contenido.
Las comprobaciones TCP, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS y Oracle se gestionan todas desde el mismo objeto de comprobación de salud. Dependiendo del checkType seleccionado, solo se muestran los campos relevantes, de modo que los operadores no se ven sobrecargados con parámetros irrelevantes.
Para las comprobaciones TCP, UDP y Oracle, se construyen flujos de control ordenados usando pasos send, expect, regex y wait. Si algún paso falla, la sonda se marca como fallida y el estado de salud del backend se actualiza en consecuencia.
Para las comprobaciones HTTP y HTTPS, se usan consultas JSONata para leer el estado real dentro de una respuesta JSON. Un backend no se considera saludable simplemente por devolver 200 — también pueden comprobarse campos como estado de dependencia, puntuación, latencia o estado de negocio.
El número de respuestas fallidas consecutivas requeridas para marcar un backend como no saludable y el número de respuestas exitosas consecutivas requeridas para devolverlo se configuran de forma independiente. Esto evita que las fluctuaciones de red transitorias ciclen continuamente los backends dentro y fuera de la rotación.
El Monitoreo Activo de Salud hace que diversos tipos de servicio sean definibles, testables y gestionables con umbrales operacionales — todo desde el mismo editor.
TR7 soporta comprobaciones de salud TCP, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS y Oracle. Los operadores no necesitan herramientas separadas para una base de datos Oracle, un directorio LDAP, un servidor DNS, un repositorio FTPS o una API HTTP. Los campos relevantes aparecen según el tipo de protocolo seleccionado; los campos no relacionados se ocultan. Este modelo hace que la comprobación de salud en backends heterogéneos sea estandarizada y mantenible.
Para las comprobaciones TCP, los pasos sendText, expectText, expectRegex y wait pueden ejecutarse en secuencia. Los banners SMTP, las consultas de capacidad IMAP, los intercambios Redis PING/PONG, las respuestas MQTT y los mensajes de protocolo TCP personalizados son todos testables con este modelo. En lugar de simplemente abrir una conexión, se ejecuta un diálogo de protocolo real. Si algún paso no produce el resultado esperado, el backend se marca como no saludable.
Para las comprobaciones UDP, están disponibles los pasos send, wait, expectText y expectRegex. Los datos a enviar pueden definirse en formato texto, hex o base64, proporcionando flexibilidad para sondas de protocolo binario. Para servicios UDP como DNS, NTP, RADIUS, SIP y similares, se valida la respuesta de protocolo esperada — no solo si el puerto está abierto. Esto hace que los servicios UDP sean monitoreables de forma activa y significativa.
Las comprobaciones de salud HTTP/HTTPS soportan método, URI, lista de headers personalizados, cuerpo de solicitud y virtual host. Un endpoint de API puede sondearse con un header Authorization, cuerpo JSON o header Host personalizado. Los códigos de estado aceptables no tienen que ser un único valor — 200, 204 o 304 pueden considerarse todos saludables. Este diseño acerca las comprobaciones de salud al uso real de la aplicación.
Cuando contentCheckMode se establece en jsonata, el cuerpo de respuesta se evalúa como JSON y se ejecuta la expresión JSONata. El estado del servicio, el resultado de dependencia, la latencia de base de datos o una métrica de negocio pueden comprobarse todos dentro de una única expresión. Si la expresión produce un resultado verdadero el backend está saludable; un resultado falso lo marca como fallido. Los errores JSONata se registran para que una expresión incorrecta o una estructura de respuesta inesperada se haga visible.
Para escenarios simples que no requieren JSONata, contentQuery realiza una búsqueda de texto dentro del cuerpo de respuesta. Cadenas de marcador como "Welcome", "UP" o "Service Ready" — o texto específico de la aplicación — pueden comprobarse rápidamente. Este modo ofrece una solución de baja complejidad para endpoints de salud simples o aplicaciones heredadas. Los operadores eligen entre la comprobación básica y JSONata según el escenario.
Las comprobaciones LDAP/LDAPS pueden probar no solo el acceso al puerto sino la operación de bind real. Un bind realizado con nombre de usuario y contraseña valida el servicio de directorio a nivel de autenticación. Incluso si el puerto está abierto, un backend puede marcarse como no saludable si la cola de bind, la autorización o el servicio tienen un problema. Esto proporciona visibilidad crítica especialmente para los flujos de acceso AAM y empresarial.
Las comprobaciones de salud Oracle soportan detalles de conexión, nombre de usuario, contraseña y pasos de escenario. El SQL se ejecuta mediante executeCmd y se verifica el texto esperado o el conteo mínimo de filas. En lugar de una simple prueba de conexión, pueden consultarse el acceso real a datos y las métricas de negocio. Este enfoque hace que la pregunta de disponibilidad de la base de datos sea significativa desde la perspectiva de la aplicación.
Las comprobaciones de salud operan junto con intervalo, timeout, umbral, composición de escenarios, identidad de instancia y controles especializados internos del sistema.
testInterval es configurable de 0,5 a 3600 segundos; el valor predeterminado es 1 segundo. timeout es configurable de 0,01 a 3600 segundos. Un timeout agresivo permite un failover más rápido pero puede aumentar el riesgo de falsos positivos y debe ajustarse al comportamiento del servicio.
requiredFailure tiene un valor predeterminado de 2; requiredSuccess tiene un valor predeterminado de 3. Estos umbrales determinan la rapidez con la que se retira un servicio de la rotación y la cautela con la que se devuelve. Ambos lados del umbral se gestionan de forma independiente para filtrar las fluctuaciones transitorias.
Una única comprobación de salud puede combinar múltiples comprobaciones atómicas usando lógica AND/OR. Esto significa que no solo un único resultado de sonda sino múltiples dependencias o pasos de protocolo pueden evaluarse juntos. La salud compleja del servicio se modela de forma más realista.
La misma comprobación de salud mantiene un estado separado para cada backend. El ID de instancia de comprobación de salud se diferencia por comprobación y objetivo. Esto significa que incluso cuando el mismo perfil de comprobación se aplica a múltiples objetivos, el historial de salud de cada objetivo se rastrea de forma independiente.
La configuración negate invierte la lógica de éxito normal. Este modo se usa cuando se espera que una URL específica sea inalcanzable, se espera que una respuesta específica no se devuelva, o se espera que una ruta de servicio permanezca inaccesible. Una respuesta exitosa se trata como un fallo; una respuesta fallida se trata como un éxito.
Las comprobaciones de salud internas del sistema como los monitores de gateway y las comprobaciones de conexión IP del clúster pueden generarse automáticamente. Estas comprobaciones se usan para monitorear no solo los backends de aplicaciones sino también la conectividad y la alcanzabilidad upstream alrededor de TR7. El modelo puede extenderse con tipos de comprobación adicionales como comprobaciones de datacenter en el lado GTM.
Un equipo de e-commerce puede usar una comprobación HTTP con JSONata para verificar no solo que el servicio de carrito devuelve 200 sino también que la latencia de la base de datos y las métricas de disponibilidad están dentro de los límites. Un backend lento o degradado en dependencias se elimina automáticamente de la rotación.
Los equipos bancarios pueden usar las comprobaciones Oracle para ir más allá de abrir una conexión y realmente ejecutar queries SQL reales. Si el conteo de filas esperado o el resultado de la consulta no se cumple, el backend se marca como no saludable y el tráfico se dirige a objetivos seguros.
Las aplicaciones gubernamentales pueden verificar que un servicio de directorio está funcionando no solo a nivel de puerto sino a través de una operación de bind real. Si el puerto está abierto pero la autenticación falla, el sistema trata esto como un problema de salud.
Los equipos de telecomunicaciones pueden ejecutar consultas de registro reales para un dominio crítico usando una comprobación DNS. Tener el puerto DNS abierto no es suficiente — el resolver debe producir la respuesta esperada para considerarse saludable.
Base sus decisiones de tráfico en datos de salud confiables en 11 protocolos, escenarios multi-paso y validación de contenido JSONata. Déjenos guiarle por una configuración en vivo sobre sus propios servicios.