La salud del backend se monitorea siempre desde la capa de protocolo en el mundo clásico del load balancing. El ADC envía una solicitud HTTP al servidor, recibe 200 OK, añade el servidor al pool. O hace un probe TCP, si el puerto está abierto lo considera sano. Incluso quizá hace una validación de contenido: '¿está esta palabra en la respuesta?'
Este enfoque mira desde la cáscara exterior; no mira desde dentro. No ve que la ocupación de disco del servidor ha llegado al 98%, que la RAM ha caído en swap y el rendimiento se ha desplomado, que el ciclo de GC se ha alargado, que se ha llenado el límite de conexiones de la base de datos. El servidor sigue devolviendo HTTP 200 — pero el usuario sufre una espera de segundos para su solicitud.
Peor aún: el probe de protocolo se considera local, no reporta el estado propio del servidor. El ADC solo ve lo que ve el probe. La presión de recursos acumulada en el servidor o el ciclo de reinicio de un proceso crítico no afectan la decisión de routing.
ETM Telemetría de Servidor cierra esta brecha. El agente en el servidor transmite continuamente su propio estado interno al ADC. La decisión de routing se toma no a partir del probe de protocolo externo, sino a partir de datos en vivo provenientes de dentro.
TR7 ETM modela la salud del servidor como una entrada viva de la capa de routing del ADC. Este enfoque combina la seguridad del cliente y la observability del servidor en la misma plataforma.
El agente en el servidor mide en tiempo real la carga de CPU, el uso de memoria, la presión de swap, la saturación de IO de disco y el throughput de las interfaces de red. Los datos se transmiten al ADC a intervalos periódicos — del orden de segundos; la decisión de routing se alimenta de estos datos actualizados.
Se monitorean la salud de los procesos críticos de la aplicación, los ciclos de reinicio, el tiempo de garbage collection, el número de descriptores de archivo abiertos, el estado del thread pool y las métricas específicas de la aplicación (p. ej. límite de conexiones de base de datos). Si la aplicación no está sana, el tráfico no va a ese servidor.
El algoritmo de load balancing del ADC puede operar según la puntuación de salud proveniente de la telemetría de ETM. Un servidor con CPU alta recibe menos tráfico, un servidor con saturación de IO se saca de las nuevas conexiones, un servidor que ha caído en swap se limpia automáticamente del pool.
El mismo agente ETM usado para la seguridad del cliente opera también en los servidores. El equipo de operaciones usa un único agente, una única capa de gestión y un único modelo de telemetría. No queda necesidad de desplegar una herramienta separada para la observability del backend.
La telemetría de servidor no es solo observability; es la fuente de datos en vivo de la decisión de routing del ADC.
El número de CPU, el promedio de carga continuo, el porcentaje de uso instantáneo y el estado térmico se miden en tiempo real. La anomalía en la carga por núcleo o la caída de rendimiento por throttle térmico se reflejan en la decisión de routing.
Se monitorean la memoria total y disponible, el uso de swap, la tasa de page fault y la actividad del OOM killer. Un servidor que ha caído en swap puede pasar automáticamente a un pool de baja prioridad; un servidor cuyo riesgo de OOM se hace evidente puede retirarse del tráfico.
Se monitorean la tasa de ocupación de disco, el tiempo de espera de IO, el número de IOPS, el número de solicitudes en cola y los recuentos de errores SMART. Cuando se supera el umbral de ocupación de disco o la saturación de IO es alta, el servidor se retira del tráfico.
Se monitorean si los procesos críticos definidos están en ejecución, la última hora de reinicio y el número de ciclos de restart. Una aplicación que se reinicia continuamente se retira del tráfico; el pool se marca para la intervención del operador.
Las métricas específicas de la aplicación en el servidor — métricas del runtime de la aplicación (tiempo de GC, latencia del event loop), saturación del límite de conexiones de base de datos, profundidad de cola — pueden extraerse a través del agente. El ADC puede incluir estas métricas en la decisión de routing.
Se monitorean el throughput de las interfaces de red del servidor, la tasa de pérdida de paquetes, el número de retransmisiones y el número de conexiones TCP activas. Un servidor con saturación de red se marca automáticamente con un peso bajo.
Se monitorean el periodo de validez de los certificados TLS en el servidor, la integridad de hash de los archivos de configuración críticos y los cambios en los almacenes de certificados. Un certificado próximo a expirar genera tanto una alerta al operador como puede incluirse en la política de routing.
La desviación del servidor respecto a su baseline de configuración se captura al instante. Un cambio de configuración no autorizado, una cuenta de usuario inesperada o el inicio de un nuevo servicio llega a ETM como un evento. Esta señal se refleja tanto en las decisiones de seguridad como de operación.
La telemetría de ETM puede convertirse en una puntuación de salud de 0 a 100 por servidor. El algoritmo de load balancing del ADC (round-robin, least-conn, weighted least-conn) puede usar esta puntuación como peso. Un servidor cuya puntuación baja recibe menos tráfico; un servidor que cae por debajo del umbral sale del pool.
Señales como la velocidad de aumento de la ocupación de disco, la tendencia de consumo de memoria y la frecuencia de restart pueden interpretarse de forma predictive. Aunque el servidor aún no haya fallado, el tráfico se retira de forma suave de un servidor cuya probabilidad de fallar en poco tiempo aumenta.
La telemetría de servidor es la fuente de datos en vivo de la inteligencia de routing del ADC — incluidas integración, escalabilidad y auditoría.
La telemetría fluye periódicamente al plano de control del ADC. El algoritmo de load balancing puede operar según la puntuación de ETM; las decisiones de routing especiales pueden dispararse según los eventos de ETM. El operador puede vincular las métricas de ETM al lenguaje de política sin escribir ningún custom script.
El probe de salud activo basado en protocolo (HTTP, TCP, Oracle) sigue funcionando; la telemetría de ETM añade una capa de 'visión interna' junto a este probe. La decisión de routing evalúa ambas fuentes en conjunto: '¿responde?' (probe de protocolo) + '¿está sano?' (ETM).
Qué métricas se recopilan con qué periodo puede configurarse según el rol del servidor. Para un servidor web pueden priorizarse CPU/RAM/IO, para un servidor de base de datos el límite de conexiones y la query latency, para un servidor de aplicaciones el GC y el thread pool.
El agente en el servidor está diseñado para un uso mínimo de recursos. Opera sin causar pérdida de rendimiento incluso en backends de alto throughput. La intensidad de recopilación de métricas es configurable.
La telemetría puede transferirse a las plataformas corporativas de monitoreo y observability. Cuando se desea usar el stack de observability estándar de la organización en lugar de la propia interfaz de gestión de ETM, se proporciona el flujo de datos.
Desde un único clúster TR7 puede recopilarse la telemetría de miles de servidores. En las estructuras multirregión, con Central Management los inventarios de servidores de distintas regiones se visualizan desde una única consola.
Cuando el límite de conexiones de base de datos del servidor de aplicaciones se acerca a la saturación, ETM lo transmite al ADC. El ADC reduce gradualmente el peso de ese servidor; las nuevas conexiones se dirigen a otros servidores. El usuario no ve timeout; el backend respira de forma gradual.
Cuando la ocupación de disco de un servidor supera el 95% por copias de seguridad o acumulación de logs, ETM genera un evento. El servidor se saca automáticamente del pool; se marca para la intervención del operador. Se evita que el disco se llene por completo y el servicio se caiga.
Un servidor cuyo uso de memoria aumenta de forma continua y con alto riesgo de OOM puede pasarse a un peso bajo mediante ETM antes de caerse. El tráfico se desplaza suavemente a otros servidores; el problema se resuelve antes de convertirse en un incidente.
La validez de menos de 30 días del certificado TLS en el servidor se notifica a ETM. Se envía una alerta al operador; hasta que se renueve el certificado, el servidor puede no recibir tráfico crítico o puede elevarse la alarma. Se elimina el riesgo de un error sorpresa de certificado.
Veamos ETM Telemetría de Servidor en vivo en su propio backend — planifiquemos una sesión de instalación sobre un grupo de servidores piloto.