Elasticsearch: el mejor en su clase para logs, ahora el mejor en su clase para métricas

Store high-cardinality metrics efficiently with time series data streams, and keep your Prometheus and PromQL workflows along for the ride. 

Dig into infrastructure and metrics monitoring. Start a free cloud trial or try Elastic on your local machine now.

En los últimos meses, Elastic ha incorporado un motor de almacenamiento columnar en Elasticsearch diseñado específicamente para datos de series temporales, ingesta y almacenamiento nativos de Prometheus, soporte para PromQL, y hemos brindado una nueva experiencia de exploración de métricas, dashboards de infraestructura prediseñados, investigación con agentes y una ruta de migración desde Datadog y Grafana. Ahora, las capacidades incluyen:

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

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

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.