Elasticsearch: o melhor da categoria em logs, agora o melhor em 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.

Nos últimos meses, a Elastic lançou um mecanismo de armazenamento colunar no Elasticsearch desenvolvido especialmente para dados de série temporal, ingestão e armazenamento nativos do Prometheus, suporte ao PromQL, e entregamos uma nova experiência de exploração de métricas, dashboards de infraestrutura pré-criados, investigação por agentes e um caminho de migração a partir do Datadog e do Grafana. Os recursos agora incluem:

• O Elasticsearch é um backend de métricas compatível com o Prometheus — Prometheus Remote Write e o PromQL agora funciona nativamente no Kibana, nenhuma camada de tradução necessária.

• As métricas chegam à arquitetura TSDS colunar do Elasticsearch armazenando dados de forma até 2,5× mais eficiente do que o Prometheus e 2× mais eficiente do que o ClickHouse.

• As consultas de séries temporais do ES|QL são executadas até 30x mais rápido do que o Prometheus em médias de gauge e taxas de contador, incluindo cargas de trabalho de alta cardinalidade.

• A Elastic custa aproximadamente 50% menos que o Datadog, sem classificação de métricas personalizadas e sem cobrança baseada em cardinalidade.

• O Grafana pode consultar o Elasticsearch diretamente por meio da API nativa do Prometheus, mantendo sua camada de visualização enquanto substitui o backend.

• O monitoramento do Kubernetes e da AWS inclui dashboards pré-criados, modelos de alerta, trabalhos de anomalia de ML e conteúdo de investigação agêntica prontos na ingestão. Além disso, habilidades e apps MCP estão disponíveis.

• Backend unificado para métricas, logs e traces, permitindo investigações agênticas sem precisar reunir o contexto de várias ferramentas.

• A exploração de métricas no Discover permite que qualquer pessoa comece imediatamente a consultar e analisar métricas, sem exigir experiência com linguagem de consulta.

• A criação de dashboards personalizados é rápida e flexível — dashboards como código, criação de dashboards com assistência de IA, controles de variáveis e painéis recolhíveis significam menos tempo criando e mais tempo investigando.

• Ferramentas de migração para ajudar a migrar facilmente dashboards e regras de alerta/monitores do Datadog e do Grafana.

O Elasticsearch metrics agora compete em todas as dimensões importantes para os SREs: você pode manter todas as métricas em resolução total, consultá-las até 30x mais rápido do que o Prometheus, pagar 50% menos do que o Datadog, migrar dashboards e regras de alertas do Grafana ou Datadog com facilidade e ir do alerta à causa-raiz sem precisar juntar contextos entre ferramentas desconectadas. O restante deste post examina cada um deles em detalhes.

Desempenho das métricas do Elasticsearch: 30× mais rápido que o Prometheus e o Mimir

O Datadog e o Prometheus forçam o mesmo tradeoff: descartar dados de alta cardinalidade ou ver os custos dispararem. SREs que gerenciam Kubernetes, AWS ou qualquer infraestrutura de alta cardinalidade conhecem a forma específica desse problema. Os rótulos do Kubernetes, dados efêmeros de pods e dimensões detalhadas do OTel que mais importam durante um incidente são os primeiros a serem descartados quando o orçamento aperta.

A Elastic reformulou o repositório de dados de série temporal e o mecanismo de computação do ES|QL para criar um mecanismo de métricas totalmente colunar. Adicionar um novo rótulo do Kubernetes, uma nova tag de instância da AWS ou uma nova dimensão de aplicação não sobrecarrega o sistema; isso gera um custo muito menor do que sistemas que indexam todos os rótulos. Métricas de OTel, Prometheus e definidas pela aplicação vão todas para o mesmo backend colunar com resolução total, com logs, traces e métricas em um único repositório. Nenhum dado é descartado, nenhuma retenção é reduzida.

O Elasticsearch armazena métricas com até 2,5 vezes mais eficiência que o Prometheus (os resultados podem variar devido a fatores como a compactação) e com 2 vezes mais eficiência que o ClickHouse. O desempenho das consultas via ES|QL é até 30 vezes mais rápido que o Prometheus em médias de gauge e taxas de contador, incluindo cargas de trabalho de alta cardinalidade nas quais os concorrentes ficam estagnados. A postagem sobre arquitetura aborda como o TSDS é organizado e por que o layout colunar produz esses resultados.

A principal diferença arquitetônica é que o Elasticsearch metrics não mantém um estado na memória por série que aumenta proporcionalmente à cardinalidade, portanto adicionar milhares de novos rótulos de pods do Kubernetes ou dimensões de OTel não aumenta a pressão de memória.

As métricas do OTel, nativas do Prometheus e definidas pelo aplicativo são todas armazenadas da mesma forma, em resolução total, consultadas rapidamente, por metade do custo do Datadog.

Preço das métricas do Elastic Observability sem as penalidades por métricas personalizadas do Datadog

O custo da observabilidade é o principal motivo pelo qual as equipes mudam de plataforma. Para os clientes do Datadog, o problema se resume a um mecanismo de precificação: métricas personalizadas. Qualquer valor definido pelo usuário fora das integrações nativas do Datadog é classificado como uma métrica personalizada e cobrado com uma tarifa mais alta. Isso inclui os dados de alta cardinalidade que o Kubernetes, o OpenTelemetry e as cargas de trabalho nativas da nuvem geram por padrão. Quanto mais granular for sua instrumentação, mais rápido a fatura aumenta. As equipes que operam infraestrutura moderna chegam rapidamente a esse limite, e a resposta é previsível: descartam dados, reduzem a retenção e perdem o contexto que mais importa quando ocorre um incidente.

As métricas do Elasticsearch removem essa classificação. Todas as métricas têm o mesmo preço, sem penalidades por métrica, sem cobrança baseada em cardinalidade e sem rollups forçados. Você mantém todas as métricas em resolução total sem uma fatura surpresa no fim do mês. E como a Elastic tem 50% do custo do Datadog, a conversa com o setor financeiro muda: não quais dados você precisou descartar para ficar dentro do orçamento, mas o que você descobriu porque manteve tudo. É também por isso que a investigação por IA funciona. Diferente da stack LGTM fragmentada do Grafana, o contexto já está unificado quando o alerta dispara, não montado manualmente em ferramentas desconectadas.

Suporte nativo a Prometheus e PromQL no Elasticsearch

A maioria das equipes de SRE não está executando um pipeline de telemetria limpo e de formato único. O Prometheus está profundamente integrado em aplicações, serviços, plataformas e automações. Historicamente, migrar backends de métricas significava reescrever consultas, reconstruir dashboards e retreinar engenheiros — atrito suficiente para que as equipes permaneçam em plataformas que já não atendem às suas necessidades, em vez de passar por esse processo.

As métricas do Elasticsearch removeram a maior parte desse atrito. As métricas do Prometheus chegam via Prometheus Remote Write e chegam ao mesmo armazenamento colunar sem alterações semânticas, preservando a fidelidade total das métricas de ponta a ponta. Direcione as métricas para o Elasticsearch em vez do Mimir e os dados fluem. Sem camada de tradução, sem alterações nas configurações de scrape existentes.

O PromQL agora funciona de forma nativa no Kibana, para que os engenheiros que trabalham com PromQL não precisem mudar como trabalham. As consultas PromQL, dashboards e regras de alerta existentes migram diretamente para o Kibana. 

As consultas PromQL funcionam sem alterações no Elasticsearch

Se a sua equipe já escreve PromQL, nada precisa mudar. Essas consultas são executadas sem alterações, usando o Elasticsearch como backend — copie, cole e pronto.

Taxa de uso de CPU (nível de container) A taxa de CPU por segundo entre os containers, agrupada por pod. Útil para identificar quais pods estão consumindo CPU durante um incidente.

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

Conjunto de trabalho da memória (nível de container) Memória atual em uso ativo por container — o número que importa para o risco de OOM, não a memória total alocada.

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

Taxa de solicitação HTTP (nível do aplicativo) Taxa de transferência de solicitações por segundo agrupada por instância. Um primeiro sinal padrão ao investigar picos de latência ou de erro.

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

Os três seguem a sintaxe padrão do PromQL. Se você usa o Elasticsearch como seu backend, eles são executados sem modificação. Para a referência completa de sintaxe e o que é coberto, consulte a documentação de suporte ao PromQL.

A API nativa do Prometheus torna o Elasticsearch um backend totalmente compatível com o Prometheus. Qualquer frontend compatível com o Prometheus (Grafana incluído) pode consultar o Elasticsearch diretamente, para que as equipes que querem manter o Grafana como sua camada de visualização enquanto consolidam no Elasticsearch possam fazer exatamente isso sem modificar dashboards ou regras de alerta existentes.

Quando os SREs precisam se aprofundar mais do que o PromQL permite, o ES|QL funciona com métricas, logs e traces em uma única interface. O comando TS lida com as particularidades das séries temporais: taxas de contadores, médias de gauges, funções de janela e agregações em vários níveis em dimensões de alta cardinalidade. A mesma consulta que busca uma taxa de contador de CPU pode fazer join com logs do mesmo host e exibir o evento de implantação que precedeu o pico. Sem troca de ferramentas, sem nenhuma nova linguagem de consulta. A linguagem de consulta, os dashboards, as regras de alerta, a camada de visualização — tudo é mantido. A única coisa que muda é que o Elasticsearch é o único backend que alimenta tudo.

Elastic Observability: dashboards, alertas e conteúdo de infraestrutura prontos para uso

A maioria dos fornecedores de Observability exige que você crie tudo do zero. O Elastic Observability reduziu essa necessidade em três áreas:

Exploração de métricas no Discover. A nova experiência de exploração de métricas do Elasticsearch permite que os SREs explorem métricas na mesma interface usada para logs — sem troca de abas, sem consultas duplicadas. Conecte um pipeline do OTel ou uma configuração de scrape do Prometheus, abra o Streams e cada métrica no fluxo de dados é renderizada como um gráfico de série temporal imediatamente. Nenhum dashboard para criar, nenhuma consulta para escrever. É aqui que as equipes podem validar dados, identificar padrões e começar a criar alertas e SLOs a partir de uma visualização em tempo real do que está fluindo e correlacioná-las com logs, traces e outros dados indexados no Elasticsearch.

Dashboards. Os dashboards do Kibana ganharam painéis recolhíveis com carregamento lento (lazy loading), de modo que os painéis que não estão visíveis imediatamente não geram consultas até serem necessários, além de variáveis de controle ES|QL que permitem aos SREs manipular visualizações por meio de menus suspensos sem precisar escrever novas consultas. Dashboards-as-code também está sendo lançado, permitindo definições de dashboards com controle de versão que podem ser transformadas em modelos, compartilhadas e implantadas de forma programática em diferentes ambientes.

Conteúdo de infraestrutura pronto para uso.  A Elastic está trazendo duas novas experiências de infraestrutura prontas para uso:

• A nova integração do Kubernetes já vem com dashboards hierárquicos, modelos de regras de alerta, jobs de detecção de anomalia de ML e o contexto e os prompts necessários para análise de causa raiz assistida por IA — tudo pré-configurado e pronto no momento em que os dados começam a fluir. 

• O monitoramento de infraestrutura da AWS segue o mesmo padrão: o conteúdo pronto para uso dos serviços essenciais da AWS é ativado na ingestão, para que as equipes não comecem do zero sempre que um novo serviço ou conta entrar em operação. A mesma abordagem se estende a bancos de dados e outras infraestruturas essenciais — a plataforma já vem com uma abordagem definida, e não como uma solução em branco.

Investigações autônomas em toda a sua infraestrutura com o Elastic Observability

O Elasticsearch correlaciona métricas, logs e traces em um único backend, de modo que o contexto da investigação é reunido antes que um engenheiro seja acionado.

A parte mais difícil é às 2h. Uma instância do RDS atingindo os limites de conexão e deixando os serviços upstream sem recursos. Um grupo de redimensionamento automático falhando nas verificações de integridade por um motivo oculto nos logs do aplicativo. Uma reinicialização de pod em cascata em um espaço de nome.

Em uma stack Grafana LGTM, você abre três guias antes de ter contexto suficiente para formar uma hipótese.

No Datadog, o contexto é unificado, mas a IA é uma caixa preta: sem BYO-LLM, sem opções de residência de dados.

No Elastic, métricas, logs e traces compartilham um único backend e um esquema comum, de modo que o contexto da investigação já está reunido quando o alerta é disparado — sem correlação manual entre ferramentas e sem perda de contexto na tradução entre linguagens de consulta. A detecção de anomalias em ML é executada automaticamente nas métricas de infraestrutura (Kubernetes, AWS, bancos de dados), para que a investigação comece com uma anomalia pontuada e com contexto sobre o que é típico, o que mudou e quão grave é o desvio, e não apenas com uma violação bruta de limite.

Quando um alerta é acionado, o fluxo de trabalho de investigação da Elastic correlaciona sinais, reúne o contexto da causa raiz e apresenta as próximas etapas recomendadas antes que alguém seja acionado. O post sobre observabilidade agêntica do Kubernetes apresenta um exemplo completo de ponta a ponta. O tutorial de solução de problemas do EKS mostra como o Agent Builder e o MCP trabalham juntos para um ciclo completo de análise de causa raiz no EC2, no EKS e em serviços relacionados da AWS.

Além de investigar problemas no Elastic Observability, você pode usar o Claude, o Cursor, o VS Code ou sua ferramenta favorita para analisar problemas usando MCP Apps e habilidades de agente da Elastic. O Observability MCP App estende a análise para onde quer que sua equipe já trabalhe. Se a sua equipe faz investigações no Claude, Cursor ou VS Code, os mesmos recursos de investigação (rollup de integridade da infraestrutura, gráfico de dependência de serviços, detalhes de anomalias, análise de raio de impacto) são renderizados como visualizações interativas diretamente na conversa. Nem o Grafana nem o Datadog oferecem isso.

• Observability MCP App — Conecta o Claude, o Cursor, o VS Code ou qualquer ferramenta compatível com MCP diretamente aos seus dados do Elasticsearch, para que a integridade da infraestrutura, as dependências de serviço e o contexto de anomalias apareçam como visualizações interativas na conversa, sem sair da sua ferramenta de preferência. Veja como funciona com o Kubernetes.

• Agent Skills — Habilidades pré-criadas para Kubernetes, AWS e outras infraestruturas principais permitem que qualquer agente — na Elastic ou o seu próprio — execute investigações estruturadas nos seus dados de observabilidade sem engenharia de prompts personalizada. Adicione-as ao Claude, Cursor ou ao seu próprio pipeline de agentes e elas funcionam imediatamente. Explore as habilidades de observabilidade ou navegue pela biblioteca de habilidades no GitHub.

Migrando do Datadog ou do Grafana para o Elastic Observability

O motivo mais comum para as equipes de SRE não trocarem de plataforma de observabilidade é a migração. Mover anos de regras de alerta, centenas de dashboards e consultas PromQL incorporadas a runbooks é uma tarefa operacional assustadora, e o custo de manter stacks paralelas durante esse processo aumenta a cada dia.

A Observability Migration Platform faz a tradução automaticamente. Aponte a CLI ou o Claude/Cursor (com as habilidades de agente da Elastic) para a sua organização do Datadog ou instância do Grafana, e a ferramenta converterá dashboards, regras de alerta e consultas PromQL compatíveis em saídas nativas do Kibana. A ferramenta permite ver o que foi totalmente migrado, o que precisou de ajustes e o que você precisa fazer para concluir a migração. Você move o que já construiu.

No lado da ingestão, o Prometheus Remote Write significa que o pipeline não requer alterações. As configurações de scrape apontam para o Elasticsearch em vez de outro backend compatível com o Prometheus, e os dados vão parar no mesmo armazenamento colunar. Fluxos de trabalho, consultas e configurações de alerta são mantidos sem alterações. Para equipes que desejam manter o Grafana como camada de visualização durante ou após a migração, a API nativa do Prometheus e o suporte ao PromQL no Kibana significam que a transição pode ser feita em etapas, em vez de uma migração completa de uma só vez.

Elasticsearch como backend para o Grafana

Para equipes que não estão prontas para deixar o Grafana, substituir o backend é um caminho de migração por si só, e há duas maneiras de fazer isso dependendo do seu fluxo de trabalho.

Se a sua equipe executa o Prometheus hoje, o caminho de menor atrito é a fonte de dados do Prometheus do Grafana. O Elasticsearch agora expõe uma API nativa compatível com o Prometheus, para que você possa apontar o plugin existente do Prometheus no Grafana diretamente para o Elasticsearch. Sem sidecars, sem adaptadores, sem necessidade de alterações de pipeline. Dashboards em PromQL, regras de alerta e menus suspensos de variáveis existentes funcionam sem modificações, incluindo o explorador Metrics Drilldown do Grafana. Adicione o Elasticsearch como um destino de remote_write na sua configuração do Prometheus e troque a URL da fonte de dados. Essa é a migração completa para a maioria das equipes. Consulte o guia de configuração de ponta a ponta.

Para equipes que querem ir além e consultar logs, métricas e traces juntos em um único editor de consultas do Grafana, o plugin oficial Grafana Elasticsearch agora vem com suporte a ES|QL. Isso viabiliza a correlação entre sinais diretamente no Grafana, com o Elasticsearch gerenciando todos os três tipos de dados em um backend colunar unificado. Veja como configurar.

De qualquer forma, mantenha o Grafana, substitua o Mimir e o Loki e aproveite todos os benefícios do armazenamento colunar e do desempenho de consultas do Elasticsearch nos bastidores. Anos de trabalho operacional, preservados. A migração que as equipes vinham adiando se torna uma simples troca de backend.

O que é GA e o que está em prévia técnica

Os posts individuais com links ao longo do texto abordam os detalhes sobre o que está em GA e o que está em prévia e as limitações conhecidas.

Tudo isso (o mecanismo de métricas colunares, o PromQL nativo, as investigações baseadas em agentes e as ferramentas de migração) é executado nos três modos de implantação da Elastic: serverless, Elastic Cloud e autogerenciado. O Datadog não tem opção no local; o Grafana Cloud limita seus recursos de maior valor às implantações hospedadas. Com a Elastic, você escolhe onde seus dados ficam.

Elastic Observability: menor custo sem perder dados

A infraestrutura de nuvem moderna quebrou o modelo de observabilidade construído em torno de ferramentas separadas para sinais separados. O custo é real: gastos duplicados com ferramentas, correlação manual durante incidentes e dados descartados apenas para ficar dentro do orçamento.

Um único backend que armazena todos os sinais com eficiência significa que você mantém o que precisa sem a conta que geralmente vem junto. Essa é uma conversa diferente para se ter com o financeiro: não "tivemos que descartar dados para ficar dentro do orçamento", mas sim "aqui está o que descobrimos". A IA tem a visão completa porque só existe uma visão, e a plataforma já chega com conteúdo pré-criado suficiente para ser útil desde o primeiro dia, e não depois de semanas de esforço com dashboards.

Isso é possível por causa de como o Elasticsearch é construído de forma diferente das plataformas que você provavelmente está substituindo:

• Armazenamento colunar de métricas armazena dados de métricas de forma altamente eficiente no modo de índice TSDS. 

• A compatibilidade nativa com o Prometheus significa que as configurações de scrape, consultas PromQL e dashboards existentes funcionam sem a necessidade de reescrita.

• Métricas, logs e traces unificados em um único backend significam que o contexto da investigação é reunido no momento da consulta, e não manualmente entre abas.

• Pesquisa e análise no mesmo mecanismo — um índice invertido para logs, um índice colunar para métricas, consultados em conjunto com o ES|QL.

• Investigações agênticas que correlacionam sinais, identificam anomalias e sugerem remediação antes que alguém seja acionado.

• Serverless, Elastic Cloud ou autogerenciado — você escolhe onde seus dados residem, o que o Datadog não pode oferecer.

A conversa sobre custos com o setor financeiro passa a ser sobre o que você encontrou, e não sobre o que gastou.

Começar

• Inicie uma avaliação gratuita

• Documentação do Elastic Observability

• Elastic Observability Labs

Perguntas frequentes

O Elasticsearch agora é uma plataforma de métricas pronta para produção?

Sim. A partir de junho de 2026, o Elasticsearch traz um mecanismo de armazenamento colunar reformulado e desenvolvido especificamente para dados de série temporal, ingestão nativa via Prometheus Remote Write, suporte a PromQL no Kibana, consultas a séries temporais no ES|QL e dashboards de infraestrutura prontos para uso para Kubernetes e AWS. O mecanismo de métricas colunares, o suporte a séries temporais no ES|QL, o PromQL e a ingestão do Prometheus estão todos em disponibilidade geral no Elastic Serverless e em breve em GA no Elastic Cloud Hosted.

Como o Elasticsearch se compara ao Datadog em termos de custo de métricas?

Em cargas de trabalho de métricas comparáveis, o Elastic Observability Serverless custa significativamente menos que o Datadog — em exemplos ilustrativos baseados em preços de tabela publicados, mais de 50% menos e, muitas vezes, cerca de dois terços menos. A diferença é estrutural: o Datadog cobra principalmente por host e, à medida que a instrumentação cresce, adiciona cobranças por métricas personalizadas e containers. A diferença de custo é maior justamente nas cargas de trabalho pelas quais o Datadog mais cobra: ambientes de alta cardinalidade e densamente instrumentados, como Kubernetes e OTel.

Como o desempenho de métricas do Elasticsearch se compara ao Prometheus e ao Grafana Mimir?

As consultas ES|QL no Elasticsearch são executadas até 30 vezes mais rápido que o Prometheus e o Mimir em médias de gauge e taxas de contador, incluindo cargas de trabalho de alta cardinalidade. O Elasticsearch armazena métricas OTel em 3,75 bytes por ponto de dados; até 2,5 vezes mais eficientemente que o Prometheus e 2 vezes mais eficientemente que o ClickHouse.

As equipes podem migrar do Datadog ou do Grafana para o Elasticsearch sem reconstruir tudo?

Sim. A Observability Migration Platform da Elastic converte dashboards e regras de alerta do Datadog e do Grafana e migra consultas PromQL para o Kibana sem alterações. As equipes também podem manter o Grafana como uma camada de visualização enquanto substituem o backend pelo Elasticsearch, usando a API nativa do Prometheus e o suporte a PromQL no Kibana.

O que torna o Elasticsearch diferente do Grafana para a observabilidade de métricas?

O Elasticsearch armazena métricas, logs e traces em um único backend unificado com uma única linguagem de consulta (ES|QL), enquanto a stack LGTM do Grafana divide métricas (Mimir/Prometheus) e logs (Loki) em backends separados, exigindo linguagens de consulta distintas. O Elasticsearch também traz recursos de investigação autônoma, o que inclui AI Agent, Workflows, MCP App e habilidades de agente, um conjunto mais abrangente de recursos do que o Grafana. 

O Elasticsearch oferece suporte nativo a Prometheus e PromQL?

Sim, de duas maneiras distintas. Primeiro, o Elasticsearch aceita métricas do Prometheus via Prometheus Remote Write e expõe uma API nativa compatível com o Prometheus, podendo servir como backend para qualquer frontend compatível com o Prometheus, incluindo o Grafana. Segundo, o Kibana oferece suporte nativo ao PromQL, o que significa que consultas, dashboards e regras de alerta existentes são executados diretamente no Kibana sem uma camada de tradução ou modificação.

Qual conteúdo de monitoramento de infraestrutura já vem pronto para uso com o Elastic Observability?

A Elastic disponibiliza dashboards pré-criados, modelos de alerta e jobs de detecção de anomalia de ML em centenas de integrações de infraestrutura, cobrindo hosts, containers, serviços de nuvem, bancos de dados, dispositivos de rede e muito mais. Especificamente para Kubernetes e AWS, a plataforma também inclui conteúdo de investigação autônoma, como habilidades de agentes e um Observability MCP App que permite às equipes executar investigações diretamente do Claude, Cursor ou VS Code. Tudo isso está disponível na ingestão sem necessidade de configuração.