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

| | | | | | :------------------------: | :----------------: | :--------------: | :----------------: | | Dimensão | vs. Prometheus | vs. Mimir | vs. ClickHouse | | Desempenho de consulta (ES|QL) | Até 30× mais rápido | Até 30× mais rápido | Até 8× mais rápido | | Eficiência de armazenamento | Até 2,5× melhor | No mesmo nível | 2× melhor |

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

| Recurso | Status | | ----------------------------------------- | ------------ | | Mecanismo de métricas colunares (TSDS) | GA | | Suporte a séries temporais no ES|QL | GA | | Suporte a PromQL no Kibana | GA | | Ingestão do Prometheus Remote Write | GA | | Experiência de infraestrutura do Kubernetes pronta para uso | GA | | Experiência de infraestrutura da AWS pronta para uso | Prévia técnica | | Observability MCP App | Prévia técnica | | Habilidades do agente | Prévia técnica | | Observability Migration Platform | 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.

Na Parte 1, abordamos como a integração de Kubernetes da Elastic envia telemetria por meio do EDOT Collector para o Elasticsearch. Neste post, vamos além com um servidor de app MCP (Model Context Protocol) que expõe essa telemetria como ferramentas que podem ser chamadas pela IA, completo com UIs React interativas renderizadas em linha. Também abordaremos como ir ainda mais longe com o Elastic Workflows: runbooks automatizados que lidam com todo o ciclo de análise de causa-raiz, do alerta à proposta de remediação.

Observability MCP App que renderiza onde você trabalha

O Elastic Observability MCP App (prévia técnica) inclui seis visualizações, uma por ferramenta. Cada uma renderiza em linha quando a ferramenta retorna e apresenta prompts direcionados para as próximas etapas como botões clicáveis, para que você não precise adivinhar a ação de acompanhamento ideal. Os MCP Apps vão além dos fluxos de trabalho de agentes isolados — eles renderizam visualizações interativas em tempo real diretamente no seu chat ou IDE, em linha na conversa, sem alternância de contexto para o Kibana.

Rollup do estado de saúde do cluster

Pergunte "o que está com defeito?" ou "me dê um relatório de status" e receba uma orientação instantânea: indicador geral de integridade, serviços degradados com as respectivas causas, principais consumidores de memória dos pods, detalhamento da gravidade das anomalias e taxa de transferência do serviço, tudo em uma única visualização embutida.

A visualização se adapta com base nos recursos compatíveis com a sua implantação. O APM fornece informações sobre a saúde do serviço. As métricas de Kubernetes adicionam contexto ao pod e ao nó. Os trabalhos de ML adicionam anomalias. Se um sinal não estiver presente, a visualização informa o que está faltando em vez de falhar. Começaremos com um relatório de status do cluster do Kubernetes:

Relatórios compostos, como o resumo de integridade, têm uma apresentação de dados condensada com expansão de detalhes para que você possa escolher a quantidade adequada de informações para visualizar de uma só vez. As ações de investigação sugeridas oferecem orientações tanto para informações específicas que estão sendo retornadas quanto para orientar os usuários sobre outras ferramentas que podem executar.

Gráfico das dependências dos serviços

Pergunte "o que chama o checkout?" ou "mostre-me a topologia" e tenha um gráfico de dependências em camadas — chamadores upstream, dependências downstream, protocolos, volume de chamadas e latência por aresta. Passe o cursor sobre uma aresta para destacar todo o caminho da chamada. Vamos pedir ao Claude para "mostrar as dependências de serviço do frontend":

Aumente o zoom, desloque a visualização e passe o cursor sobre a imagem para ter todos os detalhes necessários para compreender as complexas relações de serviço:

Detalhes da Anomalia

Pergunte "o que é anômalo?" ou "há algo incomum no checkout?" e obtenha uma de duas visualizações, escolhida automaticamente. Se várias entidades forem afetadas, o modo de visão geral mostrará as contagens de gravidade, as entidades afetadas e um detalhamento por job. Se uma única entidade estiver em foco, o modo de detalhes mostrará a pontuação, os valores reais vs. típicos com uma barra de comparação, a porcentagem de desvio e uma série temporal, quando disponível. Vamos verificar o serviço de frontend:

Esta não é uma consulta ESQL — é uma explicação dos resultados de um trabalho de detecção de anomalia definido anteriormente. Como discutido na Parte 1 desta série de blog, a integração do Kubernetes já vem com alguns para você habilitar. Esta ferramenta ajudará você a aproveitá-los ao máximo.

Observe

Observe é a principal primitiva de acesso do agente à Elastic — uma ferramenta, com dois modos para três necessidades diferentes. Diga "qual é a taxa de transferência de rede de cada um dos meus clusters do Kubernetes" para obter uma tabela ou um gráfico de resultados. Diga "avise-me quando a memória ficar abaixo de 80 MB" ou "monitore a memória do frontend em busca de algo incomum pelos próximos 10 minutos" e a execução fica bloqueada até que a condição seja acionada ou a janela expire.

A visualização se adapta ao modo: uma tabela de resultados para consultas pontuais, um gráfico de tendências ao vivo com estatísticas atuais/de pico/de referência para condições de amostragem e limite, e um cartão de gatilho com pontuação de gravidade para o modo de anomalia. Vamos usá-lo aqui para identificar o nó mais ocupado do Kubernetes:

Avalie o risco com um raio de impacto

Pergunte "o que acontece se este nó cair?" e obtenha um diagrama de impacto radial: o nó de destino no centro, implantações com interrupção total em vermelho, degradadas em âmbar, não afetadas em cinza. Um cartão de resumo flutuante mostra os pods em risco e a viabilidade de reagendamento. Implantações de réplica única são sinalizadas como pontos únicos de falha. O que aconteceria se nosso nó ocupado falhasse:

Gestão de Alertas

Com a ferramenta de gerenciamento de alertas, você pode criar, listar, obter informações e excluir alertas. Criaremos um alerta a seguir, mas antes use o Observe mais uma vez para obter uma linha de base rápida, para sabermos que o alerta fará sentido:

Diga "alerte-me se a memória do frontend ultrapassar 75 MB" e o agente cria uma regra de alerta persistente no Kibana — um objeto salvo que continua em execução após o término da conversa. A visualização exibe um cartão de regra em tempo real: nome da regra, condição, janela, intervalo de verificação, filtro KQL e tags. Os botões de próximos passos oferecem opções para verificar a regra, acompanhar a estabilização da métrica ou verificar a integridade atual do cluster. O agente confirma o que foi criado e onde encontrá-lo no Kibana:

Arquitetura do App MCP

O app é composto de um servidor Node.js, seis ferramentas voltadas para modelos conectadas a seis recursos de visualização de arquivo único, ferramentas exclusivas de app para novas consultas e empacotamento com vite-plugin-singlefile. As ferramentas são agrupadas por backend de implantação (Universal, dependente de APM, dependente de K8s, dependente de ML), para que o agente e o usuário saibam antecipadamente quais ferramentas se aplicam a uma determinada implantação, em vez de descobrir lacunas de capacidade no momento da chamada. O repositório inclui seis Skills como artefatos .zip separados que ensinam ao agente quando e como chamar cada ferramenta.

O diagrama a seguir mostra os três componentes que compõem o app: o host MCP (Claude Desktop, VS Code ou similar), que contém o LLM e as habilidades do Claude que o ensinam a usar as ferramentas; o servidor do app MCP, um único processo Node.js que expõe o registro de ferramentas, empacota as visualizações de UI do React e gerencia toda a comunicação com a Elastic; e o próprio Elastic Stack, onde o Elasticsearch e o Kibana atuam como backends de dados em tempo real e alertas.

O diagrama abaixo traça o fluxo de uma solicitação do usuário: o Claude lê o arquivo de habilidade relevante para entender qual ferramenta chamar e como preencher seus parâmetros, chama a ferramenta que aciona consultas do lado do servidor no Elasticsearch e no Kibana e recebe de volta um resumo em texto compacto junto com um recurso de UI React que renderiza em linha como um widget interativo.

Do alerta à causa raiz: Fluxos de trabalho de investigação

As regras de alerta informam que algo está errado. Os módulos de ML informam o padrão. O Elastic Workflows executa o diagnóstico — automaticamente, no momento em que um alerta é acionado.

Estamos lançando um fluxo de trabalho de investigação do Kubernetes (prévia técnica) que é acionado por um alerta do Kubernetes e retorna um resumo estruturado da causa raiz antes de você ter aberto um único dashboard. O SRE que é acionado abre o alerta e encontra a investigação já concluída.

O fluxo de trabalho é um grafo direcionado de etapas que consulta várias fontes de dados — principalmente por meio do Elasticsearch Query Language (ES|QL), com uma busca no Elasticsearch para a verificação de anomalias de ML. As etapas if se ramificam com base nos resultados da consulta, escolhendo qual corroboração executar (anomalia de memória de ML vs. classificação de logs) e se deve avaliar a integridade dos serviços upstream (apenas quando existirem dependências de APM). As etapas de IA aparecem em três pontos: na classificação de padrões de log no caminho não OOM, na classificação do upstream como degradado ou íntegro e em um ai.summarize final que sintetiza todas as evidências estruturadas em uma narrativa de causa raiz.

Como é o fluxo de trabalho de investigação na prática

A execução de exemplo abaixo é baseada no OpenTelemetry Astronomy Shop sendo executado no Elastic — 16 serviços, Kafka, PostgreSQL, todos pré-instrumentados via OTLP. Junto com a telemetria real do Shop, injetamos uma cascata de OOMKill sintética, que grava sinais sintéticos de K8s e APM no mesmo espaço de nome por meio dos fluxos de dados do EDOT. O fluxo de trabalho não consegue distinguir os nossos sinais dos reais — ele apenas investiga o alerta.

Alerta disparado: CrashLoopBackOff — app-deployment em oteldemo-esyox-default. Contagem de reinicializações: 6.

Etapa 1 do fluxo de trabalho — Caracterizar o contexto do pod e do container

O fluxo de trabalho consulta métricas do K8s para contagem de reinicializações, motivo da última finalização e utilização em relação aos limites declarados.

Resultado: último motivo de término OOMKilled, contagem de reinicializações 6. (Observação: a utilização do kubeletstats não estava disponível para este pod/janela — o fluxo de trabalho continua normalmente.)

Ramificações do fluxo de trabalho: o motivo do encerramento é OOMKilled, portanto o fluxo de trabalho segue o caminho de investigação de memória, e não o caminho de investigação de log.

Etapa 2 do fluxo de trabalho — Consultar os resultados de anomalias de ML

Em vez de recalcular as tendências de memória, o fluxo de trabalho consulta o índice de anomalias de ML em busca de uma anomalia ativa de k8s_pod_memory_growth.

Resultado: nenhuma anomalia — o pico é sinalizado como impulsionado pela carga, não como uma suspeita de vazamento.

Etapa 3 do fluxo de trabalho — Verificar a integridade do serviço upstream

O fluxo de trabalho enumera dependências upstream das agregações APM service_destination.1m e compara a taxa de erro atual e a latência média com a mesma hora de sete dias atrás. Uma etapa de classificação por IA decide se a degradação upstream precedeu o alerta. Resultado: um upstream — api-gateway. Latência média atual: 15,13 ms, taxa de erro: 41,26%. Linha de base (há 168 h): idêntica. Classificação: upstream_healthy — dentro dos limites de 5× para erros/3× para latência. O upstream é descartado.

Etapa 4 do fluxo de trabalho — Correlacionar com alterações recentes do K8s

O log de eventos do espaço de nome mostra um ciclo rápido de Pulled → Created → Started → Killing → BackOff se repetindo aproximadamente a cada 60–90 segundos. Nenhuma implantação ou evento de redimensionamento nas últimas duas horas.

Saída do fluxo de trabalho:

HIPÓTESE DE CAUSA RAIZ (confiança: alta)

O app-deployment está sofrendo OOMKilling sob pressão de memória. O pod foi reiniciado
6 vezes com o motivo de término OOMKilled. O ML sinalizou o pico de memória como
orientado por carga (sem vazamento). O api-gateway upstream está íntegro na comparação com a linha de base
de 7 dias. Este é um problema de alocação de recursos — o limite da memória
do container é muito baixo para seu conjunto de trabalho real.

Evidência:
- 6 reinicializações, motivo do último encerramento OOMKilled
- Nenhuma anomalia de crescimento de memória de ML → leak_suspected=false (orientado por carga)
- Upstream api-gateway inalterado em relação à linha de base de 7 dias (15,13 ms, 41,26%) → saudável
- Os eventos do K8s mostram ciclos rápidos de Pulled/Created/Started/Killing/BackOff;
  nenhuma implantação nas últimas 2 h

Causa provável: limite de memória insuficiente para o conjunto de trabalho real sob carga.

Próximas etapas recomendadas:
1. Aumente o limite de memória da implantação do app com base no uso observado
2. Revise o código do aplicativo em busca de oportunidades de otimização de memória
3. Considere a degradação controlada em caminhos com alta carga

Impacto downstream: nenhum identificado a partir das métricas de destino do APM.

A saída acima é como o alerta fica quando você o abre — não um link para um monte de logs ou um dashboard, mas uma resposta.

O mesmo fluxo de trabalho pode ser acessado como uma ferramenta MCP a partir do Claude Desktop, VS Code ou qualquer cliente compatível com MCP. Quando um desenvolvedor pergunta "por que o checkout está apresentando erro?" em sua IDE, o agente chama o fluxo de trabalho e retorna a mesma saída estruturada em linha — mesmas evidências, mesma causa raiz, sem sair do editor.

Aqui está um passo a passo animado da execução do fluxo de trabalho:

Skill de observabilidade para Investigações no Kubernetes

Também estamos disponibilizando uma Skill de investigação única e abrangente (observability-k8s-investigation) que codifica o protocolo de diagnóstico completo para problemas de carga de trabalho, nós e plano de controle do Kubernetes. É uma metodologia de investigação prescritiva que inclui o raciocínio que um SRE experiente aplica instintivamente, mas raramente documenta. Você terá acesso a isso mantendo o Kibana atualizado, já que está integrado às habilidades do nosso Agente de IA. Tudo começa com princípios norteadores que evitam os erros de diagnóstico mais comuns:

• A ausência de evidências não é evidência. Se as consultas de log retornarem zero linhas, informe no_logs_available — não infira um modo de falha a partir de resultados vazios.
• OOMKilled não significa vazamento de memória por padrão. Compare o uso atual com uma linha de base de 7 dias antes de alegar um vazamento. O limite pode simplesmente estar subdimensionado.
• As métricas médias de CPU ocultam a limitação. Um pod pode parecer saudável com utilização média de 40–60%, mas sofrer limitação severa no p99. Observe o máximo e o p95, não apenas a média.
• Sintomas concomitantes não são causas. Dois serviços que se degradam simultaneamente geralmente compartilham uma causa upstream. Só atribua causalidade quando a degradação de um serviço preceder claramente a do outro e o delta for grande.

A partir daí, a Skill codifica uma taxonomia de modos de falha que abrange 16 padrões distintos de falha do K8s nas camadas de carga de trabalho, nó, plano de controle, dimensionamento automático e rede — desde OOMKilled e CFS throttling até bloqueios de webhook de admissão e split-brain de StatefulSet. Cada modo tem um sinal fundamental que o identifica e um checklist de corroboração que o confirma.

O fluxo de investigação segue um arco estruturado: orientar (identificar o pod de destino, espaço de nome, implantação), caracterizar (obter contagem de reinicializações, motivos de término, utilização), classificar (fazer correspondência com a taxonomia), corroborar (extrair eventos, logs, APM, comparações de linha de base) e sintetizar (produzir uma hipótese de causa raiz com confiança calibrada — alta, média ou baixa — com evidências explícitas e próximas etapas recomendadas).

Quando dois modos de falha se encaixam nas evidências, a Skill cita ambos e diz qual acredita ser causal e por quê. Quando as evidências são ambíguas, ela avisa. "Hipóteses concorrentes são uma saída válida" é um princípio de design explícito — gerar falsa confiança é tratado como um modo de falha da própria investigação.

Para começar

Esses recursos se baseiam na integração do Kubernetes descrita na Parte 1. Assim que você tiver dashboards e a coleta de dados em execução:

Etapa 1 — Habilitar os fluxos de trabalho de investigação (prévia técnica). Importe o Kubernetes Crashloop Investigation Workflow da página Workflows no Kibana e, como opção, configure-o para ser acionado por uma regra de alerta.

Etapa 2 — Instale o MCP App em um cliente compatível com MCP (prévia técnica). O repositório do MCP App for Observability pode ser encontrado no GitHub (consulte a página Releases para downloads). Ao instalar o app, não se esqueça de também instalar e habilitar as habilidades incluídas. Acesse as ferramentas do Example MCP App no seu cliente agêntico favorito — as instruções estão no README no link do GitHub acima.

Etapa 3 — Aproveite a K8s Investigation Skill (prévia técnica). Esta sai de graça se você estiver usando o Agent Builder, porque já vem integrada às AI Agent Skills. A Skill ensina ao agente quando e como chamar as ferramentas e os fluxos de trabalho subjacentes, garantindo diagnósticos consistentes em contextos conversacionais.

O que vem a seguir

Os fluxos de trabalho de investigação diagnosticam o que está com problemas nos serviços que você está monitorando. A próxima pergunta é mais difícil: e quanto aos serviços que você não está monitorando?

Estamos pensando em uma inteligência de cobertura com reconhecimento de topologia — descobrindo automaticamente cada carga de trabalho implantada no seu cluster por meio da API do Kubernetes, cruzando essas informações com a telemetria que flui para o Elastic e evidenciando as lacunas. "Você tem 47 serviços. 11 não têm traces distribuídos. Aqui está o seu ponto cego de maior risco." Essa funcionalidade está sob consideração e provavelmente será o assunto de uma postagem futura.

Em paralelo, estamos expandindo os fluxos de trabalho para abranger a remediação — não apenas o diagnóstico, mas também a ação: criar um caso com o resumo da investigação anexado, propor uma reversão para aprovação humana ou redimensionar uma carga de trabalho para ganhar tempo enquanto a causa raiz é resolvida.

Se você está executando o Kubernetes no Elastic hoje, conte-nos quais etapas de investigação você repete manualmente a cada incidente, quais ações de remediação você confiaria que um fluxo de trabalho propusesse e quais ferramentas de MCP devemos criar a seguir. Você pode participar da Discussão na Comunidade Elastic aqui.