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

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.

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.

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

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: 

• https://stackoverflow.com/a/21123293 
• https://stackoverflow.com/a/4677892 

• 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.

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 .

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 .

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:

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.

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 .