Elasticsearch rechazaba métricas que llegaban con retraso. Esos rechazos hicieron que el pipeline se retrasara, lo que dio como resultado más datos tardíos, lo que desencadenó aún más rechazos. Finalmente, el pipeline se detuvo por completo.

Tuvimos que restaurar desde un snapshot, reindexar los datos y rediseñar el pipeline de ingesta para recuperarnos.

La causa raíz no era la gestión del ciclo de vida de los índices (ILM) en sí. Eran los flujos de datos temporales (TSDS) y cómo imponen índices de respaldo acotados en el tiempo.

TSDS puede reducir las necesidades de almacenamiento para las métricas en un 40–70 %, pero los cambios de arquitectura que hacen que TSDS sea eficiente también alteran el comportamiento de los índices con el tiempo. Esos cambios importan al diseñar políticas de ILM o cuando tus Pipelines de ingesta pueden generar datos que llegan con retraso.

TL;DR

Al usar TSDS:

• Los índices de respaldo solo aceptan documentos dentro de una ventana de tiempo específica.

• Si llegan datos tardíos después de que un índice pasa a frío o congelado, Elasticsearch rechaza esos documentos o los envía al almacén de fallas, si está configurado.

Regla de diseño:

¿Qué es un flujo de datos temporales?

Un flujo de datos temporales (TSDS) es un flujo de datos especializado optimizado para datos de métricas. Los datos se distribuyen de manera que los documentos relacionados se encuentren dentro de los mismos fragmentos, lo que optimiza su búsqueda y recuperación. Así es como lo hace Elasticsearch:

Cada documento contiene:

• Una marca de tiempo.

• Campos de dimensión que identifican las series temporales.

• Campos métricos que representan valores medidos.

Entre los ejemplos, se incluyen los siguientes:

• Uso de CPU por host.

• Latencia de las solicitudes por servicio.

• Lecturas de temperatura por sensor.

Las dimensiones identifican lo que queremos medir, mientras que las métricas representan valores que cambian con el tiempo.

Dimensiones

Las dimensiones describen la entidad medida.

Ejemplos:

Los definimos en mapeos con:

Métricas

Las métricas representan valores numéricos y se definen mediante:

Tipos comunes de métricas:

• Indicador: valores que suben y bajan.

• Contador: valores que aumentan hasta que se reinician.

Elastic Agent recopila principalmente métricas y datos de logs, por lo que, incluso si no has habilitado ningún índice TSDS manualmente, puedes tenerlos aún en tu clúster.

El campo _tsid

Elasticsearch genera internamente un valor _tsid a partir de campos dimensionales. Esto permite que los documentos con dimensiones idénticas se dirijan al mismo shard, lo que mejora:

• Compresión.

• Localidad de búsqueda.

• Rendimiento de agregación.

La diferencia clave: índices de respaldo limitados en el tiempo

Los flujos de datos tradicionales siempre escriben en el índice de respaldo más reciente, llamado índice de escritura, pero TSDS se comporta de manera diferente.

Cada índice de respaldo TSDS tiene una ventana de tiempo definida y solo acepta documentos con @timestamp valores que se encuentren en esa ventana:

Cuando se indexa un documento, Elasticsearch lo dirige al índice de respaldo responsable de esa marca de tiempo, lo que significa que, a diferencia de los índices tradicionales, un TSDS puede escribir en varios índices de respaldo al mismo tiempo.

Por ejemplo:

• Datos en tiempo real → índice más reciente.

• Datos tardíos → índice anterior que abarca ese intervalo de tiempo.

Diseño para datos con retraso

Las pipelines de ingesta reales rara vez entregan métricas perfectamente a tiempo. Las métricas pueden retrasarse por interrupciones de la red, retrasos en el camino, ingesta por batch y pérdida de dispositivos periféricos, que se vuelven a conectar y comienzan a ponerse al día.

Los índices tradicionales absorben silenciosamente esos retrasos. TSDS no lo hace.

Si la marca de tiempo de un documento queda fuera del intervalo de índices de respaldo con capacidad de escritura, Elasticsearch lo rechaza, lo que significa que tu política de ILM debe tener en cuenta los datos que llegan con retraso.

La restricción crítica

Los índices de respaldo deben mantenerse con permisos de escritura el tiempo suficiente para aceptar datos tardíos.

En términos prácticos:

Debido a que ILM mide las antigüedades desde el desplazamiento, la regla operativa se convierte en:

Por ejemplo, si las métricas pueden llegar con hasta seis horas de retraso, los índices deben permanecer editables al menos seis horas después de la transferencia.

No tener en cuenta esta restricción fue exactamente lo que causó la falla de ingesta descrita anteriormente. Los datos que llegaban tarde se dirigieron a un índice anterior, que ya estaba en el nivel frío y, por tanto, bloqueaba la escritura.

Gestión de documentos rechazados

Cuando TSDS rechaza un documento, Elasticsearch devuelve un error, lo que indica que la marca de tiempo no está dentro del rango de índices de escritura. La forma en que tu pipeline de ingesta maneja ese error determina si pierdes datos o si la ingesta se detiene.

El mecanismo principal para manejar documentos rechazados es el almacén de fallas.

Almacén de fallas (recomendado en Elasticsearch 9.1+)

Elasticsearch 9.1 introdujo el almacén de fallas, que captura automáticamente los documentos rechazados. En lugar de devolver errores a los clientes, Elasticsearch escribe los documentos rechazados en un índice de fallas dedicado dentro del flujo de datos.

Puedes inspeccionar las fallas usando:

Usar el almacén de fallas evita que los pipelines de ingesta se bloqueen por errores de rechazo, a la vez que conserva los datos fallidos para analizarlos o reindexarlos.

Monitoreo de problemas de rechazo

Los problemas de retraso suelen aparecer primero como anomalías de ingesta. Puedes notarlos primero como:

• Caídas repentinas en la tasa de indexación.

• Aumentos repentinos en el número de documentos rechazados.

• Una cantidad cada vez mayor de entradas del almacén de fallas.

• Discrepancias entre el número de entradas y salidas del pipeline.

Alertar sobre estas señales permite a los operadores detectar problemas antes de que los pipelines se detengan. Se pueden utilizar flujos de trabajo, tareas de machine learning y otros mecanismos para automatizar la detección y la notificación.

Lista de verificación de migración para TSDS + ILM

Si estás migrando un cluster de métricas a TSDS, introduciendo la organización en niveles con ILM o actualizando a una versión de Elasticsearch en la que las métricas son TSDS por defecto, revisa primero estos elementos.

1. Mide la latencia de la ingesta

Antes de cambiar las políticas de ILM, determina:

• Retraso normal de ingesta.

• Retraso en el peor de los casos durante incidentes.

• Retrasos causados por pipelines de batch.

Tu diseño de ILM debe contemplar el retraso máximo realista.

2. Verifica las ventanas de tiempo de indexación

Inspecciona tus índices de respaldo TSDS:

Busca:

• time_series.start_time

• time_series.end_time

Estos límites determinan qué índices pueden aceptar documentos. Entender estas ventanas puede ayudarte a determinar cuán tarde pueden llegar los datos antes de que se rechacen.

3. Dimensiona el nivel caliente para llegadas tardías

Garantiza que los índices de respaldo permanezcan con permisos de escritura el tiempo suficiente para los datos retrasados.

Regla operativa:

• warm_min_age > rollover_max_age + maximum_expected_lateness

Recuerda, los índices deben permanecer en modo de escritura durante al menos seis horas si las métricas pueden llegar con seis horas de retraso.

4. Decide cómo manejar los documentos rechazados

Elige una estrategia antes de habilitar TSDS:

• Almacén de fallas (recomendado en Elasticsearch 9.1+).

• Cola de mensajes no procesados de Logstash.

• Índice de respaldo para retrasos.

• Aceptar la pérdida de datos limitada.

5. Monitorea el estado de la ingesta

Agrega alertas para:

• La tasa de indexación disminuye.

• Documentos rechazados.

• Crecimiento del almacén de fallas.

• Desajustes de entrada/salida en la pipeline.

Los problemas de datos tardíos a menudo aparecen primero como anomalías de ingesta.

Resumen

Los flujos de datos temporales ofrecen importantes mejoras de almacenamiento y rendimiento para las cargas de trabajo de métricas, pero introducen un cambio arquitectónico importante: los índices de respaldo están acotados en el tiempo, lo que afecta el comportamiento de ILM.

Al usar TSDS:

• Los índices deben mantenerse con permisos de escritura el tiempo suficiente para aceptar datos tardíos.

• Los pipelines de ingesta deben gestionar los documentos rechazados de forma segura.

La regla clave a recordar es:

Si diseñas políticas de ILM teniendo en cuenta esa limitación, TSDS funciona muy bien para cargas de trabajo de métricas.

Sin embargo, si lo ignoras, tu pipeline de ingesta puede descubrir esos límites de tiempo de la manera difícil.

Tradicionalmente, gestionar los rastreadores era un proceso manual y propenso a errores. Implicaba editar configuraciones directamente en la interfaz y luchar con clonar configuraciones de rastreo, retrocesos, versionear y más. Tratar las configuraciones de rastreadores como código resuelve esto al proporcionar los mismos beneficios que esperamos en el desarrollo de software: repetibilidad, trazabilidad y automatización.

Este flujo de trabajo facilita la incorporación del Open Sitio web Crawler a tu pipeline CI/CD para rollbacks, copias de seguridad y migraciones, tareas que eran mucho más complicadas con los Elastic Crawlers anteriores, como el Elastic Sitio web Crawler o el App Search Crawler.

En este artículo, vamos a aprender cómo:

• Gestiona nuestras configuraciones de rastreo usando GitHub

• Tener una configuración local para probar pipelines antes de desplegar

• Crea una configuración de producción para ejecutar el rastreador sitio web con nuevos ajustes cada vez que enviemos cambios a nuestra rama principal

Puedes encontrar el repositorio de proyectos aquí. Según escribo, estoy usando Elasticsearch 9.1.3 y Open Sitio web Crawler 0.4.2.

Prerrequisitos

• Escritorio Docker

• Instancia de Elasticsearch

• Máquina virtual con acceso SSH (por ejemplo, AWS EC2) y Docker instalados

Pasos

1. Estructura de carpetas

2. Configuración del orugador

3. Docker-compose (entorno local)

4. Acciones en Github

5. Pruebas locales

6. Desplegando a la producción

7. Realización de cambios y re-despliegue

Estructura de carpetas

Para este proyecto, tendremos la siguiente estructura de archivos:

Configuración del orugador

Bajo crawler-config.yml, pondremos lo siguiente:

Esto se rastreará desde https://sitio web-scraping.dev/products, un sitio simulado de productos. Solo rastrearemos las tres primeras páginas del producto. La configuración max_crawl_depth evitará que el rastreador descubra más páginas de las definidas como seed_urls al no abrir los enlaces que contienen.

Elasticsearch host y api_key se llenarán dinámicamente dependiendo del entorno en el que ejecutemos el script.

Docker-compose (entorno local)

Para la docker-compose.yml, local desplegaremos el rastreador y un único clúster Elasticsearch + Kibana, para poder visualizar fácilmente los resultados del rastreo antes de desplegarlos en producción.

Fíjate en cómo el rastreador espera hasta que Elasticsearch esté listo para ejecutar.

Acciones en Github

Ahora necesitamos crear una acción en GitHub que copie la nueva configuración y ejecute el rastreador en nuestra máquina virtual en cada envío a main. Esto garantiza que siempre tengamos la última configuración desplegada, sin tener que entrar manualmente en la máquina virtual para actualizar archivos y ejecutar el rastreador. Vamos a usar AWS EC2 como proveedor de máquinas virtuales.

El primer paso es agregar el host (VM_HOST), el usuario de la máquina (VM_USER), la clave SSH RSA (VM_KEY), el host de Elasticsearch (ES_HOST) y la clave API de Elasticsearch (ES_API_KEY) a los secretos de acción de GitHub:

De este modo, la acción podrá acceder a nuestro servidor para copiar los archivos nuevos y ejecutar el rastreo.

Ahora, creemos nuestro archivo .github/workflows/deploy.yml :

Esta acción ejecutará los siguientes pasos cada vez que empujemos cambios en el archivo de configuración del rastreador:

1. Llenar el host y la clave API de Elasticsearch en la configuración de yml

2. Copia la carpeta config a nuestra máquina virtual

3. Conéctate vía SSH a nuestra máquina virtual

4. Ejecuta el rastreo con la configuración que acabamos de copiar del repositorio

Pruebas locales

Para probar nuestro rastreador localmente, creamos un script bash que llena el host de Elasticsearch con el local de Docker y comienza un rastreo. Puedes ejecutar ./local.sh para ejecutarlo.

Veamos Kibana DevTools para confirmar que el web-crawler-index se rellenó correctamente:

Desplegando a la producción

Ahora estamos listos para enviar a la rama principal, que desplegará el rastreador en tu máquina virtual y comenzará a enviar registros a tu instancia Serverless Elasticsearch.

Esto activará la Acción de GitHub, que ejecutará el script de despliegue dentro de la máquina virtual y comenzará a rastrear.

Puedes confirmar que la acción se ejecutó yendo al repositorio de GitHub y visitando la pestaña "Acciones":

Realización de cambios y re-despliegue

Algo que quizá notaste es que el price de cada producto forma parte del cuerpo del documento. Lo ideal sería almacenar el precio en un campo aparte para poder aplicar filtros sobre él.

Vamos a agregar este cambio al archivo crawler.yml para usar reglas de extracción que extraigan el precio de la clase CSS de product-price :

También vemos que el precio incluye un signo de dólar ($), que debemos eliminar si queremos hacer consultas por rango. Podemos usar una canalización de ingesta para eso. Ten en cuenta que lo estamos haciendo referencia en nuestro nuevo archivo de configuración del rastreador arriba:

Podemos ejecutar ese comando en nuestro clúster de Elasticsearch en producción. Para el desarrollo, al ser efímero, podemos hacer que la creación de pipeline forme parte del archivo docker-compose.yml agregando el siguiente servicio. Ten en cuenta que también agregamos un depends_on al servicio de rastreo para que empiece después de que la tubería se creó con éxito.

Ahora vamos a ejecutar `./local.sh` para ver el cambio localmente:

¡Bien! Ahora impulsemos el cambio:

Para confirmar que todo funciona, puedes comprobar tu Kibana de producción, que debería reflejar los cambios y mostrar el precio como un nuevo campo sin el signo del dólar.

Conclusión

El Elastic Open Sitio web Crawler te permite gestionar tu rastreador como código, lo que significa que puedes automatizar toda la pipeline —desde el desarrollo hasta el despliegue— y agregar entornos locales efímeros y pruebas programáticas contra los datos rastreados, por nombrar algunos ejemplos.

Se te invita a clonar el repositorio oficial y empezar a indexar tus propios datos usando este flujo de trabajo. También puedes leer este artículo para aprender a realizar búsqueda semántica en índices producidos por el rastreador.

1. Uso de la API _mapping para recuperar información de campos

2. Uso de la API _search para mostrar los valores de los campos

3. Visualización de subcampos

4. _source sintética

5. Campos de tiempo de ejecución

1. Uso de la API _mapping para recuperar información de campo

La API _mapping permite recuperar la definición de mapeo para un índice o varios índices. Esto incluye información sobre los campos, sus tipos de datos y otras propiedades. Para recuperar el mapeo de un índice específico, emplee la siguiente petición:

Por ejemplo, si tienes un índice llamado my_index, puedes recuperar su mapeo con la siguiente petición:

La respuesta incluirá la definición de mapeo para el índice, que contiene información sobre los campos y sus propiedades.

También es posible recuperar el mapeo de un campo específico. Esto puede ser útil si tu mapeo es bastante grande y solo quieres centrarte en un campo específico. Para recuperar el mapeo de un campo específico, emplee la siguiente petición:

También puedes recuperar las asignaciones de varios campos separando sus nombres con comas, como en la siguiente petición:

2. Uso de la API _search para mostrar los valores de los campos

Para mostrar los valores de los campos en un índice de Elasticsearch, puedes usar la API _search . La API _search te ofrece múltiples formas de controlar qué campos se devuelven; Los dos principales son:

1. _source: El campo _source contiene el cuerpo original del documento JSON exactamente como estaba indexado, incluyendo cualquier cambio realizado por las canalizaciones de ingestión o pasos de preprocesamiento. Para mostrar campos específicos del documento fuente, implementa filtrado de fuentes como veremos a continuación.

2. fields: El parámetro fields te permite recuperar campos específicos de tus documentos al realizar una búsqueda, basándote en el mapeo de índice. A diferencia de _source, fields también puede devolver valores de campos almacenados, valores de documentación o campos de ejecución sin referenciar la _source, aunque para campos estándar sin valores de documento ni configuraciones almacenadas, vuelve a _source. Esto puede aportar muchos beneficios como el rendimiento y más, como veremos a continuación.

Uso del campo _source

Por defecto, la API _search devuelve el campo _source , que contiene el documento JSON original que se indexó. Para mostrar campos específicos, puedes agregar filtros en el parámetro _source de la solicitud de búsqueda; Esto se llama filtrado de fuente.

Aquí tienes un ejemplo de una solicitud de búsqueda que devuelve los valores de los campos title y author para documentos en el índice my_index :

En este ejemplo, el parámetro _source especifica los campos que se deben devolver.

Si necesitas aún más control, puedes usar las propiedades de includes y excludes del objeto _source. Por ejemplo, la consulta siguiente devuelve el campo title de nivel superior y todos los subcampos de author excepto author.description.

En este ejemplo, usamos el patrón author.* para recuperar todos los subcampos directos del objeto author . Luego excluimos explícitamente author.description para que solo se devuelvan los otros campos de autor. Ten en cuenta que esto no tiene mejoras de rendimiento ya que aún tiene que cargar y analizar el JSON de origen, pero puede reducir el tamaño de la respuesta enviada por la red.

Uso del parámetro de campos

Puedes usar el parámetro fields para filtrar los campos que aparecen en la respuesta de búsqueda. Emplear fields _source ofrece varios beneficios, entre ellos:

• Mejora de rendimiento: fields puede devolver valores directamente desde campos almacenados o valores de documentos sin tener que cargar toda la _source, haciendo que el tamaño de la carga útil de respuesta sea menor.

• Salida formateada: Para campos estándar, fields puede recurrir a _source para obtener los valores, pero revisa el mapeo del índice para formatear correctamente la salida, como las fechas formateadas, haciéndolas consistentes con lo que se usa para agregaciones y ordenación.

• Acceso a campos de tiempo de ejecución: fields puede devolver campos de tiempo de ejecución, que no existen en el _sourceoriginal.

• Aquí se pueden encontrar más beneficios.

Por ejemplo, para devolver solo los campos title y author en el índice my_index , puedes usar la siguiente solicitud de búsqueda:

En la consulta anterior, ponemos el campo _source en false para no devolver el documento fuente. Esto puede minimizar significativamente el tamaño de la carga útil para la respuesta, pero recuerda que esto solo funciona porque los campos title y author son del tipo keyword campo, que doc_values habilitaron por defecto. Si el campo no tiene doc_values activado y el _source está configurado como falso, Elasticsearch no tendría forma de recuperarlos y se omitiría en la respuesta.

Es importante señalar que la respuesta fields siempre devuelve un array de valores para cada campo, incluso si solo hay un único valor. Esto se debe a que Elasticsearch no tiene un tipo de array dedicado, y cualquier campo puede tener varios valores. Para más información sobre los arrays en Elasticsearch, haz clic aquí.

Otras formas de recuperar campos

Aunque recuperar campos usando _source o fields son los métodos recomendados, existen diferentes métodos disponibles para casos de uso específicos, como:

Campos de valor de documentos: Si quieres evitar _source por completo, puedes buscar usando el parámetro docvalue_fields. Los valores de documentación almacenan los mismos valores de campo que _source pero en una estructura de datos en disco, optimizada para ordenar y agregar.

Como está separado de los valores almacenados con _source, puedes aplicar campos específicos sin cargar toda la _source. Esto es útil si consultas documentos grandes pero solo necesitas unos pocos campos pequeños que soporten valores de documentos. Otro caso de uso para usar docvalue_fields es cuando quieres usar formato personalizado en campos date y numeric , como veremos en el ejemplo más abajo.

Ten en cuenta que esto solo funciona para campos que activas doc_values o para tipos de campos que lo tienen activado por defecto, como keyword, date, tipos numéricos y boolean, no para text o annotated_text.

En este ejemplo, usamos el parámetro docvalue_fields para recuperar los campos title, author, y published sin cargar el documento completo de _source :

Cuando se ejecuta esta consulta, Elasticsearch toma los valores directamente de su almacenamiento columnar en disco en lugar de referenciar el _source de cada documento. El campo published se devuelve con el formato epoch_millis en lugar del formato por defecto, gracias al parámetro format proporcionado en la consulta.

Campos almacenados: Si marcas explícitamente campos específicos como almacenados en el mapeo, puedes usar el parámetro stored_fields para filtrar esos campos. Esto es útil si quieres respuestas ligeras solo con esos campos específicos o para campos que almacenaste deliberadamente para recuperarlos después. Se almacena por separado de _source, por lo que este método también es útil para evitar la necesidad de cargar _source.

Es importante señalar que esta opción está desactivada por defecto y generalmente no se recomienda. Emplea filtrado de fuentes para devolver ciertos subconjuntos del documento fuente original.

En la consulta de ejemplo a continuación, usamos el parámetro stored_fields para recuperar el campo summary , que tiene la configuración de mapeo de índice "store”: true.

Cuando se ejecuta esta consulta, Elasticsearch busca si este campo está marcado con ”store”: true, si no lo encuentra, se saltará el campo por completo.

3. Visualización de subcampos

Si tu índice contiene subcampos, puedes usar la notación de puntos para especificar el camino de campo en el parámetro fields . Ten en cuenta que los subcampos son diferentes del tipo de campo anidado. Por ejemplo, si tienes un subcampo llamado address.city, puedes incluirlo en la respuesta de búsqueda así:

En este ejemplo, la respuesta de búsqueda incluirá los valores de los campos title, author address.city .

4. _source sintético

Si quieres mantener la funcionalidad de usar _source pero también ahorrar espacio en disco, tienes la opción de usar _source sintético en tu mapeo de índice. La_source sintética es una función que permite a Elasticsearch reconstruir el _source a partir de datos existentes como campos almacenados y valores de documentos, incluso cuando _source está desactivado. Esto te permite ahorrar mucho espacio de almacenamiento a cambio de velocidades ligeramente menores en el momento de la consulta, ya que la reconstrucción se realiza sobre la marcha. Activa esta función usando los valores que aparecen a continuación en la configuración de tu índice:

Algunos beneficios de usar _source sintéticos incluyen: visualización completa del documento al usar la API _search , filtrado de código fuente y compatibilidad con otras funciones y herramientas como Kibana que esperan _source estén disponibles, todo ello evitando la necesidad de almacenar el documento completo _source .

5. Campos de tiempo de ejecución

Los campos de ejecución te permiten definir campos guionizados en el momento de la consulta o en tu mapeo de índice bajo un bloque de ejecución. Estos campos nunca se indexan, por lo que agregar un campo en tiempo de ejecución no aumenta el tamaño del índice pero nunca aparecerá en _source. Los campos de ejecución definidos en el mapeo son persistentes y están disponibles para todas las consultas, mientras que los campos de ejecución definidos en el momento de la consulta son temporales y solo están disponibles en esa solicitud de búsqueda.

El principal beneficio de usar campos de tiempo de ejecución es la posibilidad de agregar campos a documentos luego de haberlos ingerido, simplificando así tus decisiones de mapeo. Los campos de ejecución también son ideales para enriquecer tus documentos con valores que no existen en el documento original pero que se generan mediante un script, como formatear una cadena o calcular un puntaje.

También cabe destacar que los campos de ejecución pueden perjudicar el rendimiento, ya que será necesario ejecutar un script para cada documento del conjunto de resultados. Para recuperar un campo de ejecución, también puedes usar el parámetro fields en la API _search .

Conclusión

Mostrar campos de un índice de Elasticsearch puede ir desde simplemente recuperar valores usando el mapeo de índice o el _source, hasta métodos más avanzados usando campos fields, docvalue_fieldso en tiempo de ejecución para mayor control y eficiencia. Comprender los compromisos entre diferentes métodos es clave para optimizar tus experiencias de búsqueda. Ya sea que estés optimizando cargas útiles, enriqueciendo documentos o empleando _source sintéticos para ahorrar espacio, Elasticsearch te ofrece múltiples herramientas y funciones para encontrar los datos que necesitas, de la manera que necesitas. Estas técnicas pueden ayudarte a entender la estructura de tus datos, identificar campos específicos y solucionar problemas.

Logstash incluye varios filtros integrados para tareas comunes como análisis sintáctico, enriquecimiento y modificación de datos. Pero a veces te encontrarás con escenarios que requieren una lógica personalizada que va más allá de lo que estos filtros estándar pueden ofrecer. Aquí es donde entra el plugin de filtro Ruby .

El plugin de filtro Ruby te permite ejecutar código Ruby personalizado directamente dentro de tu pipeline de Logstash. Cuando los filtros estándar no son suficientes, el filtro Ruby te permite manejar transformaciones complejas de datos, implementar lógica de negocio personalizada o integrarte con sistemas externos.

En este blog, exploraremos cómo usar los filtros Ruby, desde el uso básico hasta el avanzado.

¿Cuándo deberías usar el filtro Ruby?

Como arquitecto consultor de Elastic, a menudo veo a clientes que emplean Logstash para la cadena de procesamiento de datos, aunque hoy en día no es un motor de procesamiento de datos de última generación. A menudo tienen dificultades con las limitaciones de los filtros estándar cuando se trata de manipulación compleja de datos o lógica personalizada. En estos casos, el filtro Ruby puede ayudar a superar esos desafíos.

El filtro Ruby es útil cuando los filtros Logstash estándar no pueden cumplir tus requisitos específicos. Aquí tienes algunos casos de uso comunes:

• Manipulación profunda de datos anidados: Modificar estructuras JSON complejas, arrays dentro de arrays o reestructurar dinámicamente los datos en función del contenido

• Procesamiento avanzado de cadenas: Analizar y extraer datos estructurados de texto no estructurado

• Implementación de lógica de negocio compleja: Crear transformaciones personalizadas que requieran lógica condicional, bucles o cálculos complejos

Uso básico

Empecemos con un ejemplo sencillo para entender cómo funciona el filtro Ruby.

Configuración del filtro Ruby

Cuando crees una pipeline de Logstash, deberías colocar el archivo de configuración en el directorio /etc/logstash/conf.d . Alternativamente, puedes usar -f opción para especificar la ruta al archivo de configuración cuando arranques Logstash manualmente, para que puedas experimentar fácilmente con tus pipelines.

El archivo de configuración debería tener una extensión .conf .

Para usar el filtro Ruby, define un filtro ruby en la sección de filtros de tu archivo de configuración de la tubería Logstash (*.conf). Aquí tienes un ejemplo básico:

Este filtro Ruby en línea define una instancia de filtro Ruby dentro de tu configuración de Logstash. El parámetro code proporciona el script Ruby en línea que Logstash ejecutará para cada evento procesado por este filtro. Dentro de ese script, hay una variable event disponible que representa el propio evento. El objeto evento contiene los datos originales enviados a Logstash y cualquier campo adicional creado durante las etapas de filtro de Logstash. Puedes acceder a esos campos a través de la API de eventos de Logstash como event.get() y event.set(). En este código de ejemplo, event.set('new_field', 'Hello from Ruby!') establecer un nuevo campo llamado new_field al valor de cadena Hello from Ruby!. Puedes agregar cualquier otro código en este bloque de code según lo necesites.

Ten en cuenta que este objeto event no es un objeto hash de Ruby habitual, aunque actúa como un contenedor de datos clave-valor. Consulta esta documentación oficial para saber más sobre la API de eventos.

Externalizar la escritura Ruby

Para transformaciones simples, el código Ruby en línea es cómodo. Pero, para lógica compleja o funciones reutilizables, se recomienda mover el código a un script Ruby externo. Esto mejora la mantenibilidad y mantiene limpia la configuración de tu pipeline de Logstash.

Primero, crea un script Ruby y almacénalo como my_ruby_script.rb. El script debe definir un método filter que procese el evento. Toma un objeto evento como argumento, que representa el evento actual que se está procesando. El método filter necesita devolver un serial de eventos para emitir. Para eliminar el evento, devuelvo un array vacío.

Por ejemplo, el siguiente script lee el campo message , calcula su longitud y almacena el resultado en un nuevo campo llamado message_length.

A continuación, configura la configuración del filtro Ruby para que haga referencia al script usando la opción path . Esto indica a Logstash que cargue y ejecute el script externo. Al usar scripts externos, cerciórate de que el archivo existe y tiene las licencias correctas.

Ahora, cada evento se pasa al método filter en my_ruby_script.rb y es procesado por él.

Este enfoque te ayuda a gestionar la lógica compleja de forma más eficaz, facilitando probar, depurar y reutilizar tu código Ruby.

Uso avanzado

En esta sección, exploraremos algunos ejemplos avanzados de cómo usar el filtro Ruby en Logstash. Estos ejemplos demostrarán cómo realizar transformaciones de datos, enriquecer eventos e implementar lógica personalizada usando Ruby.

Manipulación de estructuras de datos anidadas

Un evento Logstash es la estructura de datos central que procesa Logstash. Puede contener varios campos, incluyendo estructuras de datos anidadas como arrays y hashes. El filtro Ruby te permite manipular fácilmente estas estructuras anidadas.

El filtro Ruby puede manejar estructuras de datos anidadas, como hashes y arrays, permitiéndote modificar o agregar campos dentro de estas estructuras. Esto es útil cuando se trata de formatos de datos complejos como JSON.

Este ejemplo incluye un objeto JSON anidado en los datos de entrada. El filtro Ruby modifica los datos anidados agregando un nuevo par clave-valor. Este tipo de manipulación para datos anidados no es posible con los filtros Logstash estándar, lo que convierte al filtro Ruby en una opción útil para estructuras de datos complejas.

Dividir un solo evento en varios eventos

Los filtros Ruby también pueden usar para dividir un solo evento en varios eventos. Esto es útil cuando tienes un solo evento que contiene un array de objetos y quieres crear eventos separados para cada uno.

Ten en cuenta que ni la tubería de ingesta de Elasticsearch ni los procesadores de Beats/Elastic Agent soportan eventos de división. Este es uno de los casos de uso más estables de Logstash.

Con filtro dividido

Puedes usar el filtro split para dividir un evento en varios eventos según un campo especificado. Sin embargo, si necesitas realizar transformaciones adicionales o lógica durante la división, puedes usar el filtro Ruby en combinación con el filtro dividido.

En el siguiente ejemplo, tenemos un feed RSS como una sola línea de texto XML. Contiene múltiples elementos <item> . El filtro Ruby se emplea para extraer los <item> elementos del XML y almacenarlos en un nuevo campo llamado items. El filtro dividido se emplea entonces para dividir el evento en varios eventos según el campo items .

Esto dará la siguiente manera:

Como notaste, el filtro ruby no es esencial en este caso. El filtro split puede usar para dividir el evento en varios eventos basados en el campo items , y el filtro mutate puede usar para eliminar campos innecesarios. Sin embargo, si necesitas realizar transformaciones o lógica adicional durante la división, puedes usar el filtro Ruby.

Emplea escritura Ruby en línea

También puedes usar un script Ruby en línea para dividir un solo evento en varios eventos usando el método event.clone y el new_event_block variable, como new_event_block.call(new_event). Esto te permite crear nuevos eventos basados en el evento original mientras se conservan sus datos.

Aquí tienes un ejemplo de cómo usar el filtro Ruby para dividir un solo evento en varios eventos. La entrada y salida son las mismas que en el ejemplo anterior.

Usa un script Ruby externo

También puedes usar un script externo de Ruby para dividir un solo evento en varios eventos.

Archivo de configuración:

El sistema Ruby debe externalizar como split_event.rb:

Recuerda, el método filter debe devolver un serial de eventos. Puedes devolver varios eventos clonando un objeto de evento entrante y agregándolos al array, o puedes devolver un solo evento como un array con un solo elemento.

Esto te permite dividir un solo evento en varios eventos.

Ejecuta comandos externos y analiza su salida

El plugin de entrada ejecutiva de Logstash permite ejecutar comandos externos y su salida será un evento de Logstash. La salida del comando se almacenará en el campo message del evento.

Normalmente, la salida de los comandos del sistema es legible por humanos, pero no está estructurada como JSON u otros formatos que Logstash pueda analizar fácilmente. Para gestionarlo, puedes usar el filtro Ruby para analizar la salida y extraer la información de ella.

Aquí tienes un ejemplo de cómo se emplea el plugin de entrada exec para ejecutar el comando ps -ef , que lista todos los procesos en ejecución en un sistema tipo Unix. La salida será analizada por el filtro Ruby para extraer información relevante sobre cada proceso.

Este ejemplo emplea el plugin de entrada exec para ejecutar el comando ps -ef cada 60 segundos. El filtro Ruby procesa la salida, extrayendo campos relevantes como UID, PID, PPID, uso de la CPU (C), hora de inicio (STIME), TTY, tiempo total de CPU (TIME) y el comando (CMD) ejecutado. Funciona bien en mi entorno macOS, pero puede que tengas que ajustar los patrones regex para que coincidan con el formato de salida del comando ps -ef en tu sistema.

Emplea librerías integradas

El plugin de filtro Ruby permite usar librerías Ruby integradas, que pueden ser muy útiles para diversas tareas. Por ejemplo, puedes usar la librería json para analizar cadenas JSON o la librería date para manipular fechas.

Aquí tienes un ejemplo de cómo usar la librería json para analizar una cadena JSON almacenada en un campo:

Para evitar tener que usar la librería cada vez, deberías externalizar tu código Ruby para poder usar la sentencia require al principio de tu script de filtro Ruby. Esto cargará la biblioteca una vez y la pondrá disponible para tu script.

Para comprobar qué librerías están disponibles en tu entorno, puedes listar las bibliotecas integradas ejecutando el siguiente código en el filtro Ruby:

Nota: Las bibliotecas integradas no son soportadas oficialmente por Logstash, y su comportamiento puede cambiar o puede que no estén disponibles en versiones futuras. Úsalos bajo tu propia responsabilidad.

Conclusión

El filtro Ruby de Logstash te permite personalizar y ampliar las capacidades de tus pipelines de Logstash. En esta publicación, cubrimos lo básico del uso del filtro Ruby y proporcionado ejemplos avanzados de uso.

Aprovechando el filtro Ruby, puedes manejar tareas complejas de procesamiento de datos que requieren lógica personalizada o manipulación avanzada. Ya sea que trabajes con estructuras de datos anidadas, divisiones de eventos o analizes y conviertas textos complejos/no estructurados en JSON estructurado, el filtro Ruby ofrece flexibilidad para satisfacer tus necesidades específicas.

Esperamos que esta guía te proporcionó el conocimiento e inspiración para explorar todo el potencial del filtro Ruby de Logstash. ¡Feliz guion!

1. Uso de la API_mapping para recuperar información de campo

2. Uso de la API_search para mostrar los valores de los campos

3. Filtrado de campos usando el parámetrofields

4. Visualización de campos anidados

1. Uso de la API _mapping para recuperar información de campo

La API _mapping permite recuperar la definición de mapeo para un índice o varios índices. Esto incluye información sobre los campos, sus tipos de datos y otras propiedades. Para recuperar el mapeo de un índice específico, emplee la siguiente petición:

Por ejemplo, si tienes un índice llamado my_index, puedes recuperar su mapeo con la siguiente petición:

La respuesta incluirá la definición de mapeo para el índice, que contiene información sobre los campos y sus propiedades.

También es posible recuperar el mapeo de un campo específico. Esto puede ser útil si tu mapeo es bastante grande y solo quieres centrarte en un campo específico. Para recuperar el mapeo de un campo específico, emplee la siguiente petición:

También puedes recuperar los mapeos de varios campos separando sus nombres con comas, como en la siguiente petición:

2. Uso de la API _search para mostrar los valores de los campos

Para mostrar los valores de los campos en un índice de Elasticsearch, puedes usar la API _search . Por defecto, la API _search devuelve el campo _source , que contiene el documento JSON original que se indexó. Para mostrar solo campos específicos, puedes usar el parámetro _source en la solicitud de búsqueda.

Aquí tienes un ejemplo de una solicitud de búsqueda que devuelve los valores de los campos title y author para documentos en el índice my_index :

En este ejemplo, el parámetro _source especifica los campos que se deben devolver.

3. Filtrado de campos usando el parámetro de campos

También puedes usar el parámetro fields para filtrar los campos que aparecen en la respuesta de búsqueda. Esto puede ser útil si solo necesitas campos específicos y quieres reducir el tamaño de la respuesta. El parámetro fields acepta una matriz de nombres de campos o patrones comodines.

Por ejemplo, para devolver solo los campos title y author de los documentos en el índice de my_index , puedes usar la siguiente solicitud de búsqueda:

Ten en cuenta que el parámetro _source está configurado como falso para no devolver el documento fuente.

Para devolver todos los campos con un text tipo de dato, puedes usar un patrón comodín como este:

4. Visualización de campos anidados

Si tu índice contiene campos anidados, puedes usar la notación de puntos para especificar el camino de campo anidado en el parámetro fields . Por ejemplo, si tienes un campo anidado llamado address.city, puedes incluirlo en la respuesta de búsqueda así:

En este ejemplo, la respuesta de búsqueda incluirá los valores de los campos title, author address.city .

Conclusión

En conclusión, se puede lograr mostrar campos en un índice de Elasticsearch empleando la API _mapping para recuperar información de campos y la API _search para mostrar los valores de campo. Puedes filtrar los campos que aparecen en la respuesta de búsqueda usando los parámetros de _source o fields y mostrar los campos anidados usando la notación de puntos. Estas técnicas pueden ayudarte a entender la estructura de tus datos, identificar campos específicos y solucionar problemas.

En este artículo, hablaremos de las razones por las que excluye campos de la indexación, cómo configurar Elasticsearch para excluir campos específicos y algunas buenas prácticas a seguir al hacerlo.

Razones para excluir campos de la indexación

1. Rendimiento: Indexar todos los campos de un documento puede aumentar el tiempo de indexación y ralentizar el rendimiento de búsqueda. Excluyendo campos que no son necesarios para búsqueda o agregación, puedes mejorar el rendimiento general de tu clúster de Elasticsearch.

2. Almacenamiento: Los campos de indexación consumen espacio de almacenamiento. Excluir campos que no son necesarios para búsqueda o agregación puede ayudar a reducir los requisitos de almacenamiento de tu clúster de Elasticsearch.

3. Tamaño del índice: El tamaño de un índice de Elasticsearch está directamente relacionado con el número de campos indexados. Al excluir campos innecesarios, puedes minimizar el tamaño de tu índice, lo que puede llevar a un rendimiento de búsqueda e indexación más rápido.

Configuración de Elasticsearch para excluir campos

Para excluir un campo de la indexación en Elasticsearch, puedes usar la propiedad "index" en el mapeo del campo. Al poner la propiedad "index" en "false", Elasticsearch no indexará el campo, y no será buscable ni estará disponible para agregaciones.

Aquí tienes un ejemplo de cómo excluir un campo de la indexación usando el mapeo Elasticsearch:

En este ejemplo, estamos creando un nuevo índice llamado "my_index" con un solo campo llamado "field_to_exclude". Al poner la propiedad "index" en "false", le decimos a Elasticsearch que no indexe este campo. Sin embargo, el campo seguirá estando disponible en el documento fuente.

Mejores prácticas para excluir campos de la indexación

1. Analiza tus datos: Antes de excluir campos de la indexación, es esencial analizar tus datos y entender qué campos son necesarios para la búsqueda y agregación. Esto te ayudará a tomar decisiones informadas sobre qué campos excluir.

2. Prueba tus cambios: Al excluir campos de la indexación, es fundamental probar tus cambios para cerciorarte de que la funcionalidad de búsqueda y agregación sigue funcionando como se espera. Esto puede ayudarte a evitar problemas inesperados o de rendimiento.

3. Rendimiento del monitor: Luego de excluir campos de la indexación, monitoriza el rendimiento de tu clúster de Elasticsearch para cerciorarte de que los cambios tuvieron el efecto deseado. Esto puede ayudarte a identificar posibles optimizaciones adicionales que puedan ser necesarias.

4. Emplea filtrado de fuente: Si necesitas almacenar un campo en Elasticsearch pero no quieres que sea buscable ni disponible para agregaciones, considera usar filtrado de fuente. Esto te permite almacenar el campo en el campo _source pero excluirlo del índice.

Conclusión

Excluir campos de la indexación en Elasticsearch puede ayudar a mejorar el rendimiento, reducir los costos de almacenamiento y minimizar el tamaño total de tu índice. Analizando cuidadosamente tus datos y entendiendo qué campos son necesarios para la búsqueda y agregación, puedes tomar decisiones informadas sobre cuáles excluir. Prueba siempre tus cambios y monitoriza el rendimiento de tu clúster de Elasticsearch para cerciorarte de que tus optimizaciones tienen el efecto deseado.

• Las definiciones de mapeo especifican el esquema de datos.

• Los ajustes ajustan el tamaño del fragmento y las frecuencias de refresco. 

• Se emplean alias para dar nombres alternativos al índice.

Cuando indexamos un documento por primera vez o creamos un índice vacío usando la API Create Index, el índice se creará con la configuración predeterminada, sin esquema de datos y sin alias. Estos valores por defecto funcionan bastante bien en entornos de desarrollo y pruebas, pero puede que necesitemos personalizar nuestros índices para entornos de producción.

Trabajar con los mapeos y ajustes predeterminados en producción puede resultar en un índice y un rendimiento de búsqueda deficientes. Instanciar índices manualmente es un proceso tedioso y que consume mucho tiempo. Recrear tales índices en cualquier entorno es especialmente poco práctico si disponemos de un esquema de mapeo elaborado, así como de configuraciones y alias personalizados.

Por suerte, Elasticsearch nos proporciona una herramienta para aplicar automáticamente una configuración predefinida al crear índices en forma de plantillas de índices .

Plantillas de índice

Las plantillas de índice nos permiten crear índices con una configuración definida por el usuario. Un índice puede extraer la configuración de estas plantillas, por ejemplo un número determinado de fragmentos y réplicas o mapeos de campos, durante su instanciación. Se definirá una plantilla con un patrón de nombre y alguna configuración en él. Si el nombre del índice coincide con el patrón de nombres de la plantilla, el nuevo índice se creará con la configuración definida en la plantilla.

Elasticsearch mejoró su funcionalidad de plantillas en la versión 7.8 con plantillas componibles. Esta versión más reciente ofrece plantillas de índice mucho más reutilizables, como se demuestra en este artículo.

Tipos de plantillas de indexación

Las plantillas de índice pueden clasificar en dos categorías:

• Plantillas de índice (o plantillas de índice composable): Las plantillas de índice componibles pueden existir por sí solas o estar compuestas por no tener o más plantillas componentes (ver la segunda categoría).

• Plantillas de componentes: La plantilla de componentes es una plantilla reutilizable por sí sola que define la configuración requerida. Normalmente se espera que la plantilla de componentes esté asociada a una plantilla de índice. Cada una de las plantillas de componentes puede anexar con una o varias plantillas de índice. 

Como puedes ver en la imagen de abajo, las plantillas índice A y B comparten entre sí las plantillas de componentes (en este caso solo una, la Plantilla 3). Una plantilla de índice puede consistir en ninguna o muchas plantillas de componentes y cada una de las plantillas de componentes puede asociar a ninguna o a muchas plantillas de índice. Ambos tipos de plantillas pueden existir por separado, sin embargo, las plantillas de componentes no sirven a menos que estén adjuntas a una plantilla de índice.

La idea general es desarrollar un catálogo de plantillas de componentes para que una organización las emplee para diversas necesidades (por ejemplo, especificar las distintas plantillas de componentes para entornos individuales) y anexarlas a varios índices mediante las plantillas de índices componibles.

Cómo crear plantillas componibles (indexadas)

Elasticsearch proporciona un punto final _index_template para gestionar plantillas de índice. El usuario proporciona todos los mapeos, ajustes y alias necesarios junto con un patrón de nombres de índice en esta plantilla. Vamos a repasar un ejemplo de cómo crear una plantilla para una aplicación de microservicios client-order-service que es responsable de la lógica de generación de pedidos. 

Supongamos que nuestro requisito es crear una plantilla para pedidos de clientes, representada con un patrón que incluye comodines: *pedidos. Se espera que esta plantilla tenga ciertos mapeos y configuraciones, como el campo order_date, así como fragmentos y números de réplica.

Cualquier índice que se empareje con esta plantilla durante su creación hereda las configuraciones definidas en esta plantilla. Por ejemplo, un índice de black_friday_orders tendrá el campo order_date, los fragmentos se pondrán en 5 y las réplicas en 2. Además, todos los índices creados a partir de esta plantilla heredan también un único nombre de alias . Creemos este orders_template con un patrón de índice definido como *orders y con un esquema de mapeo que consiste en un solo campo de oder_date con un formato de fecha predefinido dd-MM-yyyy. El código que aparece a continuación muestra cómo crear esta plantilla de índice.

Cuando ejecutas esta consulta en DevTools de Kibana, la plantilla se crea con el patrón índice *orders junto con el mapeo predefinido, los ajustes y un alias. El index_patterns es una variedad de patrones de coincidencia; cualquier índice que coincida con este patrón derivará la configuración de la plantilla. Puedes ejecutar lo siguiente para recuperar la plantilla persistente que debería reiterar lo que hicimos:

También hay una prioridad, un número positivo, definido al crear el atributo de plantilla definido en la plantilla: cada plantilla se define con una prioridad para que cualquier cambio conflictivo de diferentes plantillas se resuelva usando este valor con precedencia dada al valor de mayor prioridad. A continuación profundizaremos en la prioridad de las plantillas.

Crear un índice con la plantilla

Ahora que tenemos una plantilla – un plano para crear índices – el siguiente paso es crear un índice. Cuando el nombre del índice coincide con el patrón dado, las configuraciones con plantilla se aplican automáticamente. Para demostrar el punto, como muestra el código de abajo, creemos un índice completamente nuevo llamado: blackfriday_orders:

Como el nombre del índice (blackfriday_orders) coincide con el patrón de nombres definido en la plantilla (es decir, *órdenes), el índice debería obtener todas las configuraciones derivadas de la plantilla. Recuperemos este índice recién creado y compruebemos si esto es realmente cierto ejecutando el siguiente código:

Esto debería volver:

Como indica la respuesta, la configuración del blackfriday_orders fue heredada de la plantilla. Podemos probar con varias combinaciones de los índices que hereden con éxito la configuración plantillada:

Sin embargo, los siguientes índices no heredarán la configuración ya que el nombre no coincidirá con el patrón:

Algo importante a recordar es que todos los índices derivados de una plantilla tienen el mismo alias – all_orders – en este caso. Existe un beneficio en tener este alias: podemos consultar simplemente con este único alias en lugar de en múltiples índices.

Aunque creamos una plantilla para *pedidos, se espera que cualquier índice coincidente adopte la configuración de la plantilla. Normalmente, consciente o inconscientemente, los equipos pueden crear algunas plantillas más por diversas razones. Esto significa que a veces el nombre del índice puede coincidir con dos patrones de plantilla diferentes. Elasticsearch tiene que decidir cuál de las configuraciones de esas plantillas debe aplicar. Afortunadamente, este dilema puede resolver usando la prioridad de la plantilla.

Cómo crear plantillas de componentes

Aprendimos sobre las plantillas de índice en la parte anterior de este artículo. Hay un par de desventajas al crear las plantillas con la configuración incorporada; una de ellas es que la configuración no es exportable para otras plantillas. Si queremos tener una configuración similar, por ejemplo para plantillas relacionadas con clientes (*clientes), puede que tengamos que recrear toda la plantilla. Eso significa que podemos estar creando docenas de ellos en una organización típica (además puede que tengas algunos más según los entornos).

Como siempre esperamos la reutilización, Elasticsearch rediseñó las plantillas teniendo en cuenta la reutilización. Las plantillas de componentes cumplen con ese requisito. Si vienes de un entorno DevOps, lo más probable es que tengas que crear índices con una configuración preestablecida para cada uno de los entornos. En lugar de aplicar manualmente cada una de estas configuraciones, puedes crear una plantilla de componentes para cada uno de los entornos.

Una plantilla de componentes no es más que un bloque reutilizable de configuraciones que podemos usar para crear más plantillas de índice. Ten en cuenta que las plantillas de componentes no tienen valor a menos que estén agrupadas con plantillas de índice. Se exponen a través de un punto final _component_template. Veamos cómo encaja todo esto.

Configuraciones en una plantilla de índice

Vamos a extraer los ajustes que definimos en nuestra plantilla de índice antes y crear una plantilla de componente a partir de ella. Se espera que el settings_component_template tenga cinco fragmentos principales con dos réplicas por fragmento principal. El primer paso, como muestra la lista de código a continuación, es declarar y ejecutar una plantilla de componente con esta configuración.

Como muestra el código anterior, usamos el punto final _component_template para crear una plantilla de componentes. El cuerpo de la solicitud contiene la información de la plantilla en un objeto plantilla. El settings_component_template ya está disponible para su uso en otras partes de las plantillas del índice. Una diferencia notable es que esta plantilla no define ningún patrón de índice; Simplemente es un bloque de código que configura algunas propiedades para nosotros.

Plantilla de mapeo

De la misma manera, creemos otra plantilla. Esta vez, extraigamos el esquema de mapeo que definimos antes en las plantillas de índice independientes. El código siguiente muestra el guion:

Plantilla de alias

Siguiendo el mismo flujo, también podemos tener una plantilla de componentes con los alias – dos alias (all_orders y sales_orders):

Plantilla de índice componible

Ahora que tenemos estas tres plantillas de componentes, el siguiente paso es ponerlas en práctica. Podemos hacerlo dejando que una plantilla de índice para, por ejemplo, christmas_orders, la emplee:

La etiqueta composed_of es una colección de todas las plantillas de componentes que conforman esta plantilla. En este caso, elegimos las plantillas de componentes de configuración, mapeo y alias. También estamos subiendo la prioridad, así que esta plantilla supera a cualquier otra. Una vez que la plantilla está lista, cualquier índice que coincida con el patrón *orders heredará la configuración de estas tres plantillas componentes.

Dicho esto, si deseamos crear una nueva plantilla, por ejemplo clientes, con solo una de las plantillas existentes (settings_component_template) y una nueva (aliases_component_template – ver más abajo), podemos hacerlo con:

La plantilla del índice es la siguiente:

¿Viste que el settings_component_template se ha (re)empleado en dos plantillas diferentes? Ese es el poder de las plantillas de componentes.

Prioridad de la plantilla de indexación

Existe la posibilidad de que los desarrolladores creen múltiples plantillas de índice sin mirar el stock existente. Es importante establecer una prioridad en cada una de estas plantillas para que se emplee la de mayor prioridad. Por ejemplo, el my_orders_template_1 anula la my_orders_template_2 en el siguiente fragmento de código:

Cuando tienes varias plantillas que coinciden con los índices que se están creando, Elasticsearch aplica todas las configuraciones de todas las plantillas coincidentes pero anula cualquier cosa que tenga mayor prioridad.

Precedencia de plantillas

Por último, puede que te preguntes por la precedencia de las plantillas: ¿la configuración definida en la plantilla de componentes anula la que aparece en la plantilla principal del índice? ¿O al revés? Bueno, hay algunas reglas:

• Un índice creado con configuraciones tiene prioridad explícita sobre todo; esto significa que si creas un índice con configuración explícita, no esperes que las plantillas las sobreescriban.

• Las plantillas heredadas (plantillas creadas antes de la versión 7.8) tienen una prioridad inferior a las plantillas componibles.

Resumen

• Un índice contiene mapeos, configuraciones y alias: los mapeos definen el esquema de campos, los ajustes establecen los parámetros del índice como el número de fragmentos y réplicas, y los alias dan nombres alternativos al índice.

• Las plantillas nos permiten crear índices con configuraciones predefinidas. Nombrar un índice con un nombre que coincida con el patrón de índice definido en una plantilla específica configurará automáticamente ese índice según la plantilla.

• Elasticsearch introdujo plantillas de índice componibles en la versión 7.8. Las plantillas de índice componibles permiten modularidad y versionado de las plantillas.

• Las plantillas componibles consisten en no tener o más plantillas de componentes.

• Una plantilla de índice también puede tener su propia configuración definida.

• Una plantilla de componente es una plantilla reutilizable con configuración predefinida, igual que una plantilla de índice componible.

• Sin embargo, se espera que las plantillas de componentes formen parte de una plantilla de índice; No sirven de nada si no están "compuestas" en una plantilla de índice.

• Las plantillas de componentes no tienen un patrón de índice definido, lo que es otra razón por la que se "espera" que formen parte de una plantilla de índice.

• Cada una de las plantillas tiene una prioridad: un número positivo. Cuanto mayor sea el número, mayor es la precedencia para que se aplique esa plantilla.

En este artículo, explicaremos cómo configurar Airbyte para que insienta datos en Elasticsearch, cubriendo conceptos clave, requisitos previos y la integración paso a paso.

Conceptos fundamentales de Airbyte

Airbyte tiene varios conceptos esenciales para su uso. A continuación, destacamos los principales:

• Fuentes: Define el origen de los datos que se extraerá.

• Destinos: Define dónde se enviarán y almacenarán los datos.

• Conexiones: Configura la relación entre la fuente y el destino, incluyendo la frecuencia de sincronización.

Integración de Airbyte con Elasticsearch

En esta demostración, realizaremos una integración en la que los datos almacenados en un cubo S3 serán migrados a un índice Elasticsearch. Mostraremos cómo configurar el código fuente (S3) y el destino (Elasticsearch) en Airbyte.

Prerrequisitos

Para seguir a esta demostración, deben cumplir los siguientes requisitos:

1. Crea un cubo en AWS, donde se almacenarán los archivos JSON que contienen los datos.

2. Instala Airbyte localmente usando Docker.

3. Crea un clúster de Elasticsearch en Elastic Cloud para almacenar los datos ingeridos.

A continuación, detallaremos cada uno de estos pasos.

Instalación de Airbyte

Airbyte puede ejecutar localmente usando Docker o en la nube, donde existen costos asociados al uso. Para esta demostración, usaremos la versión local con Docker.

La instalación puede tardar unos minutos. Tras seguir las instrucciones de instalación, Airbyte estará disponible en: http://localhost:8000.

Luego de iniciar sesión, podemos empezar a configurar la integración.

Creación del cubo

En este paso, necesitarás una cuenta de AWS para crear un bucket S3. Además, es esencial establecer las licencias correctas creando una política y un usuario IAM para permitir el acceso al cubo.

En el bucket, subiremos archivos JSON que contengan diferentes registros de log, que luego serán migrados a Elasticsearch. Los registros de archivos contienen este contenido:

A continuación están los archivos cargados en el cubo:

Configuración de la nube elástica

Para facilitar la demostración, usaremos Elastic Cloud. Si aún no tienes cuenta, puedes crear una cuenta de prueba gratis aquí: Elastic Cloud Registration.

Luego de configurar el despliegue en Elastic Cloud, necesitarás obtener:

• La URL del servidor Elasticsearch.

• Un usuario para acceder a Elasticsearch.

Para obtener la URL, ve a Despliegues > Mi despliegue, en la aplicación, busca Elasticsearch y haz clic en 'Copiar el punto final'.

Para crear el usuario, sigue los pasos a continuación:

1. Accede a Kibana > Stack Management > usuarios.

2. Crea un nuevo usuario con el rol de superusuario.

3. Diligencia el espacio para crear al usuario.

Ahora que lo tenemos todo listo, podemos empezar a configurar los conectores en Airbyte.

Configuración del conector fuente

En este paso, crearemos el conector fuente para S3. Para ello, accederemos a la interfaz de Airbyte y seleccionaremos la opción Fuente en el menú. Luego, buscaremos el conector S3. A continuación, detallamos los pasos necesarios para configurar el conector:

1. Accede a Airbyte y ve al menú de Fuentes.

2. Busca y selecciona el conector S3.

3. Configura los siguientes parámetros:

   1. Nombre de la fuente: Define un nombre para la fuente de datos.

   2. Método de entrega: Seleccionar Réplica de Registros (recomendado para datos estructurados).

   3. Formato de datos: Elige formato JSON.

   4. Nombre del flujo: Define el nombre del índice en Elasticsearch.

   5. Nombre del cubo: Introduce el nombre del cubo en AWS.

   6. Clave de acceso de AWS y clave secreta de AWS: Introduce las credenciales de acceso.

Haz clic en Configurar código fuente y espera la validación.

Conector de destino de configuración

En este paso, configuraremos el conector de destino, que será Elasticsearch. Para ello, accederemos al menú y seleccionaremos la opción Destino. Luego, buscaremos Elasticsearch y haremos clic en el resultado que devolvemos. Ahora, procederemos con la configuración de esta conexión:

1. Accede a Airbyte y ve al menú de Destinos.

2. Busca y selecciona el conector Elasticsearch.

3. Configura los siguientes parámetros:

   1. Método de autenticación: Elige nombre de usuario/contraseña.

   2. Nombre de usuario y contraseña: Emplea las credenciales creadas en Kibana.

   3. Endpoint del servidor: Pega la URL copiada de Elastic Cloud.

Haz clic en Configurar destino y espera la validación.

Creación de la conexión de origen y destino

Una vez creada la Fuente y el Destino, se creará la conexión entre ellos, completando así la creación de la integración.

A continuación se muestran las instrucciones para crear la conexión:

1. En el menú, ve a Conexiones y haz clic en Crear Primera Conexión.

2. En la siguiente pantalla, podrás seleccionar una Fuente existente o crear una nueva. Como ya tenemos una Fuente creada, seleccionaremos la Fuente S3.

3. El siguiente paso será seleccionar el destino. Como ya creamos el conector Elasticsearch, se seleccionará para finalizar la configuración.

En el siguiente paso, será necesario definir el Modo de Sincronización y qué esquema se empleará. Como solo se creó el esquema de registro, será la única opción disponible para la selección.

4. Pasaremos al paso Configurar Conexión. Aquí podemos definir el nombre de la conexión y la frecuencia de ejecución de la integración. La frecuencia puede configurar de tres maneras:

• Cron: Ejecuta las sincronizaciones basar en la expresión cron definida por el usuario (por ejemplo, 0 0 15 * * ?, a las 15:00 todos los días);

• Programado: Ejecuta las sincronizaciones en el intervalo de tiempo especificado (por ejemplo, cada 24 horas, cada 2 horas);

• Manual: Ejecuta las sincronizaciones manualmente.

Para esta demostración, seleccionaremos la opción Manual.

Finalmente, al hacer clic en Configurar conexión, se establecerá la conexión entre la Fuente y el Destino.

Sincronización de datos de S3 a Elasticsearch

Cuando vuelves a la pantalla de Conexiones, puedes ver la conexión que se creó. Para ejecutar el proceso, simplemente haz clic en Sincronizar. A partir de ese momento, comenzará la migración de datos de S3 a Elasticsearch.

Si todo va bien, obtendrás el estado sincronizado.

Visualización de datos en Kibana

Ahora, iremos a Kibana para analizar los datos y comprobar si están indexados correctamente. En la sección Kibana Discovery crearemos una Vista de Datos llamada logs. Con esto, podremos explorar los datos que solo existen en el índice de registros, que se creó tras la sincronización.

Ahora podemos visualizar los datos indexados y realizar análisis sobre ellos. De este modo, validamos todo el flujo de migración usando Airbyte, donde cargamos los datos presentes en el bucket e los indexamos en Elasticsearch.

Conclusión: Integración de Airbyte y Elasticsearch

Airbyte demostró ser una herramienta eficiente para la integración de datos, permitiéndonos conectar varias fuentes y destinos de forma automatizada. En este tutorial, demostramos cómo ingirir datos de un cubo S3 a un índice de Elasticsearch, destacando los pasos principales del proceso.

Este enfoque facilita la ingestión de grandes volúmenes de datos y permite análisis dentro de Elasticsearch, como búsquedas complejas, agregaciones y visualizaciones de datos.

Referencias

Inicio rápido de Airbyte:

https://docs.airbyte.com/using-airbyte/getting-started/oss-quickstart#part-1-install-abctl

Conceptos básicos:

https://docs.airbyte.com/using-airbyte/core-concepts/

¿Qué es LlamaIndex?

LlamaIndex es un marco que facilita la creación de agentes y flujos de trabajo impulsados por Grandes Modelos de Lenguaje (LLMs) para interactuar con datos específicos o privados. Permite la integración de datos de diversas fuentes (APIs, PDFs, bases de datos) con LLMs, facilitando tareas como investigación, extracción de información y generación de respuestas contextualizadas.

Conceptos clave:

• Agentes: Asistentes inteligentes que emplean LLMs para realizar tareas, desde respuestas simples hasta acciones complejas.

• Flujos de trabajo: Procesos de varios pasos que combinan agentes, conectores de datos y herramientas para tareas avanzadas.

• Aumento de contexto: Una técnica que enriquece el LLM con datos externos, superando sus limitaciones de entrenamiento.

Integración de LlamaIndex con Elasticsearch:

Elasticsearch puede usar de varias formas con LlamaIndex:

• Fuente de datos: Emplea el Elasticsearch Reader para extraer documentos.

• Modelo de incrustaciones: Codificar datos en vectores para búsquedas semánticas.

• Almacenamiento vectorial: Emplea Elasticsearch como repositorio para buscar documentos vectorizados.

• Almacenamiento avanzado: Configurar estructuras como resúmenes de documentos o grafos de conocimiento.

Uso de LlamaIndex y Elasticsearch para crear una búsqueda de preguntas frecuentes

Preparación de datos

Usaremos como ejemplo las preguntas frecuentes de Elasticsearch Service . Cada pregunta se extraía de la web y se almacenaba en un archivo de texto individual. Puedes usar cualquier método para organizar los datos; En este ejemplo, elegimos almacenar los archivos localmente.

Archivo de ejemplo:

Luego de almacenar todas las preguntas, el directorio se verá así:

Instalación de dependencias

Implementaremos la ingestión y búsqueda usando el lenguaje Python, la versión que usé fue la 3.9. Como requisito previo, será necesario instalar las siguientes dependencias:

Elasticsearch y Kibana se crearán con Docker, configurados mediante docker-compose.yml para ejecutar la versión 8.16.2. Esto facilita la creación del entorno local.

Ingesta de documentos usando LlamaIndex

Los documentos se indexarán en Elasticsearch usando LlamaIndex. Primero, cargamos los archivos con SimpleDirectoryReader, que permite cargar archivos desde un directorio local. Luego de cargar los documentos, los indexaremos usando el VectorStoreIndex.

Los Vector Stores en LlamaIndex son responsables de almacenar y gestionar las incrustaciones de documentos. LlamaIndex soporta diferentes tipos de Vector Stores, y en este caso, usaremos Elasticsearch. En el StorageContext, configuramos la instancia de Elasticsearch. Dado que el contexto es local, no se requerían parámetros adicionales. Para configuraciones en otros entornos, consulte la documentación para comprobar los parámetros necesarios: ElasticsearchStore Configuration.

Por defecto, LlamaIndex emplea el modelo OpenAI text-embedding-ada-002 para generar embeddings. Sin embargo, en este ejemplo, usaremos el modelo text-embedding-3-small . Es importante señalar que se requerirá una clave API de OpenAI para usar el modelo.

A continuación se muestra el código completo para la ingestión de documentos.

Tras la ejecución, los documentos se indexarán en el índice de preguntas frecuentes como se muestra a continuación:

Búsqueda con RAG

Para realizar búsquedas, configuramos el cliente ElasticsearchStore , configurando los campos index_name y es_url con la URL de Elasticsearch. En retrieval_strategy, definimos la AsyncDenseVectorStrategy para búsquedas vectoriales. También están disponibles otras estrategias, como AsyncBM25Strategy (búsqueda por palabras clave) y AsyncSparseVectorStrategy (vectores dispersos). Se pueden encontrar más detalles en la documentación oficial.

A continuación, se creará un objeto VectorStoreIndex , donde configuramos el vector_store usando el objeto ElasticsearchStore. Con el método as_retriever , realizamos la búsqueda de los documentos más relevantes para una consulta, estableciendo el número de resultados devueltos a 5 mediante el parámetro similarity_top_k .

El siguiente paso es RAG. Los resultados de la búsqueda vectorial se incorporan en un prompt formateado para el LLM, permitiendo una respuesta contextualizada basada en la información recuperada.

En la PromptPlantilla, definimos el formato del prompt, que incluye:

• Contexto ({context_str}): documentos recuperados por el recuperador.

• Consulta ({query_str}): la pregunta del usuario.

• Instrucciones: pautas para que el modelo responda según el contexto, sin depender de conocimientos externos.

Finalmente, el LLM procesa el prompt y devuelve una respuesta precisa y contextual.

El código completo se encuentra a continuación:

Ahora podemos realizar nuestra búsqueda, por ejemplo, "¿Los servicios de Elastic son gratis?" y obtener una respuesta contextualizada basada en los datos de las preguntas frecuentes en sí.

Para generar esta respuesta, se emplearon los siguientes documentos:

Conclusión

Empleando LlamaIndex, demostramos cómo crear un sistema eficiente de búsqueda de preguntas frecuentes con soporte para Elasticsearch como base de datos vectorial. Los documentos se ingieren e indexan mediante incrustaciones, lo que permite búsquedas vectoriales. A través de una PromptPlantilla, los resultados de la búsqueda se incorporan al contexto y se envían al LLM, que genera respuestas precisas y contextualizadas basadas en los documentos recuperados.

Este flujo de trabajo integra la recuperación de información con la generación contextualizada de respuestas para ofrecer resultados precisos y relevantes.

Referencias

https://www.elastic.co/guide/en/cloud/current/ec-faq-getting-started.html

https://docs.llamaindex.ai/en/stable/api_reference/readers/elasticsearch/

https://docs.llamaindex.ai/en/stable/module_guides/indexing/vector_store_index/

https://docs.llamaindex.ai/en/stable/examples/query_engine/custom_query_engine/

https://www.elastic.co/search-labs/integrations/llama-index

Apache Airflow es una plataforma diseñada para crear, programar y monitorizar flujos de trabajo. Se emplea para orquestar procesos ETL, pipelines de datos y otros flujos de trabajo complejos, ofreciendo flexibilidad y escalabilidad. Su interfaz visual y capacidades de monitorización en tiempo real hacen que la gestión de tuberías sea más accesible y eficiente, permitiéndote seguir el progreso y los resultados de tus ejecuciones. A continuación se presentan sus cuatro pilares principales:

• Dinámico: Las canalizaciones están definidas en Python, lo que permite una generación dinámica y flexible de flujos de trabajo.

• Extensible: Airflow puede integrar con una variedad de entornos, crear operadores personalizados y ejecutar código específico según sea necesario.

• Elegante: Los pipelines se escriben de manera limpia y explícita.

• Escalable: Su arquitectura modular emplea una cola de mensajes para orquestar un número arbitrario de trabajadores.

En la práctica, el flujo de aire puede emplear en escenarios como:

• Importación de datos: Orquestar la ingestión diaria de datos en una base de datos como Elasticsearch.

• Monitorización de registros: Gestionar la recopilación y procesamiento de archivos de registro, que luego se analizan en Elasticsearch para identificar errores o anomalías.

• Integración de múltiples fuentes de datos: Combina información de diferentes sistemas (APIs, bases de datos, archivos) en una sola capa en Elasticsearch, simplificando la búsqueda y la elaboración de reportes.

Comprendiendo los DAG (Grafos Acíclicos Dirigidos) en el flujo de aire

En Airflow, los flujos de trabajo se representan mediante DAGs (Grafos Acíclicos Dirigidos). Un DAG es una estructura que define la secuencia en la que se ejecutarán las tareas. Las principales características de los DAG son:

• Composición por tareas independientes: Cada tarea representa una unidad de trabajo y está diseñada para ejecutar de forma independiente.

• Secuenciación: La secuencia en la que se ejecutan las tareas está definida explícitamente en el DAG.

• Reusabilidad: Los DAG están diseñados para ejecutar repetidamente, facilitando la automatización de procesos.

Componentes de flujo de aire

El ecosistema Airflow está compuesto por varios componentes que trabajan juntos para orquestar tareas:

• Programador: Responsable de programar los DAGs y enviar tareas para su ejecución por parte de los trabajadores.

• Ejecutor: Gestiona la ejecución de las tareas, delegándolas a los trabajadores.

• Servidor sitio web: Proporciona una interfaz gráfica para interactuar con DAGs y tareas.

• Carpeta Dags: Carpeta donde almacenamos los DAGs escritos en Python.

• Metadatos: Base de datos que sirve como repositorio para la herramienta, empleada por el planificador y el ejecutor para almacenar el estado de ejecución.

Apache Airflow y Elasticsearch

Demostraremos el uso de Apache Airflow y Elasticsearch para orquestar tareas e indexar resultados en Elasticsearch. El objetivo de esta demostración es crear una cadena de tareas para actualizar registros en un índice de Elasticsearch. Este índice contiene una base de datos de películas, donde los usuarios pueden valorar y asignar valoraciones. Imaginando un escenario con cientos de audiencias diarias, es necesario mantener actualizado el registro de audiencias. Para ello, se desarrollará un DAG que se ejecutará diariamente, responsable de recuperar las nuevas calificaciones consolidadas y actualizar los registros en el índice.

En el flujo del DAG, tendremos una tarea para obtener las valoraciones, seguida de otra tarea para validar los resultados. Si los datos no existen, el DAG será dirigido a una tarea de fallo. De lo contrario, los datos se indexarán en Elasticsearch. El objetivo es actualizar el campo de calificación de las películas en un índice recuperando las calificaciones mediante un método con el mecanismo responsable de calcular los puntajes.

Usando Apache Airflow y Elasticsearch con Docker

Para crear un entorno contenedorizado, usaremos Apache Airflow con Docker. Sigue las instrucciones de la guía "Running Airflow en Docker" para configurar Airflow de forma práctica.

En cuanto a Elasticsearch, usaré un clúster en Elastic Cloud, pero si prefieres, también puedes configurar Elasticsearch con Docker. Ya se creó un índice que contiene un catálogo de películas, con los datos de las películas indexados. El campo de 'calificación' de estas películas se actualizará.

Creación del DAG

Tras instalarla mediante Docker, se creará una estructura de carpetas, incluyendo la carpeta dags, donde debemos colocar nuestros archivos DAG para que Airflow los reconozca.

Antes de eso, debemos cerciorarnos de que las dependencias necesarias estén instaladas. Estas son las dependencias de este proyecto:

Crearemos el archivo update_ratings_movies.py y empezaremos a programar las tareas.

Ahora, importemos las bibliotecas necesarias:

Emplearemos el ElasticsearchPythonHook, un componente que simplifica la integración entre Airflow y un clúster de Elasticsearch al abstraer la conexión y el uso de APIs externas.

A continuación, definimos el DAG, especificando sus argumentos principales:

• dag_id: el nombre del DAG.

• start_date: cuando empezará el DAG.

• schedule: define la periodicidad (diaria en nuestro caso).

• doc_md: documentación que se importará y mostrará en la interfaz Airflow.

Definición de las tareas

Ahora, definamos las tareas del DAG. La primera tarea será la de recuperar los datos de valoración de la película. Usaremos el PythonOperator con la task_id configurada en 'get_movie_ratings'. El parámetro python_callable llamará a la función responsable de obtener las valoraciones.

A continuación, necesitamos validar si los resultados son válidos. Para esto, usaremos un condicional con un operador BranchPython. La task_id será 'validate_result', y la python_callable llamará a la función de validación. El parámetro op_args se empleará para pasar el resultado de la tarea anterior, 'get_movie_ratings', a la función de validación.

Si la validación tiene éxito, tomaremos los datos de la tarea 'get_movie_ratings' e los indexaremos en Elasticsearch. Para lograrlo, crearemos una nueva tarea, 'index_movie_ratings', que empleará el PythonOperator. El parámetro op_args pasará los resultados de la tarea 'get_movie_ratings' a la función de indexación.

Si la validación indica un fallo, el DAG procederá a una tarea de notificación de fallo. En este ejemplo, simplemente imprimimos un mensaje, pero en un escenario real podríamos configurar alertas para notificar sobre los fallos.

Finalmente, definimos las dependencias de las tareas, cerciorándonos de que se ejecuten en el orden correcto:

Ahora sigue el código completo de nuestro DAG:

Visualización de la ejecución del DAG

En la interfaz Apache Airflow, podemos visualizar la ejecución de los DAGs. Simplemente ve a la pestaña "DAGs" y localiza el DAG que creaste.

A continuación, podemos visualizar las ejecuciones de las tareas y sus respectivos estados. Al seleccionar una ejecución para una fecha específica, podemos acceder a los registros de cada tarea. Ten en cuenta que en la tarea index_movie_ratings podemos ver los resultados de indexación en el índice y que se completó con éxito.

En las otras pestañas, es posible acceder a información adicional sobre las tareas y el DAG, ayudando en el análisis y resolución de posibles problemas.

Conclusión

En este artículo, demostramos cómo integrar Apache Airflow con Elasticsearch para crear una solución de ingestión de datos. Mostramos cómo configurar el DAG, definir las tareas responsables de recuperar, validar e indexar datos de video, así como monitorizar y visualizar la ejecución de estas tareas en la interfaz Airflow.

Este enfoque puede adaptar fácilmente a diferentes tipos de datos y flujos de trabajo, haciendo de Airflow una herramienta útil para orquestar pipelines de datos en diversos escenarios.

Referencias

Apache AirFlow

https://airflow.apache.org/

Instalar Apache Airflow con Docker

https://airflow.apache.org/docs/apache-airflow/stable/howto/docker-compose/index.html

Elasticsearch Python Hook

https://airflow.apache.org/docs/apache-airflow-providers-elasticsearch/stable/hooks/elasticsearch_python_hook.html

Operador Python

https://airflow.apache.org/docs/apache-airflow/stable/howto/operator/python.html

Prerrequisitos

• Docker y Docker Compose: Cerciórate de tener Docker y Docker Compose instalados en tu máquina.

• Python 3.x: Para ejecutar los scripts de productor y consumidor.

Introducción a Apache Kafka

Apache Kafka es una plataforma de streaming distribuida que permite una alta escalabilidad y disponibilidad, así como tolerancia a fallos. En Kafka, la gestión de datos se realiza a través de los componentes principales:

• Intermediario: responsable de almacenar y distribuir mensajes entre productores y consumidores.

• Zookeeper: gestiona y coordina los corredores Kafka, controlando el estado del clúster, los líderes de partición y la información del consumidor.

• Temas: canales donde se publican y almacenan datos para su consumo.

• Consumidores y productores: mientras los productores envían datos a los temas, los consumidores recuperan esos datos.

Estos componentes trabajan juntos para formar el ecosistema Kafka, proporcionando un marco robusto para el flujo de datos.

Estructura del proyecto

Para entender el proceso de ingesta de datos, lo dividimos en etapas:

• Aprovisionamiento de infraestructura: configurar el entorno Docker para soportar Kafka, Elasticsearch y Kibana.

• Creación de productores: implementando el Productor Kafka, que envía datos al tema de registros.

• Creación de Consumidores: desarrollar el Consumidor Kafka para leer e indexar mensajes en Elasticsearch.

• Validación de ingestión: verificar y validar los datos enviados y consumidos.

Configuración de infraestructura con Docker Compose

Empleamos Docker Compose para configurar y gestionar los servicios necesarios. A continuación, encontrarás el código Docker Compose que configura cada servicio necesario para la integración de Apache Kafka, Elasticsearch y Kibana, cerciorando un proceso de ingestión de datos.

Puedes acceder al archivo directamente desde el repositorio de GitHub de Elasticsearch Labs.

Envío de datos con el productor Kafka

El productor es responsable de enviar mensajes al tema de los logs. Al enviar mensajes en lotes, aumenta la eficiencia del uso de la red, permitiendo optimizaciones con los ajustes de batch_size y linger_ms , que controlan la cantidad y latencia de los lotes, respectivamente. La acks='all' de configuración garantiza que los mensajes se almacenen de forma duradera, lo cual es esencial para los datos de registro importantes.

Al iniciar el productor, los mensajes se envían en lotes sobre el tema, como se muestra a continuación:

Consumo e indexación de datos con el Kafka Consumer

El consumidor está diseñado para procesar mensajes de forma eficiente, consumiendo lotes del tema de logs e indexándolos en Elasticsearch. Con auto_offset_reset='latest', se cerciora que el consumidor empiece a procesar los mensajes más recientes, ignorando los antiguos, y max_poll_records=10 limita el lote a 10 mensajes. Con fetch_max_wait_ms=2000, el consumidor espera hasta 2 segundos para acumular suficientes mensajes antes de procesar el lote.

En su bucle principal, el consumidor consume mensajes de registro, procesa e indexa cada lote en Elasticsearch, cerciorando la ingestión continua de datos.

Visualización de datos en Kibana

Con Kibana, podemos explorar y validar los datos ingeridos de Kafka e indexados en Elasticsearch. Accediendo a Dev Tools en Kibana, puedes ver los mensajes indexados y confirmar que los datos son los esperados. Por ejemplo, si nuestro productor Kafka enviara 5 lotes de 10 mensajes cada uno, deberíamos ver un total de 50 registros en el índice.

Para verificar los datos, puedes usar la siguiente consulta en la sección de Herramientas de desarrollo :

Respuesta:

Además, Kibana ofrece la capacidad de crear visualizaciones y paneles que pueden ayudar a que el análisis sea más intuitivo e interactivo. A continuación, podéis ver algunos ejemplos de los paneles y visualizaciones que creamos, que ilustran los datos en varios formatos, mejorando nuestra comprensión de la información procesada.

Ingesta de datos con Kafka Connect

Kafka Connect es un servicio diseñado para facilitar la integración entre fuentes de datos y destinos (sumideros), como bases de datos o sistemas de archivos. Opera con conectores predefinidos que gestionan el movimiento de datos automáticamente. En nuestro caso, Elasticsearch funciona como el sumidero de datos.

Con Kafka Connect, podemos simplificar el proceso de ingesta de datos, eliminando la necesidad de implementar manualmente el flujo de trabajo de ingestión de datos en Elasticsearch. Con el conector adecuado, Kafka Connect permite que los datos enviados a un tema Kafka se indexen directamente en Elasticsearch con una configuración mínima y sin necesidad de codificación adicional.

Trabajando con Kafka Connect

Para implementar Kafka Connect, agregaremos el servicio kafka-connect a nuestra configuración de Docker Compose. Una parte clave de esta configuración es la instalación del conector Elasticsearch, que gestionará la indexación de datos.

Tras configurar el servicio y crear el contenedor Kafka Connect, será necesario un archivo de configuración para el conector Elasticsearch. Este archivo define parámetros esenciales como:

• connection.url: URL de conexión para Elasticsearch.

• topics: El tema de Kafka que el conector monitorizará (en este caso, "logs").

• type.name: Tipo de documento en Elasticsearch (normalmente _doc).

• value.converter: Convierte los mensajes Kafka a formato JSON.

• value.converter.schemas.enable: Especifica si el esquema debe incluir.

• schema.ignore y key.ignore: Ajustes para ignorar esquemas y claves de Kafka durante la indexación.

A continuación se muestra el comando curl para crear el conector Elasticsearch en Kafka Connect:

Con esta configuración, Kafka Connect comenzará automáticamente a ingerir los datos enviados al tema de "logs" e indexarlos en Elasticsearch. Este enfoque permite la ingesta e indexación de datos totalmente automatizada sin necesidad de codificación adicional, simplificando así todo el proceso de integración.

Conclusión

Integrar Kafka y Elasticsearch crea una poderosa cadena de procesamiento y análisis de datos en tiempo real. Esta guía proporciona un enfoque fundamental para construir una arquitectura robusta de ingestión de datos, con visualización y análisis fluidos en Kibana, lista para adaptar a requisitos más complejos en el futuro.

Además, usar Kafka Connect hace que la integración entre Kafka y Elasticsearch sea aún más ágil, eliminando la necesidad de código adicional para procesar e indexar datos. Kafka Connect permite que los datos enviados a un tema específico se indexen automáticamente en Elasticsearch con una configuración mínima.

¿Qué es el camello apache?

Apache Camel es un framework de integración de código abierto que simplifica la conexión de sistemas diversos, permitiendo a los desarrolladores centrar en la lógica de negocio sin preocupar por las complejidades de la comunicación del sistema. El concepto central en Camel son las "rutas", que definen el camino que sigue un mensaje desde el origen hasta el destino, incluyendo potencialmente pasos intermedios como transformaciones, validaciones y filtrado.

Arquitectura del camello apache

Camel emplea "componentes" para conectarse a diferentes sistemas y protocolos, como bases de datos y servicios de mensajería, y "endpoints" para representar los puntos de entrada y salida de los mensajes. Estos conceptos proporcionan un diseño modular y flexible, facilitando la configuración y gestión de integraciones complejas de forma eficiente y escalable.

Uso de Elasticsearch y Apache Camel

Demostraremos cómo configurar una aplicación Java sencilla que emplea Apache Camel para ingirir datos en un clúster de Elasticsearch. También se cubrirán los procesos de creación, actualización y eliminación de datos en Elasticsearch usando rutas definidas en Apache Camel (Apache Camel).

1. Agregar dependencias

El primer paso para configurar esta integración es agregar las dependencias necesarias al archivo pom.xml de tu proyecto. Esto incluirá las bibliotecas Apache Camel y Elasticsearch. Vamos a usar la nueva biblioteca cliente de Java API, así que debemos importar el componente camel-elasticsearch y la versión debe ser la misma que la de la biblioteca camel-core .

Si quieres usar el cliente de descanso de bajo nivel de Java, debes emplear el componente de cliente de descanso de bajo nivel de Elasticsearch.

2. Configuración y ejecución del Camel Context

La configuración comienza creando un nuevo contexto Camel usando la clase DefaultCamelContext , que sirve como base para definir y ejecutar rutas. A continuación, configuramos el componente Elasticsearch, que permitirá a Apache Camel interactuar con un clúster de Elasticsearch. La instancia ESlasticsearchComponent está configurada para conectarse a la dirección localhost:9200, que es la dirección predeterminada para un clúster local de Elasticsearch. Para una configuración de entorno que requiera autenticación, deberías leer la documentación sobre cómo configurar el componente y habilitar la autenticación básica, conocida como "Configurar el componente y habilitar la autenticación básica".

Este componente se agrega al contexto de Camel, permitiendo que las rutas definidas empleen este componente para realizar operaciones en Elasticsearch.

Después, las rutas se agregan al contexto. Crearemos rutas para la indexación masiva, actualización y eliminación de documentos.

3. Configuración de rutas Camel

Indexación de datos

La primera ruta que configuraremos es para la indexación de datos. Emplearemos un archivo JSON que contiene un catálogo de películas. La ruta se configurará para leer el archivo ubicado en src/main/resources/movies.json, deserializar el contenido JSON en objetos Java y luego aplicar una estrategia de agregación para combinar múltiples mensajes en uno solo, permitiendo operaciones por lotes en Elasticsearch. Se configuró el tamaño de 500 elementos por mensaje, es decir, el volumen indexará 500 películas a la vez.

Operación de búsqueda elástica de ruta en masa

El lote de documentos se enviará al endpoint de operaciones masivas de Elasticsearch. Este enfoque garantiza eficiencia y rapidez al manejar grandes volúmenes de datos.

Actualización de datos

La siguiente opción será actualizar los documentos. Indexamos algunas películas en el paso anterior y ahora crearemos nuevas rutas para buscar un documento por código de referencia y luego actualizar el campo de calificación.

Configuramos un contexto Camel (DefaultCamelContext), donde se registra un componente de Elasticsearch y se agrega una ruta personalizada llamada IngestionRoute. La operación comienza enviando el código del documento a través de ProducerTemplate, que inicia la ruta desde el punto final direct:update-ingestión.

A continuación, tenemos el IngestionRoute, que es el punto final de entrada para este flujo. La ruta realiza varias operaciones por oleoductos. Primero, se realiza una búsqueda en Elasticsearch para localizar el documento por código (direct:search-by-id), donde el SearchByCodeProcessor ensambla la consulta a partir del código. Después, el documento recuperado es procesado por el UpdateRatingProcessor, que convierte el resultado en objetos Película, actualiza la calificación de la película a un valor específico y prepara el documento actualizado para ser enviado de nuevo a Elasticsearch para su actualización.

El procesador SearchByCodeProcessor estaba configurado solo para ejecutar la consulta de búsqueda:

El procesador UpdateRatingProcessor es responsable de actualizar el campo de calificación.

Eliminación de datos

Finalmente, la ruta para eliminar documentos está configurada. Aquí, eliminaremos un documento usando su ID. En Elasticsearch, para eliminar un documento necesitamos conocer el identificador del documento, el índice donde se almacena el documento y ejecutar una solicitud de borrado. En Apache Camel realizaremos esta operación creando una nueva ruta como se muestra a continuación.

La ruta comienza desde el punto final direct:op-delete, que sirve como punto de entrada. Cuando un documento necesita ser eliminado, su identificador (_id) se recibe en el cuerpo del mensaje. La ruta entonces establece el encabezado indexId con el valor de este identificador usando("${body}")simple , que extrae el _id del cuerpo del mensaje.

Finalmente, el mensaje se dirige al punto final especificado por URI_DELETE_OPERATION, que se conecta con Elasticsearch para realizar la operación de eliminación de documentos en el índice correspondiente. Ahora que creamos la ruta, podemos crear un contexto Camel (DefaultCamelContext), que está configurado para incluir el componente Elasticsearch.

A continuación, se agrega la ruta de borrado, definida por la clase OperationDeleteRoute , al contexto. Con el contexto inicializado, se emplea un ProducerTemplate para pasar el identificador del documento que debe eliminar al punto final direct:op-delete , lo que activa la ruta de eliminación.

Conclusión

La integración entre Apache Camel y Elasticsearch permite una ingesta de datos robusta y eficiente, aprovechando la flexibilidad de Camel para definir rutas que pueden manejar diferentes escenarios de manipulación de datos, como indexación, actualización y eliminación. Con esta configuración, puedes orquestar y automatizar procesos complejos de forma escalable, cerciorando que tus datos se gestionen de forma eficiente en Elasticsearch. Este ejemplo demostró cómo estas herramientas pueden emplear juntas para crear una solución eficiente y adaptable para la ingestión de datos.

Referencias

• Camello apache

• Arquitectura del camello apache

• Camello apache agregado

• Componente de archivo

• Componente Elasticsearch