En operaciones cloud-native, uno de los escenarios más desconcertantes es la denominada «lentitud fantasma». Este fenómeno ocurre cuando los paneles de control como Grafana o Kubernetes muestran que todos los servicios funcionan correctamente: los pods están activos, las pruebas de vida y preparación son exitosas, y la utilización de CPU se encuentra bien por debajo del límite. Sin embargo, los usuarios abren tickets urgentes reportando latencias graves y esporádicas al consultar aplicaciones o al esperar la respuesta de un modelo de inteligencia artificial.
Esta aparente contradicción plantea la cuestión: ¿cómo es posible que las comprobaciones básicas de salud del sistema pasen sin problemas mientras el rendimiento real de la aplicación se degrada? Más aún, ¿cómo pueden los equipos de ingeniería identificar la causa raíz cuando el problema es intermitente y abarca infraestructuras híbridas y multicapa?
Para profundizar en estas regresiones de rendimiento difíciles de detectar, The New Stack entrevistó a Mahesh Ramachandran, responsable de gestión de producto en HPE OpsRamp Software. Ramachandran explica cómo la telemetría continua y el análisis retrospectivo ayudan a los equipos a investigar estas lentitudes intermitentes, y cómo la inteligencia artificial puede complementar los paneles tradicionales. 
La ilusión de tener un clúster saludable
En Kubernetes, las sondas de vida y preparación indican si un contenedor debe reiniciarse o si está listo para recibir tráfico. Estas pruebas pueden incluir condiciones específicas de aplicaciones o dependencias, pero un resultado positivo en estas pruebas no garantiza que una petición de usuario cumpla con el objetivo de tiempo de respuesta.
Ramachandran describe un escenario común en empresas: los usuarios reportan lentitud esporádica en las respuestas de una aplicación que sirve peticiones para un modelo de IA en Kubernetes. Al inspeccionar el clúster, nodos y pods, todo parece saludable y sin fallos reportados. Sin embargo, el carácter intermitente del problema dificulta enormemente detectar su origen sin evidencia histórica.
Por tanto, las pruebas de sondeo son útiles para acotar la investigación, pero no para cerrar la causa. Una instantánea del sistema saludable puede no reflejar una lentitud ya ocurrida, y la ausencia de fallos en contenedores no implica que la aplicación o sus dependencias estén funcionando de manera óptima. El siguiente paso es vincular el retraso reportado por el usuario con medidas de rendimiento tomadas durante el tiempo afectado.
Telemetría multicapa en infraestructuras híbridas: distinguir la señal del ruido
Para resolver lentitudes esporádicas es indispensable ir más allá de las métricas superficiales de Kubernetes y disponer de telemetría continua que abarque todos los niveles. Las arquitecturas modernas cloud-native dependen no solo del código de aplicación o contenedores, sino también de infraestructuras virtualizadas, infraestructuras bare-metal y APIs públicas, según el entorno desplegado.
HPE OpsRamp recolecta señales de forma constante en todos los niveles: nodos y pods Kubernetes, controladores de entrada y servicios, capturando logs, eventos y métricas. Según Ramachandran, el primer paso para investigar problemas intermitentes es tener un registro continuo para poder correlacionar los síntomas reportados por usuarios con evidencias reales en la telemetría histórica.
No obstante, encontrar estas evidencias no es trivial. A menudo las anomalías no se manifiestan como picos evidentes en una sola métrica, sino como ligeras variaciones o comportamientos correlacionados en dos señales que por separado parecen normales pero que juntas generan latencia.
Por tanto, en una investigación práctica se parte de la transacción afectada y la ventana temporal del incidente. Se comparan los tiempos de respuesta y peticiones por segundo con el estado y número de pods, buscando diferencias en las señales que coincidan con los episodios de lentitud.
Una correlación inicial aporta una posible explicación, aunque no prueba causa directa. Tras aplicar una corrección, se vuelve a medir el comportamiento para verificar una mejora. Dada la complejidad del escenario, es necesario validar cualquier hipótesis en el propio entorno del equipo.
Respecto a la cobertura, depende de los agentes, integraciones, permisos y la instrumentación configurada. OpsRamp ofrece recopilación en los distintos niveles:
- Aplicación: Recolección de trazas mediante OpenTelemetry compatible para aplicaciones instrumentadas, ya que sólo monitorizar la infraestructura no genera trazas de la aplicación.
- Orquestación: Agentes Kubernetes que obtienen telemetría del clúster y cargas de trabajo, con configuraciones adicionales para monitorizar componentes como controladores de entrada.
- Virtualización e HCI: Integraciones con VMware, Nutanix y HPE Morpheus para recopilar inventario y datos de rendimiento, facilitando la identificación de cuellos de botella en infraestructura.
- Hardware: Integración con el protocolo Redfish para obtener telemetría de servidores físicos soportados, siempre que haya acceso API y conectividad.
Desentrañando dependencias opacas fuera del clúster
Las aplicaciones frecuentemente dependen de servicios externos al clúster Kubernetes, como endpoints SaaS, bases de datos externas o modelos públicos de IA. En estos casos, la visibilidad directa se vuelve limitada, creando una frontera en el control de la monitorización.
Ramachandran explica que para descartar la influencia de una dependencia externa en un problema de latencia, es necesario cuantificar su rendimiento como una caja negra. Las transacciones sintéticas o mediciones de tiempo de respuesta al servicio externo ayudan a comparar su comportamiento con las transacciones internas afectadas.
Sin embargo, estas mediciones sólo aportan evidencia en el límite del servicio, sin revelar causas internas del proveedor externo ni diferenciando automáticamente cada retardo externo de uno interno. Es vital identificar a los responsables de cada dependencia externa y quién puede investigar cuando la monitorización no avanza más allá de ese punto.
Además, la telemetría debe contemplar medidas de seguridad, especialmente en cargas de trabajo de IA donde los prompts, respuestas y documentos recuperados podrían aparecer en logs y trazas. La recopilación y gestión de datos debe alinearse con las políticas de acceso y manejo de información de la empresa.
De paneles estáticos a copilotos inteligentes en la alerta y análisis
A medida que los entornos se complejizan, interpretar telemetría a través de múltiples paneles resulta cada vez más difícil. Decidir qué métricas merecen alertas en tiempo real frente a un monitoreo pasivo es un desafío continuo.
Ramachandran señala que determinar qué señales deben activar alertas es tanto una ciencia como un arte que requiere integrar el conocimiento explícito y tácito de la operación humana en las plataformas para que comprendan impactar realmente en la experiencia del usuario.
Los paneles curados siguen siendo útiles para vistas definidas del sistema, pero los asistentes potentes basados en inteligencia artificial ofrecen nuevas formas de explorar datos operativos por lenguaje natural. El software de HPE OpsRamp incorpora un copilot de operaciones impulsado por IA que facilita investigar incidentes, correlacionar evidencias y sugerir pasos a seguir, dependiendo de la configuración y datos disponibles en cada cliente.
Mirando hacia el futuro, Ramachandran prevé un cambio fundamental en operaciones cloud-native: la interpretación inicial de la telemetría deberá ser liderada por la inteligencia artificial, dado el aumento de la complejidad y dinamismo del entorno.
Aunque hoy el responsable de interpretar la telemetría sigue siendo mayoritariamente humano, la creciente cantidad de señales y componentes móviles vuelve inviable confiar sólo en la capacidad humana. El experto advierte que el análisis y los cambios autónomos basados en IA requieren cautela, ya que los resultados pueden no ser deterministas y las operaciones IT necesitan comportamientos consistentes y reproducibles.
Por ello, recomienda mantener supervisión humana y establecer salvaguardas fiables antes de automatizar acciones basándose en hallazgos de IA. Es esencial validar diagnósticos y comprobar el impacto de cualquier respuesta, incluso con asistencia de máquinas en la recopilación y análisis.
La base para esta evolución son la instrumentación y telemetría adecuadas, establecer líneas base y umbrales específicos para cada carga de trabajo, y verificar siempre mejoras basadas en la experiencia real del usuario.
En definitiva, aunque un panel verde en el clúster invita a la tranquilidad, solo las mediciones reales de la aplicación confirman si el servicio entrega la experiencia que los usuarios esperan y merecen.
