• Elasticsearch es un backend de métricas compatible con Prometheus Prometheus Remote Write y PromQL ahora funciona de forma nativa en Kibana, no se requiere ninguna capa de traducción.

• Las métricas llegan a la arquitectura TSDS columnar de Elasticsearch almacenando datos de manera hasta 2,5 veces más eficiente que Prometheus y 2 veces más eficiente que ClickHouse.

• Las búsquedas de series temporales de ES|QL se ejecutan hasta 30 veces más rápido que Prometheus en promedios de indicadores y tasas de contadores, incluidas las cargas de trabajo de alta cardinalidad.

• Elastic cuesta aproximadamente un 50 % menos que Datadog, sin clasificación de métricas personalizadas ni facturación basada en la cardinalidad.

• Grafana puede realizar búsquedas directamente en Elasticsearch a través de la API nativa de Prometheus, manteniendo tu capa de visualización mientras reemplazas el backend.

• Kubernetes y el monitoreo de AWS incluyen dashboards prediseñados, plantillas de alerta, trabajos de detección de anomalías de ML y contenido de investigación agéntica disponibles desde el momento de la ingesta. Además, las habilidades y las MCP Apps están disponibles.

• Backend unificado para métricas, logs y rastreos que permite realizar investigaciones agénticas sin unir el contexto entre herramientas.

• La exploración de métricas en Discover permite que cualquiera comience a consultar y analizar métricas de inmediato, sin necesidad de tener experiencia en un lenguaje de búsqueda.

• La creación de dashboards personalizados es rápida y flexible: dashboards como código, creación de dashboards asistida por AI, controles de variables y paneles contraíbles significan menos tiempo creando y más tiempo investigando.

• Herramientas de migración para ayudar a migrar fácilmente dashboards y reglas de alertas/monitores desde Datadog y Grafana.

Las métricas de Elasticsearch ahora compiten en todas las dimensiones que les importan a los SRE: puedes darte el lujo de conservar cada métrica a resolución completa, hacer búsquedas en ellas hasta 30 veces más rápido que en Prometheus, pagar un 50 % menos que en Datadog, migrar dashboards y reglas de alertas desde Grafana o Datadog con facilidad, y pasar de la alerta a la causa raíz sin tener que conectar contextos entre herramientas aisladas. En el resto de esta publicación, analizaremos cada uno de ellos en detalle.

Rendimiento de métricas de Elasticsearch: 30 veces más rápido que Prometheus y Mimir

Datadog y Prometheus plantean la misma disyuntiva: descartar los datos de alta cardinalidad o ver cómo se disparan los costos. Los SRE que administran Kubernetes, AWS o cualquier infraestructura de alta cardinalidad conocen la forma específica de este problema. Las etiquetas de Kubernetes, los datos efímeros de los pods y las dimensiones detalladas de OTel que más importan durante un incidente son lo primero que se descarta cuando los presupuestos se ajustan.

Elastic reconstruyó el almacén de datos de series temporales y el motor de cómputo de ES|QL en un motor de métricas completamente columnar. Agregar una nueva etiqueta de Kubernetes, una nueva etiqueta de instancia de AWS o una nueva dimensión de la aplicación no sobrecarga el sistema; agrega mucho menos costo que los sistemas que indexan cada etiqueta. Las métricas de OTel, Prometheus y definidas por la aplicación llegan al mismo backend columnar con resolución completa, con logs, trazas y métricas en un único almacén. No se descartan datos ni se acorta la retención.

Elasticsearch almacena métricas con una eficiencia hasta 2,5 veces mayor que Prometheus (los resultados pueden variar debido a factores como la compactación) y 2 veces mayor que ClickHouse. Las búsquedas mediante ES|QL se ejecutan hasta 30 veces más rápido que Prometheus en promedios de indicadores y tasas de contadores, incluidas las cargas de trabajo de alta cardinalidad donde los competidores se estancan. La publicación sobre arquitectura explica cómo está organizado TSDS y por qué el diseño columnar produce estos resultados.

| | | | | | :------------------------: | :----------------: | :--------------: | :----------------: | | Dimensión | frente a Prometheus | frente a Mimir | frente a ClickHouse | | Rendimiento de las búsquedas (ES|QL) | Hasta 30 veces más rápido | Hasta 30 veces más rápido | Hasta 8 veces más rápido | | Eficiencia de almacenamiento | Hasta 2,5 veces mejor | A la par | 2 veces mejor |

La diferencia arquitectónica clave es que las métricas de Elasticsearch no mantienen un estado en memoria por serie que escala con la cardinalidad, por lo que agregar miles de etiquetas nuevas de pods de Kubernetes o dimensiones de OTel no aumenta la presión sobre la memoria.

Las métricas de OTel, nativas de Prometheus y definidas por la aplicación se almacenan todas de la misma manera a resolución completa, se consultan rápidamente y a la mitad del costo de Datadog.

Precios de las métricas de Elastic Observability sin las penalizaciones por métricas personalizadas de Datadog

El costo de observabilidad es la razón n.º 1 por la que los equipos cambian de plataforma. Para los clientes de Datadog, el problema se reduce a una mecánica de precios: las métricas personalizadas. Cualquier valor definido por el usuario fuera de las integraciones prediseñadas de Datadog se clasifica como métrica personalizada y se factura a una tarifa prémium. Eso incluye los datos de alta cardinalidad que las cargas de trabajo de Kubernetes, OpenTelemetry y nativas del cloud generan de forma predeterminada. Cuanto más granular sea tu instrumentación, más rápido aumentará la factura. Los equipos que ejecutan infraestructura moderna alcanzan este límite rápidamente, y la respuesta es predecible: descartar datos, acortar la retención, perder el contexto que más importa cuando ocurre un incidente.

Las métricas de Elasticsearch eliminan esa clasificación. Cada métrica tiene el mismo precio, sin penalizaciones por métrica, sin facturación basada en la cardinalidad y sin rollups forzados. Conservas cada métrica a resolución completa sin una factura sorpresa a fin de mes. Y como Elastic cuesta el 50 % de Datadog, la conversación con finanzas cambia: no qué datos tuviste que descartar para mantenerte dentro del presupuesto, sino qué encontraste porque conservaste todo. Por eso también funciona la investigación con AI. A diferencia de la pila LGTM fragmentada de Grafana, el contexto ya está unificado cuando se activa la alerta, no reunido a mano a través de herramientas desconectadas.

Soporte nativo de Prometheus y PromQL en Elasticsearch

La mayoría de los equipos de SRE no ejecutan un pipeline de telemetría limpio y de un solo formato. Prometheus está profundamente integrado en aplicaciones, servicios, plataformas y automatizaciones. Históricamente, migrar los backends de métricas significaba reescribir búsquedas, reconstruir dashboards y volver a capacitar a los ingenieros, suficiente fricción para que los equipos permanezcan en plataformas que ya les quedaron pequeñas en lugar de pasar por ese proceso.

Las métricas de Elasticsearch han eliminado la mayor parte de esa fricción. Las métricas de Prometheus llegan a través de Prometheus Remote Write y llegan al mismo almacén columnar sin cambios semánticos, preservando la fidelidad total de las métricas de extremo a extremo. Apúntalas a Elasticsearch en lugar de Mimir y los datos fluyen. Sin capa de traducción, sin cambios en las configuraciones de scrape existentes.

PromQL ahora funciona de forma nativa en Kibana, por lo que los ingenieros que viven en PromQL no tienen que cambiar su forma de trabajar. Las búsquedas, dashboards y reglas de alerta existentes de PromQL migran directamente a Kibana. 

Las búsquedas de PromQL funcionan sin cambios en Elasticsearch

Si tu equipo ya escribe PromQL, no es necesario cambiar nada. Estas búsquedas se ejecutan tal cual en Elasticsearch como tu backend: copia, pega y listo.

Tasa de uso de CPU (nivel de contenedor) La tasa de CPU por segundo en los contenedores, agrupada por pod. Útil para detectar qué pods están consumiendo CPU durante un incidente.

PROMQL sum by (pod) (rate(container_cpu_usage_seconds_total[5m]))

Conjunto de trabajo de memoria (nivel de contenedor) Memoria actual en uso activo por contenedor: la cifra importante para el riesgo de OOM, no la memoria total asignada.

PROMQL sum by (container) (avg_over_time(container_memory_working_set_bytes[5m]))

Tasa de solicitudes HTTP (a nivel de aplicación) Rendimiento de solicitudes por segundo agrupado por instancia. Una primera señal estándar al investigar picos de latencia o de errores.

PROMQL sum by (instance) (rate(http_requests_total[5m]))

Los tres siguen la sintaxis estándar de PromQL. Si usas Elasticsearch como backend, se ejecutan sin modificaciones. Para ver la referencia completa de la sintaxis y lo que cubre, consulta la documentación de soporte de PromQL.

La API nativa de Prometheus convierte a Elasticsearch en un backend totalmente compatible con Prometheus. Cualquier frontend compatible con Prometheus (incluido Grafana) puede realizar búsquedas directamente en Elasticsearch, por lo que los equipos que quieran mantener Grafana como su capa de visualización mientras se consolidan en Elasticsearch pueden hacer exactamente eso sin modificar los dashboards o las reglas de alerta existentes.

Cuando los SRE necesitan profundizar más de lo que permite PromQL, ES|QL funciona en métricas, logs y trazas en una sola interfaz. El comando TS maneja las particularidades de las series temporales: tasas de contadores, promedios de indicadores, funciones de ventana y agregaciones multinivel en dimensiones de alta cardinalidad. La misma búsqueda que extrae una tasa de contador de CPU puede combinarse con logs del mismo host y presentar el evento de despliegue que precedió al pico. Sin cambios de herramientas ni un nuevo lenguaje de búsqueda. El lenguaje de búsqueda, los dashboards, las reglas de alertas, la capa de visualización, todo se traslada. Lo único que cambia es que Elasticsearch es el único backend que impulsa todo.

Elastic Observability: dashboards listos para usar, alertas y contenido de infraestructura

La mayoría de los proveedores de Observability requieren que crees todo desde cero. Elastic Observability ha reducido esta necesidad en tres áreas:

Exploración de métricas en Discover. La nueva experiencia de exploración de métricas de Elasticsearch permite a los SRE explorar métricas en la misma interfaz que se usa para los logs: sin cambiar de pestaña ni duplicar búsquedas. Conecta un pipeline de OTel o una configuración de extracción de Prometheus, abre Streams y cada métrica del flujo de datos se renderiza de inmediato como un gráfico de series temporales. Sin dashboards que crear, sin búsquedas que escribir. Aquí es donde los equipos pueden validar datos, detectar patrones y comenzar a crear alertas y SLO a partir de una vista en vivo de lo que está fluyendo y correlacionarlos con logs, trazas y otros datos indexados en Elasticsearch.

Dashboards. Los dashboards de Kibana ahora cuentan con paneles contraíbles con carga diferida, por lo que los paneles que no están inmediatamente visibles no generan búsquedas hasta que se necesitan, y con variables de control de ES|QL que permiten a los SRE manipular las visualizaciones mediante menús desplegables sin escribir nuevas búsquedas. Dashboards-as-code también se incluye, lo que permite definiciones de dashboards con control de versiones que se pueden usar como plantilla, compartir y desplegar mediante programación en distintos entornos.

Contenido de infraestructura listo para usar.  Elastic incluye dos nuevas experiencias de infraestructura OOTB:

• La nueva integración de Kubernetes incluye dashboards jerárquicos, plantillas de reglas de alerta, trabajos de detección de anomalías de ML y el contexto y los prompts necesarios para el análisis de causa raíz asistido por AI, todo preconfigurado y listo en el momento en que los datos comienzan a fluir. 

• El monitoreo de la infraestructura de AWS sigue el mismo patrón: el contenido OOTB para los servicios principales de AWS se activa en la ingesta, por lo que los equipos no tienen que empezar de cero cada vez que se habilita un nuevo servicio o cuenta. El mismo enfoque se aplica a las bases de datos y a otra infraestructura principal, la plataforma llega preconfigurada, no en blanco.

Investigaciones agénticas en toda tu infraestructura con Elastic Observability

Elasticsearch correlaciona métricas, logs y trazas en un solo backend, por lo que el contexto de la investigación se recopila antes de que se envíe una alerta a un ingeniero.

La parte difícil son las 2 a. m. Una instancia de RDS que alcanza los límites de conexión y deja sin recursos a los servicios upstream. Un grupo de Auto Scaling que falla las comprobaciones de estado por una razón oculta en los logs de la aplicación. El reinicio en cascada de un pod a través de un espacio de nombres.

En un stack Grafana LGTM, abres tres pestañas antes de tener suficiente contexto para formular una hipótesis.

En Datadog, el contexto está unificado, pero la AI es una caja negra: sin BYO-LLM, sin opciones de residencia de datos.

En Elastic, las métricas, los logs y las trazas comparten un único backend y un esquema común, por lo que el contexto de la investigación ya está reunido cuando se activa la alerta: sin correlación manual entre herramientas ni contexto perdido en la traducción entre lenguajes de búsqueda. La detección de anomalías de ML se ejecuta automáticamente en las métricas de infraestructura (Kubernetes, AWS y bases de datos), por lo que la investigación comienza a partir de una anomalía con puntuación y contexto sobre qué es habitual, qué cambió y cuán grave es la desviación, no solo de una infracción de umbral sin procesar.

Cuando se activa una alerta, el flujo de trabajo de investigación de Elastic correlaciona señales, recopila el contexto de la causa raíz y muestra los próximos pasos recomendados antes de que se envíe una notificación a alguien. La publicación sobre observabilidad de Kubernetes basada en agentes recorre un ejemplo completo de principio a fin. La guía paso a paso de resolución de problemas de EKS muestra cómo Agent Builder y MCP trabajan en conjunto para un ciclo completo de causa raíz en EC2, EKS y los servicios relacionados de AWS.

Además de investigar problemas en Elastic Observability, puedes usar Claude, Cursor, VS Code o tu herramienta favorita para analizar problemas mediante las MCP Apps y habilidades de agentes de Elastic. La Observability MCP App extiende el análisis a todos los lugares donde ya trabaja tu equipo. Si tu equipo investiga en Claude, Cursor o VS Code, las mismas capacidades de investigación (resumen consolidado del estado de la infraestructura, grafo de dependencias de servicios, detalles de anomalías y análisis del radio de impacto) se muestran como vistas interactivas directamente en la conversación. Ni Grafana ni Datadog ofrecen esto.

• Observability MCP App: Conecta Claude, Cursor, VS Code o cualquier herramienta compatible con MCP directamente a tus datos de Elasticsearch, para que el estado de la infraestructura, las dependencias del servicio y el contexto de anomalías aparezcan como vistas interactivas dentro de la conversación sin abandonar la herramienta de tu preferencia. Mira cómo funciona con Kubernetes.

• Agent Skills: las habilidades prediseñadas para Kubernetes, AWS y otra infraestructura principal permiten que cualquier agente, en Elastic o el tuyo propio, ejecute investigaciones estructuradas en tus datos de observabilidad sin necesidad de ingeniería de prompts personalizada. Incorpóralos en Claude, Cursor o en tu propio pipeline de agentes y funcionarán de inmediato. Explora las habilidades de observabilidad o explora la biblioteca de habilidades en GitHub.

Migración de Datadog o Grafana a Elastic Observability

La razón más común por la que los equipos de SRE no cambian de plataforma de observabilidad es la migración. Trasladar años de reglas de alerta, cientos de dashboards y búsquedas de PromQL integradas en runbooks es una tarea operativa abrumadora, y el costo de mantener stacks paralelos mientras se hace aumenta cada día.

La Observability Migration Platform se encarga de la traducción automáticamente. Dirige la CLI o Claude/Cursor (con las habilidades de agente de Elastic) a tu organización de Datadog o instancia de Grafana para convertir los dashboards, las reglas de alerta y las búsquedas de PromQL compatibles en salidas nativas de Kibana. La herramienta te permite ver qué se migró por completo, qué necesitó ajustes y qué se necesita de ti para migrar todo. Mueves lo que ya creaste.

Por el lado de la ingesta, Prometheus Remote Write significa que el pipeline no requiere cambios. Las configuraciones de scrape apuntan a Elasticsearch en lugar de a otro backend compatible con Prometheus y los datos llegan al mismo almacén columnar. Los flujos de trabajo, las búsquedas y las configuraciones de alertas se trasladan sin cambios. Para los equipos que desean mantener Grafana como capa de visualización durante o después de la migración, la API nativa de Prometheus y el soporte de PromQL en Kibana significan que la transición se puede hacer por fases en lugar de realizar un cambio total de una sola vez.

Elasticsearch como backend para Grafana

Para los equipos que no están listos para dejar Grafana, reemplazar el backend es una ruta de migración por derecho propio, y hay dos formas de hacerlo según tu flujo de trabajo.

Si tu equipo ejecuta Prometheus hoy, el camino con menor fricción es la fuente de datos de Prometheus de Grafana. Elasticsearch ahora expone una API nativa compatible con Prometheus, por lo que puedes apuntar el plugin existente de Prometheus de Grafana directamente a Elasticsearch. Sin sidecars, sin adaptadores, no se requieren cambios en los pipelines. Los dashboards de PromQL existentes, las reglas de alertas y los menús desplegables de variables funcionan sin modificaciones, incluido el explorador de Metrics Drilldown de Grafana. Agrega Elasticsearch como destino de remote_write en tu configuración de Prometheus y cambia la URL de la fuente de datos. Esa es la migración completa para la mayoría de los equipos. Consulta la guía de configuración de extremo a extremo.

Para los equipos que desean ir más allá y consultar logs, métricas y trazas de forma conjunta desde un único editor de búsquedas de Grafana, el plugin oficial de Grafana Elasticsearch ahora incluye soporte para ES|QL. Esto permite la correlación entre señales directamente en Grafana, con Elasticsearch gestionando los tres tipos de datos en un backend columnar unificado. Descubre cómo configurarlo.

De cualquier forma, conserva Grafana, reemplaza Mimir y Loki, y obtén todos los beneficios del almacenamiento en columnas y el rendimiento de búsqueda subyacentes de Elasticsearch. Años de trabajo operativo, preservados. La migración que los equipos han estado posponiendo se convierte en un cambio de backend.

Qué está en GA y qué está en vista previa técnica

| Capacidad | Estado | | ----------------------------------------- | ------------ | | Motor de métricas columnares (TSDS) | GA | | Soporte de series temporales de ES|QL | GA | | Soporte de PromQL en Kibana | GA | | Ingesta de Prometheus Remote Write | GA | | Experiencia OOTB de infraestructura de Kubernetes | GA | | Experiencia OOTB de infraestructura de AWS | Vista previa técnica | | Observability MCP App | Vista previa técnica | | Habilidades de agente | Vista previa técnica | | Observability Migration Platform | Vista previa técnica |

Las publicaciones individuales enlazadas a lo largo del texto cubren los aspectos específicos de GA frente a vista previa y las limitaciones conocidas.

Todo esto (el motor de métricas columnar, PromQL nativo, investigaciones agénticas y herramientas de migración) se ejecuta en los tres modos de despliegue de Elastic: sin servidor, Elastic Cloud y autogestionado. Datadog no tiene opción local; Grafana Cloud limita sus características de mayor valor a los despliegues hospedados. Con Elastic, eliges dónde residen tus datos.

Elastic Observability: menor costo sin perder datos

La infraestructura cloud moderna rompió el modelo de observabilidad creado en torno a herramientas separadas para distintas señales. El costo es real: facturas de herramientas duplicadas, correlación manual durante los incidentes y datos descartados solo para ajustarse al presupuesto.

Un solo backend que almacena cada señal de manera eficiente significa que conservas lo que necesitas sin la factura que suele acompañarlo. Ese es un tipo diferente de conversación para tener con finanzas: no “tuvimos que descartar datos para mantenernos dentro del presupuesto”, sino “esto es lo que encontramos”. La AI obtiene el panorama completo porque solo hay un panorama, y la plataforma llega con suficiente contenido predefinido para ser útil desde el primer día, no después de semanas de arduo trabajo con dashboards.

Esto es posible gracias a que Elasticsearch está desarrollado de manera diferente a las plataformas que probablemente estés reemplazando:

• Almacenamiento de métricas en columnas almacena datos de métricas de forma muy eficiente en el modo de índice TSDS. 

• La compatibilidad nativa con Prometheus significa que las configuraciones de recopilación, las búsquedas de PromQL y los dashboards existentes funcionan sin necesidad de reescritura.

• Tener las métricas, los logs y las trazas unificados en un solo backend significa que el contexto de investigación se recopila en el momento de la búsqueda, no manualmente entre pestañas.

• Search y analíticas en el mismo motor: un índice invertido para logs, un índice columnar para métricas, consultados conjuntamente con ES|QL.

• Investigaciones con agentes que correlacionan señales, sacan a la superficie anomalías y sugieren remediación antes de alertar a alguien.

• Sin servidor, Elastic Cloud o autogestionado: eliges dónde viven tus datos, algo que Datadog no puede ofrecer.

La conversación sobre costos con finanzas pasa a centrarse en lo que encontraste, no en lo que gastaste.

Comienza

• Comienza una prueba gratuita

• Documentación de Elastic Observability

• Elastic Observability Labs

Preguntas frecuentes

¿Es Elasticsearch ahora una plataforma de métricas lista para producción?

Sí. A partir de junio de 2026, Elasticsearch incluye un motor de almacenamiento columnar reconstruido y diseñado específicamente para datos de series temporales, ingesta nativa de Prometheus Remote Write, soporte de PromQL en Kibana, consultas de series temporales de ES|QL y dashboards de infraestructura listos para usar para Kubernetes y AWS. El motor de métricas columnares, el soporte de series temporales de ES|QL, PromQL y la ingesta de Prometheus están disponibles de forma general en Elastic Serverless y pronto en GA en Elastic Cloud Hosted.

¿Cómo se compara Elasticsearch con Datadog en cuanto al costo de las métricas?

En cargas de trabajo de métricas comparables, Elastic Observability Serverless cuesta significativamente menos que Datadog, en ejemplos ilustrativos basados en precios de lista publicados, más del 50 % menos y a menudo cerca de dos tercios menos. La diferencia es estructural: Datadog factura principalmente por host y luego agrega cargos por métricas personalizadas y contenedores a medida que aumenta la instrumentación. La diferencia de costo es mayor exactamente en las cargas de trabajo donde Datadog factura más: entornos de alta cardinalidad y densamente instrumentados como Kubernetes y OTel.

¿Cómo se compara el rendimiento de las métricas de Elasticsearch con Prometheus y Grafana Mimir?

Las búsquedas de ES|QL en Elasticsearch se ejecutan hasta 30 veces más rápido que en Prometheus y Mimir en promedios de indicadores y tasas de contadores, incluidas las cargas de trabajo de alta cardinalidad. Elasticsearch almacena métricas de OTel a 3,75 bytes por punto de datos, con una eficiencia hasta 2,5 veces mayor que Prometheus y 2 veces mayor que ClickHouse.

¿Pueden los equipos migrar de Datadog o Grafana a Elasticsearch sin reconstruir todo?

Sí. Observability Migration Platform de Elastic convierte los dashboards y las reglas de alerta de Datadog y Grafana, y migra las búsquedas de PromQL a Kibana tal como están. Los equipos también pueden mantener Grafana como una capa de visualización mientras reemplazan el backend con Elasticsearch, utilizando la API nativa de Prometheus y el soporte de PromQL en Kibana.

¿Qué diferencia a Elasticsearch de Grafana para la observabilidad de métricas?

Elasticsearch almacena métricas, logs y trazas en un único backend unificado con un solo lenguaje de búsqueda (ES|QL), mientras que el stack LGTM de Grafana divide las métricas (Mimir/Prometheus) y los logs (Loki) en backends separados, lo que requiere lenguajes de búsqueda independientes. Elasticsearch también incluye capacidades de investigación agéntica, entre las que se encuentran AI Agent, Workflows, MCP App y Agent skills, un conjunto de capacidades más completo que el de Grafana. 

¿Elasticsearch admite Prometheus y PromQL de forma nativa?

Sí, de dos formas distintas. Primero, Elasticsearch acepta métricas de Prometheus a través de Prometheus Remote Write y expone una API nativa compatible con Prometheus, por lo que puede servir como backend para cualquier frontend compatible con Prometheus, incluido Grafana. Segundo, Kibana admite PromQL de forma nativa, lo que significa que las búsquedas, los dashboards y las reglas de alerta existentes se ejecutan directamente en Kibana sin una capa de traducción ni modificación.

¿Qué contenido de monitoreo de infraestructura se incluye listo para usar con Elastic Observability?

Elastic incluye dashboards prediseñados, plantillas de alerta y trabajos de detección de anomalías de ML en cientos de integraciones de infraestructura que abarcan hosts, contenedores, servicios de cloud, bases de datos, dispositivos de red y más. Para Kubernetes y AWS específicamente, la plataforma también incluye contenido de investigación agéntica, como habilidades de agentes y una Observability MCP App que permite a los equipos ejecutar investigaciones directamente desde Claude, Cursor o VS Code. Todo esto está disponible en la ingesta sin necesidad de configuración.

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í.