Investigaciones de Kubernetes impulsadas por agentes con Elastic Observability y MCP

Monitor clusters, pods, and nodes with full application context across EKS, GKE, AKS, and OpenShift. 

Join our on-demand webinar: Kubernetes management with Elastic & agentic AI to level up your skills. You can also start a free cloud trial, or run Elasticsearch locally.

La observabilidad de Kubernetes impulsada por agentes ya está disponible en Elastic Observability. Ya sea que uses la UI de Elastic Observability o tus propios flujos de trabajo basados en agentes, Elastic ofrece un conjunto de capacidades para ayudarte a investigar el problema de Kubernetes en cuestión. Hemos lanzado una app de MCP (Protocolo de Contexto de Modelo) que permite a agentes de AI como Claude y Cursor consultar Elastic Observability para comprender las fallas de K8s y mostrar anomalías de ML sin salir de tu interfaz de chat.

En la Parte 1, cubrimos cómo la integración de Kubernetes de Elastic envía telemetría a través del EDOT Collector a Elasticsearch. En esta publicación, vamos más allá con un servidor de app de MCP (Protocolo de Contexto de Modelo) que expone esa telemetría como herramientas invocables por AI, con UI interactivas de React renderizadas en línea. También cubriremos cómo ir más allá con los flujos de trabajo de Elastic: runbooks automatizados que manejan todo el ciclo de análisis de causa raíz desde la alerta hasta la propuesta de remediación.

Observability MCP App que renderiza donde trabajas

La Elastic Observability MCP App (vista previa técnica) incluye seis vistas, una por herramienta. Cada una se renderiza en línea cuando la herramienta responde y presenta sugerencias de próximos pasos como botones en los que se puede hacer clic para que no tengas que adivinar el seguimiento adecuado. Las MCP Apps van más allá de los flujos de trabajo de agentes independientes: renderizan vistas interactivas en tiempo real directamente dentro de tu chat o IDE, integradas en la conversación y sin tener que cambiar de contexto a Kibana.

Agregación del estado del cluster

Haz preguntas como “¿qué está fallando?” o “dame un reporte de estado” y obtén una vista de orientación en una sola ejecución: indicador general de salud, servicios degradados con sus causas, principales consumidores de memoria por pod, desglose de la severidad de anomalías y rendimiento de los servicios, todo en una única vista integrada.

La vista se adapta en función de lo que soporta tu despliegue. APM te ofrece información sobre el estado de los servicios. Las métricas de Kubernetes agregan contexto de pod y nodo. Los trabajos de ML añaden la capa de anomalías. Si una señal no está presente, la vista te indica qué falta en lugar de fallar. Comenzaremos con un reporte de estado del cluster de Kubernetes:

Los reportes compuestos, como el resumen de estado, cuentan con una presentación de datos condensada con expansión de detalles para que puedas elegir la cantidad adecuada de información que deseas ver a la vez. Las acciones de investigación sugeridas brindan orientación tanto sobre la información específica que se devuelve como sobre otras herramientas que los usuarios pueden ejecutar.

Grafo de dependencia de servicios

Haz preguntas como “¿qué llama a finalizar la compra?” o “muéstrame la topología” y obtén un grafo de dependencias por capas: llamadas upstream, dependencias downstream, protocolos, volumen de llamadas y latencia por cada enlace. Pasa el puntero sobre un enlace para resaltar la ruta de llamada completa. Pidámosle a Claude que “me muestre las dependencias de servicio del frontend”:

Haz zoom, desplázate y pasa el cursor por encima para ver todos los detalles que necesitas para entender las complejas relaciones entre los servicios:

Detalles de la anomalía

Pregunta “¿qué es anómalo?” o “¿hay algo inusual en la finalización de la compra?” y obtén una de dos vistas, elegida automáticamente. Si se ven afectadas varias entidades, el modo de visión general muestra los recuentos de gravedad, las entidades afectadas y un desglose por trabajo. Si el enfoque es una sola entidad, el modo de detalle muestra la puntuación, los valores reales frente a los típicos con una barra de comparación, el porcentaje de desviación y una serie temporal cuando esté disponible. Revisemos el servicio de frontend:

Esta no es una búsqueda ESQL, sino una explicación de los resultados de un trabajo de detección de anomalías definido previamente. Como se explicó en la parte 1 de esta serie de blogs, la integración de Kubernetes incluye algunos trabajos de detección de anomalías que puedes habilitar. Esta herramienta te ayudará a aprovecharlos al máximo.

Observe

Observe es la primitiva de acceso principal del agente para Elastic: una sola herramienta, con dos modos para tres necesidades distintas. Di “cuál es el rendimiento de red de cada uno de mis clusters de Kubernetes” para obtener una tabla o un gráfico de resultados. Di “avísame cuando la memoria baje de 80 MB” o “vigila si hay alguna anomalía en la memoria del frontend durante los próximos 10 minutos” y bloquea la ejecución hasta que se cumpla la condición o expire la ventana.

La vista se adapta al modo: una tabla de resultados para búsquedas puntuales, un gráfico de tendencia en vivo con estadísticas actuales/pico/línea base para el muestreo y condiciones de umbral, y una tarjeta de activación con severidad para el modo de anomalías. Lo usaremos aquí para identificar el nodo de Kubernetes más ocupado:

Evalúa el riesgo con un radio de impacto

Haz preguntas como “¿qué pasa si se cae este nodo?” y obtén un diagrama radial de impacto: el nodo objetivo en el centro, los despliegues con interrupción total en rojo, los degradados en ámbar y los no afectados en gris. Una tarjeta de resumen flotante muestra los pods en riesgo y la viabilidad de su reprogramación. Los despliegues de una sola réplica se señalan como puntos únicos de falla. Qué pasaría si nuestro nodo ocupado cayera:

Gestión de alertas

Con la herramienta de administración de alertas, puedes crear, listar, obtener información y eliminar alertas. A continuación crearemos una alerta, pero primero usa Observe una vez más para tomar una línea base rápida a fin de saber que la alerta tendrá sentido:

Di “alértame si la memoria de frontend supera los 75 MB” y el agente crea una regla de alertas persistente de Kibana, un objeto guardado que sigue ejecutándose después de que finaliza la conversación. La vista muestra una tarjeta de regla en vivo: nombre de la regla, condición, ventana, intervalo de verificación, filtro KQL y etiquetas. Los botones de próximos pasos ofrecen verificar la regla, observar cómo se estabiliza la métrica o comprobar el estado actual del cluster. El agente confirma qué se creó y dónde encontrarlo en Kibana:

Arquitectura de la MCP App

La app está compuesta por un servidor Node.js, seis herramientas orientadas al modelo conectadas a seis recursos de vista en archivos individuales, herramientas exclusivas para la app para nuevas búsquedas y empaquetado con vite-plugin-singlefile. Las herramientas se agrupan según el backend de despliegue (universal, dependiente de APM, dependiente de K8s, dependiente de ML), de modo que tanto el agente como el usuario saben desde el inicio qué herramientas aplican a un despliegue determinado, en lugar de descubrir limitaciones de capacidad en el momento de la ejecución. El repositorio incluye seis Skills como artefactos .zip independientes que enseñan al agente cuándo y cómo invocar cada herramienta.

El siguiente diagrama muestra los tres componentes que componen la app: el host de MCP (Claude Desktop, VS Code o similar), que contiene el LLM y las habilidades de Claude que le enseñan a usar las herramientas; el servidor de la MCP App, un único proceso de Node.js que expone el registro de herramientas, empaqueta las vistas de la UI de React y gestiona toda la comunicación con Elastic; y el propio Elastic Stack, donde Elasticsearch y Kibana funcionan como los backends de alertas y datos en tiempo real.

El siguiente diagrama describe el flujo de una solicitud de usuario: Claude lee el archivo de habilidades correspondiente para comprender qué herramienta invocar y cómo completar sus parámetros, invoca la herramienta que activa búsquedas del lado del servidor en Elasticsearch y Kibana, y recibe un resumen de texto compacto junto con un recurso de UI de React que se renderiza en línea como un widget interactivo.

De la alerta a la causa raíz: flujos de trabajo de investigación

Las reglas de alerta te indican que algo anda mal. Los módulos de ML te indican el patrón. Los flujos de trabajo de Elastic realizan el diagnóstico automáticamente, en cuanto se activa una alerta.

Lanzamos un flujo de trabajo de investigación de Kubernetes (vista previa técnica) que se activa ante una alerta de Kubernetes y devuelve un resumen estructurado de la causa raíz antes de que hayas abierto un solo dashboard. El SRE que recibe la notificación abre la alerta y encuentra la investigación ya realizada.

El flujo de trabajo es un grafo dirigido de pasos que consulta múltiples fuentes de datos, principalmente mediante el lenguaje de búsqueda de Elasticsearch (ES|QL), con una búsqueda de Elasticsearch para la consulta de anomalías de ML. Los pasos if se bifurcan según los resultados de búsqueda y eligen qué corroboración ejecutar (anomalía de memoria de ML frente a clasificación de logs) y si evaluar el estado de los servicios upstream (solo cuando existen dependencias de APM). Los pasos de AI aparecen en tres puntos: clasifican patrones de logs en la ruta sin OOM, clasifican el estado upstream como degradado o saludable y, al final, ai.summarize sintetiza toda la evidencia estructurada en una narrativa de causa raíz.

Cómo se ve el flujo de trabajo de investigación en la práctica

La ejecución de ejemplo a continuación se basa en OpenTelemetry Astronomy Shop ejecutándose en Elastic: 16 servicios, Kafka, PostgreSQL, todos preinstrumentados mediante OTLP. Además de la telemetría real de la tienda, inyectamos una cascada de OOMKill sintética, que escribe señales sintéticas de K8s y APM en el mismo espacio de nombres mediante los flujos de datos de EDOT. El flujo de trabajo no puede distinguir nuestras señales de las reales; simplemente investiga la alerta.

Se activa la alerta: CrashLoopBackOff — app-deployment en oteldemo-esyox-default. Recuento de reinicios: 6.

Paso 1 del flujo de trabajo: caracterizar el contexto de pod y contenedor

El flujo de trabajo busca las métricas de K8s para obtener el recuento de reinicios, el último motivo de finalización y la utilización con respecto a los límites declarados.

Resultado: último motivo de finalización OOMKilled, recuento de reinicios 6. (Nota: La utilización de kubeletstats no estuvo disponible para este pod/ventana: el flujo de trabajo continúa sin problemas).

Ramas del flujo de trabajo: el motivo de finalización es OOMKilled, por lo que el flujo de trabajo sigue la ruta de investigación de memoria, no la ruta de investigación de logs.

Paso 2a del flujo de trabajo: consultar los resultados de anomalías de ML

En lugar de volver a calcular las tendencias de memoria, el flujo de trabajo consulta el índice de anomalías de ML en busca de una anomalía activa de k8s_pod_memory_growth.

Resultado: sin anomalías, el pico está marcado como impulsado por la carga, no como una sospecha de fuga.

Paso 3 del flujo de trabajo: comprobar el estado del servicio upstream

El flujo de trabajo enumera las dependencias upstream de los agregados service_destination.1m de APM, y luego compara la tasa de errores actual y la latencia media con respecto a la misma hora de hace 7 días. Un paso de clasificación por AI decide si la degradación upstream precedió a la alerta. Resultado: un upstream — api-gateway. Latencia media actual de 15,13 ms, tasa de errores de 41,26 %. Línea base (hace 168 h): idéntica. Clasificación: upstream_healthy: dentro de los umbrales de 5× de error/3× de latencia. Se descarta el servicio upstream.

Paso 4 del flujo de trabajo: correlacionar con cambios recientes de K8s

El log de eventos del espacio de nombres muestra un ciclo ajustado de Pulled → Created → Started → Killing → BackOff que se repite aproximadamente cada 60-90 segundos. No hay despliegues ni eventos de escalado en las últimas dos horas.

Salida del flujo de trabajo:

HIPÓTESIS DE CAUSA RAÍZ (confianza: alta)

app-deployment se está terminando por OOMKill debido a la presión de la memoria. El pod se ha reiniciado
6 veces con el motivo de finalización OOMKilled. ML marcó el pico de memoria como impulsado
por la carga (sin fuga). El servicio upstream api-gateway está en buen estado en comparación
con la línea base de hace 7 días. Este es un problema de asignación de recursos: el límite de la memoria del contenedor
es demasiado bajo para su conjunto de trabajo real.

Evidencia:
- 6 reinicios, último motivo de terminación OOMKilled
- Sin anomalías de crecimiento de memoria detectadas por ML → leak_suspected=false (impulsado por la carga)
- El servicio upstream api-gateway no presenta cambios respecto de la línea base de hace 7 días (15,13 ms, 41,26 %) → en buen estado
- Los eventos de K8s muestran ciclos rápidos y repetitivos de Pulled/Created/Started/Killing/BackOff;
  sin despliegues en las últimas 2 h

Causa probable: límite de memoria insuficiente para el conjunto de trabajo real bajo carga.

Próximos pasos recomendados:
1. Aumenta el límite de memoria del despliegue de la app según el uso observado
2. Revisa el código de la aplicación en busca de oportunidades de optimización de memoria
3. Considera la degradación controlada en rutas con alta carga

Impacto downstream: ninguno identificado a partir de las métricas de destino de APM.

La salida anterior es cómo se ve la alerta cuando la abres, no un enlace a un montón de logs o a un dashboard, sino una respuesta.

El mismo flujo de trabajo es accesible como una herramienta MCP desde Claude Desktop, VS Code o cualquier cliente compatible con MCP. Cuando un desarrollador pregunta “¿por qué la finalización de la compra da error?” desde su IDE, el agente llama al flujo de trabajo y devuelve la misma salida estructurada en línea, la misma evidencia, la misma causa raíz, sin salir del editor.

Este es un recorrido animado de la ejecución del flujo de trabajo:

Skill de Observability para investigaciones de Kubernetes

También incluimos una sola habilidad de investigación integral (observability-k8s-investigation) que codifica el protocolo de diagnóstico completo para problemas de cargas de trabajo, nodos y plano de control de Kubernetes. Es una metodología de investigación prescriptiva que incluye el razonamiento que un SRE experimentado aplica instintivamente, pero rara vez documenta. Obtendrás esto al mantener Kibana actualizado, ya que está integrado en las habilidades de nuestro agente de AI. Comienza con principios rectores que previenen los diagnósticos erróneos más comunes:

• La ausencia de evidencia no es evidencia. Si las búsquedas de logs devuelven cero filas, reporta no_logs_available, no infieras un modo de falla a partir de resultados vacíos.
• OOMKilled no significa una fuga de memoria de forma predeterminada. Compara el uso actual con una línea base de 7 días antes de afirmar que hay una fuga. Es posible que el límite simplemente sea demasiado bajo.
• Las métricas de CPU promedio ocultan la limitación. Un pod puede parecer en buen estado con un uso promedio del 40 al 60 % mientras sufre una limitación severa en p99. Mira el máximo y el p95, no solo el promedio.
• Los síntomas concurrentes no son causas. Dos servicios que se degradan simultáneamente suelen compartir una causa upstream. Solo atribuye causalidad cuando la degradación de un servicio precede claramente a la del otro y la diferencia es grande.

A partir de allí, la Skill codifica una taxonomía de modos de falla que abarca 16 patrones de falla distintos de K8s en las capas de cargas de trabajo, nodos, plano de control, escalado automático y redes, desde OOMKilled y limitación de CFS hasta bloqueos de webhook de admisión y split-brain de StatefulSet. Cada modo cuenta con una señal clave que lo identifica y una lista de verificación de corroboración que lo confirma.

El flujo de investigación sigue un arco estructurado: orientar (resolver el pod, espacio de nombres y despliegue de destino), caracterizar (obtener el recuento de reinicios, los motivos de finalización y la utilización), clasificar (contrastar con la taxonomía), corroborar (extraer eventos, logs, APM y comparaciones con la línea base) y sintetizar (producir una hipótesis de la causa raíz con una confianza calibrada, alta, media o baja, con evidencia explícita y próximos pasos recomendados).

Cuando dos modos de falla se ajustan a la evidencia, la Skill menciona ambos y dice cuál considera que es causal y por qué. Cuando la evidencia es ambigua, lo dice. “Las hipótesis en competencia son una salida válida” es un principio de diseño explícito: generar una falsa confianza se considera un modo de falla de la propia investigación.

Primeros pasos

Estas capacidades se basan en la integración de Kubernetes descrita en la Parte 1. Una vez que tengas los dashboards y la recopilación de datos en funcionamiento:

Paso 1: habilita los flujos de trabajo de investigación (vista previa técnica). Importa el flujo de trabajo Kubernetes Crashloop Investigation desde la página Workflows en Kibana y, opcionalmente, configúralo para que se active a partir de una regla de alerta.

Paso 2: instala la MCP App en un cliente compatible con MCP (vista previa técnica). El repositorio de la MCP App para Observability se puede encontrar en GitHub (consulta la página Lanzamientos para ver las descargas). Al instalar la app, no olvides instalar y habilitar también las habilidades incluidas. Accede a las herramientas de la MCP App de ejemplo desde tu cliente agéntico favorito; las instrucciones se encuentran en el README en el enlace de GitHub de arriba.

Paso 3: aprovecha la habilidad de investigación de K8s (vista previa técnica). Esto es gratis si usas Agent Builder, porque está integrado en AI Agent Skills. La habilidad le enseña al agente cuándo y cómo invocar las herramientas y los flujos de trabajo subyacentes, lo que garantiza diagnósticos coherentes en contextos conversacionales.

¿Qué sigue?

Los flujos de trabajo de investigación diagnostican qué está roto en los servicios que estás monitoreando. La siguiente pregunta es más difícil: ¿qué sucede con los servicios que no estás monitoreando?

Estamos pensando en la inteligencia de cobertura con reconocimiento de topología: descubrir automáticamente cada carga de trabajo desplegada en tu cluster a través de la API de Kubernetes, cotejarla con la telemetría que fluye hacia Elastic y visibilizar la brecha. “Tienes 47 servicios. 11 no tienen trazas distribuidas. Aquí está tu punto ciego más riesgoso”. Esa capacidad está en consideración y probablemente sea el tema de una futura publicación.

En paralelo, estamos extendiendo los flujos de trabajo hacia la remediación, no solo diagnóstico sino acción: crear un caso con el resumen de la investigación adjunto, proponer una reversión para aprobación humana o escalar una carga de trabajo para ganar tiempo mientras se aborda la causa raíz.

Si hoy ejecutas Kubernetes en Elastic, cuéntanos qué pasos de investigación repites manualmente en cada incidente, qué remediaciones confiarías que proponga un flujo de trabajo y qué herramientas MCP deberíamos crear a continuación. Puedes unirte al debate de la comunidad de Elastic aquí.