Un centro de datos puede parecer sano mientras la aplicación, la base de datos o el camino de acceso no lo están.
El error más común del GTM es gestionar la salud del centro de datos con un único flag up/down. En realidad, un centro de datos puede ser alcanzable mientras la aplicación está caída; la aplicación puede responder mientras la base de datos no funciona; el enlace WAN puede estar abierto mientras el acceso del lado LAN ha fallado. Un modelo de salud con un único flag no puede capturar estas distinciones.
En muchas organizaciones, el vínculo entre health checks y respuestas DNS es manual o fragmentado. Un sistema de monitorización lanza una alerta, un equipo de operaciones ejecuta un script, un registro DNS se actualiza a mano o una automatización separada toma el relevo. Esta cadena reacciona despacio y es vulnerable al error humano en momentos críticos.
Los escenarios complejos son aún más difíciles. Condiciones como "activar DC1 si tiene acceso a internet y no está en mantenimiento; en caso contrario, devolver un registro de backup si la salud de aplicación de DC2 o el acceso de DC3 son positivos" suelen gestionarse mediante ficheros YAML, scripts y dependencias manuales. Esto convierte una decisión GTM en un laberinto operativo difícil de entender o auditar.
Las oscilaciones son un riesgo real. Cuando un health check falla momentáneamente y el DNS cambia inmediatamente, el tráfico del usuario se mueve a otra región innecesariamente. Igualmente, un éxito breve puede traer el tráfico de vuelta antes de que el problema esté plenamente resuelto. Por tanto, los umbrales consecutivos de éxito y fallo más la lógica de preservación de estado son esenciales.
Los escenarios de health check de TR7 combinan el centro de datos, la aplicación, la base de datos, el modo mantenimiento y comprobaciones personalizadas en una única capa de decisión booleana, atando las respuestas DNS directamente a la salud real del servicio.
Nuestro enfoque
TR7 evalúa las decisiones de salud del GTM combinando comprobaciones automáticas por centro de datos, health checks manuales y lógica de escenario en un modelo unificado.
Las comprobaciones automáticas y manuales se unen en el mismo escenario
Las comprobaciones automáticas por centro de datos, los health checks HTTP/HTTPS/Oracle definidos por el usuario y los resultados de salud del ADC pueden usarse todos dentro de la misma estructura de decisión. Esto liga la salud de la infraestructura y de la aplicación en una única decisión GTM.
Las condiciones booleanas simplifican decisiones complejas
Los escenarios se construyen con grupos AND y OR. Añadir `!` a un identificador de health check niega la condición, de modo que estados como el modo mantenimiento pueden usarse como condiciones negativas en la misma decisión.
Solo se reevalúan los registros afectados cuando cambia el estado de salud
Las relaciones entre health check, escenario y registro DNS se rastrean mediante mapas tipo grafo. Cuando cambia un estado de salud, solo los escenarios y registros impactados se reevalúan.
La validación de contenido comprueba la capa de aplicación — no solo la disponibilidad de puerto
Los health checks HTTP y HTTPS pueden verificar códigos de estado y contenido de respuesta, no solo si un puerto está abierto. Las expresiones JSONata o comprobaciones de contenido simples confirman que la aplicación está devolviendo realmente una respuesta sana.
Capacidades
Los Escenarios de Health Check de TR7 cubren un abanico de necesidades del GTM — desde comprobaciones simples de acceso hasta decisiones multi-capa de aplicación y centro de datos.
Los health checks HTTP y HTTPS validan códigos de estado y contenido de respuesta
TR7 soporta parámetros como método, URI, cuerpo, cabeceras, códigos de estado esperados, verificación de certificado y timeout para las comprobaciones HTTP y HTTPS. Por tanto, la comprobación no solo mide si se puede establecer una conexión — también verifica que la aplicación está devolviendo la respuesta correcta desde el endpoint correcto, acercando la decisión del GTM al comportamiento real de la aplicación.
Historial del escenario — qué paso falló y qué respondió
Un escenario es una cadena de pasos, así que «la comprobación falló» nunca es por sí sola una respuesta útil. TR7 guarda las transiciones de estado de cada backend junto con el paso que falló y los bytes que la sonda recibió realmente en ese momento: la caída del martes a las 03:40 se relee en vez de adivinarse. Las cadenas send/expect con cargas en hexadecimal y Base64 hacen que un puerto que responde pero ya no habla su protocolo suspenda el escenario — y la respuesta registrada muestra exactamente por qué.
Las comprobaciones de contenido JSONata validan respuestas API de forma significativa
Para endpoints de salud que devuelven JSON, pueden evaluarse campos específicos mediante una expresión JSONata. Una expresión como `status = "ok"` confirma no solo que la aplicación responde sino que devuelve el estado de salud esperado. El cuerpo de respuesta se parsea a la estructura adecuada y la expresión se evalúa contra él. Esto da una medida de salud más fiable para aplicaciones modernas basadas en JSON API.
Las comprobaciones de contenido simples proporcionan coincidencia rápida de cadenas
Para escenarios más sencillos, puede comprobarse la presencia de una cadena específica en el cuerpo de respuesta. Este enfoque es suficiente para health checks de aplicación simples que no requieren una expresión JSONata completa. Los equipos de operaciones pueden atar la decisión DNS a la confirmación de que una palabra conocida o un estado fijo aparece en la respuesta de aplicación, haciendo las comprobaciones rápidas y fáciles de entender.
Los health checks Oracle añaden un nivel de base de datos al escenario
Las comprobaciones Oracle se configuran mediante un escenario que incluye pasos para establecer una conexión, esperar y ejecutar un comando. Los resultados se evalúan basándose en un conteo de filas esperado o un texto esperado. Esto permite atar las respuestas DNS no solo al nivel de aplicación sino también a la alcanzabilidad de la base de datos, reduciendo el punto ciego de "la aplicación está arriba pero la base de datos no funciona" en aplicaciones críticas para el negocio.
Cinco health checks automáticos están disponibles para cada centro de datos
TR7 puede usar las comprobaciones `wanAccess`, `lanAccess`, `access`, `internet` y `maintenanceMode` por centro de datos. Estas comprobaciones representan diferentes estados de acceso y operación de cada centro de datos de forma independiente. Estados como el modo mantenimiento pueden tratarse como condiciones negativas en un escenario en lugar de como señales de salud positivas, dando a las decisiones DNS una correspondencia más cercana con la realidad operativa.
Los escenarios booleanos soportan AND, OR y condiciones negativas
Los escenarios se construyen con estructuras de grupos de condición; las condiciones dentro de un grupo siguen lógica AND mientras que las relaciones entre grupos pueden ser OR o AND. Añadir `!` a un identificador de health check invierte la condición, habilitando construcciones como `dcAccess AND NOT maintenanceMode`. Pueden diseñarse decisiones GTM complejas sin escribir scripts.
Los umbrales consecutivos de éxito y fallo reducen el riesgo de oscilación
Los valores `requiredSuccess` y `requiredFailure` pueden configurarse para los health checks. El enfoque por defecto cuenta éxitos o fallos consecutivos antes de aceptar una transición de estado. Esto evita que pérdidas de paquetes momentáneas, picos breves de latencia o fluctuaciones transitorias de servicio cambien inmediatamente la respuesta DNS, haciendo el comportamiento del GTM más estable.
La persistencia local del estado de salud proporciona continuidad tras reinicios
Los estados de health check pueden persistirse a un fichero local y restaurarse cuando el sistema se reinicia. Esto significa que no es necesario reaprender todos los estados de salud desde cero tras cada reinicio. Esta continuidad es especialmente importante en entornos GTM grandes con muchos escenarios y registros, dando a los equipos de operaciones un comportamiento más predecible tras un reinicio.
Once tipos de health check están disponibles para coordinación GTM y ADC
Los health checks TCP, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS y Oracle están disponibles en el ecosistema TR7. Coordinar los resultados de salud del GTM y el ADC permite que las decisiones DNS reflejen el verdadero estado de la capa de servicio. Este amplio soporte de tipos hace posible construir un modelo de salud no solo para aplicaciones web sino para servicios empresariales multiprotocolo. Los escenarios tipo script TCP send-receive también están disponibles para necesidades de comprobaciones personalizadas.
Profundidad operativa
Para que los escenarios de health check funcionen de forma fiable, deben gestionarse claramente el formato del identificador, la persistencia de estado, la secuencia de triggers, el control del nodo maestro y la propagación de cambios.
Tipos de health check
El motor de escenarios puede evaluar tipos de health check que incluyen static, dcCheck, http, https y oracle. Combinado con la familia más amplia de health checks de GTM y ADC, los estados de servicio multiprotocolo pueden traerse a la estructura de decisión — importante para arquitecturas de servicio que no se limitan a un único tipo de comprobación HTTP.
Formato del identificador automático
Los health checks automáticos por centro de datos se identifican usando el formato `auto|
Identificadores de health check manuales
Los health checks definidos por el usuario se crean con identificadores únicos. Estos identificadores pueden referenciarse directamente en las condiciones de escenario, lo que significa que el mismo health check HTTP, HTTPS u Oracle puede evaluarse en múltiples escenarios GTM.
Flujo de triggers
Cuando cambia un estado de salud, el estado del health check correspondiente se actualiza primero. Los escenarios enlazados se reevalúan a continuación y, si es necesario, se regenera la configuración dinámica. Este flujo garantiza que los cambios se propaguen a las respuestas DNS de forma controlada.
Estados de escenario por defecto
Escenarios integrados como `ALWAYS` y `NEVER` están disponibles para producir decisiones fijas. Con `ALWAYS`, un registro siempre se considera elegible; con `NEVER`, se obtiene comportamiento deshabilitado. Esto es útil para pruebas, retiradas temporales o routing incondicional.
Control del nodo maestro
Las acciones de trigger se ejecutan solo en el nodo maestro del GTM. Esto evita que la misma acción se ejecute repetidamente por múltiples nodos en un clúster. Para acciones como disparar DR, webhooks o notificaciones, este control proporciona seguridad operativa.
Cuándo utilizarlo
Decisión DNS basada en acceso WAN y LAN
Las organizaciones multi-sitio pueden no querer que un centro de datos se considere up basándose en un único camino de acceso. TR7 combina distintas rutas de acceso en la misma decisión DNS usando escenarios como `wanAccess OR lanAccess`.
Responder solo cuando aplicación y base de datos están sanas
Para aplicaciones críticas para el negocio, la alcanzabilidad del centro de datos por sí sola no es suficiente. TR7 usa escenarios como `dcAccess AND appHC AND dbHC` para incluir la IP correspondiente en la respuesta DNS solo cuando tanto la aplicación como la base de datos Oracle están sanas.
Mantener el tráfico fuera cuando el modo mantenimiento está activo
Un equipo de operaciones puede no querer que un centro de datos reciba tráfico durante el mantenimiento incluso si es técnicamente alcanzable. TR7 puede eliminar una ubicación en mantenimiento de la respuesta DNS usando un escenario como `dcAccess AND NOT maintenanceMode`.
Routing GTM basado en salud de API JSON
Las aplicaciones modernas pueden publicar su estado de salud mediante un endpoint JSON. TR7 ata las respuestas DNS a la salud real de la aplicación combinando un health check HTTPS con una expresión JSONata como `status = "ok"`.
Preguntas frecuentes
¿Cuál es la diferencia entre un escenario de health check y una comprobación simple up/down?
¿Cómo reflejo el modo mantenimiento en una decisión DNS?
¿Qué puede hacerse para evitar oscilaciones?
¿Cómo ato la salud de una base de datos Oracle a una decisión GTM?
¿Puede usarse el mismo health check para múltiples registros DNS?
¿Se resetean los estados de health check cuando el GTM se reinicia?
Ate sus decisiones DNS a la salud real del servicio
Combine comprobaciones HTTP, HTTPS, Oracle y de centro de datos en escenarios booleanos. Permítanos hacer un recorrido en vivo en su propio entorno.