Qué significa la compatibilidad con versiones anteriores para la API de Dashboards de Kibana

Durante la vista previa técnica, la forma de la API podría cambiar entre versiones.[1] Eso ya no es así. Disponibilidad general (GA) significa:

• Compatibilidad total con versiones anteriores. Con el tiempo, se agregarán nuevos campos y tipos de panel, pero los campos y el comportamiento actuales se mantendrán sin cambios. Cualquier cambio futuro que rompa la compatibilidad será considerado con mucho cuidado y solo se introducirá en una nueva versión principal del stack.

• Listo para producción con soporte completo. La API ofrece las garantías completas de soporte de Elastic. Puedes usarla de manera segura en entornos de producción para despliegues automatizados, promoción del entorno y administración programática del dashboard.

Nuevos endpoints de la API Kibana para los paneles de etiquetas, markdown y enlaces

Elastic 9.5 también introduce un nuevo endpoint independiente para etiquetas, que permite categorizar y filtrar paneles. Ahora puedes administrarlos mediante programación a través de endpoints CRUD dedicados, lo que facilita organizar paneles a gran escala en todos los entornos.

Los nuevos endpoints de paneles Markdown y Enlaces ya están disponibles en Serverless y llegarán en la próxima versión de la pila (9.6).

¿Qué tipos de paneles soporta la API de Kibana Dashboards?

La API de dashboards admite todos los paneles por valor en la versión 9.5 (los definidos directamente en un dashboard, a diferencia de los paneles de biblioteca guardados para su reutilización). Cada tipo de panel admitido tiene un esquema tipificado y validado.

Tipo de panel

Estado

Gráficos XY

Con soporte

Métricas

Con soporte

Circular

Con soporte

Calibre

Con soporte

Mapa de calor

Con soporte

Tablas de datos

Con soporte

Mapa de árbol

Con soporte

Sesiones de Discover

Con soporte

Controles

Con soporte

Markdown

Con soporte

Enlaces

Con soporte

Paneles de ML

Con soporte

Paneles de Observability

Con soporte

Mapas

Próximamente

Vega

Próximamente

Cómo gestionar los dashboards de Kibana como código

La API de dashboards permite un flujo de trabajo completo de dashboards como código: exportar un dashboard como JSON limpio y diferenciable, hacer commit en Git como fuente de verdad, revisar los cambios en pull requests, y desplegar la misma definición en desarrollo, staging y producción. Una vez que un dashboard se administra como código, trata a Git como la única fuente de verdad: los cambios efectuados directamente en la UI se sobrescriben la próxima vez que despliegues.

El principal desafío al mover un dashboard entre espacios, clústeres o etapas es que los dashboards hacen referencia a objetos como Data view y visualizaciones de biblioteca mediante un ID. Debido a que estos ID se generan automáticamente y difieren de un entorno a otro, un dashboard exportado desde un entorno puede apuntar a objetos que no existen en otro. Hay tres formas de manejarlo, enumeradas aquí de la más a la menos automatizada:

• Usa Terraform. El proveedor Elastic Stack Terraform rastrea cada recurso y mapea automáticamente los ID por entorno, por lo que las referencias se mantienen estables mientras promocionas un dashboard desde el desarrollo hasta la producción.

• Definir por valor Paneles de lenguaje de búsqueda de Elasticsearch (ES|QL). La forma más portátil de construir un panel es definir su visualización con ES|QL directamente en el dashboard. Una consulta ES|QL lee los índices que se especifican en ella, por lo que el panel no contiene referencias externas a vistas de datos ni a objetos de biblioteca. El resultado es un dashboard totalmente autónomo y portátil.

• Asigna ID coincidentes. Si haces referencia a objetos guardados, como Data view o visualizaciones de biblioteca, créalos con un ID elegido usando PUT (upsert) en lugar de POST (que genera automáticamente un ID). Emplea ID legibles por humanos, como logs-prod, para que sean fáciles de reutilizar y reconocer en diferentes entornos.

Para un recorrido detallado de estos patrones de portabilidad y del flujo de trabajo completo de dashboards como código, consulta la documentación de Gestionar dashboards como código.

Crea un dashboard de Kibana con la API de dashboards usando PUT

Aquí hay un ejemplo rápido de crear un dashboard con un panel métrico usando PUT en lugar de POST para asignar un ID personalizado usando el nombre del dashboard (service-health-overview). La misma lógica funciona para crear visualizaciones independientes guardadas en la biblioteca.

Roadmap de la API de paneles de Kibana: Maps, Vega y endpoints independientes

Estamos ampliando activamente el alcance de la API. El siguiente paso es agregar compatibilidad con mapas y paneles Vega, incluyendo esquemas tipados para ellos. También estamos creando endpoints CRUD independientes para las sesiones de Discover (más allá de su compatibilidad actual como paneles del dashboard), Vega, Maps y Anotaciones, desacoplados del ciclo de vida del dashboard.

Para las definiciones completas de esquemas, visita la documentación de la API de Dashboards. Para los usuarios de Terraform, el proveedor Terraform de Elastic Stack es compatible con la API GA Dashboards.

Nota

1. Los endpoints de núcleo no han cambiado desde la vista previa técnica. Si construiste integraciones contra 9.4, funcionan en 9.5. Los únicos cambios incompatibles son dos menores que afectan al listado del dashboard y a los formatos de unidades de duración, documentados aquí.

Novedades en la creación del dashboard de IA de Kibana

Capacidad

Vista previa técnica (9.4)

GA (9.5)

Manejo de errores

No se permiten reintentos en consultas ES|QL fallidas

Reintento automático hasta tres veces con inspección y ajuste de consultas

Costo de generación de ES|QL

Todas las consultas enrutadas a través del modelo principal

Enrutamiento por niveles, hasta 5 veces más económico

Intervalo de tiempo

Ventana predeterminada fija

Selección automática basada en la distribución temporal de los datos

Controles de filtro

Sin soporte

Se agrega automáticamente para los campos más relevantes

Gráficos de Vega-Lite

Sin soporte

Creación en lenguaje natural, incluyendo gráficos de dispersión, gráficos de caja, formato condicional, sugerencias de herramientas personalizadas

Edición de gráficos

Sin soporte

Edita paneles Vega-Lite existentes a través del lenguaje natural

Recuperación automática de errores para la generación del dashboard de IA

En la versión preliminar técnica, el agente no volvió a intentar las consultas ES|QL fallidas. En la versión 9.5, detecta errores de consulta y vuelve a intentarlo hasta tres veces, inspeccionando cada error y ajustando la consulta antes de darte por vencido. En la práctica, esto elimina la mayoría de los problemas de paneles vacíos y produce dashboards que se renderizan correctamente en el primer intento.

¿Por qué es más barato crear dashboards con IA en Elastic 9.5?

No todos los pasos en la generación del dashboard requieren el mismo nivel de razonamiento. En la versión 9.5, la generación de ES|QL emplea un modelo más ligero de manera predeterminada y solo recurre al modelo principal cuando es necesario. Si tu conector emplea Claude Opus 4.8 de Anthropic, eso significa que la generación de ES|QL será 5 veces más económica en todos los paneles.

Selección automática de intervalos de tiempo basada en tus datos

Los dashboards solo son útiles cuando muestran la ventana de datos correcta. El agente ahora aplica una lógica mejorada para elegir un intervalo de tiempo que tenga sentido para los datos que está consultando, a menos que el usuario solicite un intervalo de tiempo específico. Considera la distribución temporal de los datos y ajusta en consecuencia, ya sea la última hora para un incidente en tiempo real o los últimos 90 días para un análisis de tendencias, en lugar de recurrir de manera predeterminada a una ventana fija.

Control automático de filtros en dashboards generados por IA

La creación de dashboards ahora admite controles; es decir, filtros interactivos que permiten a los usuarios refinar un dashboard por valores de campo sin editar las consultas subyacentes. Al generar un dashboard, el agente agrega automáticamente controles en la parte superior para los campos más relevantes para filtrar.

Gráficos Vega-Lite de lenguaje natural: tipos de gráficos y formato más allá de los valores predeterminados

Vega y Vega-Lite admiten una amplia variedad de tipos de gráficos y personalizaciones en Kibana. Con 9.5, puedes construirlos a partir de un lenguaje sencillo en lugar de escribir el código tú mismo. 

Gráficos de dispersión, gráficos de caja y más tipos de gráficos Vega-Lite

Los diagramas de dispersión, diagramas de caja, múltiplos pequeños facetados, gráficos de burbujas y diagramas de composición (como combinar histogramas con mapas de calor), entre muchos otros, se admiten en Vega-Lite. Una indicación como Muéstrame un gráfico de dispersión del tiempo de respuesta frente al tamaño de la solicitud, coloreado por nombre de servicio, produce un panel Vega-Lite con los mapeos de datos correctos. Usan las paletas de colores predeterminadas de Kibana para combinarse con el resto del dashboard.

Formato condicional, información sobre herramientas personalizadas y etiquetas en gráficos estándar

Incluso para tipos de gráficos que ya son nativos de los dashboards, como barra, línea o área, a veces necesitas más control del que ofrecen las capacidades predeterminadas. Vega-Lite, a través del chat, cubre esa necesidad. Algunos ejemplos incluyen:

• Formato de color condicional: colorea los puntos de datos por encima de un umbral de manera diferente; por ejemplo, marca en rojo los puntos de datos en una línea o barras cuando alguna métrica supera tu objetivo de nivel de servicio (SLO). Pregúntale al agente algo como Marca en rojo cualquier punto por encima de 500 ms para mi gráfico de líneas.

  

• Marcas y etiquetas personalizadas: agrega emojis, símbolos o etiquetas de texto en línea a los puntos de datos para obtener indicadores de estado de un vistazo.

  

• Información sobre herramientas personalizada: enriquece los estados del cursor con métricas adicionales, contexto o valores calculados que no forman parte de los ejes del gráfico. Pregunta algo como Agrega una descripción emergente que muestre el total de registros y el porcentaje por barra.

  

Esto también funciona para editar gráficos de Vega existentes. Si tienes un panel Vega-Lite que necesita un ajuste como cambiar una escala de color, ajustar un eje o cambiar el tipo de marca, describe el cambio en el chat en lugar de indagar en el código JSON.

Cómo construimos la generación en lenguaje natural de Vega-Lite en Kibana

Generar un gráfico Vega-Lite a partir de una oración no es una simple indicación de solicitud JSON al modelo. Construimos un pequeño pipeline agéntico que convierte la intención del lenguaje natural en un gráfico validado y respaldado por datos.

Cuando llega una solicitud, el agente primero determina si Vega-Lite es la opción adecuada. Para las solicitudes de Vega-Lite, establece la visualización en una consulta ES|QL real contra Elasticsearch y luego usa un modelo para generar el código Vega-Lite. Antes de renderizar, el resultado pasa por una capa de normalización que corrige el esquema y vincula la consulta canónica. También aplica transformaciones de seguridad de renderizado.

Algunas decisiones de diseño hacen que este flujo de trabajo sea confiable:

• Llamadas a herramientas tipificadas: la creación de gráficos es una invocación de herramienta estructurada en lugar de Vega-Lite de forma libre pegada en la conversación.

• Generación con restricciones: el modelo genera código Vega-Lite dentro de un esquema definido, haciendo que la salida sea más previsible y fácil de validar.

• Ejemplos seleccionados: los patrones estructurales, como el facetado, las marcas superpuestas y los mapas de calor, proporcionan orientación sin copiar los datos subyacentes.

• Ejecutar y verificar bucles: las consultas se ejecutan antes de la creación de gráficos y los errores de validación desencadenan reintentos correctivos para la generación de ES|QL.

Prueba la creación de dashboard con IA y gráficos Vega-Lite en Kibana

Para probar la creación de dashboards en lenguaje natural y gráficos Vega-Lite, actualiza a Elastic 9.5 (o inicia una prueba gratis), y abre el chat en Kibana. Luego pídele que cree un dashboard a partir de tus datos. Para Vega-Lite, intenta pedir un tipo de gráfico que hayas querido pero que nunca hayas construido, como un diagrama de dispersión o un gráfico de burbujas. Si el resultado no es del todo correcto, dile al agente qué cambiar. El agente itera contigo.

Esto requiere una licencia Empresarial. Comencemos.

El lanzamiento y el momento de cualquier característica o funcionalidad descrita en esta publicación quedan a exclusivo criterio de Elastic. Es posible que alguna característica o funcionalidad que no esté disponible en este momento no se lance a tiempo o no se lance en absoluto.

Cada año, los desastres naturales obligan a los gestores de emergencias, comandantes militares y oficiales de seguridad pública a tomar decisiones críticas en plazos ajustados. Estas decisiones suelen depender de cadenas de llamadas, hojas de cálculo y conocimiento institucional distribuido entre decenas de personas. La coordinación por sí sola consume un tiempo valioso.

Esta publicación demuestra cómo Elastic puede potenciar un sistema de coordinación agéntico con capacidad de respuesta ante desastres, que detecta amenazas, analiza la logística y actúa automáticamente. Para hacerlo concreto, creamos una simulación: un huracán ficticio de categoría 4 que amenaza la costa de Hampton Roads desencadena la reubicación automatizada de más de 137 000 personas en siete instalaciones militares.

Descargo de responsabilidad: Este es un escenario totalmente ficticio creado con fines de demostración. El huracán ELARA-26 no existe. Las ubicaciones de las instalaciones se basan en datos geográficos reales y disponibles públicamente (el set de datos Military Installations, Ranges, and Training Areas [MIRTA] del Departamento de Defensa de los EE. UU. [DoD]), pero todos los datos operativos, como el recuento de personal, la capacidad de alojamiento, los activos, los correos electrónicos de contacto y los perfiles de misión, son completamente ficticios. Nada en esta demostración refleja la preparación, la capacidad o los procedimientos operativos militares reales.

Por qué la respuesta automatizada ante desastres requiere coordinación geoespacial y agéntica

Cuando un desastre natural amenaza la infraestructura crítica, el desafío de coordinación es inmediato:

• ¿Qué instalaciones están en la zona de impacto?

• ¿Cuánto personal necesita trasladarse?

• ¿A dónde pueden ir? ¿Esas instalaciones tienen capacidad?

• ¿A quién se necesita notificar en este momento?

Estas preguntas no esperan. Tampoco deberían hacerlo las respuestas.

Despliega el pipeline: requisitos previos y configuración

Sigue las instrucciones aquí en el repositorio de ejemplo para desplegar un cluster local de Elastic con Elastic Inference Service (EIS) mediante Cloud Connect.

Cómo funciona el pipeline de respuesta ante desastres con agentes de Elasticsearch

El pipeline tiene siete capas que trabajan juntas de extremo a extremo:

1. Ingesta de datos: eventos de desastres del Sistema Mundial de Alerta y Coordinación de Desastres (GDACS) enviados a Elasticsearch

2. Pipeline de ingesta: GeoJSON se ingesta y normaliza a Elastic Common Schema (ECS).

3. Enriquecimiento geoespacial: el polígono del área afectada del evento se compara con los límites indexados de las instalaciones militares.

4. Alerting: una regla de detección de Kibana se activa cuando un desastre interseca cualquier instalación.

5. Automatización de flujos de trabajo: la alerta activa un flujo de trabajo de Kibana que inicia una conversación con un agente de AI.

6. Razonamiento de AI: el agente analiza las instalaciones afectadas, sus activos y las instalaciones de apoyo más cercanas para determinar cómo reubicar todos los activos y al personal.

7. Notificaciones por correo electrónico: el agente envía correos electrónicos a todos los destinatarios sobre la llegada y salida de personal o activos.

Revisemos cada capa.

Paso 1: indexar instalaciones militares con límites geográficos

La base es el set de datos MIRTA del DoD de source.coop/seerai/hifld. Este set de datos proporciona un geo_shape de tipo Point para cada instalación; coordenadas de centroide en lugar de polígonos de límites completos.

Cada documento de instalación en el índice mitra-facilities se enriquece con datos de perfil operativo (todos ficticios), más allá de lo que proporciona MIRTA:

Este índice enriquecido es lo que le permite al agente de AI tomar decisiones inteligentes de asignación; no solo “aquí hay bases cercanas”, sino “aquí hay bases con capacidad de alojamiento disponible, tipos de misión compatibles y la logística para recibir activos entrantes”.

Paso 2: ingestar y normalizar eventos de GDACS

GDACS publica GeoJSON en tiempo real para terremotos, ciclones tropicales, inundaciones, incendios forestales, volcanes y sequías. Ingestamos este feed en un flujo de datos (logs-gdacs.events-*) mediante un pipeline de ingesta personalizado que normaliza el GeoJSON sin procesar a campos de ECS.

El pipeline de ingesta de GDACS hace varias cosas que vale la pena destacar:

Extracción de geometría: el centroide se almacena como geo_point para la visualización en mapas, y el polígono de impacto se almacena como geo_shape en gdacs.affected_area, que es el campo que se utiliza para búsquedas de intersección más adelante.

Normalización de la gravedad: cada tipo de desastre tiene una escala de gravedad diferente. Un ciclón tropical se mide en velocidad del viento en km/h; un terremoto, en magnitud de Richter. El pipeline los mapea a todos a una puntuación normalizada de 0–100:

Luego, la puntuación de gravedad normalizada se mapea a una etiqueta severity_level (low, medium, high, critical) utilizada para el mapeo de gravedad de las alertas en la regla de detección.

Alineación con ECS: event.kind: alert, event.category: threat, marcas de tiempo asignadas a event.start/event.end, y un _id estable basado en una huella digital para la deduplicación.

Paso 3: enriquecimiento geoespacial: búsqueda de instalaciones afectadas al momento de la indexación

La política de enriquecimiento geo_match de Elasticsearch compara el polígono del desastre con el límite de cada instalación al momento de la indexación, sin necesidad de una unión en tiempo de búsqueda. En lugar de consultar durante la búsqueda, usamos un procesador de enriquecimiento en el pipeline de ingesta para comparar el polígono de impacto del desastre con el límite de cada instalación a medida que se indexa el documento.

La política de enriquecimiento es una política geo_match:

El procesador se ejecuta al final del pipeline de ingesta:

INTERSECTS detecta cualquier instalación cuyo límite toque o se superponga con el polígono de desastre, incluidas las intersecciones parciales. El resultado es que cada documento de evento de GDACS se almacena con un arreglo anidado affected_facilities que nos indica exactamente qué instalaciones se encuentran en la zona de impacto. No se necesita una búsqueda de unión.

Paso 4: regla de detección: alertas sobre el impacto en las instalaciones

Una regla de detección de Kibana monitorea el flujo de datos logs-gdacs.events-* y se activa cuando un evento de GDACS se ha enriquecido con información sobre al menos una instalación afectada:

La regla se ejecuta cada hora (cubre un intervalo de now-1h a now) y usa un mapeo dinámico de gravedad; el campo gdacs.severity_level calculado por el pipeline de ingesta determina automáticamente la gravedad de la alerta.

La gravedad de la alerta también determina la puntuación de riesgo mediante el mapeo de campos:

Cuando la regla se activa, envía todo el contexto de la alerta, incluido el arreglo enriquecido affected_facilities con los nombres, tipos y ubicaciones de las instalaciones, a un flujo de trabajo de Kibana para su procesamiento posterior.

Paso 5: automatización del flujo de trabajo: conectar la alerta con el agente

Los flujos de trabajo de Kibana gestionan la transferencia de la detección a la respuesta. El flujo de trabajo de respuesta ante desastres naturales se activa mediante la alerta:

Toda la carga útil de la alerta (tipo de desastre, gravedad, área afectada y la lista de instalaciones afectadas) se reenvía al agente de AI como contexto inicial. El agente se encarga del resto.

Paso 6: el agente de AI: de los datos a la acción coordinada

El agente mitra.response toma la carga útil completa de la alerta y, en un único ciclo agéntico, evalúa el alcance, encuentra instalaciones receptoras, asigna personal y envía notificaciones de evacuación y recepción, todo sin intervención humana.

El agente tiene dos herramientas disponibles:

• mitra.nearest_facilityrealiza una búsqueda en el índice mitra-facilities mediante una búsqueda geo_shape, ordenada por distancia desde una coordenada dada, y devuelve hasta 50 instalaciones activas cercanas con capacidad disponible.

• mitra.send_email itera sobre una arreglo JSON de objetos de instalaciones y envía notificaciones de evacuación o recepción con formato.

El conjunto de instrucciones del agente define un flujo de trabajo claro:

1. Evalúa la situación. Parsea la alerta, identifica las instalaciones afectadas y determina el alcance del desastre.

2. Haz un inventario de lo que se debe mover. Recuentos de personal, activos críticos, requisitos de alojamiento por instalación.

3. Encuentra instalaciones de destino. Invoca a mitra.nearest_facility para cada instalación afectada, sin incluir las que aún están en la zona de peligro.

4. Toma decisiones de asignación. Analiza soluciones que involucren una o varias instalaciones, la compatibilidad entre ramas de las fuerzas armadas, la capacidad de alojamiento y el apoyo para los activos.

5. Envía correos electrónicos de coordinación. Envía órdenes de evacuación a las instalaciones de origen y notificaciones de recepción a las instalaciones receptoras.

6. Genera un reporte resumido. Genera un breve resumen de todas las instalaciones afectadas, el total de personal, los activos trasladados, las instalaciones de destino y cualquier inquietud en el chat para su revisión.

La lógica de asignación del agente sigue restricciones del mundo real: no exceder la capacidad de alojamiento, dar preferencia a las reubicaciones dentro de la misma rama de las fuerzas armadas cuando sea posible, usar bases conjuntas para alojar al personal de distintas ramas que exceda la capacidad de otras instalaciones y priorizar la distancia para minimizar el tiempo de traslado.

La herramienta de instalación más cercana

La búsqueda subyacente del flujo de trabajo usa geo_shape con un filtro de círculo y ordenamiento por _geo_distance:

La capacidad disponible se calcula en el momento de la búsqueda mediante un campo de script que calcula la capacidad de alojamiento menos el recuento de personal actual. El agente usa esto para asignar personal entre destinos sin exceder los límites.

Huracán ELARA-26: coordinación agéntica de 137 000 efectivos, de extremo a extremo

El huracán ELARA-26 es una tormenta de categoría 4 (vientos máximos de 213 km/h) que se prevé que toque tierra en el área de Hampton Roads de Virginia. Cuando se ingiere el evento de GDACS, el polígono del área afectada interseca siete instalaciones militares principales de la región. La regla de detección se activa. El flujo de trabajo inicia una conversación del agente.

Dentro de un solo ciclo agéntico, el agente:

• Identificó siete instalaciones en la zona de impacto, con un total combinado de 137 372 miembros del personal.

• Llamó a mitra.nearest_facility para encontrar instalaciones receptoras fuera de la trayectoria de la tormenta.

• Distribuyó al personal entre nueve instalaciones receptoras en función de la capacidad de alojamiento disponible y la distancia.

• Generó y despachó órdenes de evacuación a las siete instalaciones afectadas.

• Generó y despachó notificaciones de recepción a las nueve instalaciones receptoras.

• Generó un resumen completo de coordinación, similar al siguiente:

Instalaciones evacuadas:

Instalación

Personal

Naval Station Norfolk

50 000

Joint Expeditionary Base Little Creek-Fort Story

18 000

Naval Air Station Oceana

15 355

Naval Air Station Oceana Dam Neck Annex

17 509

NG State Military Reservation Camp Pendleton

9707

Joint Base Langley-Eustis

15 000

Naval Weapons Station Yorktown

11 801

Instalaciones receptoras:

Instalación

Distancia

Personal entrante

Fort Gregg-Adams

97 km

~40 000

Marine Corps Base Quantico

148 km

~30 000

Naval Support Facility Indian Head

151 km

~30 000

Joint Base Andrews

180 km

~30 000

Naval Air Station Patuxent River

141 km

~10 000

NG MTA Camp Butner

174 km

~5000

NG Bethany Beach Training Site

209 km

~4707

Rivanna Station

140 km

~7500

Def Gen Supply Center

22 km

~6000

Los activos reubicados incluyen vehículos de transporte, helicópteros, lanchas patrulleras, unidades médicas, vehículos de ingeniería, generadores, remolques de agua, kits de refugio y sistemas de comunicación.

Notificaciones por correo electrónico automatizadas

Una vez que el agente finalizó su plan de asignación, invocó a mitra.send_email y envió 16 correos electrónicos en una sola pasada; es decir, órdenes de evacuación a las siete instalaciones afectadas y notificaciones de recepción a las nueve instalaciones receptoras. Cada mensaje incluía la instalación de destino, el recuento de personal entrante, los activos por trasladar y un contacto de coordinación. Lo que habría requerido horas de cadenas de llamadas se completó automáticamente en cuanto el agente terminó de razonar.

Ampliación de la respuesta agéntica ante desastres con RAG y fundamentación en políticas

Esta demostración se basa exclusivamente en datos estructurados, como cifras de capacidad, distancias y estado operativo. Las funcionalidades de búsqueda semántica y Retrieval Augmented Generation (RAG) de Elastic pueden hacer que el agente sea significativamente más inteligente, con dos adiciones:

Recuperación de respuestas históricas: indexa reportes posteriores a la acción, resúmenes de incidentes de la Agencia Federal para el Manejo de Emergencias (FEMA) y registros de respuesta ante desastres anteriores como incrustaciones vectoriales. Cuando se activa un evento nuevo, el agente puede recuperar semánticamente cómo se gestionaron eventos similares, lo que fundamenta las decisiones de asignación con conocimiento institucional en lugar de basarse únicamente en cálculos de capacidad.

Fundamentación en políticas y doctrina: indexa las directivas de gestión de emergencias del DoD, los planes de continuidad de las operaciones de la instalación y las directrices del comandante. El agente puede recuperar y citar las políticas reales que rigen una respuesta, lo que garantiza que cada decisión esté fundamentada en la doctrina en lugar de en inferencias.

Ambos siguen el mismo enfoque nativo de Elastic: un pipeline de inferencia genera incrustaciones al momento de la indexación, y se expone una herramienta de búsqueda semántica al agente. El pipeline de coordinación permanece igual. El agente simplemente se vuelve más inteligente.

Por qué Elasticsearch es la plataforma adecuada para la respuesta agéntica del sector público

Esto no es un chatbot. No es un dashboard. Es un sistema de flujo de trabajo agéntico con capacidad de respuesta, uno que detectó una amenaza, razonó sobre un problema logístico complejo y coordinó la reubicación de 137 000 personas sin intervención humana. Ese tipo de resultado solo es posible porque cada funcionalidad de la que depende reside en una sola plataforma unificada.

El soporte geoespacial de Elasticsearch (geo_point, geo_shape, políticas de enriquecimiento y ordenación basada en la distancia) gestiona el razonamiento espacial que hace posible la detección de intersecciones y la búsqueda de instalaciones a escala. La búsqueda semántica y las incrustaciones vectoriales proporcionan a los agentes una base factual, lo que garantiza que el razonamiento de la AI se apoye en el contenido real de tus datos y no en suposiciones producto de alucinaciones. El motor de detección de Kibana, Workflows, Agent Builder y las herramientas de Agent Builder lo integran todo en un pipeline que va desde el evento sin procesar hasta la acción coordinada, sin necesidad de código de integración externo.

Ninguna otra plataforma reúne esto como lo hace Elastic. La combinación de indexación en tiempo real, precisión geoespacial, recuperación semántica y orquestación agéntica, todo en un solo stack, con seguridad y observabilidad de nivel empresarial integradas, es lo que diferencia a Elastic de las herramientas que hacen bien una de estas cosas pero requieren que unas el resto por tu cuenta.

Respuesta geoespacial agéntica para la gestión de emergencias, bomberos, fuerzas del orden y salud pública

La misma arquitectura se aplica dondequiera que se crucen personas, instalaciones y eventos en tiempo real. Los datos específicos cambian. El pipeline no.

Gestión de emergencias: FEMA y las oficinas estatales de gestión de emergencias pueden mapear las ubicaciones de los refugios, las áreas de preparación y las poblaciones vulnerables con respecto a los polígonos de fenómenos meteorológicos adversos entrantes del Servicio Meteorológico Nacional (NWS), lo que activa el posicionamiento previo automatizado de recursos antes de que una tormenta toque tierra.

Servicios de bomberos y emergencias médicas: los departamentos de bomberos pueden superponer las ubicaciones de las unidades y las zonas de respuesta sobre los perímetros de incendios forestales o las agrupaciones de incendios estructurales, y dirigir automáticamente las solicitudes de ayuda mutua a las unidades disponibles más cercanas que cuenten con el equipo adecuado.

Fuerzas del orden: las agencias pueden correlacionar las ubicaciones de incidentes activos con zonas escolares, infraestructura crítica y posiciones de los oficiales, lo cual activa notificaciones de confinamiento con reconocimiento geográfico o el despacho de recursos sin esperar la clasificación manual.

Seguridad en las escuelas públicas: los distritos escolares pueden monitorear datos de amenazas en tiempo real y compararlos con los límites de los recintos escolares. Cuando una amenaza cruza el perímetro de una escuela, un agente puede notificar de inmediato a la administración, iniciar las comunicaciones de cierre de emergencia y coordinar la respuesta de las fuerzas del orden, todo antes de que un despachador atienda el teléfono.

Salud pública: los departamentos de salud pueden cotejar datos de vigilancia de enfermedades o zonas de riesgo ambiental con ubicaciones de clínicas, capas de densidad poblacional e inventarios de depósitos de suministros para dirigir los recursos donde más se necesitan.

Sector

Caso de uso

Capacidad de Elastic

Gestión de emergencias

Hacer coincidir las ubicaciones de los refugios con los polígonos de fenómenos meteorológicos adversos del NWS

Enriquecimiento de geo_shape + flujos de trabajo de Kibana

Bomberos y EMS

Superponer las ubicaciones de las unidades sobre los perímetros de incendios forestales

enrutamiento geoespacial + búsqueda de la instalación más cercana

Fuerzas del orden

Correlacionar incidentes con zonas escolares y posiciones de oficiales

reglas de alerta con reconocimiento geográfico + envío de recursos mediante el agente

Seguridad en las escuelas públicas

Monitorear las fuentes de amenazas contra los perímetros del campus

reglas de detección + notificación automatizada

Salud pública

Comparar las zonas de peligro con las ubicaciones de las clínicas y los depósitos de suministros

búsqueda semántica + enriquecimiento geoespacial

Los datos son diferentes en cada escenario. El patrón subyacente de ingestar, enriquecer en tiempo de indexación, detectar intersecciones, activar una respuesta agéntica y actuar es exactamente el mismo. Elastic brinda a las organizaciones del sector público la plataforma para crearlo una vez y adaptarlo en todas partes.

El lanzamiento de cualquiera de las características o funcionalidades descritas en esta publicación, así como su fecha, quedan a exclusivo criterio de Elastic. Es posible que algunas características o funcionalidades que no estén disponibles en este momento no se lancen a tiempo o no se lancen en absoluto.

El agente crea dashboards desde cero, pero también funciona con lo que ya tienes. Abre la barra lateral de AI Chat mientras se ve un dashboard y se conecta automáticamente. Pregunta por qué una métrica se disparó, desglosa por región o agrega un panel de comparación. Tu dashboard existente se convierte en el punto de partida, no solo en el producto final.

Detrás de escena: cómo creamos dashboards en AI Chat

Enseñamos al agente tareas específicas a través de habilidades, descripciones estructuradas de cómo operar en un problema dado. Sin embargo, crear una habilidad de dashboard significaba enseñar a un LLM a generar dashboards de Kibana válidos, y la API heredada de objetos guardados lo hacía muy difícil: JSON profundamente anidado, cambios sutiles de versión a versión, referencias frágiles. Necesitábamos un enfoque diferente.

Una API especialmente diseñada para dashboards programáticos

La nueva API de dashboards se diseñó precisamente para este escenario. En lugar de exponer el estado interno sin procesar, ofrece esquemas tipados y validados para cada tipo de panel. La API se encarga de la conversión entre estructuras externas limpias y las representaciones internas de Kibana, así que el agente puede centrarse en lo que debe incluir el dashboard en lugar de en cómo darle formato.

Una habilidad, una herramienta, muchas operaciones

La dashboard-management habilidad expone una sola manage_dashboard herramienta que acepta una matriz ordenada de operaciones. Cada operación es una acción discreta: establecer metadatos, agregar un panel de Markdown, crear visualizaciones respaldadas por ES|QL a partir del lenguaje natural, editar paneles existentes, agrupar paneles en secciones plegables o reposicionar elementos en la cuadrícula.

Puedes describir un dashboard completo: título, descripción, secciones y cada panel interior en una sola llamada:

Las operaciones se ejecutan en orden, por lo que los pasos posteriores pueden hacer referencia a los anteriores y basarse en ellos. Este diseño mantiene la conversación centrada en la intención en lugar de en los detalles de implementación.

El pipeline de visualización: del lenguaje natural a ES|QL y, finalmente, a las visualizaciones

Cuando solicitas un dashboard, el agente explora tus datos (índices, mapping de campos, tipos), luego planifica las visualizaciones y llama a manage_dashboard.

Cada panel pasa por su propia pipeline: selección de tipo de gráfico, generación de ES|QL, configuración de visualización y validación. Separamos esto del hilo principal del agente: la construcción de la visualización requiere varias llamadas al modelo por cada panel, y mezclarlo con el contexto principal sobrecargaría la ventana y entorpecería el razonamiento.

Dentro de manage_dashboard, todos los paneles se construyen de manera concurrente y luego se reensamblan en orden. El resultado es un dashboard completo con paneles insertados: sin visualizaciones huérfanas, sin problemas de sincronización.

Por qué movimos la creación de visualizaciones dentro de la herramienta del dashboard

Nuestro primer enfoque usó una herramienta separada para crear visualizaciones: una llamada por panel, y luego pasábamos cada archivo adjunto a la herramienta del dashboard. Funcionó, pero cada visualización necesitaba su propia llamada a la herramienta, su propio ciclo de vida y una entrega explícita. Lo peor es que, al editar una visualización en la conversación, el panel del dashboard no se actualizaba, lo que confundía a los usuarios.

Integramos la creación de visualizaciones directamente en manage_dashboard. Los mismos flujos de trabajo paralelos se ejecutan, pero los paneles se ensamblan en la estructura del dashboard sin archivos adjuntos intermedios. Menos llamadas, sin problemas de sincronización, un ciclo de vida único.

Las visualizaciones independientes siguen funcionando: puedes colocar gráficos existentes en un dashboard a través de referencias de archivos adjuntos, pero para construir desde cero, la creación en línea es la ruta más limpia

Para equipos de seguridad

Los analistas de SOC y los ingenieros de detección no pueden permitirse el lujo de tener que ir y volver al editor del dashboard en medio de una investigación. Con AI Chat, pide volumen de alertas por tipo de regla, host o táctica MITRE y velo en tu hilo en aproximadamente un minuto. A medida que la búsqueda se desarrolla, incorpora paneles, anomalías en la ejecución de procesos, conexiones de red, comparaciones de línea de tiempo, sin perder el contexto.

Guarda cuando hayas terminado. El dashboard se convierte en una referencia para la revisión posterior al incidente, un punto de partida para el próximo analista, o una sesión informativa semanal sobre amenazas (sin necesidad de una nueva explicación).

Lee más sobre cómo los equipos de seguridad pueden usar la creación de dashboards y otras capacidades de AI Chat recientemente lanzadas en esta publicación de blog.

Para ingenieros de observabilidad y confiabilidad del sitio (SRE)

Cuando un servicio se deteriora a las 2 a. m., no hay tiempo para crear dashboards desde cero. Con AI Chat, un SRE puede describir las métricas que necesita (latencia p99 por servicio, tasa de error frente a eventos de despliegue, reinicios del pod en la última hora) y obtener un dashboard completo en el hilo de investigación en aproximadamente un minuto. El agente puede refinarlo paso a paso a medida que el panorama se aclara: agregar un panel, cambiar la ventana de tiempo, desglosar por región.

Guarda el dashboard y estará inmediatamente disponible en la sala de crisis (los mismos paneles, el mismo encuadre) para todos los que se unan a la reunión sobre el incidente. Después del incidente, se convierte en la base para el análisis de lo ocurrido.

Lo que se viene

Estamos trabajando en la optimización de tokens, interacciones de pantalla completa más ricas, soporte de panel más amplio y mejoras continuas de calidad. La vista previa técnica es el momento adecuado para definir prioridades: si falta algo, avísanos a través del ícono “Enviar comentarios” en el menú superior.

Pruébalo

Actualiza a Elastic 9.4 (o inicia una prueba), abre AI Chat en modo de pantalla completa y pruébalo en una investigación real. Pídele al agente que te muestre un gráfico con las métricas que te interesan y, después, pídele el siguiente desglose. Si la historia se mantiene, guárdala y compártela: mismos paneles, mismo encuadre, sin necesidad de volver a explicarla. Requiere una licencia empresarial (comenzar). El lanzamiento y la disponibilidad de cualquier característica o funcionalidad descrita en esta publicación quedan a exclusivo criterio de Elastic. Es posible que cualquier característica o funcionalidad que no esté disponible actualmente no se entregue a tiempo o no se entregue en absoluto.

Cómo Kibana obtiene datos al cargar un dashboard

Cuando se abre un dashboard, la mayoría de los paneles (internamente, los llamamos insertables) inician una o más búsquedas de Elasticsearch. Sin embargo, en lugar de la simple llamada y respuesta de una búsqueda síncrona (sinc), usamos el poder de la búsqueda asíncrona (asinc) (docs).

Con la búsqueda asincrónica, los resultados de las consultas se mantienen disponibles en Elasticsearch fuera de cualquier solicitud HTTP en particular. Esto es importante porque

• hace que la carga de datos sea resistente a la turbulencia de la red

• impulsa nuestra función de búsqueda en segundo plano, que permite a los usuarios seguir trabajando en otras cosas en Kibana mientras esperan a que se cargue un dashboard o una sesión de Discover que tarda mucho en cargarse

Tras enviar la búsqueda inicial, Kibana monitorea la búsqueda para detectar cuándo está completa y recuperar el conjunto de resultados.

Cómo el sondeo tradicional afecta los tiempos de carga del dashboard de Kibana

En el sondeo tradicional, Kibana envía una búsqueda, cierra la conexión inicial y luego verifica periódicamente en Elasticsearch si la búsqueda ha finalizado.

Le damos a Elasticsearch un corto período de tiempo después del envío de la búsqueda para que simplemente complete la búsqueda y devuelva los resultados. Si la búsqueda se completa tan rápidamente, equivale a una simple llamada y respuesta. Pero para búsquedas más largas, la conexión inicial se cierra y Kibana comienza a verificar periódicamente la búsqueda para completarla. Esto se llama sondeo.

Desventajas en el rendimiento del sondeo tradicional

Si observamos la figura anterior, tal vez ya puedas ver el inconveniente de rendimiento de este enfoque: lo más probable es que la búsqueda termine durante uno de los intervalos de suspensión de Kibana, lo que lleva a perder tiempo.

En el peor de los casos (cuando una búsqueda se completa al comienzo de un período de inactividad) se desperdiciará toda la duración del intervalo de sondeo.

El impacto de una estrategia de retroceso

Aplicar una estrategia de retroceso, es una práctica estándar al realizar sondeos. Esto significa que cuanto más larga sea la duración de la búsqueda, con menos frecuencia realizamos el sondeo.

Sin embargo, esto también significa que el tiempo potencial perdido escala con la duración de la búsqueda.

Cómo los intervalos de sondeo generan patrones de latencia en forma de diente de sierra

Al unir estos factores, nuestro tiempo perdido se convierte en una función escalonada en diente de sierra.

Aquí, los picos representan los peores escenarios posibles y los valles, los mejores. Esto muestra que el sondeo tradicional nos puede costar desde nada hasta el tiempo completo del intervalo de sondeo, dependiendo de cuánto dure la búsqueda (y las condiciones de la red).

Sondeos continuos: cómo Kibana elimina el tiempo de espera

El problema con los sondeos tradicionales es la falta fundamental de coordinación entre Kibana y Elasticsearch. Idealmente, Kibana sabe inmediatamente cuándo hay resultados disponibles. Entonces, ¿qué pasaría si invirtiéramos el patrón de sondeo para que casi todo el tiempo se dedique a revisar Elasticsearch y no se pierda nada?

Con esta combinación de sondeos largos y sin más períodos de inactividad, los resultados se entregan no bien están listos.

Degradación de HTTP/1

La teoría es sólida. Entonces, ¿por qué este despliegue de Kibana parece tan degradado cuando activamos el sondeo continuo?

La clave es que este despliegue se está ejecutando sobre HTTP/1. En HTTP/1, las solicitudes HTTP se mapean 1:1 a conexiones TCP. Así que varias solicitudes de sondeo de larga duración están acaparando el límite de conexiones del navegador, lo que provoca que otras peticiones se pongan en cola.

En cambio, en HTTP/2+, las solicitudes de red pueden compartir conexiones TCP mediante multiplexación, así que no nos encontramos con este problema.

Entonces, en HTTP/2+ el sondeo continuo es una virtud, pero en HTTP/1 se convierte en un vicio.

HTTP/1

HTTP/2+

Conexiones TCP

Uno por solicitud HTTP

Multiplexado (muchas solicitudes comparten conexiones)

Comportamiento del sondeo continuo

Degradación del rendimiento (agotamiento del grupo de conexiones)

Beneficio completo (resultados entregados inmediatamente)

Cómo Kibana detecta el protocolo HTTP para un sondeo óptimo

HTTP/2 es el protocolo recomendado y es el predeterminado de Kibana desde la versión 9.0, así que sería una pena no enviar esta mejora de rendimiento. Por otro lado, la experiencia de HTTP/1 está tan degradada que no es aceptable arriesgarse a usarla en ningún despliegue local que aún no haya actualizado su protocolo. La respuesta es clara: necesitamos detectar qué protocolo está en uso y aplicar la estrategia de sondeo óptima.

Ciertamente es posible que el servidor de Kibana sepa de qué protocolo está hablando. Pero hay un problema: el factor limitante es el grupo de conexiones del navegador. Eso significa que lo que realmente importa es lo que el navegador está diciendo.

Debido a los proxies, no siempre son los mismos.

Si basáramos nuestra optimización en el protocolo del servidor, podríamos equivocarnos de dos maneras diferentes.

1. Aplica sondeos continuos cuando no deberíamos y degrada la experiencia.

2. Si no aplicamos el sondeo continuo cuando deberíamos, nos perdemos la optimización.

Afortunadamente, los navegadores modernos proporcionan una manera de detectar el protocolo del último salto de red de cualquier solicitud completada mediante el uso de un PerformanceObserver. Así que nos fijamos en el protocolo de la primera búsqueda enviada y optimizamos en función de eso.

Resultados de laboratorio: sondeo continuo frente a sondeo tradicional en Kibana

Para validar el sondeo continuo, creamos dashboards con retardos de búsqueda que iban de 1 a 23 segundos y medimos los tiempos de carga con y sin la optimización activada. Luego cargamos los dashboards con y sin sondeo continuo para medir las ganancias (nos divertimos mucho con race-for-the-prize).

El patrón reproduce nuestro diagrama de diente de sierra original. Para algunas duraciones de búsqueda, las ganancias son pequeñas, mientras que para otras ascienden a varios segundos.

Conclusión

Esta optimización reemplaza con éxito la latencia inherente al sondeo tradicional con una estrategia de sondeo continuo más eficiente. El reto principal fue implementar esta optimización condicionalmente para evitar la degradación del rendimiento en despliegues HTTP/1. Lo solucionamos usando el PerformanceObserver del navegador para detectar de forma confiable el protocolo en uso en el salto final de red.

Las pruebas de laboratorio validan la teoría, muestran que el sondeo continuo arroja resultados tan pronto como están listos. En promedio, esto conduce a una mejora significativa en la experiencia del usuario, lo que hace que los datos se carguen hasta un 25 % más rápido.

Este trabajo es el último paso en nuestro compromiso por reducir el tiempo que tardan nuestros usuarios en obtener información útil. Al hacer de Kibana un proxy más transparente para los datos de Elasticsearch, superamos los límites del rendimiento dentro de nuestra esfera de influencia. Más próximamente.

(en 2025, Thomas Neirynk ofreció una excelente visión general de los métodos y la motivación detrás de la mejora del rendimiento del dashboard de Kibana. Esta es una actualización sobre esa iniciativa).

¿Qué es el generador de dashboard de Kibana?

¿Y si pudieras describir el dashboard que quieres en un lenguaje sencillo y ver cómo aparece, con gráficos interactivos, un diseño de arrastrar y soltar y la posibilidad de exportarlo a Kibana con un solo clic?

Eso es precisamente lo que hace example-mcp-dashbuilder. Es una aplicación open source (Model Context Protocol (MCP)) que conecta asistentes de IA a Elasticsearch que te permiten crear paneles completos de Kibana a través de la conversación. No hay que hacer clic en los menús. No hay que escribir manualmente las configuraciones de visualización. Solo describe lo que necesitas y la IA explora tus datos, escribe las consultas en lenguaje de búsqueda de Elasticsearch (ES|QL), construye los gráficos y entrega un dashboard interactivo en vivo, todo dentro de la ventana de chat de tu editor.

De la línea de comandos al dashboard en segundos

Así es como se ve en la práctica. Escribes algo como:

"Crea un dashboard de tráfico web desde logstash-*, con solicitudes totales, bytes transferidos a lo largo del tiempo, fuentes geográficas principales y un desglose de código de respuesta"

La IA entonces:

1. Descubre tus datos: enumera índices, inspecciona mapeos de campo.

2. Escribe consultas ES|QL: adaptadas a tu esquema con las agregaciones correctas.

3. Crea visualizaciones: gráficos de barras, gráficos de líneas, métricas con líneas de destellos, mapas de calor, gráficos circulares.

4. Organiza todo: secciones plegables, títulos significativos, diseño adecuado.

5. Muestra una vista previa interactiva: directamente en el chat, con descripciones emergentes, un selector de hora y arrastrar y soltar.

Cada gráfico aparece en línea a medida que se crea, por lo que puedes ver el progreso en tiempo real. Luego view_dashboard muestra el dashboard completo con todos los paneles dispuestos en la cuadrícula de 48 columnas de Kibana.

Vista previa de un solo gráfico en línea.

Impulsado por ES|QL

Toda recuperación de datos usa ES|QL, el lenguaje de búsquedas canalizadas de Elasticsearch. La IA no se limita a pasar consultas sin procesar, sino que también utiliza su conocimiento integrado de la sintaxis de ES|QL, junto con la información sobre la estructura de tus datos, para escribir consultas correctas y eficientes para cada tipo de visualización.

El servidor incluye una referencia completa de ES|QL como recurso MCP. Antes de escribir cualquier consulta, la IA lee esta referencia para comprender los comandos, funciones y patrones disponibles. Combinada con una guía de mejores prácticas de visualización de datos (que también sirve como recurso), la IA sabe no solo cómo realizar consultas, sino qué constituye una buena visualización:

• Usa BUCKET(@timestamp, 1 day) para series temporales; siempre SORT por el campo de tiempo.

• Limita los gráficos circulares a seis porciones con | SORT value DESC | LIMIT 6.

• Elige gráficos de barras para comparaciones de categorías, gráficos de líneas para tendencias, métricas para indicadores clave de rendimiento (KPIs).

Exploración de datos basada en IA con análisis abierto

Una cosa es crear un dashboard que ya diseñaste en tu cabeza. Preguntar "¿Qué tiene de interesante este índice?" y obtener una respuesta útil es más difícil. Requiere que la IA sepa cómo explorar, no solo cómo dibujar.

example-mcp-dashbuilder envía un recurso analysis://guidelines que define un flujo de exploración estructurado: perfila los datos, ejecuta agregaciones específicas, revela patrones que vale la pena investigar, crea gráficos para los hallazgos más interesantes y propone consultas desglosadas que el usuario podría querer a continuación. Frases desencadenantes, como "analizar mis registros" o "encontrar patrones en este índice", hacen que la IA lea el manual antes de hacer cualquier otra cosa, por lo que un prompt abierto produce una investigación coherente en lugar de un montón aleatorio de gráficos.

El resultado: puedes proporcionarle a la IA un índice desconocido y obtener a cambio un punto de partida: un dashboard más una breve lista de preguntas del tipo "¿Esto es lo que observé, quieres que profundice en alguno de estos puntos?".

Exportación e importación de dashboard de Kibana: el viaje de ida y vuelta completo

El viaje de ida y vuelta de exportación e importación es donde example-mcp-dashbuilder se vuelve realmente útil para los equipos que ya trabajan en Kibana. example-mcp-dashbuilder es una interfaz de dashboard conversacional que vive dentro de tu editor, pero no limita tu trabajo allí. Los paneles que crees aquí pueden trasladarse a Kibana cuando quieras, y los paneles existentes de Kibana pueden venir de otro lado para la edición asistida por IA.

Exportar a Kibana

Cuando te guste tu dashboard, un solo comando lo exporta:

"Exportar este dashboard a Kibana"

Cada panel se traduce a una visualización real de Kibana Lens. La traducción preserva:

• Consultas ES|QL: transferidas directamente como fuentes de datos Lens ES|QL.

• Posiciones de cuadrícula: el mismo sistema de 48 columnas que usa Kibana, así tu diseño se ve idéntico.

• Colores personalizados: paletas de series, fondos de métricas, rampas de color de mapa de calor.

El resultado es un dashboard de Kibana completamente funcional. No es una captura de pantalla. No es una inserción. Un dashboard real que puedes compartir y continuar editando en Kibana.

El dashboard de Kibana y el dashboard del chat de cursor, uno al lado del otro.

Importar desde Kibana

El viaje de ida y vuelta también funciona en la otra dirección:

"Importar el dashboard de Kibana con ID abc-123"

Esto recupera un dashboard de Kibana existente, traduce sus visualizaciones de Lens de vuelta a configuraciones de gráficos editables, conserva la disposición de la cuadrícula y las secciones, y carga todo en example-mcp-dashbuilder. Desde ahí, puedes modificarlo con lenguaje natural y volver a exportarlo.

Esto hace que la IA sea un complemento de tu flujo de trabajo actual en Kibana, no un sustituto.

Temas personalizados y colores

¿Quieres un dashboard de marca? Solo pregúntanos.

"Crea un dashboard de temática rosa con colores personalizados"

Cada tipo de visualización admite una configuración de color personalizada:

• Gráficos: palette acepta una matriz de colores hexadecimales para series y segmentos.

• Métricas: color establece el color de fondo.

• Mapas de calor: colorRamp define el gradiente, de valores bajos a altos.

La IA capta las solicitudes de temas de forma natural. Di, "Tema oceánico," y elegirá azules y verdes azulados. Di: "Que coincidan con los colores de nuestra marca" y proporciona los valores hexadecimales, y estos se transferirán a Kibana en el momento de la exportación.

Un dashboard temático con colores personalizados.

Cómo funciona example-mcp-dashbuilder: arquitectura MCP

example-mcp-dashbuilder se basa en MCP, el estándar abierto para conectar asistentes de IA con herramientas y datos externos. Aquí está la arquitectura a alto nivel:

El servidor MCP expone 25 herramientas que la IA puede llamar directamente, desde ejecutar consultas ES|QL hasta exportar dashboards, junto con un puñado de herramientas internas "exclusivas de la app" que la vista previa en línea usa para obtener datos, conservar los cambios de diseño y detectar campos de tiempo. Ofrece tres recursos: una guía de mejores prácticas para la visualización de datos, una referencia de ES|QL y un manual de análisis profundo que se activa con preguntas abiertas ("analiza mis logs", "¿qué hay de interesante en este índice?"). Y se ejecuta por stdio o HTTP. El transporte HTTP soporta respuestas transferibles y gestión de sesiones, de modo que varios clientes pueden conectarse a un solo servidor.

La app MCP es la vista previa interactiva. Está hecha con React, Elastic Charts y Elastic UI, todo empaquetado en un único archivo HTML independiente. Cuando la IA llama a view_dashboard o crea un gráfico, el host renderiza este HTML en un iframe en modo sandbox. La app se comunica completamente con el servidor a través del protocolo de aplicaciones MCP, con callServerTool() a través de postMessage para obtener datos, almacenar diseños y detectar campos de tiempo. No hay un servidor localhost, no hay un puerto para configurar ni una dependencia de red externa.

Esto significa que funciona con cualquier cliente compatible con MCP: Cursor, Claude Desktop, Claude.ai, VS Code con Copilot y más.

¿Qué tipos de gráficos soporta example-mcp-dashbuilder?

Al momento de escribir, se admiten seis tipos de gráficos que cubren los escenarios de dashboard más comunes:

Tipo

Lo mejor para

Ejemplo

Barra

Comparación de categorías

Solicitudes por origen geográfico

Línea

Tendencias a lo largo del tiempo

Bytes transferidos por hora

Área

Volumen a lo largo del tiempo

Volumen de solicitudes a lo largo del tiempo

Circular

Parte del todo (máximo seis segmentos)

Distribución de los códigos de respuesta

Métrica

Indicador clave de rendimiento (KPI) único con minilínea

Total de solicitudes con tendencia horaria

Mapa de calor

Patrones en dos dimensiones

Solicitudes por día de la semana y por hora

Los paneles de control admiten secciones plegables para su organización, un selector de tiempo con detección automática de campos de tiempo y la capacidad de guardar y cambiar entre varios paneles; las sesiones de chat paralelas permanecen aisladas entre sí mediante un dashboardId que se interpone en cada llamada a la herramienta.

Cómo instalar y ejecutar example-mcp-dashbuilder

example-mcp-dashbuilder es de open source y está listo para usar. Necesitarás Node.js 22+, una instancia de Elasticsearch (local o Elastic Cloud) y un cliente compatible con MCP.

Claude Desktop: descarga la última versión .mcpb de GitHub Releases y haz doble clic. Claude Desktop te pedirá tus credenciales de Elasticsearch.

Cursor / Claude Code / VS Code Copilot: apunta tu configuración de MCP al archivo tar publicado; sin clonar, sin npm install:

Establece ES_NODE, ES_API_KEY (o ES_USERNAME / ES_PASSWORD) y KIBANA_URL como variables de entorno. Si prefieres trabajar desde el código fuente, clona el repositorio y ejecuta npm run setup para un asistente interactivo que gestione tanto Elasticsearch local como Elastic Cloud (Cloud ID + clave API).

Y empieza a crear:

"Explora el índice de logs y crea el dashboard más completo que puedas"

A partir de ahí, la IA se encarga de todo. 😉

Roadmap: lo que viene para example-mcp-dashbuilder

Esta es una versión preliminar y la estamos desarrollando activamente. Algunas áreas en las que nos enfocamos:

• Más tipos de gráficos: indicador, donut, treemap, tabla de datos y nube de cloud para igualar todas las capacidades de Lens.

• Enviar paneles a Git: escribe las configuraciones de los paneles en un repositorio para el control de versiones y los flujos de trabajo de revisión de código.

• Mejor experiencia de error: comentarios más detallados cuando las consultas ES|QL fallan, con sugerencias para correcciones comunes.

• Flujos de análisis más ricos: ampliación del manual de análisis profundo para cubrir más formas de datos (log, métricas, trazas).

Nos encantaría saber lo que crees con él. Pruébalo, reporta problemas y cuéntanos qué visualizaciones y flujos de trabajo serían más útiles para tu equipo.

GitHub: elastic/example-mcp-dashbuilder

Agradecimientos

Gracias a Walter Rafelsberger y Tim Schnell por sus contribuciones a la implementación.

Preguntas frecuentes

¿Qué es example-mcp-dashbuilder? example-mcp-dashbuilder es una aplicación de open source MCP (Model Context Protocol) que conecta asistentes de IA con Elasticsearch. Te permite describir un dashboard de Kibana en lenguaje sencillo y genera automáticamente consultas ES|QL, crea visualizaciones y muestra un dashboard interactivo en tiempo real dentro de la ventana de chat de tu editor.

¿Qué lenguaje de búsqueda usa example-mcp-dashbuilder para recuperar datos? Toda la recuperación de datos utiliza ES|QL, el lenguaje de búsqueda de Elasticsearch. El servidor MCP incluye una referencia integrada de ES|QL que la IA consulta antes de escribir cualquier consulta, lo que garantiza una sintaxis correcta y agregaciones eficientes para cada tipo de visualización.

¿Puedo exportar paneles creados con example-mcp-dashbuilder a Kibana? Sí. Ejecutar "Exporta este dashboard a Kibana" convierte cada panel en una visualización real de Kibana Lens, conserva las consultas ES|QL, el diseño de cuadrícula de 48 columnas, los colores personalizados y las paletas de series. El resultado es un dashboard de Kibana completamente funcional, no una captura de pantalla ni una incrustación.

¿Puedo importar un dashboard de Kibana existente en example-mcp-dashbuilder para una edición asistida por IA? Sí. Al introducir el ID de un dashboard de Kibana, se recupera el dashboard existente, se convierten sus visualizaciones de Lens en configuraciones de gráficos editables y se cargan en example-mcp-dashbuilder. Después puedes modificar el dashboard usando lenguaje natural y volver a exportarlo a Kibana.

¿Qué clientes de MCP son compatibles con example-mcp-dashbuilder? example-mcp-dashbuilder funciona con cualquier cliente compatible con MCP, incluidos Cursor, Claude Desktop, Claude.ai y VS Code con Copilot. Es compatible tanto con el transporte stdio como HTTP, sin necesidad de configuración de servidor o puerto localhost.

¿Qué tipos de gráficos admite example-mcp-dashbuilder? La versión actual admite seis tipos de gráficos: barra, línea, área, circular, métrica (con minigráfico) y mapa de calor. Las adiciones previstas incluyen medidor, dona, gráfico de rectángulos, tabla de datos y nube de etiquetas para igualar las capacidades completas de Kibana Lens.

¿Qué necesito para ejecutar example-mcp-dashbuilder? Necesitas Node.js versión 22 o superior, una instancia de Elasticsearch (local o en Elastic Cloud) y un cliente compatible con MCP. Configura las variables de entorno ES_NODE, ES_API_KEY (o ES_USERNAME/ES_PASSWORD) y KIBANA_URL. Para Claude Desktop, descarga el archivo .mcpb Descarga el archivo desde GitHub Releases y haz doble clic para instalarlo.

¿Qué son los controles variables?

Si has trabajado antes con los dashboards de Kibana, probablemente conozcas nuestros controles clásicos de dashboard: esos prácticos menús desplegables que muestran valores de tus datos para que puedas aplicar filtros con un par de clics.

A simple vista, los controles variables son parecidos , pero tienen un giro ingenioso: en lugar de filtrar automáticamente cada panel en tu dashboard, pueden conectarse directamente a búsquedas ES|QL dentro de visualizaciones individuales.

Eso significa que tú decides dónde se aplica cada control. Y aún más, puedes usarlos para todo tipo de trucos creativos, como ajustar intervalos de tiempo, cambiar campos de desglose o modificar parámetros de visualización en el momento. Básicamente, ofrecen a tus dashboards una experiencia realmente interactiva, lo que permite obtener tu información de manera más rápida y fácil.

Casos de uso para controles variables

Muy bien, los controles variables parecen útiles, pero ¿para qué sirven realmente? A continuación se muestran algunos ejemplos de cómo mejorar tus dashboards:

Filtrar visualizaciones seleccionadas.

¿Quieres filtrar algunas visualizaciones sin cambiar otras? Los controles de variables te permiten hacer exactamente eso. Selecciona los paneles a los que deseas responder y conéctalos en las búsquedas de ES|QL detrás de tus visualizaciones.

Selecciona diferentes intervalos de tiempo

Otorga a tus usuarios el poder de cambiar entre “5 minutos”, “1 hora”, “1 día” o cualquier cubeta de tiempo que tenga sentido. Crea un control variable con intervalos predefinidos y conéctalo a tu búsqueda de series temporales.

Cambiar funciones

En lugar de crear múltiples gráficos para cada operación, permite que los usuarios del dashboard elijan si quieren ver el máximo, el promedio, diferentes percentiles o cualquier otro agregador.

Agrupar por diferentes campos

A veces necesitas desglosar los datos por diferentes dimensiones durante una investigación. Con controles variables, puedes definir múltiples campos “agrupar por” y permitir que los usuarios del dashboard elijan cuál les permite descubrir su información.

¿Cómo puedes crearlos?

La manera más sencilla (y probablemente más amena) de crear un control de variable es directamente desde el editor de búsquedas ES|QL en tu visualización. Simplemente comienza a escribir tu búsqueda, usa el menú de autocompletado y Kibana configurará el control de una manera que te resulte útil.

Pero si prefieres empezar desde la variable en sí, también puedes ir a: Agregar panel → Controles → Control de variables y agregar la variable a tus visualizaciones después de crear el control.

Ejemplo 1: Control de filtrado con selección de múltiples valores.

1. Elija una visualización que se realice a partir de una búsqueda ES|QL y haga clic en “Crear control” dentro de la cláusula WHERE.

2. Serás redirigido automáticamente al elemento flotante de creación de variables, donde se seleccionará el tipo “Valores de una búsqueda” para ti, y el nombre de la variable ya estará previamente completado. Recuerda que el nombre de un control siempre debe comenzar con “?...” para que funcione en la búsqueda de visualización.

Normalmente necesitarás una búsqueda como esta para obtener los valores de un campo y actualizarlos según el rango de tiempo seleccionado en el dashboard:

3. Al guardar el control, lo verás aparecer en la parte superior del dashboard y tu búsqueda de visualización se actualizará con el nombre del control variable.

4. Si deseas agregar una selección de valores múltiples al control, debes usar la función MV_CONTAINS en la búsqueda y seleccionar “Permitir selecciones múltiples” durante la creación del control en el paso 2 (disponible desde la versión 9.3).

Ejemplo 2: Control de intervalos de tiempo.

Si estás creando una serie temporal, puedes agregar fácilmente un control variable en el intervalo de histograma de fecha:

1. Cuando escribas una búsqueda ES|QL para tu serie temporal, haz clic en “Crear control”. Al construir una variable para intervalos, es mejor usar TBUCKET en lugar de BUCKET para que acepte intervalos más legibles como “1 hora”, “1 día”, etc. Pronto habrá una opción automática para TBUCKET que se adaptará automáticamente a los intervalos de tiempo.

2. Define los intervalos para completar las opciones en el menú desplegable.

3. Selecciona diferentes intervalos en el menú desplegable y observa cómo cambia tu visualización.

Ejemplo 3: variables para funciones

1. Crea una variable usando el tipo de control “Valores estáticos” y agrega nombres de funciones a los valores de tu menú desplegable. Es importante usar un nombre para la variable que comience con “??...” para reemplazar funciones.

2. Incluye el nombre de la variable en la búsqueda ES|QL.

Ejemplo 4: variables para campos

1. Puedes usar el tipo de control “Valores estáticos” y escribir los nombres de los campos que desees. Es importante usar un nombre de variable que comience con “??...” para que funcione en los campos.

2. Crea una referencia a la variable donde la necesites en la búsqueda de la visualización.

Controles de variables en Discover

Los controles variables no son solo una característica del dashboard: también están disponibles directamente en el editor de ES|QL en Discover. Puede crear controles para obtener una experiencia de exploración de datos más rápida en Discover, llevarlos al dashboard y viceversa.

Detalles técnicos

A estas alturas, probablemente hayas notado que los controles de variables incluyen algunas reglas, como a qué partes de una búsqueda pueden hacer referencia y los prefijos de nombres que necesitas usar (“?...” para valores y “??...” para campos o funciones). Eso se debe a que las variables no son simplemente reemplazos de texto que ocurren en el cliente. En realidad, son ciudadanos de primera clase en el propio lenguaje de búsquedas (conocidos como parámetros en ES|QL).

Este diseño ofrece grandes ventajas. Por un lado, Kibana puede entender el contexto de cada variable, lo que nos permite generar y completar previamente, de manera automática, su configuración. Además, es mucho más seguro: debido a que el lenguaje valida estrictamente las entradas de variables, previene las inyecciones maliciosas y genera errores fácilmente, si algo parece incorrecto. Asimismo, mejora el rendimiento y la estabilidad al trasladar la compleja validación y el manejo de errores al servidor en lugar de al cliente. Recordatorio sobre el rendimiento: una de las mejores prácticas es crear variables que incluyan búsquedas rápidas, ya que se cargan antes que el dashboard, por lo que las búsquedas lentas pueden afectar al rendimiento de todo el dashboard.

Por supuesto, esta arquitectura también tiene algunas limitaciones—por ahora. Las variables aún no admiten una opción “Cualquiera” para filtrar, y actualmente no se pueden usar con ciertos operadores como LIKEo FROM (para cambiar fuentes de datos). ¿La buena noticia? Estamos trabajando activamente para agregar estas funciones.

Qué depara el futuro para los controles

¡Este no es el final! Algunas de las mejoras importantes incluyen:

✨ La capacidad de colocar controles en cualquier lugar del dashboard

✨ Encadenar tus controles, lo que significa que la salida de un control se convierte en la entrada para el siguiente

✨ Mejores opciones de selección como la opción “Cualquiera” para variables.

✨ Nuevos tipos de control (control de tipo búsqueda y variables para tus fuentes de datos)

✨ Y otras mejoras en la experiencia del usuario que han estado solicitando, como el filtro previo de controles normales.

Si tienes ideas o comentarios, nos encantaría saber de ti.

En este artículo, haremos que eso suceda. Crearemos una aplicación que tome una imagen de un panel de control, analice nuestros mapeos y luego genere un panel sin que tengamos que tocar Kibana en absoluto.

Pasos:

1. Antecedentes y flujo de trabajo de la aplicación

2. Preparar datos

3. Configuración de LLM

4. Funciones de aplicación

Antecedentes y flujo de trabajo de la aplicación

La primera idea que se me ocurrió fue dejar que el LLM generara todo el formato NDJSON de los objetos almacenados de Kibana y luego los importara a Kibana.

Probamos algunos modelos:

• Gemini 2.5 pro

• GPT o3 / o4-mini-alto / 4,1

• Claude 4 soneto

• Grok 3

• Deepseek (Deepthink R1)

Y para los prompts, empezamos tan sencillos como:

A pesar de repasar algunos ejemplos de planos y explicaciones detalladas sobre cómo construir cada visualización, no tuvimos suerte. Si te interesa esta experimentación, puedes encontrar detalles aquí.

El resultado de este enfoque fue ver estos mensajes al intentar subir a Kibana los archivos producidos por el LLM:

Esto significa que el JSON generado es inválido o está mal formateado. Los problemas más comunes eran que el LLM producía NDJSON incompleto, alucinaban parámetros o devolvían JSON normal en lugar de NDJSON, por mucho que intentáramos hacer cumplir lo contrario.

Inspirados por este artículo —donde las plantillas de búsqueda funcionaban mejor que el estilo libre de un LLM— decidimos dar plantillas al LLM en lugar de pedir generar el archivo NDJSON completo y luego, en código, usar los parámetros dados por el LLM para crear las visualizaciones adecuadas. Este enfoque no decepcionó, y es previsible y ampliable, ya que ahora el código hace el trabajo duro y no el LLM.

El flujo de trabajo de la aplicación será el siguiente:

Omitiremos algo de código para simplificar, pero puedes encontrar el código funcional de la aplicación completa en este cuaderno.

Prerrequisitos

Antes de empezar a desarrollar, necesitarás lo siguiente:

1. Python 3.8 o superior

2. Un entorno Venv Python

3. Una instancia de Elasticsearch en ejecución, junto con su endpoint y clave API

4. Una clave de API de OpenAI almacenada bajo el nombre de la variable de entorno OPENAI_API_KEY:

Preparar datos

Para los datos, lo mantendremos sencillo y usaremos registros sitio web de muestra de Elastic. Puedes aprender cómo importar esos datos a tu clúster aquí.

Cada documento incluye detalles sobre el anfitrión que emitió las solicitudes a la aplicación, junto con información sobre la propia solicitud y su estado de respuesta. A continuación se muestra un documento de ejemplo:

Ahora, vamos a tomar los mapeos del índice que acabamos de cargar, kibana_sample_data_logs:

Vamos a pasar los mapeos junto con la imagen que cargaremos más adelante.

Configuración de LLM

Configuremos el LLM para que use una salida estructurada para introducir una imagen y recibir un JSON con la información que necesitamos pasar a nuestra función para producir los objetos JSON.

Instalamos las dependencias:

Elasticsearch nos ayudará a recuperar los mapeos de índice. Pydantic nos permite definir esquemas en Python para luego pedir al LLM que lo siga, y LangChain es el framework que facilita la llamada a LLMs y herramientas de IA.

Crearemos un esquema Pydantic para definir la salida que queremos del LLM. Lo que necesitamos saber de la imagen es el tipo de gráfico, campo, título de visualización y título del panel de control:

Para la entrada de imagen enviaremos un panel de control que acabo de dibujar:

Ahora declaramos la llamada al modelo LLM y la carga de imagen. Esta función recibirá los mapeos del índice de Elasticsearch y una imagen del panel de control que queremos generar.

Con with_structured_output podemos usar nuestro esquema de Dashboard Pydantic como objeto de respuesta que producirá el LLM. Con Pydantic, podemos definir modelos de datos con validación, lo que garantiza que la salida del LLM coincida con la estructura esperada.

Para convertir la imagen a base64 y enviarla como entrada, puedes usar un convertidor online o hacerlo en código.

El LLM ya tiene contexto sobre los paneles Kibana, así que no necesitamos explicar todo en el prompt, solo algunos detalles para cerciorarnos de que no olvide que está funcionando con Elasticsearch y Kibana.

Vamos a desglosar el prompt:

Sección

Razón

Eres un experto en analizar paneles de Kibana a partir de imágenes para la versión 9.0.0 de Kibana.

Al reforzar esto es Elasticsearch, y la versión de Elasticsearch reducimos la probabilidad de que el LLM alucine parámetros antiguos o inválidos.

Se te dará una imagen del panel de control y un mapeo de índice de Elasticsearch.

Explicamos que la imagen trata sobre paneles para evitar interpretaciones erróneas por parte del LLM.

A continuación se muestran los mapeos de índices del índice en el que se basa el panel de control. Emplea esto para ayudarte a entender los datos y los campos disponibles. Mapeos de índice: {index_mappings}

Es crucial proporcionar los mapeos para que el LLM pueda seleccionar campos válidos dinámicamente. De lo contrario, podríamos codificar los mapeos aquí, lo cual es demasiado rígido, o confiar en la imagen que contiene los nombres de campo correctos, lo cual no es fiable.

Incluye solo los campos relevantes para cada visualización, basándote en lo que sea visible en la imagen.

Tuvimos que agregar este refuerzo porque a veces intenta agregar campos que no son relevantes para la imagen.

Esto devolverá un objeto con un serial de visualizaciones para mostrar:

Procesamiento de la respuesta de los LLM

Creamosun panel de panel de muestra 2x2 y luego lo exportamos en JSON usando la API Get a dashboard, y después almacenamos los paneles como plantillas de visualización (pastel, barra, métrica) donde podemos reemplazar algunos parámetros para crear nuevas visualizaciones con diferentes campos según la pregunta.

Puedes ver los archivos JSON de plantilla aquí. Fíjate en cómo cambiamos los valores de los objetos que queremos reemplazar más adelante por {variable_name}

Con la información que nos proporcionó el LLM, podemos decidir qué plantilla usar y qué valores reemplazar.

fill_template_with_analysis recibirá los parámetros de un único panel, incluyendo la plantilla JSON de la visualización, un título, un campo y las coordenadas de la visualización en la cuadrícula.

Luego, reemplazará los valores de la plantilla y devolverá la visualización JSON final.

Para simplificar, tendremos coordenadas estáticas que asignaremos a los paneles que el LLM decida crear y produciremos un panel de cuadrícula 2x2 como en la imagen anterior.

Dependiendo del tipo de visualización decidido por el LLM, elegiremos una plantilla de archivo JSON y reemplazaremos la información relevante usando fill_template_with_analysis , luego agregaremos el nuevo panel a un array que usaremos más adelante para crear el panel de control.

Cuando el panel esté listo, usaremos la API Crear un panel para enviar el nuevo archivo JSON a Kibana y generar el panel:

Para ejecutar el script y generar el panel de control, ejecuta el siguiente comando en la consola:

El resultado final será el siguiente:

Conclusión

Los LLMs muestran sus fuertes capacidades visuales al hacer texto a código o convertir imágenes en código. La API de los paneles también permite convertir archivos JSON en paneles, y con un LLM y algo de código, podemos convertir imágenes en un panel Kibana.

El siguiente paso es mejorar la flexibilidad de los gráficos del salpicadero empleando diferentes configuraciones de cuadra, tamaños y posiciones de tablero. Además, ofrecer soporte para visualizaciones y tipos de visualización más complejos sería una adición útil a esta aplicación.

Diferencias respecto al primer análisis de Spotify Wrapped

En el primer blog, usamos la exportación de Spotify directamente y no realizamos ninguna tarea de normalización ni ningún otro procesamiento de datos. Esta vez, usaremos los mismos datos, pero realizaremos un procesamiento de datos para hacerlos más utilizables. Esto nos permitirá responder a preguntas mucho más complejas, como:

• ¿Cuál es la duración media de una canción en mi top 100?

• ¿Cuál es la popularidad media de una canción en mi top 100?

• ¿Cuál es la duración media de escucha de una canción?

• ¿Cuál es la pista que más me salto?

• ¿Cuándo me gusta saltarme pistas?

• ¿Estoy escuchando una hora concreta del día más que otras?

• ¿Estoy escuchando más un día de la semana que otros?

• ¿Es un mes de especial interés?

• ¿Cuál es el artista con el mayor tiempo de escucha?

Spotify Wrapped es una experiencia divertida cada año, mostrando lo que escuchaste este año. No te da cambios año tras año, y por tanto podrías extrañarte a algunos artistas que antes estaban en tu top 10, pero que ahora desaparecieron.

Procesamiento de datos envueltos en Spotify para análisis

Hay una gran diferencia en la forma en que procesamos los datos en la primera y la segunda publicación. Si quieres seguir trabajando con los datos de la primera publicación, tendrás que tener en cuenta algunos cambios en el nombre de campos, así como volver a ES|QL para hacer ciertas extracciones como hour of day sobre la marcha.

Aun así, todos deberíais poder seguir esta publicación. El procesamiento de datos se realiza en el repositorio de Spotify a Elasticsearch , implica aplicar a la API de Spotify la duración de la canción, la popularidad y también renombrar y mejorar algunos campos. Por ejemplo, el campo artist en la exportación de Spotify es solo una cadena y no representa características ni pistas multiartista

Visualizando datos en Spotify Wrapped con paneles de control

Creé un panel de control en Kibana para visualizar los datos. El panel está disponible aquí y puedes importarlo a tu instancia Kibana. El panel de control es bastante extenso y responde muchas de las preguntas anteriores.

¡Vamos a hablar de algunas preguntas y cómo responderlas juntos!

¿Cuál es la duración media de una canción en mi top 100?

Para responder a esta pregunta, podemos usar Lens o ES|QL. Vamos a explorar las tres opciones. Formulemos esta pregunta correctamente de manera Elasticsearch. Queremos encontrar las 100 canciones más populares y luego calcular la duración media de todas esas canciones juntas. En términos de Elasticsearch eso serían dos agregaciones:

1. Descubre las 100 mejores canciones

2. Calcula la duración media de esas 100 canciones.

Lens

En Lens, esto es bastante sencillo: crear un nuevo Lens, cambiar a una tabla y arrastrar y soltar el campo title dentro de la tabla. Luego haz clic en el campo title y pon el tamaño en 100, además de poner modo accuracy . Luego arrastra y suelta el campo duration en la tabla y usa last value, porque realmente solo necesitamos el último valor de la duración de cada canción. La misma canción solo tendrá una duración. Al final de esta agregación de last value hay un desplegable para una fila resumen, selecciona average y te lo mostrará.

ES|QL

ES|QL es un lenguaje bastante nuevo comparado con DSL y agregaciones, pero es muy poderosa y fácil de usar. Para responder a la misma pregunta en ES|QL, escribirías la siguiente consulta:

Déjame guiarte paso a paso por este ES|Consulta QL:

1. from spotify-history - Este es el patrón índice que estamos usando.

2. stats duration=max(duration), count=count() by title - Esta es la primera agregación, estamos calculando la duración máxima de cada canción y el recuento de cada canción. Usamos max en lugar de last value como se usa en el Lens, eso es porque ES|Ahora mismo QL no tiene ni primera ni última.

3. sort count desc - Ordenamos las canciones por el conteo de cada canción, así que la canción más escuchada está arriba.

4. limit 100 - Limitamos el resultado a las 100 mejores canciones.

5. stats Average duration of the songs=avg(duration) - Calculamos la duración media de las canciones.

¿Me interesa especialmente un mes?

Para responder a esta pregunta podemos usar Lens con la ayuda de campo de ejecución y ES|QL. ¿Qué notamos de inmediato? No hay ningún campo en los datos que denote el month directamente, sino que necesitamos calcularlo a partir del campo @timestamp . Hay varias formas de hacerlo:

1. Emplea un campo de ejecución para alimentar el objetivo

2. ES|QL

Personalmente creo que ES|QL es la solución más ordenada y rápida.

Eso es todo, no hace falta nada sofisticado, podemos aprovechar la función DATE_EXTRACT para extraer el mes del campo @timestamp y luego podemos agregar sobre él. Usando el ES|Visualización QL podemos incluirla en el panel de control.

¿Cuál es mi duración de escucha por artista y al año?

La idea detrás de eso es ver si un artista es solo algo puntual o si hay una repetición. Si no recuerdo mal, Spotify solo te muestra los 5 mejores artistas en el wrappeado anual. ¿Quizá tu artista número 6 se mantiene igual todo el tiempo, o cambia mucho después de la décima posición?

Una de las representaciones más sencillas de esto es un gráfico de barras porcentuales. Podemos usar Lens para esto. Sigue los pasos a seguir:

Arrastra y suelta el campo listened_to_ms . Este campo representa cuánto tiempo escuchaste una canción en milisegundos. Ahora, por defecto, Lens creará una agregación median , no queremos eso, cambia eso a un sum. En la parte superior selecciona percentage en lugar de stacked para el tipo de gráfico de barras. Para el desglose selecciona artist y di top 10. En el menú desplegable de Advanced no olvides seleccionar accuracy mode. Ahora, cada bloque de color representa cuánto escuchaste a este único artista. Dependiendo de tu selector de tiempo, las barras pueden representar valores que van de días, a semanas, a meses o años. Si quieres un desglose semanal, selecciona el @timestamp y configura el mininum interval en year. Ahora, lo que podemos decir en mi caso es que Fred Again.. es el artista que más escuché, casi el 12% de mi tiempo total de escucha lo consumía Fred Again... También vemos que Fred Again.. bajó un poco en 2024, pero Jamie XX creció considerablemente. Si comparamos solo el tamaño de las barras. También podemos notar que, aunque Billie Eilish se está tocando constantemente en 2024, el ancho del manillar. Esto significa que escuché más a Billie Eilish en 2024 que en 2023.

¿Y qué hay de las pistas principales por artista por tiempo de escucha frente al tiempo total de escucha?

Es una pregunta larga. Déjame intentar explicar lo que quiero decir con eso. Spotify te dice cuál es la canción más destacada de un solo artista, o tus 5 canciones más populares en total. Bueno, eso es sin duda interesante, pero ¿qué pasa con la ruptura de un artista? ¿Todo mi tiempo lo consumo solo con una sola canción que pongo una y otra vez, o eso se distribuye de forma equitativa?

Crea un nuevo objetivo y selecciona Treemap como tipo. Para el metric, igual que antes: selecciona sum y usa listened_to_ms como campo. Para el group by necesitamos dos valores. El primero se artist y luego agrega otro con title. El resultado intermedio es así:

Vamos a cambiar eso a los 100 mejores artistas y desseleccionar la other en el desplegable avanzado, además de activar el modo de precisión. Para el título, cambia eso a top 10 y activa el modo de precisión. El resultado final es así:

¿Qué nos dice esto ahora exactamente? Sin mirar ningún componente temporal, podemos decir que en todo mi historial de escuchas con Spotify, pasé un 5,67% escuchando Fred Again... En individuo, pasé el 1,21% de ese tiempo escuchando Delilah (pull me out of this). Es interesante ver si hay una sola canción que ocupe a un artista, o si hay otras canciones también. El propio mapa de árbol es una forma agradable para representar estas distribuciones de datos.

¿Escucho en una hora y día concretos?

Bueno, eso podemos responder de forma muy sencilla con una visualización de lentes aprovechando el Heat Map. Crea una nueva lente, selecciona Heat Map. Para el Horizontal Axis selecciona dayOfWeek campo y ponlo en Top 7 en vez de Top 3. Para el Vertical Axis seleccionar el hourOfDay y para Cell Value simplemente un Count of recordssimple . Ahora esto dará lugar a este panel:

Hay un par de cosas molestas alrededor de esta lente que simplemente me molestan al interpretar. Intentemos limpiarlo un poco. Primero que nada, no me importa demasiado la leyenda, usa el símbolo de arriba con el triángulo, cuadrado, círculo y desactivarlo.

Ahora, la segunda parte que resulta molesta es la organización de los días. Es lunes, miércoles, jueves o cualquier otra cosa, dependiendo de los valores que tengas. El hourOfDay está correctamente ordenado. La forma de ordenar los días es un truco gracioso y eso se llama usar Filters en vez de Top Values. Haz clic en dayOfWeek y selecciona Filters, ahora debería ver así:

Ahora empieza a escribir los días. Un filtro por cada día. "dayOfWeek" : Monday y ponle la etiqueta Monday y repite.

Una advertencia en todo esto es que Spotify proporciona los datos en UTC+0 sin ninguna información de zona horaria. Claro, también proporcionan la dirección IP y el país al que escuchaste, y podríamos deducir la información de la zona horaria a partir de eso, pero eso puede ser un poco raro y para países como EE. UU., que tienen múltiples zonas horarias, puede ser demasiado complicado. Esto es importante porque Elasticsearch y Kibana tienen soporte para zonas horarias y, al proporcionar la zona horaria correcta en el campo @timestamp , Kibana ajustaría automáticamente la hora a la hora de tu navegador.

Debería ver así cuando se finalice, y se nota que soy un oyente muy activo durante el horario laboral y menos los sábados y domingos.

Conclusión

En este blog, profundizamos un poco más en las complejidades que ofrecen los datos de Spotify. Mostramos algunas formas sencillas y rápidas de poner en marcha algunas visualizaciones. Es simplemente asombroso tener tanto control sobre tu propio historial de escucha. Echa un vistazo a las otras partes del serial:

• Parte 1: Cómo crear tu propio Spotify Wrapped in Kibana

• Parte 3: Empleos de población para detección de anomalías

• Parte 4: Detección de relaciones en los datos

• Parte 5: Encontrar a tu mejor amigo musical con vectores

Aquí tienes un diagrama de lo que configuraremos en este tutorial:

Configuración de la inferencia local con Ollama

Ollama es una excelente forma de probar rápidamente un conjunto curado de modelos de open source para la inferencia local y es una herramienta popular para los desarrolladores de IA.

Ejecutar Ollama en recursos físicos

Una instalación local en Mac, Linux o Windows es la forma más sencilla de aprovechar cualquier capacidad de GPU local que tengas, especialmente para aquellos con chips Apple de la serie M. Una vez que tengas Ollama instalado, puedes descargar y ejecutar DeepSeek R1 con el siguiente comando.

Le recomendamos ajustar el tamaño del parámetro a algo que se adapte a su hardware. Los tamaños disponibles se pueden encontrar aquí.

Puede chatear con el modelo en la terminal, pero el modelo sigue ejecutándose cuando sale del comando con CTL+d o escribe “/bye”. Para ver que el modelo aún se está ejecutando, ingrese:

Ejecutar Ollama en un contenedor

Alternativamente, la manera más rápida de ejecutar Ollama es utilizando un motor de contenedores como Docker. Usar la GPU de su máquina local no siempre es tan sencillo, dependiendo de su entorno, pero obtener una configuración de prueba rápida no es difícil siempre que su contenedor tenga la RAM y el almacenamiento para adaptarse a los modelos de varios GB.

Para poner en marcha Ollama en Docker, solo tienes que ejecutar lo siguiente:

Esto creará un directorio llamado “ollama” en el directorio actual y lo montará dentro del contenedor para almacenar la configuración de Ollama y también los modelos. Dependiendo de la cantidad de parámetros utilizados, pueden variar desde algunos GB hasta decenas de GB, así que asegúrese de elegir un volumen con suficiente espacio libre.

Nota: Si tienes una GPU Nvidia en tu máquina, asegúrate de instalar el Nvidia container toolkit y agrega "--gpus=all" al comando docker ejecutar mencionado.

Una vez que el contenedor de Ollama esté en funcionamiento en su máquina, puede descargar un modelo como deepseek-r1 con:

De manera similar al enfoque de hardware dedicado, es posible que desees ajustar el tamaño del parámetro a algo que se adapte a tu hardware. Los tamaños disponibles se pueden encontrar en https://ollama.com/library/deepseek-r1.

Una vez que finalice la extracción del modelo, puede escribir “/bye” para salir de la indicación. Para comprobar que el modelo sigue ejecutándose:

Prueba de nuestra inferencia local con curl

Para probar la inferencia local con curl, puedes ejecutar el siguiente comando. Usamos stream:false para poder leer fácilmente la respuesta narrativa JSON:

Probar Ollama "Compatible con OpenAI" y un aviso RAG

Convenientemente, Ollama también ofrece un endpoint REST que imita el comportamiento de OpenAI para compatibilidad con una amplia gama de herramientas, incluido Kibana.

La prueba de esta indicación más compleja da como resultado un contenido que tiene una sección <think> en la que el modelo ha sido entrenado para razonar el problema.

Conectando Ollama a Kibana

Una excelente manera de usar Elasticsearch es el script de desarrollo “start-local”.

Asegúrate de que tu Kibana y Elasticsearch puedan llegar a tu Ollama en la red. Si estás utilizando una configuración de contenedor local de Elastic stack, quizás deberías reemplazar “localhost” por “host.docker.internal” o “host.containers.internal” para obtener una ruta de red a la máquina hospedada.

En Kibana, navegue a Stack Management > Alertas e información > Conectores.

Qué debes hacer si ves que se trata de una advertencia de configuración común

Necesitará asegurarse de que xpack.encryptedSavedObjects.encryptionKey esté configurado correctamente. Este es un paso común que se omite al ejecutar una instalación local de Docker de Kibana, así que enumeraré los pasos para corregirlo en la sintaxis de Docker.

Asegúrate de mantener tu directorio kibana/config para que los cambios se guarden cuando el contenedor se apague. Mis volúmenes del contenedor de Kibana se ven así en docker-compose.yml:

Ahora puede crear el almacén de claves y poner un valor para que las claves de Connector no se almacenen en texto plano.

Reinicie completamente todo el clúster para asegurarse de que los cambios surtan efecto.

Creación del conector

Desde la pantalla de configuración del conector (en Kibana, navega hasta Stack Management > Alerts and Insights > Connectors), crea un conector y selecciona el tipo “OpenAI”.

Configure el conector con las siguientes configuraciones

• Nombre del conector: DeepSeek (Ollama)

• Seleccione un proveedor de OpenAI: otro (Servicio compatible con OpenAI)

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

  • Ajusta la ruta correcta hacia tu Ollama. Recuerda sustituir host.docker.internal o su equivalente si estás llamando desde dentro de un contenedor.

• Modelo predeterminado: deepseek-r1:7b

• Clave API: invente algo, se necesita una entrada pero el valor no importa

Ten en cuenta que la prueba de un conector personalizado para Ollama en la configuración del conector está rota en 8.17 en este momento, pero se ha corregido en la próxima versión 8.18 de Kibana.

Nuestro conector se ve así:

Incorporación de datos de incrustaciones vectoriales en Elasticsearch

Si ya estás familiarizado con Playground y tienes datos configurados, puedes saltar al paso de Playground que aparece a continuación, pero si necesitas algunos datos de prueba rápidos, debemos asegurarnos de que nuestras API de _inference estén configuradas. A partir de la versión 8.17, las asignaciones de machine learning son dinámicas. Por lo tanto, para descargar y activar el vector denso multilingüe e5, solo necesitaremos ejecutar lo siguiente en las herramientas de desarrollo de Kibana.

Si aún no lo has hecho, esto activará la descarga del modelo e5 desde los repositorios de modelos de Elastic.

A continuación, carguemos un libro de dominio público como nuestro contexto de RAG. Aquí hay un lugar para descargar “Las aventuras de Alicia en el país de las maravillas” del Proyecto Gutenberg: enlace. Guárdelo como un archivo .txt.

Navegue hasta Elasticsearch > Inicio > Cargar un archivo

Seleccione o arrastre y suelte su archivo de texto y luego pulse el botón "Importar".

En la pantalla “Importar datos” seleccione la pestaña “Avanzado” y luego establezca el nombre del índice como “book_alice”.

Selecciona la opción "Add additional field" (Agregar campo adicional), que está justo debajo de "Automatically created fields" (Campos creados de forma automática). Selecciona “Add semantic text field" (Agregar campo de texto semántico) y cambia el endpoint de inferencia a “.multilingual-e5-small-elasticsearch”. Selecciona "Add" (Agregar) y luego "Import" (Importar).

Cuando termine la carga y la inferencia, estaremos listos para dirigirnos a Playground.

Prueba de RAG en Playground

Navega hasta Elasticsearch > Playground en Kibana.

En la pantalla de Playground, debería ver una marca de verificación verde y “LLM Connected” para indicar que un conector está presente. Este es el conector de Ollama que acabamos de crear arriba. Puede encontrar una guía más extensa para Playground aquí.

Haga clic en el botón azul Agregar fuentes de datos y seleccione el índice book_alice que creamos anteriormente u otro índice que haya configurado previamente que utilice API de inferencia para incrustaciones.

Deepseek es un modelo de cadena de pensamiento con fuertes características de alineación. Esto es tanto bueno como malo desde la perspectiva del RAG. El entrenamiento de la cadena de pensamiento puede ayudar a Deepseek a racionalizar declaraciones aparentemente contradictorias en las citas, pero la fuerte alineación con el conocimiento de entrenamiento puede hacer que prefiera su propia versión de los hechos del mundo sobre nuestra base contextual. Si bien es bien intencionada, se sabe que esta fuerte alineación hace que los LLM sean difíciles de instruir cuando se discuten temas en los que nuestro conocimiento privado se contrae o no está bien representado en el conjunto de datos de entrenamiento.

En nuestra configuración de Playground, ingresamos el siguiente mensaje del sistema: “Eres un asistente para tareas de respuesta a preguntas que utiliza pasajes de texto relevantes del libro Alicia en el país de las maravillas” y aceptamos los otros valores predeterminados.

A la pregunta “¿Quién estuvo en la fiesta del té?” obtenemos la respuesta: “Respuesta: La Liebre de Marzo, el Sombrerero y el Lirón estaban en la fiesta del té. [Cita: posición 1 y 2]” lo cual es correcto.

Podemos ver en las etiquetas <think> que Deepseek definitivamente ponderó el contenido de las citas para responder a las preguntas.

Prueba de limitaciones de alineación

Creemos un escenario intelectualmente desafiante para Deepseek como prueba. Crearemos un índice de teorías de conspiración que los datos de entrenamiento de Deepseek saben que no son ciertas.

En las herramientas de desarrollo de Kibana, vamos a crear el siguiente índice y datos:

Estas teorías de conspiración serán nuestro fundamento para el LLM. A pesar de introducir un mensaje agresivo en el sistema, Deepseek no aceptará nuestra versión de los hechos. Si estuviéramos en una situación en la que supiéramos que nuestros datos privados son más confiables, bien fundamentados o alineados con las necesidades de nuestra organización, esto no sería aceptable:

A la pregunta de prueba "¿Son reales los pájaros?" (explicación conoce tu meme) obtenemos la respuesta "En el contexto proporcionado, los pájaros no se consideran reales, pero en realidad, son animales reales. [Contexto: posición 1]". Esta prueba demuestra que DeepSeek R1 es poderoso, incluso en el nivel de parámetro 7B... sin embargo, puede que no sea la mejor opción para RAG, dependiendo de nuestro conjunto de datos.

Entonces, ¿qué aprendimos?

En resumen:

• Ejecutar modelos localmente en herramientas como Ollama es una excelente opción para echar un vistazo al comportamiento del modelo.

• DeepSeek R1 es un modelo de razonamiento, lo que significa que tiene ventajas y desventajas para casos de uso como RAG.

• Playground puede conectarse a marcos de trabajo de alojamiento de inferencia como Ollama a través de una API REST similar a OpenAI, que se está convirtiendo en un estándar de facto en esta era inicial del alojamiento de IA.

En general, estamos impresionados con lo lejos que ha llegado el RAG local aislado o "air gapped". Las herramientas de Elasticsearch, Kibana y los modelos de pesos abiertos disponibles han avanzado significativamente desde que escribimos por primera vez sobre búsqueda de IA que prioriza la privacidad en 2023.

Importación de datos geoespaciales usando Kibana

Los datos que usamos para los ejemplos del blog anterior se basaban en datos que usamos internamente para pruebas de integración. Para tu comodidad, lo incluimos aquí en forma de algunos archivos CSV que se pueden importar fácilmente usando Kibana. Los datos son una mezcla de aeropuertos, ciudades y límites urbanos. Puedes descargar los datos desde:

• airports.csv

  • Este contiene una fusión de tres conjuntos de datos:

    • Aeropuertos (nombres, ubicaciones y datos relacionados) de Natural Earth

    • Ubicaciones de las ciudades según SimpleMaps

    • Elevaciones de aeropuertos según la base de datos global de aeropuertos

• airport_city_boundaries.csv

  • Esto contiene una fusión de nombres de aeropuertos y ciudades mencionados anteriormente con una fuente nueva:

    • Límites de la ciudad según OpenStreetMap

Como puedes imaginar, dedicamos un tiempo a combinar estas fuentes de datos en los dos archivos anteriores, con el objetivo de poder probar las características geoespaciales de ES|QL. Puede que esto no sea exactamente lo mismo que tus necesidades específicas de datos, pero espero que esto te dé una idea de lo que es posible. En individuo, queremos demostrar algunas cosas interesantes:

• Importación de datos con campos geoespaciales junto con otros datos indexables

• Importar datos geo_point y geo_shape y usarlos juntos en consultas

• Importación de datos en dos índices que pueden unir mediante una relación espacial

• Crear una canalización de ingestión para facilitar futuras importaciones (más allá de Kibana)

• Algunos ejemplos de procesadores de ingest, como csv, convert y split

Aunque en este blog hablaremos sobre cómo trabajar con datos CSV, es importante entender que existen varias formas de agregar datos geográficos usando Kibana. Dentro de la aplicación de mapas puedes subir datos delimitados como archivos de forma CSV, GeoJSON y ESRI, y también puedes dibujar formas directamente en el mapa. Para este blog nos centraremos en importar archivos CSV desde la página principal de Kibana.

Importación de aeropuertos

El primer expediente , airports.csv, tiene algunas rarezas interesantes con las que tenemos que lidiar. En primer lugar, las columnas tienen espacios en blanco adicionales que las separan, algo que no es típico de los archivos CSV. En segundo lugar, el campo type es un campo de varios valores, que necesitamos separar en cuerpos separados. Por último, algunos campos no son cadenas y necesitan convertir al tipo correcto. Todo esto se puede hacer empleando la instalación de importación CSV de Kibana.

Empieza en la página principal de Kibana. Hay una sección llamada "Empezar agregando integraciones", que tiene un enlace llamado "Subir un archivo":

Haz clic en este enlace y serás llevado a la página "Subir archivo". Aquí puedes arrastrar y soltar el archivo airports.csv , y Kibana analizará el archivo y te mostrará una vista previa de los datos. Debería detectar automáticamente el delimitador como una coma, y la primera fila como la fila de cabecera. Sin embargo, probablemente no recortó el espacio en blanco extra entre las columnas, ni determinó los tipos de campos, suponiendo que todos los campos sean text o keyword. Tenemos que arreglar esto.

Haz clic Override settings y marca la casilla para Should trim fieldsy Apply para cerrar la configuración. Ahora necesitamos fijar los tipos de los campos. Esto está disponible en la página siguiente, así que adelante y haz clic Import.

Primero elige un nombre de índice y luego selecciona Advanced para acceder a la página de mapeo de campos e ingesta del procesador.

Aquí necesitamos hacer cambios tanto en los mapeos de campos del índice como en la canalización de ingesta para importar los datos. En primer lugar, aunque Kibana probablemente detectó automáticamente el campo scalerank como long, percibió erróneamente los campos location y city_location como keyword. Edítalos para que geo_point, y acabes con mapeos que se ven algo así como:

Aquí tienes cierta flexibilidad, pero ten en cuenta que el tipo que elijas afectará a cómo se indexa el campo y qué tipo de consultas son posibles. Por ejemplo, si dejas location tal keyword no puedes realizar ninguna consulta de búsqueda geoespacial sobre él. De manera similar, si dejas elevation tal text no puedes realizar consultas numéricas por rango.

Ahora es el momento de arreglar la pipeline de ingest. Si Kibana detectó automáticamente scalerank como long anterior, también agregó un procesador para convertir el campo en un long. Necesitamos agregar un procesador similar para el campo elevation , esta vez convirtiéndolo a double. Edita la canalización para cerciorarte de que tienes esta conversión en marcha. Antes de almacenar esto, queremos una conversión más, para dividir el campo de type en varios campos. Agregar un procesador split a la canalización, con la siguiente configuración:

La pipeline final de ingesta debería ser la siguiente:

Ten en cuenta que no agregamos un procesador de conversión para los campos location y city_location . Esto se debe a que el tipo geo_point en el mapeo de campos ya entiende el formato WKT de los datos en estos campos. El tipo geo_point puede comprender una variedad de formatos, incluyendo WKT, GeoJSON y más. Si tuviéramos, por ejemplo, dos columnas en el archivo CSV para latitude y longitude, tuvimos que agregar un procesador script o un set para combinarlas en un solo campo geo_point (por ejemplo, "set": {"field": "location", "value": "{{lat}},{{lon}}"}).

Ahora estamos listos para importar el archivo. Haz clic Import y los datos se importarán al índice con los mapeos y la pipeline de ingesta que acabamos de definir. Si hay errores al absorber los datos, Kibana los reportará aquí, así que puedes editar los datos fuente o la pipeline de ingesta y volver a intentarlo.

Fíjate que se creó una nueva canalización de ingestión. Esto puede comprobar yendo a la sección Stack Management de Kibana y seleccionando Ingest pipelines. Aquí puedes ver la canalización que acabamos de crear y editarla si es necesario. De hecho, la sección Ingest pipelines puede usar para crear y probar canalizaciones de ingest, una función muy útil si planeas hacer ingestas aún más complejas.

Si quieres explorar estos datos inmediatamente, baja a las secciones posteriores, pero si también quieres importar los límites de la ciudad, sigue leyendo.

Importación de los límites de la ciudad

El archivo de límites de la ciudad disponible en airport_city_boundaries.csv es un poco más sencillo de importar que el ejemplo anterior. Contiene un campo city_boundary que es una representación WKT del límite de la ciudad como POLYGONy un campo city_location que es una representación geo_point de la ubicación de la ciudad. Podemos importar estos datos de forma similar a los datos del aeropuerto, pero con algunas diferencias:

• Tuvimos que seleccionar la opción de anulación Has header row ya que no se detectó automáticamente

• No fue necesario recortar campos, ya que los datos ya estaban limpios de espacio en blanco extra

• No tuvimos que editar la tubería de ingesta porque todos los tipos eran de cadena o de tipos espaciales

• Sin embargo, tuvimos que editar los mapeos de campos para establecer el campo city_boundary a geo_shape y el campo city_location a geo_point

Nuestros mapeos finales de campo eran los siguientes:

Como con la importación airports.csv anterior, simplemente haz clic Import para importar los datos al índice. Los datos se importarán junto con los mapeos que editamos y la pipeline de ingesta que Kibana definió.

Explorando datos geoespaciales con herramientas de desarrollo

En Kibana es habitual explorar los datos indexados con "Descubrir". Sin embargo, si tu intención es crear tu propia app usando ES|Consultas QL, podría ser más interesante intentar acceder a la API en bruto de Elasticsearch. Kibana tiene una consola práctica para experimentar escribiendo consultas. Esto se llama la consola Dev Tools y se puede encontrar en la barra lateral de Kibana. Esta consola se comunica directamente con el clúster Elasticsearch y puede usar para ejecutar consultas, crear índices y más.

Prueba lo siguiente:

Esto debería proporcionar los siguientes resultados:

distancia

Abbrev

nombre

Ubicación

país

ciudad

elevación

273418.05776847183

JAMÓN

Hamburgo

POINT (10.005647830925 53.6320011640866)

Alemania

Norderstedt

17.0

337534.653466062

TXL

Berlin-Tegel Int'l

POINT (13.2903090925074 52.5544287044101)

Alemania

Hohen Neuendorf

38.0

483713.15032266214

OSL

Oslo Gardermoen

POINT (11.0991032762581 60.1935783171386)

Noruega

Oslo

208.0

522538.03148094116

BMA

Bromma

POINT (17.9456175406145 59.3555902065112)

Suecia

Estocolmo

15.0

522538.03148094116

ARN

Arlanda

POINT (17.9307299016916 59.6511203397372)

Suecia

Estocolmo

38.0

624274.8274399083

DUS

Düsseldorf Int'l

POINT (6.76494446612174 51.2781820420774)

Alemania

Düsseldorf

45.0

633388.6966435644

PRG

Ruzyn

POINT (14.2674849854076 50.1076511703671)

Chequia

Praga

381.0

635911.1873311149

AMS

Schiphol

PUNTO (4.76437693232812 52.3089323889822)

Países Bajos

Hoofddorp

-3.0

670864.137958866

FRA

Nt'l de Frankfurt

POINT (8.57182286907608 50.0506770895207)

Alemania

Fráncfort

111.0

683239.2529970079

WAW

Okecie Int'l

POINT (20.9727263383587 52.171026749259)

Polonia

Piaseczno

111.0

Visualización de datos geoespaciales con Kibana Maps

Kibana Maps es una herramienta poderosa para visualizar datos geoespaciales. Puede emplear para crear mapas con múltiples capas, cada capa representando un conjunto de datos diferente. Los datos pueden filtrar, agregar y estilizar de diversas maneras. En esta sección, te mostraremos cómo crear un mapa en Kibana Maps usando los datos que importamos en la sección anterior.

En el menú Kibana, navega hasta Analytics->Maps para abrir una nueva vista del mapa. Haz clic en Add Layer y selecciona Documents, eligiendo el airports de vista de datos y luego editando el estilo de capa para colorear los marcadores usando el campo elevation , para que podamos ver fácilmente la altura de cada aeropuerto.

Haz clic en 'Conservar cambios' para almacenar el mapa:

Ahora agrega una segunda capa, esta vez seleccionando la vista de datos airport_city_boundaries . Esta vez, usaremos el campo city_boundary para estilizar la capa y pondremos el color de relleno en azul claro. Esto mostrará los límites de la ciudad en el mapa. Cerciórate de reordenar las capas para que los marcadores del aeropuerto estén encima.

Unirías espaciales

ES|QL no soporta comandos JOIN, pero puedes lograr un caso especial de unión usando el comando ENRICH. Este comando funciona de forma similar a una 'unión por la izquierda' en SQL, permitiéndote enriquecer resultados de un índice con datos de otro índice basar en una relación espacial entre los dos conjuntos de datos.

Por ejemplo, enriquezcamos los resultados de una tabla de aeropuertos con información adicional sobre la ciudad a la que sirven encontrando el límite de la ciudad que contiene la ubicación del aeropuerto, y luego realicemos algunas estadísticas sobre los resultados:

Si ejecutas esta consulta sin preparar primero el índice de enriquecimiento, recibirás un mensaje de error como:

Esto se debe a que, como mencionamos antes, ES|QL no soporta comandos de JOIN verdadero. Una razón importante para ello es que Elasticsearch es un sistema distribuido, y las uniones son operaciones costosas que pueden ser difíciles de escalar. Sin embargo, el comando ENRICH puede ser bastante eficiente, ya que emplea índices de enriquecimiento especialmente preparados que se duplican a lo largo del clúster, permitiendo realizar uniones locales en cada nodo.

Para entender mejor esto, centrémonos en el comando ENRICH de la consulta anterior:

Este comando instruye a Elasticsearch para enriquecer los resultados recuperados del índice de airports y realizar una unión intersects entre el campo city_location del índice original y el campo city_boundary del índice de airport_city_boundaries , que usamos en algunos ejemplos anteriores. Pero parte de esta información no es claramente visible en esta consulta. Lo que sí vemos es el nombre de una política de enriquecimiento city_boundaries, y la información que falta está encapsulada dentro de esa definición de política.

Aquí podemos ver que realizará una consulta geo_match (intersects es el valor predeterminado), el campo a emparejar es city_boundary, y los enrich_fields son los campos que queremos agregar al documento original. Uno de esos campos, el region , se usó como clave de agrupación para el comando STATS , algo que no podríamos hacer sin esta capacidad de 'unión izquierda'. Para más información sobre las pólizas de enriquecimiento, consulte la documentación de enriquecimiento.

Los índices y políticas de enriquecimiento en Elasticsearch fueron diseñados originalmente para enriquecer datos en el momento del índice, empleando datos de otro índice de enriquecimiento preparado. En ES|QL, sin embargo, el comando ENRICH funciona en el momento de la consulta y no requiere el uso de pipelines de ingest. Esto lo hace efectivamente bastante similar a un LEFT JOINSQL, excepto que no puedes unir dos índices cualquiera, solo un índice normal a la izquierda con un índice enrich especialmente preparado a la derecha.

En cualquier caso, ya sea para canalizaciones de ingesta o para su uso en ES|QL, es necesario realizar algunos pasos preparatorios para establecer el índice de enriquecimiento y la póliza. Ya importamos el índice de airport_city_boundaries arriba, pero este no se puede usar directamente como índice de enriquecimiento en el comando ENRICH . Primero necesitamos realizar dos pasos:

• Crea la política de enriquecimiento descrita anteriormente para definir el índice fuente, el campo en el índice fuente para coincidir y los campos que devolver una vez emparejados.

• Ejecuta esta política para crear el índice enriquecido. Esto construirá un índice interno especial, leyendo el índice original en una estructura de datos más eficiente que se copia a través del clúster.

La política de enriquecimiento puede crear usando el siguiente comando:

Y la política puede ejecutar usando el siguiente comando:

Ten en cuenta que si alguna vez cambias el contenido del índice de airport_city_boundaries , tendrás que volver a ejecutar esta política para ver los cambios reflejados en el índice de enriquecimiento. Ahora vamos a ejecutar el ES| originalConsulta QL de nuevo:

Esto devuelve las 5 regiones con más aeropuertos, junto con el centroide de todos los aeropuertos que tienen regiones coincidentes, y el rango en longitud de la representación WKT de los límites de la ciudad dentro de esas regiones:

centroide

Recuento

región

POINT (-12.139086859300733 31.024386116624648)

126

nulo

POINT (-83.10398317873478 42.300230911932886)

3

Detroit

POINT (39.74537850357592 47.21613017376512)

3

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

POINT (-156.80986787192523 20.476673701778054)

3

Hawai

POINT (-73.94515332765877 40.70366442203522)

3

Ciudad de Nueva York

POINT (-83.10398317873478 42.300230911932886)

3

Detroit

POINT (-76.66873019188643 24.306286952923983)

2

Nueva Providencia

POINT (-3.0252167768776417 51.39245774131268)

2

Cardiff

POINT (-115.40993484668434 32.73126147687435)

2

Municipio de Mexicali

POINT (41.790108773857355 50.302146775648)

2

Центральный район

POINT (-73.88902732171118 45.57078813901171)

2

Montréal

También puede que notes que la región más común era null. ¿Qué podría implicar esto? Recuerda que comparé este comando con un 'left join' en SQL, lo que significa que si no se encuentra ningún límite de ciudad coincidente para un aeropuerto, el aeropuerto sigue devolver pero con valores null para los campos del índice de airport_city_boundaries . Resulta que hubo 125 aeropuertos que no encontraron city_boundarycoincidentes, y un aeropuerto con un coincidente donde el campo de region estaba null. Esto llevó a un recuento de 126 aeropuertos sin region en los resultados. Si tu caso de uso requiere que todos los aeropuertos puedan coincidir con un límite de ciudad, eso requeriría buscar datos adicionales para cubrir los huecos. Sería necesario determinar dos cosas:

• qué registros en el índice de airport_city_boundaries no tienen campos city_boundary

• qué registros en el índice de airports no coinciden usando el comando ENRICH (es decir, no intersectar)

Usando ES|QL para datos geoespaciales en Kibana Maps

Kibana agregó soporte para Spatial ES|QL en la aplicación de Mapas. Esto significa que ahora puedes usar ES|QL para buscar datos geoespaciales en Elasticsearch y visualizar los resultados en un mapa.

Hay una nueva opción de capa en el menú de agregar capas, llamada "ES|QL". Como todas las características geoespaciales descritas hasta ahora, esto está en "vista previa técnica". Seleccionar esta opción te permite agregar una capa al mapa basada en los resultados de un ES|Consulta QL. Por ejemplo, podrías agregar una capa al mapa que muestre todos los aeropuertos del mundo.

O podrías agregar una capa que muestre los polígonos del índice de airport_city_boundaries , o mejor aún, ¿qué tal esa compleja consulta de ENRICH arriba que genera estadísticas sobre cuántos aeropuertos hay en cada región?

¿Qué sigue ahora?

El anterior blog de búsqueda geoespacial se centraba en el uso de funciones como ST_INTERSECTS para realizar búsquedas, disponibles en Elasticsearch desde la versión 8.14. Y este blog te muestra cómo importar los datos que usamos para esas búsquedas. Sin embargo, Elasticsearch 8.15 venía con una función especialmente interesante: ST_DISTANCE que puede usar para realizar búsquedas espaciales eficientes, ¡y este será el tema del próximo blog!