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.