LINWARE | Blog | Elastic - Presentamos el modo de huella digital de Filestream

BLOG

Elastic - Presentamos el modo de huella digital de Filestream

Publicada el 26/09/2023

En Filebeat 8.10.0 y 7.17.12, introdujimos un nuevo modo de huellas dactilares que brinda a nuestros usuarios la opción de usar hash del contenido de los archivos para identificarlos en lugar de depender de los metadatos del sistema de archivos. Este cambio está disponible en las entradas de Filestream.

¿Qué es Filestream?

Filestream es un tipo de entrada en Filebeat que se utiliza para ingerir archivos de las rutas indicadas.

Arquitectura de flujo de archivos

Para explicar qué es el modo de huella digital y dónde exactamente lo introdujimos en Filestream, comencemos explicando la arquitectura básica de una entrada de Filestream.

Pelar la cebolla de los componentes superiores:

File Scanner recopila información sobre todos los archivos que coinciden con las rutas de entrada.
File Watcher escanea el sistema de archivos cada pocos segundos, como se especifica en la configuración prospector.scanner.check_interval , y luego compara los estados del sistema de archivos entre comprobaciones. Si algo cambia, emite un evento que describe el cambio.
Prospector toma decisiones sobre qué hacer con estos eventos del sistema de archivos: iniciar/detener la recolección de un archivo, agregar/actualizar/eliminar el estado del archivo, etc.
- Para comenzar a trabajar en un archivo y administrar su estado en el registro, Prospector necesita una identificación única para este archivo, que obtiene del proveedor de identidad de archivo configurado mediante el parámetro file_identity de la entrada.
- Todos los estados de los archivos (como las compensaciones) se almacenan en el Registro : almacenamiento en memoria que se descarga en el disco en cada intervalo de registro.flush configurado en Filebeat. Se almacena en el disco como un registro de operaciones.
- Los recolectores realizan la ingesta de archivos real y envían las líneas que leen a la canalización de procesamiento de eventos que realiza cierto enriquecimiento, transformación, puesta en cola, procesamiento por lotes y, finalmente, entrega los eventos a la salida.

Cuando el enfoque predeterminado no es suficiente

De forma predeterminada, File Scanner utiliza metadatos del sistema de archivos para comparar archivos cuando busca cambios de nombre/movimientos, como: cadena - en sistemas Unix (puede encontrar más información sobre inode aquí ) y - -cadena en Windows ( nFileIndexHigh , nFileIndexLow y dwVolumeSerialNumber respectivamente; lea más en la documentación oficial de Microsoft). La misma cadena se utiliza como identificador de archivo único devuelto por File Identity Provider , y este valor se utiliza como clave para cada archivo en el Registro para buscar el estado actual del archivo.

El objetivo del identificador de archivo único devuelto por el proveedor de identidad de archivo es que debe ser estable, lo que significa que no cambiará durante el tiempo que Filestream ingiere el archivo. Debe ser estable porque Filestream usa este identificador para rastrear los metadatos del archivo, incluido el desplazamiento actual del archivo, para saber dónde continuar la ingesta.

¿Qué pasa si el identificador no es estable? Conduce a la pérdida o duplicación de datos.

Ejemplo de pérdida de datos :

Un ID de archivo ahora coincide con un archivo diferente (no ingerido antes).
En lugar de leer este archivo desde el desplazamiento 0, como se supone que debe hacer Filestream, se aplica la información de desplazamiento incorrecta a este archivo.
Filestream continúa leyendo las líneas de registro demasiado adelante en el archivo, omitiendo líneas de registro. Estas líneas nunca llegarán a la salida.

Ejemplo de duplicación de datos :

Un ID de archivo ha cambiado para un archivo existente.
Ahora aparece como un archivo nuevo en Filestream.
Filestream comienza a leerlo desde el desplazamiento 0 (reingestión).

Desafortunadamente, no todos los sistemas de archivos pueden producir valores de inodo y de dispositivo estables.

Los sistemas de archivos almacenan en caché los inodos y los reutilizan

Si intenta ejecutar este script en diferentes sistemas de archivos, es posible que vea resultados diferentes:

#!/bin/bashnnFILENAME=inode-testnntouch $FILENAMEnINODE=$(ls -i "$FILENAME")necho "$FILENAME created with inode '$INODE'"nnCOPY_FILENAME="$FILENAME-copy"ncp -a $FILENAME $COPY_FILENAMEnCOPY_INODE=$(ls -i "$COPY_FILENAME")necho "Copied $FILENAME->$COPY_FILENAME, the new inode for the copy '$COPY_INODE'"nnrm $FILENAMEnecho "$FILENAME has been deleted"nnls $FILENAMEnncp -a $COPY_FILENAME $FILENAMEnNEW_INODE=$(ls -i "$FILENAME")nnecho "After copying $COPY_FILENAME back to $FILENAME the inode is '$NEW_INODE'"nnrm $FILENAME $COPY_FILENAME

Por ejemplo, en Mac (APFS) verás:

inode-test created with inode '112076744 inode-test'nCopied inode-test->inode-test-copy, the new inode for the copy '112076745 inode-test-copy'ninode-test has been deletednAfter copying inode-test-copy back to inode-test the inode is '112076746 inode-test'

Como puede ver, en APFS los tres archivos tienen diferentes valores de inodo: 112076744 , 112076745 y 112076746 . Entonces, esto funciona como se esperaba.

Sin embargo, si ejecuta el mismo script en un contenedor Docker de Ubuntu:

inode-test created with inode '1715023 inode-test'nCopied inode-test->inode-test-copy, the new inode for the copy '1715026 inode-test-copy'ninode-test has been deletednls: cannot access 'inode-test': No such file or directorynAfter copying inode-test-copy back to inode-test the inode is '1715023 inode-test'

Puede ver que el sistema de archivos almacenó en caché el valor de inodo del primer archivo, que eliminamos, y lo reutilizó para la segunda copia con el mismo nombre de archivo: 1715023 , 1715026 y 1715023 .

Ni siquiera tiene que ser el mismo nombre de archivo; un archivo diferente puede reutilizar el mismo inodo :

# touch xn# ls -i xn1715023 x # <-n# rm xn# touch yn# ls -i yn1715023 y # <-

Hemos observado estos problemas principalmente en entornos de contenedores/virtualizados, pero depende de la implementación del sistema de archivos almacenar en caché y reutilizar los inodos o no. En teoría, puede suceder en cualquier lugar.

Los valores de inodo pueden cambiar en sistemas de archivos que no son Ext.

Los sistemas de archivos ext (por ejemplo, ext4) almacenan el número de inodo en el archivo i_ino , dentro de la estructura inode , que se escribe en el disco. En este caso, si el archivo es el mismo (no otro archivo con el mismo nombre), se garantiza que el número de inodo será el mismo.

Si el sistema de archivos no es Ext, el número de inodo se genera mediante las operaciones de inodo definidas por el controlador del sistema de archivos. Como no tienen el concepto de qué es un inodo , tienen que imitar todos los campos internos del inodo para cumplir con VFS , por lo que este número probablemente será diferente después de reiniciar, en teoría, incluso después de cerrar y abrir el archivo nuevamente. .

Fuentes:

Algunas herramientas de procesamiento de archivos cambian los valores de inodo

Hemos visto a nuestros clientes experimentar problemas con el uso de rsync y cambiar los inodos .
Además, no todo el mundo sabe que sed -i crea un archivo temporal y luego lo mueve al lugar del archivo original cambiando el valor del inodo (es básicamente un archivo nuevo). Por ejemplo, algunos usuarios pueden usar sed -i para enmascarar las credenciales en los registros.

La identificación del dispositivo puede cambiar

Además de los problemas con inode , dependiendo de cómo estén montadas las unidades de disco, es posible que el ID del dispositivo cambie después de reiniciar. Sin embargo, hace algún tiempo ya presentamos una solución para este problema: file_identity: inodemarker .

¿Qué es el modo de huella digital?

El nuevo modo de huellas dactilares se implementa en el componente Escáner de archivos para evitar los problemas mencionados anteriormente.

El nuevo modo de huellas digitales cambia el comportamiento predeterminado del Explorador de archivos de usar metadatos del sistema de archivos a usar hash SHA256 para un rango de bytes determinado del archivo. De forma predeterminada, este rango es de 0 a 1024, pero se puede configurar mediante parámetros de configuración de desplazamiento y longitud .

Ahora que tenemos esta información de huellas dactilares en File Scanner , también se propaga con cada evento del sistema de archivos y es posible utilizar este hash de huellas dactilares como identificador de archivo único en File Identity Provider . Por lo tanto, ahora también hay una nueva opción file_identity: huella digital que permite el uso del valor de la huella digital como identificador de archivo principal en el Registro .

Qué tener en cuenta al utilizar el modo de huella digital + identidad del archivo de huella digital

Hay algunos puntos que se deben considerar antes de comenzar a utilizar esta nueva característica:

Todos sus archivos de registros deben ser únicos en el rango de bytes configurado. La mayoría de los archivos de registro lo son, debido a las marcas de tiempo y simplemente a la naturaleza pura de los registros, pero uno debe inspeccionar los registros y decidir el desplazamiento y la longitud de la huella digital.
Una vez que comience a usar file_identity: huellas dactilares , ya no podrá cambiar el desplazamiento y la longitud de la huella digital; conduciría a una reingestión total de todos los archivos que coincidan con las rutas de entrada.
Hay un impacto en el rendimiento: el aspecto del rendimiento de esta característica merece una sección separada en este artículo:

Actuación

Desde la etapa inicial de trabajo en esta característica, hubo preocupación con respecto al impacto en el rendimiento que causaría en File Scanner . Al final, necesitaríamos abrir un archivo, leer la cantidad de bytes establecidos por la opción de configuración prospector.scanner.fingerprint.length y calcular un SHA256 a partir de él. Y necesitaríamos hacer eso para cada archivo que coincida con los globos en las rutas .

Una pequeña nota al margen aquí: para implementar esta nueva característica, File Scanner tuvo que cambiar mucho. Entonces, cuando trabajé en el código, aproveché esta oportunidad para refactorizar algunas partes de File Scanner y hacer algunas optimizaciones mientras lo hacía, principalmente reduciendo la cantidad de llamadas al sistema . También agregué muchas pruebas para verificar el comportamiento esperado. Entonces, existía la sospecha de que el nuevo Explorador de archivos (modo de huella digital deshabilitado) es más rápido ya que ya no realiza tantas llamadas al sistema.

Después de que el modo de huellas dactilares finalmente se entregó a main , ejecuté algunas pruebas comparativas.

Hay varias conclusiones que sacar aquí:

Al realizar las optimizaciones mencionadas anteriormente en File Scanner , obtuvo un aumento del 84% en el rendimiento.
El nuevo modo de huellas dactilares es un 76% más lento que el modo predeterminado device_id+inode en el NUEVO escáner, lo que lo hace un 8% más rápido que el modo predeterminado en el ANTIGUO Escáner de archivos . Por lo tanto, nuestros clientes experimentarán un Filestream más rápido incluso con el modo de huella digital habilitado.
Ni el algoritmo hash ni la longitud de la huella digital contribuyen mucho al rendimiento general: la mayor parte del tiempo se dedica a abrir y cerrar archivos para leerlos. Entonces, los valores predeterminados para el modo de huellas digitales parecen estar bien.

Conclusión

Este nuevo modo de huellas dactilares resuelve muchos problemas con metadatos inestables en sistemas de archivos y, en comparación con la versión anterior de Filebeat, es incluso más rápido que el modo predeterminado.

Además, el modo predeterminado se volvió mucho más rápido en la nueva versión de Filebeat, por lo que parece muy beneficioso refactorizar algún código antiguo de vez en cuando y ejecutar pruebas comparativas/perfiles para ver cómo cambió el rendimiento.

¿Qué más hay de nuevo en Elastic 8.10? Consulte la publicación del anuncio 8.10 para obtener más información .

Ir al Blog