Lanzamiento de Elastic Stack 6.6.0

¡La versión 6.6.0 ya está aquí!

Este lanzamiento presenta nuevas características en el stack que simplifican la forma en que gestionas y escalas el cluster, la indexación y la búsqueda de formas geométricas con mayor rapidez y almacenamiento más eficiente, y mejoras clave para Elasticsearch SQL, Machine Learning, Auditbeat y más.

Despliega un cluster en nuestro Elasticsearch Service o descarga el stack para probar estas nuevas características.

Gestiona el ciclo de vida de los datos en escala con la gestión de ciclo de vida del índice

Los usuarios con casos de uso de series temporales, como logging, métricas y APM, suelen almacenar datos en índices basados en el tiempo. A medida que aumenta la antigüedad de estos datos, existen diversas maneras de asegurar que se almacenen de la forma más rentable. Por ejemplo, a medida que aumenta la antigüedad del índice, el usuario puede comprimir la cantidad de shards o reducir la cantidad de réplicas usadas para almacenar el índice, o bien, moverlo a nodos desplegados en hardware más económico. Otra opción es eliminar índices que alcancen una cierta antigüedad. Los métodos existentes para definir las políticas de gestión del ciclo de vida del índice se encuentran fuera del cluster (por ejemplo, Curator o los scripts de automatización personalizados), son limitados y suponen una sobrecarga de gestión para configurar y controlar. La nueva característica de gestión de ciclo de vida del índice brinda una forma más integrada y simple de gestionar estos datos. Esto facilita la aplicación de las mejores prácticas.

La característica de gestión de ciclo de vida del índice divide el ciclo de vida de un índice en cuatro fases: caliente, cálido, frío y eliminado. Puedes definir una política de ciclo de vida del índice que te permita alcanzar lo siguiente:

• Tener un shard primario en cada nodo caliente para maximizar el rendimiento de la indexación.
• Reemplazar el índice caliente por un nuevo índice vacío tan pronto como el índice existente esté “lleno”, o después de un determinado período de tiempo.
• Mover el índice antiguo a nodos cálidos, donde se lo puede comprimir en un shard único y fusionarlo en un segmento único para optimizar el almacenamiento y la búsqueda.
• En un futuro, mover el índice a nodos fríos para conseguir un almacenamiento más económico.

En el lanzamiento futuro, podrás “congelar” el índice y dejarlo en un estado que compense la densidad de almacenamiento por latencia de búsqueda. Finalmente, cuando el índice ya no te sea útil, podrás eliminarlo.

Todo esto está disponible de forma automática mediante la gestión de ciclo de vida del índice.

Los índices congelados permiten un almacenamiento mayor para las proporciones de memoria

Elasticsearch está altamente optimizado para realizar búsquedas de la forma más rápida y eficiente posible. Entonces, históricamente, cada índice abierto (es decir, apto para la búsqueda) usaba una pequeña cantidad de memoria para asegurar que, ante cualquier coincidencia de búsqueda, ese índice se ejecutaría rápidamente. Cuanto mayor el tamaño y la cantidad de índices en un determinado nodo, mayor la memoria necesaria para mantener los índices en estado abierto. Esto significa, efectivamente, que existen límites prácticos para la cantidad de almacenamiento que un nodo determinado podrá cubrir con un JVM único. Para la mayoría de los usuarios y los casos de uso, esto no es un problema. Sin embargo, en algunos casos, como en los que se requiere almacenar datos a largo plazo durante muchos años por razones normativas, existe el deseo de mantener los datos en línea y aptos para la búsqueda, pero con una necesidad menor de rendimiento máximo en las solicitudes de datos más antiguos.

Los índices congelados permiten una proporción mucho mayor de almacenamiento en disco para heap (memoria), a expensas de la latencia de búsqueda. Cuando se congela un índice, no acepta heap, lo cual permite que un nodo simple gestione con facilidad miles de índices con una sobrecarga muy baja. Cuando una búsqueda se dirige a índices congelados, la búsqueda abrirá completamente cada índice, buscará en él y, después, lo cerrará de manera secuencial. A diferencia de los índices cerrados, los índices congelados se indexan. Los índices congelados brindan una nueva gama de opciones para optimizar el costo y el rendimiento del cluster según tus necesidades.

Formas geométricas más rápidas y más pequeñas admitidas por Bkd

La estructura de datos de árbol de Bkd continúa disponible. En la versión 5.0, introdujimos puntos geográficos admitidos por Bkd, lo cual resultó en mejoras significativas en almacenamiento, memoria y rendimiento para la búsqueda de puntos geográficos. ¡Con la versión 6.6.0, ofrecemos los mismos beneficios basados en Bkd para las formas geométricas! Hemos logrado la Triple Crown de la búsqueda: la indexación es más rápida, necesita menos espacio en disco y usará menos memoria.

Elasticsearch SQL agrega soporte para histogramas de fecha

Elasticsearch SQL continúa su camino hacia el GA con una gama de mejoras que tratan las búsquedas por tiempo, incluido el soporte nativo para histogramas de fecha que usan la sintaxis de SQL. Estas mejoras son importantes para todos los usuarios de Elasticsearch SQL, pero esperamos que el soporte de histogramas de fecha genere el mayor impacto en los usuarios de Canvas, lo cual facilitará la construcción de cuadros de series temporales en Kibana.

Machine Learning presenta las anotaciones

Cuando se investiga un problema potencial de sistema o de seguridad, es normal querer registrar los hallazgos y el progreso, registrar la causa raíz de un problema de sistema y los pasos necesarios para resolverlo, etcétera. Ahora, directamente en la UI de Machine Learning, podrás crear anotaciones que todos los usuarios podrán ver. Esto simplifica la colaboración y permite que mantengas un registro de las acciones llevadas a cabo sin salir de Kibana.

La APM de Elastic agrega nuevas métricas de agente

La APM presenta métricas de agente en el lanzamiento 6.6. Ahora, la última versión de nuestros agentes informará automáticamente las métricas de la CPU y la memoria de nivel de proceso y de sistema, junto con los rastros y errores.

Además, el rastreo distribuido ahora está disponible, y todos los agentes cumplen con OpenTracing. Por último, la UI de la APM simplifica el cambio de la vista de APM a las vistas de Logging o infraestructura relevantes, y el agente Java cuenta con dos nuevas característica increíbles. Lee el artículo de blog APM para conocer todos los detalles.

Además de estos cambios, también estamos entusiasmados por anunciar que la APM de Elastic ahora estará disponible para despliegues en Elasticsearch Service (lee el blog) y Elastic Cloud Enterprise (lee el blog).

Espera. Hay más…

Además de todo esto, también agregamos varias características y mejoras recientes en Beats, Logstash y Kibana.

Auditbeat agregó un nuevo módulo de sistema para recopilar del sistema diferentes tipos de información relacionada con la seguridad. Esto incluye datos sobre el sistema operativo, los procesos, los sockets y los usuarios existentes en un host particular. Puedes leer más sobre el módulo de sistema de Auditbeat en el artículo de blog dedicado.

Ahora, Machine Learning viene con trabajos de aprendizaje automático para los datos de Audibeat. Esto brinda a los usuarios una introducción para detectar anomalías comunes en la información de auditoría.

Filebeat agrega una nueva entrada de NetFlow, que puede usarse para recibir esos registros de NetFlow y IPFIX sobre UDP. Es compatible con NetFlow v1, v5, v6, v7, v8, v9 y IPFIX.

Ahora, cuando uses el gestor central de Beats, podrás configurar Metricbeat y Filebeat para rechazar modificaciones a algunas partes de la configuración. Esto permite una aplicación efectiva a nivel de beat en ejecución de lo que se puede modificar a partir de la configuración remota. Para mejorar la operación segura, ahora bloqueamos las modificaciones en la salida de la consola y en la salida del archivo por defecto.

Del lado de Logstash, la máquina de ejecución Java de mayor rendimiento introducida como beta en la 6.1, ahora está disponible de forma general.

En cuanto a Kibana, presentamos una característica muy demandada que permite una única instancia de Kibana para múltiples nodos de Elasticsearch, lo cual evade los desafíos previos relacionados con un único punto de falla en la conexión entre Kibana y Elasticsearch. En el frente de visualización, el dashboard de Kibana puede exportarse como PNG. Puedes leer los destacados del lanzamiento de Kibana 6.6 para conocer más detalles sobre estos cambios y otros.

Pruébalo ahora

Despliega un cluster en nuestro Elasticsearch Service o descarga el stack para probar estas nuevas características.