La gente de Elastic continua trabajando en el proveedor de identidad (IdP) para habilitar el inicio de sesión único entre nuestra interfaz de usuario (consola) en la nube y las aplicaciones implementadas, por ejemplo, Kibana. Nos estamos acercando para tener algo que podamos fusionar en master y 7.x, hemos agregado recientemente:
Instantáneas de búsqueda
Continuamos trabajando en instantáneas de búsqueda, discutiendo casos de uso, los componentes técnicos, las características que se desarrollarán a partir de esto y cómo encaja en el ecosistema Elastic más amplio. Los entregables iniciales se centran en proporcionar un nuevo nivel cálido más barato en nuestro servicio en la nube alojado, mientras que las fases futuras del proyecto están orientadas hacia un nuevo nivel frío con capacidades de escalado casi ilimitadas.
En el frente del desarrollo, hemos agregado información de tiempo a las estadísticas que recopilamos con respecto a la recuperación de datos del almacén de blobs al buscar una instantánea, y también hemos agregado soporte para instantáneas de búsqueda congeladas . Al limitar el número de fragmentos de instantáneas que se pueden buscar que se pueden buscar simultáneamente, esperamos tratar con más gracia los conjuntos de datos cuyo tamaño total excede el tamaño de la memoria caché.
Estamos agregando una API dedicada para montar un índice de una instantánea en un clúster . Esta API, que toma el repositorio, la instantánea y el nombre de índice como entrada, permite que un índice en una instantánea esté disponible para la búsqueda sin esfuerzo y servirá como base para implementar acciones ILM que hacen la transición de índices regulares a índices impulsados por instantáneas.
Hemos estado comparando nuestra implementación actual de instantáneas de búsqueda utilizando diferentes conjuntos de datos (pmc, nyc_taxis, geonames) sobre diferentes desafíos y con varias configuraciones de tamaño de caché. Con esto, pudimos confirmar que la ejecución de consultas de búsqueda en índices respaldados por instantáneas tiene un rendimiento similar al de los índices regulares, siempre que el caché sea lo suficientemente grande como para almacenar en caché los datos del fragmento. También investigamos cómo funciona la característica cuando solo una parte de los datos puede caber en la memoria caché. Aquí, los resultados varían más en función de una serie de factores, y estamos buscando formas de mejorar nuestra implementación actual. También medimos el rendimiento de descarga de S3 sin procesar ejecutando puntos de referencia de restauración completa e identificamos optimizaciones potenciales para hacer que las restauraciones de instantáneas de búsqueda sean más rápidas (más paralelización; descargas más pequeñas en verificaciones de suma de verificación;Número de errores en el proceso.
Crear clave API en nombre de otro usuario
Tenemos un PR abierto que permitiría a un usuario (generalmente un usuario del sistema) crear una clave API en nombre de otro usuario (generalmente un usuario final).
La API requiere credenciales para el usuario final (un nombre de usuario + contraseña o un token de acceso), pero significa que la verificación de autorización se realiza contra el usuario del sistema en lugar del usuario final.
No permitimos intencionalmente a los usuarios crear claves API de forma predeterminada. Por ejemplo, queremos admitir situaciones en las que un administrador de clúster requiere que los usuarios se autentiquen a través de SAML utilizando un dispositivo de segundo factor. Si a esos usuarios se les permitiera crear claves API, eso les daría un medio alternativo de autenticación para el clúster que no utiliza el proveedor de identidad SAML y omite los controles de seguridad previstos.
Sin embargo, las API Keys tienen usos dentro de los productos Elastic para almacenar una credencial que permite que un proceso en segundo plano actúe en nombre de un usuario. El ejemplo principal de esto es el proyecto Kibana Alerting. Una alerta que interactúa con Elasticsearch debe poder autenticarse en Elasticsearch como el usuario que creó la alerta, pero no debe (y puede que no pueda) almacenar la contraseña del usuario. Debido a que las alertas utilizan esa API internamente y nunca la exponen al usuario, el perfil de riesgo es diferente; no le da al usuario una forma de evitar el proceso de autenticación principal.
Por lo tanto, está bien permitir que Kibana cree claves API para usuarios a los que no se les permite crear sus propias claves API. Pero, no queremos que Kibana pueda crear claves API para cualquier usuario que elija; si pudiera hacerlo, podría crear una clave API para el usuario elástico y obtener privilegios de superusuario. Por lo tanto, esta nueva API permite a Kibana crear claves API para usuarios que no necesariamente podrían hacerlo por sí mismos, pero requiere que primero se autentiquen en Kibana (por lo que Kibana se restringe efectivamente para crear solo claves API para usuarios que están registrados en el momento).
Consola correcciones de errores
Arreglamos una regresión en el proxy de la consola que siempre sobrescribía el encabezado "host" reenviado desde Kibana. Esta regresión se introdujo en 7.5.0 y la solución se envía con 7.6.2.
También eliminamos algunos otros errores en la consola, como respetar la carga de los elementos de autocompletar seleccionados en la configuración y restaurar la autocompletar para el punto final de la configuración del índice .
agregación geo_line
Recientemente hemos estado revisando su prototipo de agregación geo_line ( compromiso WIP aquí ), buscando la mejor manera de utilizar nuestras estructuras de datos existentes de asignación eficiente. GeoLine es un agg que puede unir puntos "consecutivos" para crear una sola forma de línea. Piense en un buque de carga con una baliza que informa las coordenadas GPS una vez por hora. Si une esos puntos de datos individuales, obtendrá la ruta espacio-temporal que ha tomado la nave.
Migramos un prototipo para usar matrices primitivas dentro de Object BigArrays que crecen con la ayuda de las utilidades de matriz de Lucene. La clasificación de estos arreglos se realiza con la ayuda de IntroSorter de Lucene. Necesita sincronizarse con la gente de Lucene para entender si ese es el mejor clasificador para el trabajo, se está eligiendo por ahora porque es el más simple.
Ingesta: rendimiento y reintentos
Continuamos trabajando en el POC para agrupar por lotes las operaciones de fragmentos. Las pruebas de rendimiento demostraron cuán poco interactúa esto con las colas existentes de recuento limitado de solicitudes , para las cuales estamos investigando soluciones. La evaluación comparativa también muestra la efectividad de agrupar fsyncs juntos cuando hay niveles muy altos de concurrencia.
Trabajamos con un colaborador de la comunidad para cambiar el código de respuesta cuando la indexación está bloqueada debido a que el uso del espacio en disco excede la etapa de inundación , lo que ahora indica que esta condición es recuperable, ya que el bloqueo del índice se liberará automáticamente una vez que haya suficiente espacio en disco disponible nuevamente. Esto soluciona un problema en el que nuestros clientes de ingesta no estaban volviendo a intentar las solicitudes en esta situación según el código de estado de respuesta erróneo.
Más información: Elastic
Linware Bolivia ⯈