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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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 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.
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.
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.
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.
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.
Los health checks automáticos por centro de datos se identifican usando el formato `auto|
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.
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.
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.
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.
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`.
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.
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`.
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"`.
Combine comprobaciones HTTP, HTTPS, Oracle y de centro de datos en escenarios booleanos. Permítanos hacer un recorrido en vivo en su propio entorno.