O que a compatibilidade com versões anteriores significa para a API do dashboard do Kibana

Durante a prévia técnica, a configuração da API pode mudar entre os lançamentos.[1] Esse não é mais o caso. Disponibilidade geral (GA) significa:

• Compatibilidade retrógrada completa. Novos campos e tipos de painel serão adicionados ao longo do tempo, mas os campos e comportamentos existentes permanecem inalterados. Quaisquer mudanças futuras que quebrem a compatibilidade seriam cuidadosamente consideradas e só seriam introduzidas em uma nova versão principal da pilha.

• Pronto para produção com suporte completo. A API oferece todas as garantias de compatibilidade da Elastic. Você pode usá-lo com segurança em ambientes de produção para implantações automatizadas, promoção de ambiente e gerenciamento programático do dashboard.

Novos endpoints da API Kibana para os painéis Tags, Markdown e Links

O Elastic 9.5 também introduz um novo  endpoint independente para Tags, que permite categorizar e filtrar painéis. Agora, você pode gerenciá-los programaticamente por meio de endpoints CRUD dedicados, facilitando a organização de painéis em escala entre ambientes.

Os novos endpoints para os painéis Markdown e Links já estão disponíveis no Serverless e serão lançados na próxima versão do stack (9.6).

Com quais tipos de painel a API do dashboard do Kibana é compatível?

A API do dashboard é compatível com todos os painéis definidos por valor na versão 9.5 (aqueles definidos diretamente em um dashboard, em oposição aos painéis da biblioteca salvos para reutilização). Cada tipo de painel compatível possui um esquema tipado e validado.

Tipo de painel

Status

Gráficos XY

Compatível

Métricas

Compatível

Pizza

Compatível

Medidor

Compatível

Heatmap

Compatível

Tabelas de dados

Compatível

Mapa de árvore

Compatível

Discover sessões

Compatível

Controles

Compatível

Markdown

Compatível

Links

Compatível

Painéis de ML

Compatível

Painéis de observabilidade

Compatível

Mapas

Em breve

Vega

Em breve

Como gerenciar dashboards do Kibana como código

A API de dashboards permite um fluxo de trabalho completo de dashboards como código: exportar um dashboard como JSON limpo e passível de comparação, enviá-lo ao Git como fonte de verdade, revisar mudanças em pull requests e implantar a mesma definição em desenvolvimento, staging e produção. Depois que um dashboard for gerenciado como código, trate o Git como a única fonte da verdade: as alterações feitas diretamente na UI serão substituídas na próxima vez que você implantar.

O principal desafio ao mover um dashboard entre espaços, clusters ou estágios é que os dashboards referenciam objetos como data view e visualizações da biblioteca por ID. Como esses IDs são gerados automaticamente e diferem entre ambientes, um dashboard exportado de um ambiente pode apontar para objetos que não existem em outro. Existem três maneiras de lidar com isso, listadas aqui da mais automatizada à menos automatizada:

• Use Terraform. O provedor Terraform do Elastic Stack acompanha cada recurso e mapeia os IDs automaticamente por ambiente, para que as referências permaneçam consistentes enquanto você promove um dashboard do desenvolvimento para a produção.

• Defina por-valor a Linguagem de Consulta Elasticsearch (ES|QL). A maneira mais portátil de construir um painel é definir sua visualização com o ES|QL diretamente no dashboard. Uma consulta ES|QL lê os índices que você especificar nela; portanto, o painel não contém referências externas a data views ou objetos de biblioteca. O resultado é um dashboard portátil e totalmente independente.

• Atribua IDs correspondentes. Se você fizer referência a objetos salvos, como visualizações de dados ou visualizações de bibliotecas, crie-os com um ID escolhido usando PUT (upsert) em vez de POST (que gera automaticamente um ID). Use IDs legíveis por humanos, como logs-prod, para que sejam fáceis de reutilizar e reconhecer em diferentes ambientes.

Para obter uma descrição detalhada desses padrões de portabilidade e do fluxo de trabalho completo de dashboards como código, consulte a documentação Gerenciar dashboards como código.

Crie um dashboard do Kibana com a API Dashboards usando PUT

Aqui está um exemplo rápido de criação de um dashboard com uma métrica usando PUT em vez de POST para atribuir um ID personalizado com o nome do dashboard (service-health-overview). A mesma lógica funciona para criar visualizações independentes salvas na biblioteca.

Roadmap da API do dashboard do Kibana: Maps, Vega e endpoints independentes

Estamos expandindo ativamente o escopo da API. Na sequência, compatibilidade com mapas e painéis Vega, adicionando esquemas tipados para eles. Também estamos construindo pontos finais CRUD independentes para sessões Discover (além do suporte existente como painéis de dashboard), Vega, maps e anotações, desacoplados do ciclo de vida do dashboard.

Para as definições completas de esquema, visite a documentação da API dos Dashboards. Para usuários do Terraform, o provedor Terraform do Elastic Stack é compatível com a API GA Dashboards.

Nota

1. Os endpoints núcleos permanecem inalterados em relação à prévia técnica. Se você construiu integrações contra a 9.4, elas funcionam na 9.5. As únicas alterações que quebram a compatibilidade são duas pequenas que afetam os formatos de listagem do dashboard e dos formatos da unidade de duração, documentadas aqui.

Novidades na criação do dashboard de IA do Kibana

Capacidade

Prévia técnica (9.4)

GA (9,5)

Tratamento de erros

Sem nova tentativa em consultas ES|QL

Tenta novamente automaticamente até três vezes, com inspeção e ajuste da consulta

Custo de geração ES|QL

Todas as consultas são roteadas pelo modelo primário

Roteamento em camadas de modelos, até 5 vezes mais barato

Intervalo de tempo

Janela padrão fixa

Seleção automática baseada na distribuição temporal dos dados

Controles de filtro

Sem suporte

Adicionado automaticamente para os campos mais relevantes

Gráficos Vega-Lite

Sem suporte

Criação em linguagem natural, incluindo diagramas de dispersão, diagramas de caixa, formatação condicional e dicas de ferramenta personalizadas

Edição de gráficos

Sem suporte

Editar painéis existentes do Vega-Lite usando linguagem natural

Recuperação automática de erros para geração de dashboards por IA

Na prévia técnica, o agente não tentou novamente as consultas ES|QL com falha. Na versão 9.5, ele detecta erros de consulta e tenta até três vezes, inspecionando cada erro e ajustando a consulta antes de desistir. Na prática, isso elimina a maioria dos problemas de painéis vazios e produz dashboards que renderizam corretamente na primeira tentativa.

Por que a criação de dashboards de IA é mais barata no Elastic 9.5?

Nem toda etapa na geração de dashboards exige o mesmo nível de raciocínio. Na 9.5, ES|QL passa por um modelo mais leve por padrão e retorna ao modelo primário apenas quando necessário. Se seu conector usa o Claude Opus 4.8 da Anthropic, isso significa que a geração de ES|QL em todos os painéis fica 5 vezes mais barata.

Seleção automática do intervalo de tempo com base nos seus dados

Dashboards só são úteis quando mostram o intervalo de dados correto. Agora, o agente aplica uma lógica aprimorada para escolher um intervalo de tempo que faça sentido para os dados que está consultando, a menos que o usuário solicite um intervalo de tempo específico. Ele considera a distribuição temporal dos dados e ajusta o intervalo de acordo, seja para a última hora em um incidente em andamento ou para os últimos 90 dias em uma análise de tendências, em vez de recorrer a uma janela fixa.

Controles automáticos de filtro em dashboards gerados por IA

A criação de dashboards agora oferece suporte a controles; ou seja, filtros interativos que permitem aos usuários filtrar um dashboard pelos valores dos campos sem editar as consultas subjacentes. Ao gerar um dashboard, o agente adiciona automaticamente controles na parte superior para os campos mais relevantes para filtragem.

Gráficos Vega-Lite a partir da linguagem natural: tipos de gráficos e formatação além dos padrões

Vega e Vega-Lite suportam uma ampla variedade de tipos de gráficos e personalizações no Kibana. Com a versão 9.5, você pode criá-los a partir de uma linguagem natural em vez de escrever o código você mesmo. 

Diagramas de dispersão, diagramas de caixa e mais tipos de gráficos Vega-Lite

Diagramas de dispersão, gráficos de caixa, múltiplos pequenos facetados, gráficos de bolhas e gráficos de composição (como combinar histogramas com mapas de calor), entre muitos outros, são suportados pelo Vega-Lite. Um prompt como Mostre-me um gráfico de dispersão entre tempo de resposta e tamanho da requisição, colorido pelo nome do serviço, gera um painel Vega-Lite com os mapeamentos de dados corretos. Usam as paletas de cores padrão do Kibana para se misturar com o restante do dashboard.

Formatação condicional, dicas de ferramentas personalizadas e rótulos em gráficos padrão

Mesmo para tipos de gráficos que já são nativos de dashboards, como barra, linha ou área, às vezes você precisa de mais controle do que as capacidades padrão oferecem. O Vega-Lite via chat preenche essa lacuna. Alguns exemplos incluem:

• Formatação condicional de cores: colorir pontos de dados acima de um limiar de forma diferente; por exemplo, tornar vermelhos os pontos de dados em uma linha ou barras quando algum indicador ultrapassa seu objetivo de nível de serviço (SLO). Peça ao agente algo como pinte de vermelho qualquer ponto acima de 500ms no meu gráfico de linhas.

  

• Marcas e etiquetas personalizadas: adicione emojis, símbolos ou etiquetas de texto em linha aos pontos de dados para indicadores de status de fácil visualização.

  

• Dicas de ferramentas personalizadas: enriqueça as dicas exibidas ao passar o cursor com mais métricas, contexto ou valores calculados que não fazem parte dos eixos do gráfico. Peça algo como Adicionar uma dica de ferramenta que mostre o total de registros e a % por barra.

  

Isso também funciona para editar gráficos Vega existentes. Se você tem um painel Vega-Lite que precisa de ajustes, como alterar uma escala de cores, ajustar um eixo ou mudar o tipo de marca, descreva a mudança no bate-papo em vez de se aprofundar no código JSON.

Como construímos a geração em linguagem natural do Vega-Lite no Kibana

Gerar um gráfico Vega-Lite a partir de uma frase não consiste em fazer um único prompt para o modelo gerar o JSON. Construímos um pequeno pipeline autônomo que transforma a intenção em linguagem natural em um gráfico validado e respaldado por dados.

Quando um pedido chega, o agente primeiro determina se o Vega-Lite é a opção adequada. Para requisições Vega-Lite, a visualização se baseia em uma consulta ES|QL real no Elasticsearch e então usa um modelo para gerar o código Vega-Lite. Antes da renderização, o resultado passa por uma camada de normalização que corrige o esquema e vincula a consulta canônica. Também aplica transformações para segurança na renderização.

Algumas escolhas de design tornam esse fluxo de trabalho confiável:

• Chamada tipada de ferramenta: a criação de gráficos é uma invocação de ferramenta estruturada, em vez de um código Vega-Lite de formato livre colado na conversa.

• Geração restrita: o modelo gera código Vega-Lite dentro de um esquema definido, tornando a saída mais previsível e fácil de validar.

• Exemplos selecionados: padrões estruturais, como facetas, marcas em camadas e mapas de calor, fornecem orientação sem copiar os dados subjacentes.

• Loops de execução e verificação: as consultas são executadas antes da criação do gráfico e as falhas de validação acionam novas tentativas corretivas para a geração de ES|QL.

Experimente a criação de dashboards por IA e gráficos Vega-Lite em Kibana

Para experimentar a criação de dashboards em linguagem natural e os gráficos Vega-Lite, atualize para o Elastic 9.5 (ou inicie um teste gratuito) e abra o chat no Kibana. Depois, peça para ele criar um dashboard a partir dos seus dados. Para Vega-Lite, tente pedir um tipo de gráfico que você sempre quis, mas nunca construiu, como um gráfico de dispersão ou um gráfico de bolhas. Se o resultado não estiver totalmente certo, diga ao agente o que mudar. Ele itera com você.

Isso requer uma licença empresarial. Comece agora mesmo.

O lançamento e o cronograma de quaisquer recursos ou funcionalidades descritos neste artigo permanecem a exclusivo critério da Elastic. Os recursos ou funcionalidades não disponíveis no momento poderão não ser entregues no prazo previsto ou sequer serem disponibilizados.

Todos os anos, os desastres naturais forçam gestores de emergência, comandantes militares e autoridades de segurança pública a tomar decisões de alto risco em prazos reduzidos. Essas decisões tradicionalmente dependem de árvores de chamadas, planilhas e conhecimento institucional distribuído entre dezenas de pessoas. A sobrecarga de coordenação por si só consome um tempo precioso.

Este post demonstra como a Elastic pode viabilizar um sistema de coordenação responsivo e baseado em agentes para resposta a desastres que detecta uma ameaça, avalia a logística e toma medidas automaticamente. Para tornar isso concreto, criamos uma simulação: um furacão fictício de Categoria 4 que ameaça a costa de Hampton Roads aciona o realojamento automatizado de mais de 137.000 pessoas em sete instalações militares.

Aviso: Este é um cenário totalmente fictício criado para fins de demonstração. O furacão ELARA-26 não existe. Os locais das instalações são baseados em dados geográficos reais e disponíveis publicamente (o conjunto de dados Military Installations, Ranges, and Training Areas [MIRTA] do Departamento de Defesa dos EUA [DoD]), mas todos os dados operacionais, como contagem de pessoal, capacidade de alojamento, ativos, e-mails de contato e perfis de missão, são totalmente fictícios. Nada nesta demonstração reflete prontidão militar, capacidade ou procedimentos operacionais reais.

Por que a resposta automatizada a desastres requer coordenação geoespacial e agêntica

Quando um desastre natural ameaça a infraestrutura crítica, o desafio de coordenação é imediato:

• Quais instalações estão na zona de impacto?

• Quantas pessoas precisam se deslocar?

• Para onde eles podem ir, e essas instalações têm capacidade?

• Quem precisa ser notificado agora?

Essas perguntas não esperam. Nem as respostas deveriam.

Implantar o pipeline: pré-requisitos e configuração

Siga as instruções aqui no repositório de exemplo para implantar um cluster local da Elastic com o Elastic Inference Service (EIS) via Cloud Connect.

Como funciona o pipeline agêntico de resposta a desastres do Elasticsearch

O pipeline tem sete camadas que trabalham juntas de ponta a ponta:

1. Ingestão de dados: eventos de desastre do Global Disaster Alert and Coordination System (GDACS) enviados para o Elasticsearch

2. Pipeline de ingestão: GeoJSON é ingerido e normalizado para o Elastic Common Schema (ECS).

3. Enriquecimento geoespacial: O polígono da área afetada pelo evento é comparado aos limites indexados de instalações militares.

4. Alerting: Uma regra de detecção do Kibana é acionada quando um desastre afeta qualquer instalação.

5. Automação de fluxo de trabalho: O alerta aciona um fluxo de trabalho do Kibana que inicia uma conversa com um agente de IA.

6. Raciocínio da IA: o agente analisa as instalações afetadas, seus ativos e as instalações de apoio mais próximas para determinar a realocação de todos os ativos e do pessoal.

7. Notificações por e-mail: o agente envia e-mails para todos os destinatários referentes à entrada e saída de pessoal e/ou ativos.

Vamos examinar cada camada.

Etapa 1: indexação de instalações militares com limites geográficos

A base é o conjunto de dados DoD MIRTA de source.coop/seerai/hifld. Este conjunto de dados fornece um geo_shape do tipo Point para cada instalação; coordenadas de centroide em vez de polígonos de limites completos.

Cada documento de instalação no índice mitra-facilities é enriquecido com dados de perfil operacional (todos fictícios), além do que o MIRTA fornece:

Esse índice rico é o que permite ao agente de IA tomar decisões inteligentes de alocação; não apenas "aqui estão as bases próximas," mas "aqui estão bases com capacidade de alojamento disponível, tipos de missão compatíveis e a logística para receber os ativos que chegam."

Etapa 2: ingerindo e normalizando eventos do GDACS

O GDACS publica GeoJSON em tempo real para terremotos, ciclones tropicais, inundações, incêndios florestais, vulcões e secas. Ingerimos esse feed em um fluxo de dados (logs-gdacs.events-*) usando um pipeline de ingestão personalizado que normaliza o GeoJSON bruto para campos do ECS.

O pipeline de ingestão do GDACS faz várias coisas que valem a pena notar:

Extração de geometria: O centróide é armazenado como um geo_point para exibição no mapa, e o polígono de impacto é armazenado como um geo_shape em gdacs.affected_area, que é o campo usado posteriormente para consultas de interseção.

Normalização da gravidade: cada tipo de desastre tem uma escala de gravidade diferente. Um ciclone tropical é medido pela velocidade do vento em km/h; um terremoto, pela magnitude Richter. O pipeline mapeia todos eles para uma pontuação normalizada de 0–100:

A pontuação de gravidade normalizada é então mapeada para um rótulo severity_level (low, medium, high, critical) usado para o mapeamento de gravidade do alerta na regra de detecção.

Alinhamento ao ECS: event.kind: alert, event.category: threat, registros de data e hora mapeados para event.start/event.end, e um _id estável baseado em fingerprint para desduplicação.

Passo 3: enriquecimento geoespacial: encontrar instalações afetadas no momento da indexação

A política enrich geo_match do Elasticsearch compara o polígono do desastre com todos os limites de instalação no momento da indexação, sem a necessidade de uma junção no momento da consulta. Em vez de consultar no momento da busca, usamos um processador enrich no pipeline de ingestão para comparar o polígono de impacto do desastre com todos os limites de instalação à medida que o documento é indexado.

A política de enriquecimento é uma política geo_match:

O processador é executado no final do pipeline de ingestão:

O INTERSECTS captura qualquer instalação cujo limite toque ou sobreponha o polígono do desastre e até mesmo interseções parciais. O resultado é que cada documento de evento do GDACS é armazenado com um array aninhado affected_facilities que nos informa exatamente quais instalações estão na zona de impacto. Nenhuma consulta de junção é necessária.

Etapa 4: regra de detecção: alerta sobre impacto nas instalações

Uma regra de detecção do Kibana monitora o fluxo de dados logs-gdacs.events-* e é disparada quando um evento do GDACS tiver sido enriquecido com pelo menos uma instalação afetada:

A regra é executada em uma programação de hora em hora (abrangendo uma janela de now-1h a now) e usa o mapeamento dinâmico de gravidade; o campo gdacs.severity_level calculado pelo pipeline de ingestão determina automaticamente a gravidade do alerta.

A gravidade do alerta também determina a pontuação de risco por meio do mapeamento de campos:

Quando a regra dispara, ela passa todo o contexto do alerta, incluindo o array affected_facilities enriquecido com nomes, tipos e locais de instalação, para um fluxo de trabalho subsequente do Kibana.

Etapa 5: Automação do fluxo de trabalho: conectando o alerta ao agente

Os fluxos de trabalho do Kibana cuidam da transição da detecção para a resposta. O fluxo de trabalho de resposta a desastres naturais é acionado pelo alerta:

Toda a carga útil do alerta (tipo de desastre, gravidade, área afetada e a lista de instalações impactadas) é encaminhada ao agente de IA como contexto inicial. O agente cuida do restante.

Etapa 6: o agente de IA: dos dados à ação coordenada

O agente mitra.response recebe o payload completo do alerta e, em um único loop agêntico, avalia o escopo, localiza instalações receptoras, aloca pessoal e envia notificações de evacuação e recebimento, tudo sem intervenção humana.

O agente tem duas ferramentas disponíveis:

• mitra.nearest_facilityconsulta o índice mitra-facilities usando uma consulta geo_shape, classificada por distância de uma determinada coordenada, retornando até 50 instalações ativas próximas com capacidade disponível.

• mitra.send_email itera sobre um array JSON de objetos de instalações e envia notificações formatadas de evacuação ou recebimento.

O conjunto de instruções do agente define um fluxo de trabalho claro:

1. Avalie a situação. Analise o alerta, identifique as instalações afetadas e determine a abrangência do desastre.

2. Faça um inventário do que precisa ser movido. Contagem de pessoal, ativos críticos, requisitos de alojamento por instalação.

3. Encontre as instalações de destino. Chame mitra.nearest_facility para cada instalação afetada, filtrando as instalações que ainda estão na zona de perigo.

4. Tome decisões de alocação. Analise soluções de instalação única em comparação com instalações múltiplas, compatibilidade entre ramos, capacidade de alojamento e suporte a ativos.

5. Envie e-mails de coordenação. Envie ordens de evacuação para as instalações de origem e notificações de recebimento para as instalações receptoras.

6. Gere um relatório de resumo. Gera um breve resumo de todas as instalações afetadas, do total de pessoas, dos ativos transferidos, das instalações de destino e de quaisquer preocupações para o chat para revisão.

A lógica de alocação do agente segue restrições do mundo real: não exceder a capacidade de alojamento, preferir relocações do mesmo ramo quando possível, usar bases conjuntas para o excedente de diferentes ramos e priorizar a distância para minimizar o tempo de deslocamento.

A ferramenta de instalação mais próxima

A consulta do fluxo de trabalho subjacente usa geo_shape com um filtro circle e classificação por _geo_distance:

A capacidade disponível é calculada no momento da consulta por meio de um campo com script que calcula a capacidade de alojamento menos a contagem atual de pessoal. O agente usa isso para alocar pessoal entre os destinos sem exceder os limites.

Furacão ELARA-26: coordenação agêntica de 137.000 pessoas, de ponta a ponta

O furacão ELARA-26 é uma tempestade de categoria 4 (ventos máximos de 213 km/h) com previsão de atingir a costa na região de Hampton Roads, na Virgínia. Quando o evento do GDACS é ingerido, o polígono da área afetada intercepta sete grandes instalações militares na região. A regra de detecção dispara. O fluxo de trabalho inicia uma conversa com o agente.

Em um único loop agêntico, o agente:

• Identificou sete instalações na zona de impacto, com um total combinado de 137.372 pessoas.

• Chamou mitra.nearest_facility para encontrar instalações receptoras fora da trajetória da tempestade.

• Distribuiu o pessoal entre nove instalações receptoras com base na capacidade de alojamento disponível e na distância.

• Gerou e enviou ordens de evacuação para todas as sete instalações afetadas.

• Gerou e enviou notificações de recebimento para todas as nove instalações receptoras.

• Produziu um resumo completo de coordenação, semelhante ao mostrado abaixo:

Instalações evacuadas:

Instalação

Pessoal

Estação Naval de Norfolk

50.000

Base expedicionária conjunta Little Creek-Fort Story

18.000

Naval Air Station Oceana

15.355

Naval Air Station Oceana Dam Neck Annex

17.509

Reserva Militar Estadual NG Camp Pendleton

9.707

Base Conjunta Langley-Eustis

15.000

Naval Weapons Station Yorktown

11.801

Instalações receptoras:

Instalação

Distância

Pessoal ingressante

Fort Gregg-Adams

97 km

~40.000

Base do Corpo de Fuzileiros Navais de Quantico

148 km

~30.000

Naval Support Facility Indian Head

151 km

~30.000

Base Conjunta Andrews

180 km

~30.000

Naval Air Station Patuxent River

141 km

~10.000

NG MTA Camp Butner

174 km

~5.000

Local de treinamento NG Bethany Beach

209 km

~4.707

Rivanna Station

140 km

~7.500

Centro de suprimentos Def Gen

22 km

~6.000

Os ativos realocados incluem veículos de transporte, helicópteros, barcos de patrulha, unidades médicas, veículos de engenharia, geradores, reboques de água, kits de abrigo e sistemas de comunicação.

Notificações automatizadas por e-mail

Depois que o agente finalizou seu plano de alocação, ele chamou mitra.send_email e enviou 16 e-mails de uma só vez; ou seja, ordens de evacuação para todas as sete instalações afetadas e notificações de recebimento para todas as nove instalações receptoras. Cada mensagem incluía a instalação de destino, a quantidade de pessoal que chegaria, os ativos a serem movidos e um contato de coordenação. O que teria levado horas de ligações em cadeia foi concluído automaticamente no momento em que o agente terminou de raciocinar.

Estendendo a resposta agêntica a desastres com RAG e fundamentação em políticas

Esta demo é puramente baseada em dados estruturados, como números de capacidade, distâncias e status operacional. Os recursos de busca semântica e retrieval augmented generation (RAG) da Elastic podem tornar o agente significativamente mais inteligente, com duas adições:

Recuperação de respostas históricas: indexe relatórios pós-ação anteriores, resumos de incidentes da Agência Federal de Gestão de Emergências (FEMA) e registros de resposta a desastres como embeddings vetoriais. Quando ocorre um novo evento, o agente pode recuperar semanticamente como eventos semelhantes foram tratados, embasando decisões de alocação com conhecimento institucional, em vez de se basear apenas em cálculos de capacidade.

Fundamentação em políticas e doutrinas: indexe diretrizes de gerenciamento de emergências do DoD, planos de continuidade de operações de instalações e orientações do comandante. O agente pode recuperar e citar as políticas reais que regem uma resposta, garantindo que cada decisão seja fundamentada em doutrina, em vez de inferência.

Ambos seguem a mesma abordagem nativa da Elastic:; um pipeline de inferência gera embeddings em tempo de indexação, e uma ferramenta de busca semântica é exposta ao agente. O pipeline de coordenação permanece o mesmo. O agente simplesmente fica mais inteligente.

Por que o Elasticsearch é a plataforma certa para a resposta agêntica no setor público

Este não é um chatbot. Não é um dashboard. É um sistema responsivo de fluxo de trabalho agêntico, que detectou uma ameaça, raciocinou sobre um problema logístico complexo e coordenou a realocação de 137.000 pessoas sem intervenção humana. Esse tipo de resultado só é possível porque todos os recursos dos quais ele depende estão em uma única plataforma unificada.

O suporte geoespacial do Elasticsearch (geo_point, geo_shape, políticas de enriquecimento e classificação baseada em distância) lida com o raciocínio espacial que torna a detecção de interseções e a consulta de instalações possíveis em escala. A busca semântica e os embeddings vetoriais ancoram os agentes na realidade, garantindo que o raciocínio da IA seja baseado no que realmente está em seus dados, em vez de suposições alucinadas. O mecanismo de detecção do Kibana, os fluxos de trabalho, o Agent Builder e as ferramentas do Agent Builder conectam tudo em um pipeline que vai do evento bruto à ação coordenada, sem a necessidade de nenhum código de integração externo.

Nenhuma outra plataforma reúne tudo isso como a Elastic. A combinação de indexação em tempo real, precisão geoespacial, recuperação semântica e orquestração por agentes, tudo em uma única pilha de tecnologia, com segurança e observabilidade de nível empresarial integradas, é o que diferencia a Elastic de ferramentas que fazem bem uma dessas coisas, mas exigem que você reúna o restante por conta própria.

Resposta geoespacial agêntica para gerenciamento de emergências, bombeiros, aplicação da lei e saúde pública

A mesma arquitetura se aplica onde quer que pessoas, instalações e eventos em tempo real se cruzem. Os dados específicos mudam. O pipeline não.

Gerenciamento de emergências: a FEMA e os órgãos estaduais de gerenciamento de emergências podem mapear locais de abrigo, áreas de mobilização e populações vulneráveis em relação aos polígonos de clima severo do National Weather Service (NWS), acionando o pré-posicionamento automatizado de recursos antes que uma tempestade atinja a costa.

Serviços de bombeiros e emergência médica: os corpos de bombeiros podem sobrepor localizações de unidades e zonas de resposta a perímetros de incêndios florestais ou clusters de incêndios estruturais, encaminhando automaticamente solicitações de ajuda mútua para as unidades disponíveis mais próximas com o equipamento adequado.

Aplicação da lei: as agências podem correlacionar locais de incidentes ativos com zonas escolares, infraestrutura crítica e posições de policiais, disparando notificações de bloqueio baseadas em localização geográfica ou despacho de recursos sem esperar pela triagem manual.

Segurança nas escolas públicas: os distritos escolares podem monitorar feeds de ameaças em tempo real em relação aos limites do campus. Quando uma ameaça cruza o perímetro de uma escola, um agente pode notificar imediatamente a administração, iniciar comunicações de confinamento e coordenar a resposta das forças policiais, tudo antes que um atendente pegue o telefone.

Saúde pública: os departamentos de saúde podem cruzar dados de vigilância de doenças ou zonas de risco ambiental com a localização de clínicas, camadas de densidade populacional e estoques de depósitos de suprimentos para direcionar recursos para onde são mais necessários.

Setor

Caso de uso

Recurso da Elastic

Gerenciamento de emergências

Corresponda os locais de abrigo aos polígonos de clima severo do NWS

Enriquecimento de geo_shape + fluxos de trabalho do Kibana

Bombeiros e EMS

Sobreponha as localizações das unidades aos perímetros de incêndios florestais

roteamento geoespacial + consulta de instalação mais próxima

Aplicação da lei

Correlacione incidentes com zonas escolares e posições de policiais

regras de alerta com reconhecimento geográfico + despacho de agentes

Segurança nas escolas públicas

Monitore feeds de ameaças em relação aos perímetros do campus

regras de detecção + notificação automatizada

Saúde pública

Corresponda zonas de perigo a locais de clínicas e depósitos de suprimentos

busca semântica + enriquecimento geoespacial

Os dados são diferentes em cada cenário. O padrão subjacente de ingerir, enriquecer no momento da indexação, detectar interseção, acionar resposta agêntica e agir é o mesmo. A Elastic oferece às organizações do setor público a plataforma para criar uma vez e adaptar em qualquer lugar.

O lançamento e a disponibilização de quaisquer recursos ou funcionalidades descritos neste artigo ficam a exclusivo critério da Elastic. Os recursos ou funcionalidades não disponíveis no momento podem não ser disponibilizados no prazo previsto ou nem chegar a ser disponibilizados.

O agente cria dashboards do zero, mas também trabalha com o que você já tem. Abra a barra lateral do AI Chat enquanto visualiza um dashboard e ele é anexado automaticamente. Pergunte por que uma métrica disparou, divida por região ou adicione um painel de comparação. Seu dashboard existente se torna o ponto de partida, não apenas o produto final.

Bastidores: como construímos dashboards no AI Chat

Ensinamos ao agente tarefas específicas por meio de habilidades — descrições estruturadas de como operar em um determinado problema. Mas construir uma habilidade de dashboard significava ensinar um LLM a gerar dashboards Kibana válidos, e a API de objetos salvos legada tornava isso doloroso: JSON profundamente aninhado, mudanças sutis de versão em versão, referências frágeis. Precisávamos de uma abordagem diferente

Uma API construída especialmente para dashboards programáticos

A nova API de dashboards foi criada exatamente para esse cenário. Em vez de expor o estado interno bruto, ele oferece esquemas tipados e validados para cada tipo de painel. A API lida com a tradução entre as estruturas externas limpas e as representações internas do Kibana, para que o agente possa se concentrar no que o dashboard deve conter e não em como formatá-lo.

Uma habilidade, uma ferramenta, muitas operações

A habilidade dashboard-management expõe uma única ferramenta manage_dashboard que aceita uma matriz ordenada de operações. Cada operação é uma ação discreta: definir metadados, adicionar um painel de markdown, criar visualizações com suporte ES|QL a partir de linguagem natural, editar painéis existentes, agrupar painéis em seções dobráveis ou reposicionar itens na grade.

O agente pode descrever um dashboard inteiro: título, descrição, seções e todos os painéis dentro deles em uma única chamada:

As operações são executadas em ordem, para que etapas posteriores possam referenciar e construir sobre as anteriores. Esse design mantém a conversa focada na intenção e não nos detalhes da implementação.

O pipeline de visualização: linguagem natural para ES|QL para visualizações

Quando você pede um dashboard, o agente explora seus dados — índices, mapeamentos de campos, tipos — e depois planeja as visualizações e chama manage_dashboard.

Cada painel executa seu próprio pipeline: seleção de tipo de gráfico, ES|QL, configuração de visualização e validação. Isolamos isso do thread principal do agente — a construção da visualização exige várias chamadas de modelo por painel, e misturá-las ao contexto principal incharia a janela e confundiria o raciocínio.

Dentro do manage_dashboard, todos os painéis são construídos simultaneamente e depois remontados em ordem. O resultado é um dashboard completo com painéis embutidos — sem visualizações órfãs, sem problemas de sincronização.

Por que movemos a criação de visualizações para dentro da ferramenta de dashboard

Nossa primeira abordagem usou uma ferramenta create_visualization separada — uma chamada por painel, depois de passar cada anexo para a ferramenta do dashboard. Funcionou, mas toda visualização precisava de sua própria chamada da ferramenta, seu próprio ciclo de vida e uma entrega explícita. Pior ainda, editar uma visualização na conversa não atualizou o painel do dashboard, o que confundiu os usuários.

Integramos a criação de visualizações diretamente em manage_dashboard. Os mesmos fluxos de trabalho paralelos são executados, mas os painéis se organizam na estrutura do dashboard sem anexos intermediários. Menos chamadas, sem problemas de sincronização, um ciclo de vida único.

As visualizações independentes ainda funcionam — você pode inserir gráficos existentes em um dashboard por meio de referências de anexos — mas, para criar do zero, a criação em linha é o caminho mais limpo

Para equipes de segurança

Analistas SOC e engenheiros de detecção não podem perder tempo indo e voltando do editor de dashboard no meio da investigação. No AI Chat, peça o volume de alertas por tipo de regra, host ou tática do MITRE e veja isso no seu tópico em cerca de um minuto. À medida que a investigação avança, insira painéis — anomalias na execução de processos, conexões de rede, comparações de linhas do tempo — sem perder o contexto.

Salve quando terminar. O dashboard se torna uma referência para a revisão pós-incidente, um ponto de partida para o próximo analista, ou um briefing semanal de ameaças — sem necessidade de reexplicação.

Leia mais sobre como as equipes de segurança podem usar a criação de painéis e outras capacidades recentemente lançadas do AI Chat neste post do blog.

Para engenheiros de observabilidade e confiabilidade do site (SREs)

Quando um serviço se deteriora às 2:00, não há tempo para construir painéis do zero. Com o AI Chat, um SRE pode descrever as métricas de que precisa (latência p99 por serviço, taxa de erro em relação a eventos de implantação, reinicializações do pod na última hora) e obter um dashboard completo no tópico de investigação em cerca de um minuto. O agente pode refiná-la passo a passo à medida que a imagem fica mais nítida: adicione um painel, altere a janela de tempo, divida por região.

Ao salvar o dashboard, ele fica imediatamente disponível na sala de guerra (mesmos painéis, mesma estrutura) para todos que participam da ponte de incidentes. Após o incidente, ele se torna a base para o postmortem.

O que vem a seguir

Estamos trabalhando em otimização de token, interações em tela cheia mais ricas, suporte de painel mais amplo e melhorias contínuas de qualidade. A visualização técnica é o momento certo para definir prioridades — se algo estiver faltando, informe-nos através do ícone "Enviar feedback" no menu superior.

Experimente

Atualize para o Elastic 9.4 (ou inicie uma avaliação), abra o AI Chat no modo de tela cheia e experimente em uma investigação real. Peça ao agente que gere gráficos para as métricas que você está analisando e depois peça a próxima análise. Quando a história se confirma, salve e compartilhe — mesmos quadros, mesma estrutura, sem necessidade de reexplicação. Você precisa de uma licença empresarial (comece agora). O lançamento e o tempo de amadurecimento de todos os recursos ou funcionalidades descritos neste artigo permanecem a exclusivo critério da Elastic. Os recursos ou funcionalidades não disponíveis no momento poderão não ser entregues ou não chegarem no prazo previsto.

Como o Kibana busca dados ao carregar um dashboard

Quando um dashboard é aberto, a maioria dos painéis (internamente, chamamos esses incorporáveis) inicia uma ou mais consultas no Elasticsearch. Mas, em vez da simples chamada e resposta de uma busca síncrona (sync), usamos o poder da busca assíncrona (docs async).

Com a busca assíncrona, os resultados das consultas ficam disponíveis no Elasticsearch fora de qualquer requisição HTTP específica. Isso é importante porque

• torna o carregamento de dados resiliente à turbulência da rede

• potencializa nosso recurso de busca em segundo plano, o que permite que os usuários trabalhem em outras coisas no Kibana enquanto esperam por um dashboard de longa duração ou por uma sessão do Discover

Após a consulta inicial ser enviada, o Kibana monitora a busca para detectar quando ela está concluída e recuperar o conjunto de resultados.

Como a sondagem tradicional afeta os tempos de carregamento do dashboard do Kibana

Na sondagem tradicional, o Kibana envia uma consulta, fecha a conexão inicial e então verifica periodicamente a conclusão do Elasticsearch.

Damos ao Elasticsearch um curto período de tempo após o envio da consulta para simplesmente completar a busca e devolver os resultados. Se a busca for concluída tão rapidamente, isso se resume a uma simples chamada e resposta. Mas para buscas mais longas, a conexão inicial é fechada e o Kibana começa a verificar periodicamente a busca para conclusão. Isso é chamado de sondagem.

Desvantagens de desempenho da sondagem tradicional

Observando a figura acima, talvez você já possa ver a desvantagem de desempenho dessa abordagem: é mais provável que a busca termine durante um dos intervalos de espera do Kibana, levando à perda de tempo.

No pior cenário (quando uma busca é concluída no início de um período de espera), toda a duração do intervalo de sondagem será desperdiçada.

O impacto de uma estratégia de backoff

É prática padrão durante a sondagem aplicar uma estratégia de backoff. Isso significa que, quanto maior a duração da busca, menos frequentemente a consultamos.

No entanto, isso também significa que o tempo potencial perdido varia proporcionalmente com a duração da busca.

Como intervalos de sondagem criam padrões de latência em forma de serra

Ao combinar todos esses fatores, o tempo perdido passa a seguir um padrão em dente de serra escalonado.

Aqui, os picos são os piores cenários possíveis e os vales são os melhores cenários. Isso ilustra que a sondagem tradicional nos custa entre nada e a duração total do intervalo de sondagem, dependendo da duração da busca (e das condições da rede).

Sondagem contínuas: como o Kibana elimina o tempo de espera

O problema com a sondagem tradicional é uma falta fundamental de coordenação entre Kibana e Elasticsearch. Idealmente, o Kibana sabe imediatamente quando os resultados estão disponíveis. Então, e se invertêssemos o padrão de sondagem para que quase todo o tempo seja gasto checando o Elasticsearch e nenhum tempo seja gasto em espera?

Com esta combinação de sondagem longa e sem mais períodos de espera, os resultados são entregues assim que estiverem prontos.

Degradação HTTP/1

A teoria é sólida. Então, por que essa implantação do Kibana parece tão degradada quando ativamos a sondagem contínua?

A chave é que essa implantação está sendo executada em HTTP/1. No HTTP/1, as requisições HTTP são mapeadas 1:1 para conexões TCP. Portanto, várias solicitações de sondagem de longa duração estão monopolizando o pool de conexões finito do navegador, fazendo com que outras solicitações sejam colocadas na fila.

No HTTP/2+, por outro lado, as solicitações de rede podem compartilhar conexões TCP via multiplexação, então não enfrentamos esse problema.

Portanto, no HTTP/2+, a sondagem contínua é uma virtude, mas no HTTP/1 ela se torna um vício.

HTTP/1

HTTP/2+

Conexões TCP

Uma por solicitação HTTP

Multiplexado (muitas solicitações compartilham conexões)

Comportamento de sondagem contínua

Degrada o desempenho (esgotamento do pool de conexão)

Benefício total (resultados entregues imediatamente)

Como o Kibana detecta o protocolo HTTP para sondagem ideal

HTTP/2 é o protocolo recomendado e é o padrão do Kibana desde a versão 9.0, então seria uma pena não enviar esse aprimoramento de desempenho. Por outro lado, a experiência HTTP/1 é tão degradada que não é aceitável arriscar isso em implantações no local que ainda não atualizaram seu protocolo. A resposta é clara: precisamos detectar qual protocolo está em uso e aplicar a estratégia de sondagem ideal.

Certamente é possível que o servidor Kibana saiba qual protocolo ele utiliza. Mas há um porém: o fator limitante é o conjunto de conexões do navegador. Isso significa que o que realmente importa é o que o navegador utiliza.

Por causa dos proxies, nem sempre são iguais.

Se basearmos nossa otimização no protocolo do servidor, podemos errar de duas maneiras.

1. Aplicar sondagem contínua quando não deveria e isso prejudica a experiência.

2. Deixar de aplicar a sondagem contínua quando necessário e perder a otimização.

Felizmente, navegadores modernos oferecem uma forma de detectar o protocolo do último salto de rede de qualquer requisição concluída por meio do uso de um PerformanceObserver. Então, observamos o protocolo da primeira submissão de consulta e otimizamos com base nisso.

Resultados de laboratório: sondagem contínua vs. sondagem tradicional em Kibana

Para validar a sondagem contínua, criamos dashboards com atrasos de consulta variando de 1 a 23 segundos e medimos os tempos de carregamento com e sem a otimização ativada. Em seguida, carregamos os dashboards com e sem sondagem contínua para medir os ganhos (nos divertimos bastante com race-for-the-prize).

O padrão ecoa nosso diagrama dente de serra original. Para algumas durações de consulta, os ganhos são pequenos, enquanto para outras chegam a vários segundos.

Conclusão

Essa otimização substitui com sucesso a latência inerente à sondagem tradicional por uma estratégia de sondagem contínua mais eficiente. O principal desafio foi implementar essa otimização condicionalmente para evitar a degradação do desempenho em implantações HTTP/1. Resolvemos usando o PerformanceObserver do navegador para detectar de forma confiável o protocolo em uso no salto final da rede.

Testes laboratoriais validam a teoria, mostrando que a sondagem contínua entrega resultados assim que estão disponíveis. Em média, isso leva a uma melhoria significativa na experiência do usuário, tornando o carregamento de dados até 25% mais rápido.

Este trabalho é o passo mais recente em nosso compromisso de reduzir o tempo para obter insights para nossos usuários. Ao tornar o Kibana um proxy mais transparente para os dados do Elasticsearch, ultrapassamos os limites do desempenho dentro da nossa esfera de influência. Mais novidades em breve!

(Em 2025, Thomas Neirynk apresentou uma excelente visão geral dos métodos e da motivação por trás do aprimoramento do desempenho do dashboard do Kibana. Esta é uma atualização sobre essa iniciativa.)

O que é um construtor de dashboard do Kibana?

E se você pudesse descrever o dashboard que deseja em inglês simples e vê-lo aparecer completo, com gráficos interativos, um layout de arrastar e soltar e exportação para o Kibana com um clique?

É exatamente isso que o example-mcp-dashbuilder faz. É um aplicativo open source (Model Context Protocol (MCP)) que conecta assistentes de IA ao Elasticsearch, permitindo que você crie painéis completos do Kibana por meio de conversas. Sem precisar clicar nos menus. Sem escrever manualmente as configs de visualização. Basta descrever o que você precisa para que a IA explore seus dados, escreva as consultas Elasticsearch Query Language (ES|QL), crie os gráficos e forneça um dashboard interativo ao vivo, tudo dentro da janela de bate-papo do seu editor.

Do prompt ao dashboard em segundos

Veja como isso funciona na prática. Você digita algo como:

"Crie para mim um dashboard de tráfego da web a partir do logstash-* com total de solicitações, bytes transferidos ao longo do tempo, principais fontes geográficas e um detalhamento do código de resposta"

A IA então:

1. Descobre seus dados: lista índices e inspeciona mapeamentos de campos.

2. Escreve consultas ES|QL: adaptadas ao seu esquema, usando as agregações corretas.

3. Cria visualizações: gráficos de barras, gráficos de linhas, métricas com sparklines, mapas de calor, gráficos de pizza.

4. Organiza tudo: seções retráteis, títulos significativos, layout adequado.

5. Renderiza uma visualização interativa: diretamente no bate-papo, com dicas de ferramentas, um seletor de tempo e arrastar e soltar.

Cada gráfico aparece em linha conforme é criado, então você pode ver o progresso em tempo real. Depois, view_dashboard mostra o dashboard completo com todos os painéis dispostos na grade de 48 colunas de Kibana.

Prévia de gráfico único em linha.

Desenvolvido por ES|QL

Toda recuperação de dados utiliza ES|QL, a linguagem de consulta em pipeline do Elasticsearch. A IA não apenas passa por consultas brutas, ela também usa conhecimento integrado do ES|QL junto com informações sobre a estrutura dos seus dados para escrever consultas corretas e eficientes para cada tipo de visualização.

O servidor inclui uma referência abrangente de ES|QL como um recurso MCP. Antes de escrever qualquer consulta, a IA lê essa referência para entender os comandos, funções e padrões disponíveis. Em conjunto com um guia de **práticas recomendadas** de visualização de dados (que também serviu como recurso), a IA sabe não apenas como fazer consultas, mas o que torna uma visualização boa:

• Use BUCKET(@timestamp, 1 day) para séries temporais; sempre SORT pelo campo de tempo.

• Limite os gráficos de pizza a seis fatias com | SORT value DESC | LIMIT 6.

• Escolha gráficos de barras para comparações de categorias, gráficos de linhas para tendências, métricas para indicadores-chave de desempenho (KPIs).

Exploração de dados orientada por IA com análise aberta

Construir um dashboard que você já imaginou na cabeça é outra história. Perguntar "O que há de interessante nesse índice?" e obter uma resposta útil é mais difícil; isso exige que a IA saiba como explorar, não apenas como desenhar.

O example-mcp-dashbuilder envia um recurso analysis://guidelines que define um fluxo de exploração estruturado: faça o perfil dos dados, execute agregações direcionadas, identifique padrões que valem a pena investigar, crie gráficos para as descobertas mais interessantes e proponha consultas detalhadas que o usuário possa querer em seguida. Frases gatilho, como "analisar meus logs" ou "encontrar padrões neste índice", fazem a IA ler o manual antes de fazer qualquer outra coisa, então um prompt aberto produz uma investigação coerente em vez de uma pilha aleatória de gráficos.

O resultado: você pode entregar um índice não familiar à IA e receber de volta um ponto de partida: um dashboard mais uma pequena lista de prompts "Aqui estão minhas impressões, quer que eu investigue mais a fundo algum desses?"

Exportação e importação do dashboard do Kibana: a viagem completa de ida e volta

A viagem de ida e volta de exportação/importação é onde o example-mcp-dashbuilder se torna realmente útil para as equipes que já trabalham com o Kibana. O example-mcp-dashbuilder é algo próprio, uma superfície de dashboard de conversação que fica dentro do seu editor, mas não prende o seu trabalho lá. Dashboards construídos aqui podem ser movidos para o Kibana quando você quiser, e dashboards existentes do Kibana podem seguir o caminho inverso para edição assistida por IA.

Exportar para Kibana

Quando você estiver satisfeito com seu dashboard, um comando irá exportá-lo:

"Exportar este dashboard para o Kibana"

Cada painel é traduzido para uma visualização real do Kibana Lens. A tradução preserva:

• Consultas ES|QL: transferidas diretamente como fontes de dados ES|QL do Lens.

• Posições de grade: o mesmo sistema de 48 colunas que o Kibana usa, para que você tenha um layout idêntico.

• Cores personalizadas: paletas de séries, fundos métricos, rampas de cores de heatmap.

O resultado é um dashboard do Kibana totalmente funcional. Não é uma captura de tela. Não é uma incorporação. Um dashboard do Kibana que você pode compartilhar e continuar editando.

Dashboard do Kibana e dashboard no chat do Cursor lado a lado.

Importar do Kibana

A viagem de ida e volta também funciona na outra direção:

"Importar o dashboard do Kibana com o ID abc-123"

Isso busca um dashboard do Kibana existente, traduz suas visualizações do Lens para configurações de gráficos editáveis, preserva o layout e as seções da grade e carrega tudo no example-mcp-dashbuilder. A partir daí, você pode modificar com linguagem natural e reexportar.

Isso torna a IA uma colaboradora em seu fluxo de trabalho existente do Kibana, não uma substituta para ele.

Temas e cores personalizados

Quer um dashboard de marca? É só pedir:

"Crie um dashboard com tema rosa e cores personalizadas"

Todo tipo de visualização permite configuração de cor personalizada:

• Gráficos: palette aceita uma matriz de cores hexadecimais para séries e fatias.

• Métricas: color define a cor de plano de fundo.

• Mapas de calor: colorRamp define o gradiente, dos valores baixos aos altos.

A IA identifica os pedidos de tema naturalmente. Diga "tema do oceano", e ele vai escolher tons de azul e verde-azulado. Diga "Combine as cores da nossa marca" e forneça valores hexadecimais, e eles serão aplicados no Kibana na exportação.

Um dashboard temático com cores personalizadas.

Como funciona o example-mcp-dashbuilder: arquitetura MCP

O example-mcp-dashbuilder foi desenvolvido com base no MCP, o padrão aberto para conectar assistentes de IA a ferramentas e dados externos. Aqui está a arquitetura em alto nível:

O servidor MCP expõe 25 ferramentas que a IA pode chamar diretamente, desde a execução de consultas ES|QL até a exportação de painéis, além de algumas ferramentas internas "exclusivas do app" que a pré-visualização embutida usa para buscar dados, persistir alterações de layout e detectar campos de tempo. Ele oferece três recursos: um guia de **práticas recomendadas** de dataviz, uma referência ES|QL e um manual de análise aprofundada que entra em ação para prompts abertos ("analisar meus logs", "o que há de interessante neste índice"). E executa tanto em stdio quanto em HTTP; o transporte HTTP permite respostas em fluxo contínuo e gerenciamento de sessão, permitindo que vários clientes se conectem a um mesmo servidor.

O MCP App é uma pré-visualização interativa. Ele foi desenvolvido com React, Elastic Charts e Elastic UI, agrupados em um único arquivo HTML independente. Quando a IA chama view_dashboard ou cria um gráfico, o host renderiza este HTML em um iframe isolado. O aplicativo se comunica com o servidor inteiramente através do protocolo MCP Apps, usando callServerTool() sobre postMessage para buscar dados, salvar layouts e detectar campos de tempo. Não há servidor localhost, nenhuma porta para configurar, nenhuma dependência de rede externa.

Isso significa que funciona com qualquer cliente compatível com MCP: Cursor, Claude Desktop, Claude.ai, VS Code com Copilot e muito mais.

Quais tipos de gráficos o example-mcp-dashbuilder permite?

No momento desta publicação, são permitidos seis tipos de gráficos que cobrem os cenários de dashboard mais comuns:

Tipo

Melhor para

Exemplo

Barra

Comparando categorias

Solicitações por fonte geográfica

Linha

Tendências ao longo do tempo

Bytes transferidos por hora

Área

Volume ao longo do tempo

Volume de solicitações ao longo do tempo

Pizza

Parte do todo (máximo seis fatias)

Distribuição de código de resposta

Métrica

KPI único com sparkline

Total de solicitações com tendência horária

Heatmap

Padrões em duas dimensões

Solicitações por dia da semana e hora

Dashboards permitem seções recolhíveis para organização, um seletor de tempo com detecção automática de campos de tempo e a capacidade de salvar e alternar entre múltiplos dashboards; sessões paralelas de chat permanecem isoladas umas das outras por meio de um dashboardId que passa por cada chamada de ferramenta.

Como instalar e executar o example-mcp-dashbuilder

O example-mcp-dashbuilder é open source e está pronto para uso. Você vai precisar de Node.js 22+, uma instância Elasticsearch (local ou Elastic Cloud) e um cliente compatível com MCP.

Claude Desktop: baixe a versão mais recente .mcpb do GitHub Releases, e clique duas vezes nela. O Claude Desktop solicitará suas credenciais do Elasticsearch.

Cursor / Claude Code / VS Code Copilot: aponte sua configuração MCP para o tarball liberado; sem clone, sem npm install:

Configure ES_NODE, ES_API_KEY (ou ES_USERNAME / ES_PASSWORD) e KIBANA_URL como variáveis de ambiente. Se você preferir trabalhar a partir da fonte, clone o repositório e execute npm run setup para um assistente interativo que lida com o Elasticsearch local e o Elastic Cloud (Cloud ID + chave de API).

E comece a construir:

"Explore o índice de logs e construa o dashboard mais perspicaz que puder"

A partir daí, a IA assume o controle. 😉

Roadmap: o que está por vir para o example-mcp-dashbuilder

Este é um lançamento antecipado, e estamos em desenvolvimento ativo. Algumas áreas em que estamos focados:

• Mais tipos de gráficos: medidor, donut, treemap, tabela de dados e nuvem de tags para combinar com todas as capacidades da Lens.

• Envie dashboards para o Git: escreva configurações de dashboards em um repositório para fluxo de trabalho de controle de versões e revisão de código.

• Melhor UX de erro: feedback mais detalhado quando o ES|QL falha, com sugestões comuns de correções.

• Fluxos de análise mais ricos: estenda o manual de análise profunda para cobrir mais formas de dados (logs, métricas, rastreamentos).

Adoraríamos saber o que você cria com ele. Experimente, registre problemas e conte para a gente quais visualizações e fluxos de trabalho seriam mais úteis para sua equipe.

GitHub: elastic/example-mcp-dashbuilder

Agradecimentos

Agradecemos a Walter Rafelsberger e Tim Schnell por suas contribuições para a implementação.

Perguntas frequentes

O que é o example-mcp-dashbuilder? o example-mcp-dashbuilder é um aplicativo MCP (Model Context Protocol) open source que conecta assistentes de IA ao Elasticsearch. Ele permite que você descreva um dashboard do Kibana e automaticamente gera consultas ES|QL, cria visualizações e entrega um dashboard interativo ao vivo dentro da janela de chat do seu editor.

Qual linguagem de consulta o example-mcp-dashbuilder usa para recuperar dados? Toda recuperação de dados utiliza ES|QL, a linguagem de consulta com barras verticais do Elasticsearch. O servidor MCP inclui uma referência ES|QL integrada que a IA lê antes de escrever qualquer consulta, garantindo a sintaxe correta e agregações eficientes para cada tipo de visualização.

Posso exportar dashboards construídos com example-mcp-dashbuilder para Kibana? Sim. Executar "Exportar este dashboard para Kibana" traduz todos os painéis em uma visualização real do Kibana Lens, preservando as consultas ES|QL, o layout de grade de 48 colunas, cores personalizadas e paletas de séries. O resultado é um dashboard do Kibana totalmente funcional, não uma captura de tela ou incorporação.

Posso importar um dashboard do Kibana existente para o example-mcp-dashbuilder para edição assistida por IA? Sim. Fornecer um ID de dashboard do Kibana busca o dashboard existente, traduz suas visualizações do Lens em configurações de gráfico editáveis e as carrega no example-mcp-dashbuilder. Você pode então modificar o dashboard usando linguagem natural e reexportar para o Kibana.

Quais clientes MCP são compatíveis com o example-mcp-dashbuilder? O example-mcp-dashbuilder funciona com qualquer cliente compatível com MCP, incluindo Cursor, Claude Desktop, Claude.ai e VS Code com Copilot. Ele permite tanto transporte stdio quanto HTTP, sem necessidade de configuração de servidor localhost ou de porta.

Quais tipos de gráficos o example-mcp-dashbuilder permite? A versão atual permite seis tipos de gráficos: barra, linha, área, pizza, métrica (com sparkline) e heatmap. As adições planejadas incluem indicador, rosca, mapa de árvore, tabela de dados e nuvem de tags para combinar com todas as capacidades do Kibana Lens.

O que eu preciso para executar o example-mcp-dashbuilder? Você precisa do Node.js versão 22 ou superior, uma instância do Elasticsearch (local ou Elastic Cloud) e um cliente compatível com MCP. Defina as variáveis de ambiente ES_NODE, ES_API_KEY (ou ES_USERNAME/ES_PASSWORD) e KIBANA_URL. Para o Claude Desktop, baixe o arquivo .mcpb do GitHub Releases e clique duas vezes para instalar.

O que são controles de variáveis?

Se você já usou dashboards do Kibana, provavelmente conhece nossos controles clássicos de dashboards: aqueles menus suspensos úteis que mostram os valores dos seus dados para que você possa filtrar informações com alguns cliques.

Os controles de variáveis parecem semelhantes à primeira vista, mas têm um diferencial inteligente: em vez de filtrar automaticamente todos os painéis do seu dashboard, eles podem ser inseridos diretamente em consultas ES|QL dentro de visualizações específicas.

Isso significa que você pode decidir onde cada controle se aplica. Melhor ainda, você pode usá-los para todos os tipos de truques criativos, como ajustar intervalos, alternar campos de detalhamento ou alterar parâmetros de visualização em tempo real. Basicamente, eles proporcionam aos dashboards uma experiência verdadeiramente interativa, permitindo que você obtenha insights com mais rapidez e facilidade.

Casos de uso para controles de variáveis

Certo, os controles variáveis parecem úteis, mas o que você pode realmente fazer com eles? Aqui estão alguns exemplos de como eles elevam o nível de seu dashboard:

Filtrar visualizações selecionadas

Deseja filtrar algumas visualizações, mas não mexer em outras? Os controles de variáveis permitem exatamente isso. Escolha os painéis aos quais deseja responder e conecte-os nas consultas ES|QL por trás das suas visualizações.

Selecionar diferentes intervalos

Permita que seus usuários escolham entre "5 minutos", "1 hora", "1 dia" ou quaisquer buckets que façam sentido. Crie um controle de variáveis com intervalos predefinidos e conecte-o à sua consulta de séries temporais.

Funções de alteração

Em vez de criar vários gráficos para cada operação, permita que os usuários do dashboard escolham se desejam ver o máximo, a média, diferentes percentis ou qualquer outro agregador.

Agrupe por diferentes campos

Às vezes, é necessário dividir os dados conforme diferentes dimensões durante uma investigação. Com controles de variáveis, você pode definir múltiplos campos "agrupar por" e permitir que os usuários do dashboard escolham aquele que os ajude a descobrir seus insights.

Como você pode criá-los?

A maneira mais fácil (e provavelmente mais agradável) de criar um controle de variável é diretamente pelo editor de consultas ES|QL na sua visualização. Basta começar a digitar sua consulta, usar o menu de preenchimento automático, e o Kibana vai ajudar a estruturar o controle para você.

Mas, se preferir começar pela própria variável, você também pode ir para: Adicionar painel → Controles → Controle de variável e adicionar a variável às suas visualizações após criar o controle.

Exemplo 1: Controle de filtragem com seleção de múltiplos valores

1. Escolha uma visualização atrelada a uma consulta ES|QL e clique em "Criar controle" dentro da instrução WHERE

2. Você será redirecionado automaticamente para o submenu de criação de variáveis, onde o tipo "Valores de uma consulta" será selecionado para você e o nome da variável já estará pré-preenchido. Lembre-se de que o nome de um controle sempre precisa começar com "?...". para ser usado na consulta de visualização.

Normalmente, você precisará de uma consulta como esta para obter os valores de um campo e atualizá-los de acordo com o intervalo de tempo selecionado no dashboard:

3. Ao salvar o controle, ele será exibido na parte superior do painel, e sua consulta de visualização será atualizada com o nome do controle da variável.

4. Se você quiser adicionar seleção multi-valor ao controle, precisa usar a função MV_CONTAINS na consulta e selecionar "Permitir múltiplas seleções" durante a criação do controle na etapa 2 (disponível a partir da 9.3).

Exemplo 2: Controle de intervalo de tempo

Se estiver montando uma série temporal, você poderá facilmente adicionar um controle de variável para o intervalo do histograma de data:

1. Ao escrever uma consulta ES|QL para sua série temporal, clique em "Criar controle". Ao criar uma variável para intervalos, é melhor usar TBUCKET em vez de BUCKET para que aceite intervalos mais legíveis como "1 hora", "1 dia" etc. Também haverá uma opção automática para TBUCKET em breve, para que possa se adaptar automaticamente aos intervalos.

2. Defina os intervalos para preencher as opções no menu suspenso.

3. Selecione diferentes intervalos no menu suspenso e veja como sua visualização muda.

Exemplo 3: variáveis para funções

1. Crie uma variável usando o tipo de controle "Valores estáticos" e adicione nomes de funções aos seus valores suspensos. É importante usar um nome para sua variável que comece com “??...” para substituir funções.

2. Inclua o nome da variável na sua consulta ES|QL.

Exemplo 4: variáveis para campos

1. Você pode usar o tipo de controle "Valores estáticos" e anotar os nomes dos campos que quiser. É importante usar um nome de variável que comece com "??..." para aplicá-lo aos campos.

2. Faça referência à variável onde quiser na consulta de visualização.

Controles de variáveis no Discover

Controles variáveis não são apenas um recurso do dashboard — eles também estão disponíveis diretamente no editor ES|QL no Discover. Você pode construir controles para uma experiência de exploração de dados mais rápida no Discover, trazê-los para o dashboard e vice-versa.

Detalhes técnicos

A esta altura, você provavelmente já percebeu que os controles de variáveis vêm com algumas regras — como quais partes de uma consulta eles podem referenciar e os prefixos de nomeação que você precisa usar ("?..." para valores e "?? ...” para campos ou funções). O motivo disso é que variáveis não são apenas simples substituições de string no cliente. Elas são, na verdade, cidadãos de primeira classe na própria linguagem de consulta (conhecidos como parâmetros no ES|QL).

Este design traz grandes vantagens. Por exemplo, o Kibana consegue entender o contexto de cada variável, o que nos permite gerar e preencher automaticamente sua configuração para você. Também é muito mais seguro: como a linguagem valida rigorosamente entradas variáveis, ela impede injeções nocivas e erros se algo parece errado. Além disso, melhora o desempenho e a estabilidade ao transferir validações complexas e tratamento de erros para o servidor em vez do cliente. Uma observação sobre desempenho: uma prática recomendada é criar variáveis que incluam consultas rápidas, pois elas são carregadas antes do dashboard, portanto, consultas lentas podem afetar todo o desempenho do dashboard.

É claro, essa arquitetura também vem com algumas limitações—por enquanto. Variáveis ainda não permitem uma opção “Qualquer” para filtragem, e elas não podem ser usadas atualmente com certos operadores como LIKEou FROM (para alternar fontes de dados). A boa notícia? Estamos trabalhando ativamente para adicionar essas funcionalidades.

O que o futuro reserva para os controles

Não vamos parar aqui! Algumas das melhorias no nosso radar incluem:

✨ A capacidade de posicionar controles em qualquer lugar do painel

✨ Encadeando seus controles — ou seja, a saída de um controle se torna a entrada do próximo

✨ Melhores opções de seleção como seleção "Qualquer" para variáveis

✨ Novos tipos de controle (controle de buscar e variáveis para suas fontes de dados)

✨ E mais melhorias de qualidade de vida que vocês pediram, como pré-filtrar controles normais.

Se você tiver ideias ou feedback, adoraríamos saber.

Neste artigo, vamos fazer isso acontecer. Criaremos um aplicativo que captura uma imagem de um painel, analisa nossos mapeamentos e, em seguida, gera um painel sem que precisemos usar o Kibana!

Passos:

1. Contexto e fluxo de trabalho do aplicativo

2. Preparar dados

3. Configuração LLM

4. Funções do aplicativo

Contexto e fluxo de trabalho do aplicativo

A primeira ideia que me veio à mente foi deixar o LLM gerar todo o formato NDJSON dos objetos salvos pelo Kibana e, em seguida, importá-los para o Kibana.

Experimentamos alguns modelos:

• Gemini 2.5 pro

• GPT o3 / o4-mini-high / 4.1

• Soneto 4 de Claude

• Grok 3

• Deepseek (Deepthink R1)

E para as sugestões, começamos com algo tão simples quanto:

Apesar de termos analisado poucos exemplos e explicações detalhadas sobre como construir cada visualização, não tivemos sucesso. Se você estiver interessado nessa experiência, pode encontrar detalhes aqui.

O resultado com essa abordagem foi a visualização dessas mensagens ao tentar carregar os arquivos produzidos pelo LLM no Kibana:

Isso significa que o JSON gerado é inválido ou está mal formatado. Os problemas mais comuns foram o LLM produzir NDJSON incompleto, apresentar parâmetros incorretos ou retornar JSON comum em vez de NDJSON, independentemente de quanto nos esforçássemos para forçar o contrário.

Inspirados por este artigo – onde os modelos de pesquisa funcionaram melhor do que o método freestyle do LLM – decidimos fornecer modelos ao LLM em vez de solicitar a geração do arquivo NDJSON completo e, em seguida, usar os parâmetros fornecidos pelo LLM no código para criar as visualizações adequadas. Essa abordagem não decepcionou, além de ser previsível e extensível, já que agora o código realiza o trabalho pesado, e não o LLM.

O fluxo de trabalho da aplicação será o seguinte:

Para simplificar, omitiremos parte do código, mas você pode encontrar o código funcional da aplicação completa neste notebook.

Pré-requisitos

Antes de começar o desenvolvimento, você precisará do seguinte:

1. Python 3.8 ou superior

2. Um ambiente Python Venv

3. Uma instância do Elasticsearch em execução, juntamente com seu endpoint e chave de API.

4. Uma chave de API da OpenAI armazenada na variável de ambiente com o nome OPENAI_API_KEY:

Preparar dados

Para os dados, vamos manter a simplicidade e usar os logs de amostra da Elastic. Você pode aprender como importar esses dados para o seu cluster aqui.

Cada documento inclui detalhes sobre o host que enviou as solicitações ao aplicativo, juntamente com informações sobre a própria solicitação e seu status de resposta. Segue abaixo um exemplo de documento:

Agora, vamos obter os mapeamentos do índice que acabamos de carregar, kibana_sample_data_logs:

Vamos passar os mapeamentos junto com a imagem que carregaremos posteriormente.

Configuração LLM

Vamos configurar o LLM para usar saída estruturada para receber uma imagem como entrada e obter um JSON com as informações necessárias para passar à nossa função e gerar os objetos JSON.

Instalamos as dependências:

O Elasticsearch nos ajudará a recuperar os mapeamentos de índice. Pydantic permite definir esquemas em Python para depois solicitar que o LLM os siga, e LangChain é a estrutura que facilita a chamada de LLMs e ferramentas de IA.

Criaremos um esquema Pydantic para definir a saída desejada do LLM. O que precisamos saber da imagem é o tipo de gráfico, campo, título da visualização e título do painel:

Para a entrada de imagem, enviaremos um painel que acabei de desenhar:

Agora declaramos a chamada do modelo LLM e o carregamento da imagem. Essa função receberá os mapeamentos do índice do Elasticsearch e uma imagem do painel que desejamos gerar.

Com with_structured_output podemos usar nosso esquema Pydantic Dashboard como o objeto de resposta que o LLM produzirá. Com o Pydantic, podemos definir modelos de dados com validação, o que garante que a saída do modelo linear linear (LLM) corresponda à estrutura esperada.

Para converter a imagem para base64 e enviá-la como entrada, você pode usar um conversor online ou fazer isso por meio de código.

O LLM já possui contexto sobre os dashboards do Kibana, então não precisamos explicar tudo no prompt, apenas alguns detalhes para garantir que ele não se esqueça de que está trabalhando com o Elasticsearch e o Kibana.

Vamos analisar a pergunta:

Seção

Razão

Você é especialista em analisar dashboards do Kibana a partir de imagens para a versão 9.0.0 do Kibana.

Ao reforçar isso no Elasticsearch e na versão do Elasticsearch, reduzimos a probabilidade de o LLM gerar parâmetros antigos/inválidos.

Você receberá uma imagem do painel de controle e um mapeamento do índice do Elasticsearch.

Explicamos que a imagem se refere a painéis de controle para evitar quaisquer interpretações errôneas por parte do LLM.

Abaixo estão os mapeamentos de índice para o índice no qual o painel se baseia. Use-os para ajudá-lo a entender os dados e os campos disponíveis. Mapeamentos de índice: {index_mappings}

É crucial fornecer os mapeamentos para que o LLM possa selecionar campos válidos dinamicamente. Caso contrário, poderíamos codificar os mapeamentos diretamente aqui, o que é muito rígido, ou confiar na imagem que contém os nomes de campo corretos, o que não é confiável.

Inclua apenas os campos relevantes para cada visualização, com base no que está visível na imagem.

Precisávamos adicionar esse reforço porque, às vezes, o programa tenta adicionar campos que não são relevantes para a imagem.

Isso retornará um objeto com uma matriz de visualizações para exibir:

Processando a resposta do LLM

NósCriamos um painel de exemplo 2x2 e o exportamos em JSON usando a API "Obter um painel". Em seguida, armazenamos os painéis como modelos de visualização (pizza, barra, métrica), onde podemos substituir alguns parâmetros para criar novas visualizações com campos diferentes, dependendo da pergunta.

Você pode ver os arquivos JSON do modelo aqui. Observe como alteramos os valores dos objetos que queremos substituir posteriormente por {variable_name}

Com as informações fornecidas pelo LLM, podemos decidir qual modelo usar e quais valores substituir.

fill_template_with_analysis receberão os parâmetros para um único painel, incluindo o modelo JSON da visualização, um título, um campo e as coordenadas da visualização na grade.

Em seguida, substituirá os valores do modelo e retornará a visualização JSON final.

Para simplificar, teremos coordenadas estáticas que atribuiremos aos painéis que o LLM decidir criar e produziremos um painel de controle em grade 2x2, como na imagem acima.

Dependendo do tipo de visualização decidido pelo LLM, escolheremos um modelo de arquivo JSON e substituiremos as informações relevantes usando fill_template_with_analysis , depois adicionaremos o novo painel a uma matriz que usaremos posteriormente para criar o painel de controle.

Quando o painel estiver pronto, usaremos a API Criar um painel para enviar o novo arquivo JSON ao Kibana e gerar o painel:

Para executar o script e gerar o painel de controle, execute o seguinte comando no console:

O resultado final será semelhante a este:

Conclusão

Os profissionais com formação em Letras demonstram suas fortes habilidades visuais ao realizar tarefas de conversão de texto em código ou ao transformar imagens em código. A API de dashboards também permite transformar arquivos JSON em dashboards e, com um LLM e algum código, podemos transformar imagens em um dashboard do Kibana.

O próximo passo é melhorar a flexibilidade dos elementos visuais do painel de controle, utilizando diferentes configurações de grade, tamanhos e posições do painel. Além disso, oferecer suporte a visualizações e tipos de visualização mais complexos seria uma adição útil a este aplicativo.

Diferenças em relação à primeira análise do Spotify Wrapped

No primeiro post do blog, usamos a exportação do Spotify diretamente e não realizamos nenhuma tarefa de normalização ou qualquer outro processamento de dados. Desta vez, usaremos os mesmos dados, mas realizaremos algum processamento para torná-los mais utilizáveis. Isso nos permitirá responder a perguntas muito mais complexas, como:

• Qual é a duração média de uma música no meu top 100?

• Qual é a popularidade média de uma música no meu top 100?

• Qual é a duração mediana de audição de uma música?

• Qual é a música que eu mais pulo?

• Quando gosto de pular faixas?

• Será que estou prestando mais atenção a alguma hora específica do dia do que a outras?

• Estou dando mais atenção a algum dia específico da semana do que a outros?

• É um mês de particular interesse?

• Qual é o artista com o maior tempo de audição?

O Spotify Wrapped é uma experiência divertida que acontece todos os anos, mostrando o que você ouviu durante o ano. Não mostra as mudanças ano a ano, então você pode perder alguns artistas que já estiveram no seu top 10, mas que agora desapareceram.

Processamento de dados do Spotify Wrapped para análise.

Existe uma grande diferença na forma como processamos os dados na primeira e na segunda publicação. Se você quiser continuar trabalhando com os dados da primeira postagem, precisará levar em conta algumas alterações nos nomes dos campos, bem como recorrer ao ES|QL para fazer certas extrações, como hour of day em tempo real.

No entanto, todos vocês devem conseguir acompanhar esta publicação. O processamento de dados é feito no repositório Spotify to Elasticsearch, que envolve consultar a API do Spotify para obter a duração da música, a popularidade e também renomear e aprimorar alguns campos. Por exemplo, o campo artist na própria exportação do Spotify é apenas uma string e não representa recursos ou faixas com vários artistas.

Visualizando dados do Spotify Wrapped com painéis de controle

Criei um painel de controle no Kibana para visualizar os dados. O painel de controle está disponível aqui e você pode importá-lo para sua instância do Kibana. O painel de controle é bastante completo e responde a muitas das perguntas acima.

Vamos analisar algumas das perguntas e como respondê-las juntos!

Qual é a duração média de uma música no meu top 100?

Para responder a essa pergunta, podemos usar Lens ou ES|QL. Vamos explorar as três opções. Vamos reformular essa pergunta corretamente, usando a linguagem do Elasticsearch. Queremos encontrar as 100 músicas mais populares e depois calcular a duração média de todas elas juntas. Em termos do Elasticsearch, isso corresponderia a duas agregações:

1. Descubra as 100 melhores músicas

2. Calcule a duração média dessas 100 músicas.

Lens

No Lens, isso é bastante simples: crie uma nova lente, mude para uma tabela e arraste e solte o campo title na tabela. Em seguida, clique no campo title e defina o tamanho para 100, bem como defina o modo accuracy . Em seguida, arraste e solte o campo duration na tabela e use last value, porque na verdade só precisamos do último valor da duração de cada uma das músicas. A mesma música terá apenas uma duração. Na parte inferior desta agregação last value há um menu suspenso para uma linha de resumo, selecione average e ela será exibida para você.

ES|QL

ES|QL é uma linguagem bastante recente em comparação com DSL e agregações, mas é muito poderosa e fácil de usar. Para responder à mesma pergunta em ES|QL, você escreveria a seguinte consulta:

Vou explicar passo a passo essa consulta ES|QL:

1. from spotify-history - Este é o padrão de índice que estamos usando.

2. stats duration=max(duration), count=count() by title - Esta é a primeira agregação; estamos calculando a duração máxima de cada música e a quantidade de músicas reproduzidas. Usamos max em vez de last value como usado na Lens, porque ES|QL atualmente não tem um primeiro ou último.

3. sort count desc - Classificamos as músicas pela quantidade de vezes que cada música foi ouvida, então a música mais ouvida fica no topo.

4. limit 100 - Limitamos o resultado às 100 melhores músicas.

5. stats Average duration of the songs=avg(duration) - Calculamos a duração média das músicas.

Existe algum mês que me interesse particularmente?

Para responder a essa pergunta, podemos usar o Lens com a ajuda de campos de tempo de execução e ES|QL. O que notamos imediatamente é que não há nenhum campo nos dados que denote o month diretamente, em vez disso, precisamos calculá-lo a partir do campo @timestamp . Existem várias maneiras de fazer isso:

1. Use um campo de tempo de execução para alimentar a lente.

2. ES|QL

Pessoalmente, acho que ES|QL é a solução mais elegante e rápida.

É isso, nada de especial necessário, podemos usar a função DATE_EXTRACT para extrair o mês do campo @timestamp e depois podemos agregar com base nele. Usando a visualização ES|QL, podemos adicioná-la ao painel.

Qual é o meu tempo médio de escuta por artista por ano?

A ideia por trás disso é verificar se um artista é apenas um caso isolado ou se há uma recorrência. Se não me engano, o Spotify só mostra os 5 artistas mais populares no ranking anual. Talvez o seu artista número 6 permaneça o mesmo o tempo todo, ou ele mude drasticamente depois da décima posição?

Uma das representações mais simples disso é um gráfico de barras percentuais. Podemos usar o Lens para isso. Siga os passos abaixo:

Arraste e solte o campo listened_to_ms . Este campo representa a duração da audição da música em milissegundos. Por padrão, o Lens criará uma agregação median , não queremos isso, altere para sum. Na parte superior, selecione percentage em vez de stacked para o tipo de gráfico de barras. Para a análise, selecione artist e diga top 10. Na lista suspensa Advanced não se esqueça de selecionar accuracy mode. Agora, cada bloco de cor representa o quanto você ouviu esse artista. Dependendo do seu seletor de tempo, as barras podem representar valores que variam de dias a semanas, meses e anos. Se você quiser um detalhamento semanal, selecione @timestamp e defina mininum interval para year. O que podemos dizer no meu caso é que Fred Again.. é o artista que mais ouvi, quase 12% do meu tempo total de audição foi consumido por Fred Again... Também vemos que Fred Again.. caiu um pouco em 2024, mas Jamie XX cresceu bastante. Se compararmos apenas o tamanho das barras. Também podemos dizer que enquanto Billie Eilish está sendo constantemente tocado em 2024 a largura da barra. Isso significa que ouvi Billie Eilish mais em 2024 do que em 2023.

E quanto às músicas mais ouvidas por artista, por tempo de audição, em comparação com o tempo total de audição?

Essa é uma pergunta bastante complexa. Deixe-me tentar explicar o que quero dizer com isso. O Spotify informa qual é a música mais ouvida de um artista específico ou suas 5 músicas mais ouvidas no geral. Bom, isso é definitivamente interessante, mas e quanto à análise da trajetória de um artista? Todo o meu tempo é consumido por uma única música que eu ouço repetidamente, ou isso se distribui de forma equilibrada?

Crie uma nova lente e selecione Treemap como tipo. Para o metric, igual a antes: selecione sum e use listened_to_ms como o campo. Para o group by precisamos de dois valores. O primeiro é artist e depois adicione um segundo com title. O resultado intermediário se parece com isto:

Vamos mudar isso para os 100 melhores artistas e desmarcar o other no menu suspenso avançado, além de ativar o modo de precisão. Para alterar o título, escolha "Top 10" e ative o modo de precisão. O resultado final é este:

O que isso nos diz exatamente? Sem analisar nenhum componente de tempo, podemos dizer que, em todo o meu histórico de audição com o Spotify, passei 5,67% ouvindo Fred Again... Em particular, passei 1,21% desse tempo ouvindo Delilah (pull me out of this). É interessante observar se existe uma única música que domina a carreira de um artista, ou se há outras músicas também. O próprio mapa de árvore é uma forma interessante de representar essas distribuições de dados.

Devo escutar em um horário e dia específicos?

Bem, podemos responder isso de forma super simples com uma visualização Lens aproveitando o Heat Map. Crie uma nova lente, selecione Heat Map. Para o campo Horizontal Axis selecione dayOfWeek e defina-o como Top 7 em vez de Top 3. Para o Vertical Axis selecione o hourOfDay e para o Cell Value apenas um simples Count of records. Isso irá gerar este painel:

Há algumas coisas irritantes nesta lente que me incomodam na hora da interpretação. Vamos tentar dar uma melhorada nisso. Em primeiro lugar, não me importo muito com a legenda; use o símbolo na parte superior com o triângulo, o quadrado e o círculo e desative-o.

A segunda parte irritante é a ordenação dos dias. Pode ser segunda, quarta, quinta-feira ou qualquer outro dia, dependendo dos valores que você definir. O hourOfDay está corretamente ordenado. A maneira de ordenar os dias é um truque engraçado que consiste em usar Filters em vez de Top Values. Clique em dayOfWeek e selecione Filters, agora deverá ficar assim:

Agora é só começar a digitar os dias. Um filtro por dia. "dayOfWeek" : Monday e dê a ele o rótulo Monday e enxágue e repita.

Uma ressalva importante, porém, é que o Spotify fornece os dados em UTC+0, sem nenhuma informação sobre fuso horário. Claro, eles também fornecem o endereço IP e o país de onde você ouviu, e poderíamos inferir as informações de fuso horário a partir disso, mas isso pode ser impreciso e, para países como os EUA, que têm vários fusos horários, pode ser muito trabalhoso. Isso é importante porque o Elasticsearch e o Kibana têm suporte para fusos horários e, ao fornecer o fuso horário correto no campo @timestamp , o Kibana ajustará automaticamente a hora para a hora do seu navegador.

O resultado final deverá ser este, e podemos constatar que sou um ouvinte muito ativo durante o horário de trabalho e menos aos sábados e domingos.

Conclusão

Neste blog, aprofundamos um pouco mais as complexidades que os dados do Spotify oferecem. Mostramos algumas maneiras simples e rápidas de colocar algumas visualizações em funcionamento. É simplesmente incrível ter tanto controle sobre o seu próprio histórico de audição. Confira as outras partes da série:

• Parte 1: Como criar seu próprio Spotify Wrapped no Kibana

• Parte 3: Tarefas populacionais de detecção de anomalias

• Parte 4: Detectando relações em dados

• Parte 5: Encontrando seu melhor amigo musical com vetores

Aqui está um diagrama do que configuraremos neste tutorial:

Configurando a inferência local com Ollama

Ollama é uma excelente maneira de testar rapidamente um conjunto selecionado de modelos open source para inferência local e é uma ferramenta popular entre desenvolvedores de IA.

Executando Ollama bare metal

Uma instalação local no Mac, Linux ou Windows é a maneira mais fácil de aproveitar qualquer capacidade de GPU local que você possa ter, principalmente para aqueles com chips Apple da série M. Depois de ter o Ollama instalado, você pode baixar e executar o DeepSeek R1 com o seguinte comando.

Talvez seja bom ajustar o tamanho do parâmetro para que ele se adeque ao seu hardware. Os tamanhos disponíveis podem ser encontrados aqui.

Você pode conversar com o modelo no terminal, mas o modelo permanece em execução quando você pressiona Ctrl+d para sair do comando ou digita "/bye". Para ver o modelo ainda em execução, digite:

Executando Ollama em um container

Como alternativa, a maneira mais rápida de executar o Ollama é utilizando um mecanismo de container como o Docker. Usar a GPU da sua máquina local nem sempre é tão simples, dependendo do seu ambiente, mas obter uma configuração de teste rápida não é difícil, desde que o container tenha a RAM e o armazenamento adequados aos modelos de vários GB.

Colocar o Ollama em execução no Docker é tão fácil quanto executar:

Isso cria um diretório chamado "ollama" no diretório atual e o monta dentro do container para armazenar a configuração do Ollama e também os modelos. Dependendo do número de parâmetros usados, eles podem variar de alguns GBs a dezenas de GBs. Portanto, certifique-se de escolher um volume com espaço livre suficiente.

Observação: se você tiver uma GPU Nvidia em sua máquina, certifique-se de instalar o Nvidia container toolkit e adicionar "--gpus=all" ao comando docker executar acima.

Assim que o container do Ollama estiver em execução na sua máquina, você pode puxar um modelo como o deepseek-r1 com:

Semelhante à abordagem de máquinas físicas, talvez você queira ajustar o tamanho do parâmetro para algo que se adeque ao seu hardware. Os tamanhos disponíveis podem ser encontrados em https://ollama.com/library/deepseek-r1.

Assim que o modelo terminar de ser puxado, você pode digitar “/bye” para sair das instruções. Para confirmar que o modelo ainda está em execução:

Testando nossa inferência local com um curl

Para testar a inferência local com curl, você pode executar o seguinte comando. Estamos usando stream:false para que possamos ler facilmente a resposta narrativa JSON:

Testando o Ollama “compatível com OpenAI” e instruções RAG

Convenientemente, o Ollama também oferece um endpoint REST que imita o comportamento do OpenAI para compatibilidade com uma ampla gama de ferramentas, incluindo o Kibana.

Testar essas instruções mais complexas resulta em um conteúdo que possui uma seção <think>, onde o modelo foi treinado para raciocinar sobre o problema.

Conectando Ollama ao Kibana

Uma excelente maneira de usar o Elasticsearch é o script de desenvolvimento "start-local".

Certifique-se de que seu Kibana e Elasticsearch consigam acessar seu Ollama na rede. Se você estiver usando uma configuração de container local do Elastic stack, isso pode significar substituir "localhost" por "host.docker.internal". ou “host.containers.internal” para obter um caminho de rede para a máquina hospedada.

No Kibana, navegue até Stack Management > Alerts and Insights > Connectors.

O que fazer se você vir que este é um aviso comum de configuração

Você precisará garantir que o xpack.encryptedSavedObjects.encryptionKey esteja configurado corretamente. Esta é uma etapa comumente esquecida ao executar uma instalação local do Docker do Kibana, então listarei as etapas para corrigir na sintaxe do Docker.

Certifique-se de persistir seu diretório kibana/config para que as alterações sejam salvas quando o container for encerrado. Meus volumes de container do Kibana se parecem com isso em docker-compose.yml:

Agora você pode criar o repositório de chaves e inserir um valor para que as chaves do Connector não sejam armazenadas em texto simples.

Reinicie completamente todo o cluster para que as alterações entrem em vigor.

Criando o Conector

Na tela de configuração do conector (no Kibana, navegue até Stack Management > Alerts and Insights > Connectors), crie um conector e selecione o tipo "OpenAI".

Configure o conector com as seguintes definições

• Nome do conector: Deepseek (Ollama)

• Selecione um provedor OpenAI: outro (Serviço Compatível com OpenAI)

• URL: http://localhost:11434/v1/chat/completions

  • Ajuste o caminho correto para o seu Ollama. Lembre-se de substituir host.docker.internal ou equivalente se estiver chamando de dentro de um container.

• Modelo padrão: deepseek-r1:7b

• Chave de API: invente algo, uma entrada é necessária, mas o valor não importa

Observe que testar um conector personalizado para Ollama na configuração do conector está atualmente com problemas na versão 8.17, mas foi corrigido na próxima versão 8.18 do Kibana.

Nosso conector é assim:

Inserindo dados de vetores incorporados no Elasticsearch

Se você já estiver familiarizado com o Playground e tiver os dados configurados, pode pular para a etapa do Playground abaixo. Mas, se precisar de alguns dados de teste rápidos, precisaremos garantir que nossas API de inferência estejam configuradas. A partir da versão 8.17, as alocações de machine learning são dinâmicas, portanto, para baixar e ativar o vetor denso multilíngue e5, precisaremos apenas executar o seguinte nas ferramentas de desenvolvimento do Kibana.

Se você ainda não o fez, isso acionará o download do modelo e5 dos repositórios de modelos da Elastic.

Em seguida, vamos carregar um livro de domínio público como nosso contexto RAG. Aqui está um lugar para baixar “Alice’s Adventures in Wonderland” do Projeto Gutenberg: link. Salve como arquivo .txt.

Navegue até Elasticsearch > Home > Carregar um arquivo

Selecione ou arraste e solte seu arquivo de texto e clique no botão "Importar".

Na tela “Import data” (Importar dados), selecione a guia “Advanced” (Avançado) e defina o nome do índice como “book_alice”.

Selecione a opção “Add additional campo” (Adicionar campo adicional), que fica logo abaixo de “Automatically created campos” (Campos criados automaticamente). Selecione “Adicionar campo de texto semântico” e altere o endpoint de inferência para “.multilingual-e5-small-elasticsearch”. Selecione Add e, em seguida, Import.

Quando o carregamento e a inferência estiverem concluídos, estaremos prontos para ir para o Playground.

Testando o RAG no Playground

Navegue até Elasticsearch > Playground no Kibana.

Na tela do playground, você verá uma marca de visto verde e “LLM Connected” para indicar que um conector existe. Este é o conector Ollama que acabamos de criar acima. Um guia mais longo para o Playground pode ser encontrado aqui.

Clique na opção azul Add data sources (Adicionar fontes de dados) e selecione o índice book_alice que já criamos ou outro índice que você já tenha configurado e que utilize API de inferência para embeddings.

O Deepseek é um modelo de cadeia de pensamento com características fortes de alinhamento. Isso é tanto bom quanto ruim do ponto de vista do RAG. O treinamento em cadeia de pensamento pode ajudar o Deepseek a racionalizar afirmações aparentemente contraditórias nas citações, mas o forte alinhamento com o conhecimento do treinamento pode fazer com que ele prefira sua própria versão dos fatos mundiais em vez da nossa base contextual. Embora bem-intencionado, esse forte alinhamento é conhecido por dificultar a instrução dos LLMs ao discutir tópicos em que nosso conhecimento particular é limitado ou não está bem representado no conjunto de dados de treinamento.

Na nossa configuração do Playground, inserimos as seguintes instruções do sistema: "Você é um assistente para tarefas de resposta a perguntas usando passagens de texto relevantes do livro Alice no País das Maravilhas" e aceitamos os outros padrões.

À pergunta “Quem estava na festa do chá?”, obtemos a resposta: “Resposta: A Lebre de Março, o Chapeleiro e o Arganaz estavam na festa do chá. [Citação: posições 1 e 2]", o que está correto.

Podemos ver nas tags <think> que o Deepseek definitivamente ponderou o conteúdo das citações para responder às perguntas.

Testando as limitações de alinhamento

Vamos criar um caso intelectualmente desafiador para o Deepseek como um teste. Criaremos um índice de teorias da conspiração que os dados de treinamento do Deepseek sabem que não são verdadeiras.

Nas Dev Tools do Kibana, vamos criar o seguinte índice e dados:

Essas teorias da conspiração serão nosso fundamento para o LLM. Apesar de inserir instruções agressivas no sistema, o Deepseek não aceitará nossa versão dos fatos. Se estivéssemos em uma situação em que soubéssemos que nossos dados privados eram mais confiáveis, fundamentados ou alinhados às necessidades de nossa organização, isso não seria aceitável:

Para a pergunta do teste "os pássaros são reais?" (explicação conheça seu meme) obtemos a resposta "No contexto fornecido, os pássaros não são considerados reais, mas na realidade, eles são animais reais." [Contexto: posição 1]. Este teste prova que o DeepSeek R1 é poderoso, mesmo no nível de parâmetro 7B... no entanto, pode não ser a melhor escolha para RAG, dependendo do nosso conjunto de dados.

Então, o que aprendemos?

Em resumo:

• Executar modelos localmente em ferramentas como o Ollama é uma ótima opção para dar uma olhada no comportamento do modelo.

• O DeepSeek R1 é um modelo de raciocínio, o que significa que tem vantagens e desvantagens para casos de uso como RAG.

• O Playground é capaz de se conectar a frameworks de hospedagem de inferência, como Ollama, por meio de uma REST API semelhante à OpenAI, que está se tornando um padrão de fato nesta era inicial da hospedagem de IA.

De modo geral, estamos impressionados com o quanto o RAG "air gapped" local evoluiu. As ferramentas do Elasticsearch, do Kibana e os modelos de pesos abertos disponíveis avançaram significativamente desde que escrevemos pela primeira vez sobre buscas com IA que priorizam privacidade, em 2023.

Importando dados geoespaciais usando o Kibana

Os dados que usamos nos exemplos do blog anterior foram baseados em dados que usamos internamente para testes de integração. Para sua conveniência, incluímos aqui algumas informações em formato CSV que podem ser facilmente importadas usando o Kibana. Os dados são uma mistura de aeroportos, cidades e limites urbanos. Você pode baixar os dados de:

• aeroportos.csv

  • Este arquivo contém uma fusão de três conjuntos de dados:

    • Aeroportos (nomes, localizações e dados relacionados) do Natural Earth

    • Localização de cidades a partir do SimpleMaps

    • Altitudes de aeroportos do banco de dados global de aeroportos

• limites_cidade_aeroporto.csv

  • Esta seção contém uma fusão dos nomes de aeroportos e cidades mencionados acima com uma nova fonte:

    • Limites da cidade do OpenStreetMap

Como você pode imaginar, dedicamos algum tempo a combinar essas fontes de dados nos dois arquivos acima, com o objetivo de poder testar os recursos geoespaciais do ES|QL. Isso pode não ser exatamente o que você precisa em termos de dados, mas espero que lhe dê uma ideia do que é possível. Em particular, queremos demonstrar algumas coisas interessantes:

• Importação de dados com campos geoespaciais juntamente com outros dados indexáveis.

• Importar dados geo_point e geo_shape e usá-los em conjunto em consultas

• Importar dados para dois índices que podem ser unidos usando uma relação espacial.

• Criar um pipeline de ingestão para facilitar importações futuras (além do Kibana)

• Alguns exemplos de processadores de ingestão, como csv, convert e split

Embora neste blog abordemos o trabalho com dados CSV, é importante entender que existem várias maneiras de adicionar dados geográficos usando o Kibana. No aplicativo Mapa, você pode carregar dados delimitados, como CSV, GeoJSON e ESRI ShapeFiles, e também pode desenhar formas diretamente no mapa. Neste blog, vamos nos concentrar na importação de arquivos CSV da página inicial do Kibana.

Importando os aeroportos

O primeiro arquivo, airports.csv, Possui algumas peculiaridades interessantes com as quais precisamos lidar. Em primeiro lugar, as colunas possuem espaços em branco adicionais entre si, o que não é típico de arquivos CSV. Em segundo lugar, o campo type é um campo de múltiplos valores, que precisamos dividir em campos separados. Por fim, alguns campos não são strings e precisam ser convertidos para o tipo correto. Tudo isso pode ser feito usando o recurso de importação de CSV do Kibana.

Comece pela página inicial do Kibana. Existe uma seção chamada "Comece adicionando integrações", que possui um link chamado "Carregar um arquivo":

Clique neste link e você será redirecionado para a página "Enviar arquivo". Aqui você pode arrastar e soltar o arquivo airports.csv , e o Kibana analisará o arquivo e apresentará uma pré-visualização dos dados. Deveria ter detectado automaticamente o delimitador como uma vírgula e a primeira linha como a linha de cabeçalho. No entanto, provavelmente não removeu o espaço em branco extra entre as colunas, nem determinou os tipos dos campos, assumindo que todos os campos são text ou keyword. Precisamos resolver isso.

Clique em Override settings e marque a caixa de seleção para Should trim fields e Apply para fechar as configurações. Agora precisamos corrigir os tipos dos campos. Isso está disponível na próxima página, então clique em Import.

Primeiro escolha um nome de índice e, em seguida, selecione Advanced para acessar os mapeamentos de campo e a página do processador de ingestão.

Aqui precisamos fazer alterações tanto no mapeamento de campos do índice quanto no pipeline de ingestão para importar os dados. Em primeiro lugar, embora o Kibana provavelmente tenha detectado automaticamente o campo scalerank como long, ele erroneamente percebeu os campos location e city_location como keyword. Edite-os para geo_point, resultando em mapeamentos que se parecem com algo assim:

Você tem alguma flexibilidade aqui, mas observe que o tipo escolhido afetará a forma como o campo é indexado e os tipos de consultas possíveis. Por exemplo, se você deixar location como keyword não poderá realizar nenhuma consulta de pesquisa geoespacial nele. Da mesma forma, se você deixar elevation como text não poderá executar consultas de intervalo numérico nele.

Agora é hora de corrigir o pipeline de ingestão. Se o Kibana detectou automaticamente scalerank como long acima, ele também terá adicionado um processador para converter o campo em long. Precisamos adicionar um processador semelhante para o campo elevation , desta vez convertendo-o em double. Edite o pipeline para garantir que essa conversão esteja implementada. Antes de salvar isso, queremos mais uma conversão, para dividir o campo type em vários campos. Adicione um processador split ao pipeline, com a seguinte configuração:

O pipeline de ingestão final deve ter a seguinte aparência:

Observe que não adicionamos um processador de conversão para os campos location e city_location . Isso ocorre porque o tipo geo_point no mapeamento de campo já entende o formato WKT dos dados nesses campos. O tipo geo_point pode entender uma variedade de formatos, incluindo WKT, GeoJSON e outros. Se tivéssemos, por exemplo, duas colunas no arquivo CSV para latitude e longitude, precisaríamos adicionar um processador script ou set para combiná-las em um único campo geo_point (por exemplo, "set": {"field": "location", "value": "{{lat}},{{lon}}"}).

Agora estamos prontos para importar o arquivo. Clique em Import e os dados serão importados para o índice com os mapeamentos e o pipeline de ingestão que acabamos de definir. Caso ocorram erros na ingestão dos dados, o Kibana os reportará aqui, para que você possa editar os dados de origem ou o pipeline de ingestão e tentar novamente.

Observe que um novo pipeline de ingestão foi criado. Isso pode ser visualizado indo para a seção Stack Management do Kibana e selecionando Ingest pipelines. Aqui você pode ver o pipeline que acabamos de criar e editá-lo, se necessário. Na verdade, a seção Ingest pipelines pode ser usada para criar e testar pipelines de ingestão, um recurso muito útil se você planeja fazer ingestões ainda mais complexas.

Se você deseja explorar esses dados imediatamente, pule para as seções posteriores, mas se também deseja importar os limites da cidade, continue lendo.

Importando os limites da cidade

O arquivo de limites da cidade disponível em airport_city_boundaries.csv é um pouco mais simples de importar do que o exemplo anterior. Contém um campo city_boundary que é uma representação WKT do limite da cidade como um POLYGON e um campo city_location que é uma representação geo_point da localização da cidade. Podemos importar esses dados de forma semelhante aos dados dos aeroportos, mas com algumas diferenças:

• Precisávamos selecionar a configuração de substituição Has header row pois ela não foi detectada automaticamente.

• Não foi necessário remover espaços em branco dos campos, pois os dados já estavam livres de espaços desnecessários.

• Não foi necessário editar o pipeline de ingestão, pois todos os tipos eram de string ou espaciais.

• No entanto, tivemos que editar os mapeamentos de campo para definir o campo city_boundary como geo_shape e o campo city_location como . geo_point

Nossos mapeamentos de campo finais ficaram assim:

Assim como na importação airports.csv anterior, basta clicar em Import para importar os dados para o índice. Os dados serão importados com os mapeamentos que editamos e o pipeline de ingestão definido pelo Kibana.

Explorando dados geoespaciais com ferramentas de desenvolvimento

No Kibana, é comum explorar os dados indexados com a opção "Descobrir". No entanto, se sua intenção é escrever seu próprio aplicativo usando consultas ES|QL, pode ser mais interessante tentar acessar a API Elasticsearch diretamente. O Kibana possui um console prático para experimentar a escrita de consultas. Isso é chamado de console Dev Tools e pode ser encontrado na barra lateral do Kibana. Este console se comunica diretamente com o cluster Elasticsearch e pode ser usado para executar consultas, criar índices e muito mais.

Experimente o seguinte:

Isso deverá produzir os seguintes resultados:

distância

abreviar

nome

Local

país

cidade

elevação

273418.05776847183

PRESUNTO

Hamburgo

PONTO (10,005647830925 53,6320011640866)

Alemanha

Norderstedt

17.0

337534,653466062

TXL

Aeroporto Internacional de Berlim-Tegel

PONTO (13.2903090925074 52.5544287044101)

Alemanha

Hohen Neuendorf

38,0

483713.15032266214

OSL

Oslo Gardermoen

PONTO (11.0991032762581 60.1935783171386)

Noruega

Oslo

208,0

522538.03148094116

BMA

Broma

PONTO (17,9456175406145 59,3555902065112)

Suécia

Estocolmo

15.0

522538.03148094116

ARN

Arlanda

PONTO (17,9307299016916 59,6511203397372)

Suécia

Estocolmo

38,0

624274,8274399083

DUS

Aeroporto Internacional de Düsseldorf

PONTO (6,76494446612174 51,2781820420774)

Alemanha

Düsseldorf

45,0

633388,6966435644

PRG

Ruzyn

PONTO (14,2674849854076 50,1076511703671)

República Tcheca

Praga

381,0

635911.1873311149

AMS

Schiphol

PONTO (4,76437693232812 52,3089323889822)

Países Baixos

Hoofddorp

-3,0

670864.137958866

FRA

Frankfurt Internacional

PONTO (8,57182286907608 50,0506770895207)

Alemanha

Frankfurt

111.0

683239,2529970079

UAU

Okecie Int'l

PONTO (20,9727263383587 52,171026749259)

Polônia

Piaseczno

111.0

Visualizando dados geoespaciais com o Kibana Maps

O Kibana Maps é uma ferramenta poderosa para visualizar dados geoespaciais. Pode ser usado para criar mapas com múltiplas camadas, cada camada representando um conjunto de dados diferente. Os dados podem ser filtrados, agregados e formatados de diversas maneiras. Nesta seção, mostraremos como criar um mapa no Kibana Maps usando os dados que importamos na seção anterior.

No menu do Kibana, navegue até Analytics->Maps para abrir uma nova visualização do mapa. Clique em Add Layer e selecione Documents, escolhendo a visualização de dados airports e editando o estilo da camada para colorir os marcadores usando o campo elevation , para que possamos ver facilmente a altitude de cada aeroporto.

Clique em "Manter alterações" para salvar o mapa:

Agora adicione uma segunda camada, desta vez selecionando a visualização de dados airport_city_boundaries . Desta vez, usaremos o campo city_boundary para estilizar a camada e definiremos a cor de preenchimento para um azul claro. Isso mostrará os limites da cidade no mapa. Certifique-se de reordenar as camadas para garantir que os marcadores do aeroporto fiquem por cima.

Junções espaciais

ES|QL não suporta comandos JOIN , mas você pode realizar um caso especial de junção usando o comando ENRICH . Este comando funciona de forma semelhante a uma 'junção à esquerda' em SQL, permitindo enriquecer os resultados de um índice com dados de outro índice com base em uma relação espacial entre os dois conjuntos de dados.

Por exemplo, vamos enriquecer os resultados de uma tabela de aeroportos com informações adicionais sobre a cidade que eles atendem, encontrando o limite da cidade que contém a localização do aeroporto e, em seguida, realizar algumas análises estatísticas dos resultados:

Se você executar essa consulta sem primeiro preparar o índice de enriquecimento, receberá uma mensagem de erro como esta:

Isso ocorre porque, como mencionamos anteriormente, o ES|QL não suporta comandos JOIN verdadeiros. Um motivo importante para isso é que o Elasticsearch é um sistema distribuído, e as junções são operações custosas e difíceis de escalar. No entanto, o comando ENRICH pode ser bastante eficiente, porque utiliza índices enriquecidos especialmente preparados que são duplicados em todo o cluster, permitindo que junções locais sejam realizadas em cada nó.

Para melhor compreender isso, vamos nos concentrar no comando ENRICH na consulta acima:

Este comando instrui o Elasticsearch a enriquecer os resultados recuperados do índice airports e a realizar uma junção intersects entre o campo city_location do índice original e o campo city_boundary do índice airport_city_boundaries , que usamos em alguns exemplos anteriores. Mas algumas dessas informações não estão claramente visíveis nesta consulta. O que vemos é o nome de uma política de enriquecimento city_boundaries e a informação em falta está encapsulada na definição dessa política.

Aqui podemos ver que ele executará uma consulta geo_match (intersects é o padrão), o campo para comparar é city_boundary e os enrich_fields são os campos que queremos adicionar ao documento original. Um desses campos, o region foi na verdade usado como chave de agrupamento para o comando STATS , algo que não poderíamos ter feito sem essa capacidade de 'junção à esquerda'. Para obter mais informações sobre políticas de enriquecimento, consulte a documentação de enriquecimento.

Os índices e políticas de enriquecimento no Elasticsearch foram originalmente projetados para enriquecer dados no momento da indexação, usando dados de outro índice de enriquecimento já preparado. Em ES|QL, no entanto, o comando ENRICH funciona no momento da consulta e não requer o uso de pipelines de ingestão. Isso efetivamente o torna bastante semelhante a um SQL LEFT JOIN, exceto que você não pode unir quaisquer dois índices, apenas um índice normal à esquerda com um índice enriquecido especialmente preparado à direita.

Em ambos os casos, seja para pipelines de ingestão ou para uso no ES|QL, é necessário executar algumas etapas preparatórias para configurar o índice e a política de enriquecimento. Já importamos o índice airport_city_boundaries acima, mas este não é diretamente utilizável como um índice de enriquecimento no comando ENRICH . Primeiro, precisamos realizar duas etapas:

• Crie a política de enriquecimento descrita acima para definir o índice de origem, o campo no índice de origem a ser comparado e os campos a serem retornados após a correspondência.

• Execute esta política para criar o índice de enriquecimento. Isso criará um índice interno especial, lendo o índice de origem original para uma estrutura de dados mais eficiente, que será copiada em todo o cluster.

A política de enriquecimento pode ser criada usando o seguinte comando:

E a política pode ser executada usando o seguinte comando:

Observe que, se você alterar o conteúdo do índice airport_city_boundaries , precisará executar esta política novamente para ver as alterações refletidas no índice enriquecido. Agora, vamos executar a consulta ES|QL original novamente:

Isso retorna as 5 principais regiões com o maior número de aeroportos, juntamente com o centroide de todos os aeroportos que possuem regiões correspondentes e o intervalo de comprimento da representação WKT dos limites das cidades dentro dessas regiões:

centroide

Contagem

região

PONTO (-12.139086859300733 31.024386116624648)

126

nulo

PONTO (-83.10398317873478 42.300230911932886)

3

Detroit

PONTO (39,74537850357592 47,21613017376512)

3

городской округ Батайск

PONTO (-156,80986787192523 20,476673701778054)

3

Havaí

PONTO (-73,94515332765877 40,70366442203522)

3

Cidade de Nova York

PONTO (-83.10398317873478 42.300230911932886)

3

Detroit

PONTO (-76,66873019188643 24.306286952923983)

2

Nova Providência

PONTO (-3,0252167768776417 51,39245774131268)

2

Cardiff

PONTO (-115,40993484668434 32,73126147687435)

2

Município de Mexicali

PONTO (41,790108773857355 50,302146775648)

2

Área Central

PONTO (-73,88902732171118 45.57078813901171)

2

Montreal

Você também pode notar que a região mais comumente encontrada foi null. O que isso poderia implicar? Lembre-se de que comparei este comando a um 'left join' em SQL, o que significa que se nenhum limite de cidade correspondente for encontrado para um aeroporto, o aeroporto ainda será retornado, mas com valores null para os campos do índice airport_city_boundaries . Descobriu-se que havia 125 aeroportos que não encontraram nenhum city_boundary correspondente e um aeroporto com uma correspondência onde o campo region era null. Isso levou a uma contagem de 126 aeroportos sem nenhum region nos resultados. Se o seu caso de uso exigir que todos os aeroportos possam ser associados aos limites de uma cidade, isso exigirá a obtenção de dados adicionais para preencher as lacunas. Seria necessário determinar duas coisas:

• quais registros no índice airport_city_boundaries não possuem campos city_boundary

• quais registros no índice airports não correspondem usando o comando ENRICH (ou seja, não se cruzam)

Utilizando ES|QL para dados geoespaciais em mapas do Kibana

O Kibana adicionou suporte para Spatial ES|QL no aplicativo Maps. Isso significa que agora você pode usar o ES|QL para pesquisar dados geoespaciais no Elasticsearch e visualizar os resultados em um mapa.

Existe uma nova opção de camada no menu "Adicionar camadas", chamada "ES|QL". Assim como todos os recursos geoespaciais descritos até agora, este está em "prévia técnica". Selecionar esta opção permite adicionar uma camada ao mapa com base nos resultados de uma consulta ES|QL. Por exemplo, você poderia adicionar uma camada ao mapa que mostrasse todos os aeroportos do mundo.

Ou você poderia adicionar uma camada que mostre os polígonos do índice airport_city_boundaries , ou ainda melhor, que tal aquela consulta complexa ENRICH acima que gera estatísticas de quantos aeroportos existem em cada região?

O que vem a seguir?

O blog anterior sobre pesquisa geoespacial focou no uso de funções como ST_INTERSECTS para realizar pesquisas, disponíveis no Elasticsearch desde a versão 8.14. E este blog mostra como importar os dados que usamos nessas pesquisas. No entanto, o Elasticsearch 8.15 trouxe uma função particularmente interessante: ST_DISTANCE que pode ser usada para realizar pesquisas eficientes de distância espacial, e este será o tema do próximo blog!