Skip to main content
Este motor permite procesar archivos de registro de aplicaciones como un flujo de registros. FileLog le permite:
  • Suscribirse a archivos de registro.
  • Procesar nuevos registros a medida que se añaden a los archivos de registro a los que se haya suscrito.

Crear una table

Argumentos del motor:
  • path_to_logs – Ruta de los archivos de registro a los que suscribirse. Puede ser la ruta a un directorio con archivos de registro o a un único archivo de registro. Una ruta relativa se resuelve con respecto al directorio user_files_path, como en la función de table file; una ruta relativa que ya apunta a una ubicación dentro de user_files_path desde el directorio de trabajo del servidor (por ejemplo, user_files/my_app/app.log cuando el servidor se ejecuta en su directorio de datos, como en la imagen oficial de Docker) conserva ese significado. El nombre de archivo en la ruta puede contener globs (*, ?, {abc,def}, {N..M}) para leer solo los archivos coincidentes del directorio; consulte Selección de archivos con globs. Tenga en cuenta que ClickHouse solo permite rutas dentro del directorio user_files.
  • format_name - Formato del registro. Tenga en cuenta que FileLog procesa cada línea de un archivo como un registro independiente y que no todos los formatos de datos son adecuados para ello.
Parámetros opcionales:
  • poll_timeout_ms - Tiempo de espera para una sola operación de sondeo del archivo de registro. Predeterminado: stream_poll_timeout_ms.
  • poll_max_batch_size — Número máximo de registros que se pueden sondear en una sola operación. Predeterminado: max_block_size.
  • max_block_size — Tamaño máximo del lote (en registros) para el sondeo. Predeterminado: max_insert_block_size.
  • max_threads - Número máximo de hilos para analizar archivos; el valor predeterminado es 0, lo que significa que el número será max(1, physical_cpu_cores / 4).
  • poll_directory_watch_events_backoff_init - Valor de espera inicial para el hilo de supervisión del directorio. Predeterminado: 500.
  • poll_directory_watch_events_backoff_max - Valor de espera máximo para el hilo de supervisión del directorio. Predeterminado: 32000.
  • poll_directory_watch_events_backoff_factor - Velocidad del backoff; de forma predeterminada, es exponencial. Predeterminado: 2.
  • handle_error_mode — Cómo gestionar los errores del motor FileLog. Valores posibles: default (un SELECT directo lanza una excepción si no se puede analizar un registro; cuando la table envía datos en streaming a vistas materializadas, ese registro se omite y el error se escribe en el log del servidor), stream (el mensaje de excepción y el registro sin procesar se guardarán en las columnas virtuales _error y _raw_record).

Descripción

Los registros entregados se controlan automáticamente, de modo que cada registro de un archivo de registro solo se cuenta una vez. Si, en la siguiente lectura, un archivo es más corto que el offset registrado para él, como ocurre después de logrotate con copytruncate, se vuelve a leer desde el principio. No se detecta un truncamiento si el archivo vuelve a crecer hasta alcanzar al menos ese offset antes de la siguiente lectura. Un archivo con varios nombres en el directorio (enlaces físicos) se lee con uno solo de ellos. Un archivo que no se puede abrir (un enlace simbólico cuyo destino se eliminó, un archivo que el servidor no puede leer o el archivo de una table de un solo archivo que se eliminó) se omite, se registra un error en el log del servidor y, mientras la table esté cargada, se reintenta su apertura hasta que sea posible; en ese momento, un archivo que faltaba se lee desde el principio. Un enlace simbólico solo se lee si su destino existe cuando la table lo encuentra. SELECT no resulta especialmente útil para leer registros (excepto para depuración), porque cada registro solo puede leerse una vez. Es más práctico crear hilos en tiempo real mediante vistas materializadas. Para ello:
  1. Use el motor para crear una table FileLog y considérela un flujo de datos.
  2. Cree una table con la estructura deseada.
  3. Cree una vista materializada que convierta los datos del motor y los inserte en una table creada previamente.
Cuando la MATERIALIZED VIEW se conecta al motor, comienza a recopilar datos en segundo plano. Esto le permite recibir continuamente registros de archivos de registro y convertirlos al formato requerido mediante SELECT. Una table FileLog puede tener tantas vistas materializadas como desee; no leen datos de la table directamente, sino que reciben nuevos registros (en bloques). De este modo, puede escribir en varias tables con distintos niveles de detalle (con agrupación y agregación, y sin ellas). Ejemplo:
Para dejar de recibir datos de los flujos o cambiar la lógica de conversión, desvincula la vista materializada:
Si desea cambiar la table de destino con ALTER, le recomendamos deshabilitar la vista materializada para evitar discrepancias entre la table de destino y los datos de la vista.

Selección de archivos con globs

Cuando el nombre de archivo en path_to_logs contiene globs, la table lee los archivos de ese directorio cuyos nombres coinciden, incluidos los que aparezcan más adelante. Los globs no son compatibles en la parte de directorio de la ruta. Un archivo que la table lee se sigue leyendo aunque se le cambie el nombre por uno que no coincida, hasta que se elimine del directorio. Un archivo que se crea y se renombra con un nombre que no coincide mientras la table está desasociada (detached) o el servidor está detenido no se lee. En macOS, donde el directorio se supervisa comparando sus enumeraciones, ocurre lo mismo con un archivo que se crea y se renombra con un nombre que no coincide antes de que la table lo enumere. Este es justamente el comportamiento que requiere la rotación de logs. Por ejemplo, logrotate con compress y delaycompress deja el directorio así:
Una table definida sobre FileLog('/var/lib/clickhouse/user_files/my_app/*.log', 'JSONEachRow') lee app.log; tras la rotación, sigue leyendo app.log.1, de modo que no se pierden las líneas que la aplicación escribe allí antes de volver a abrir su log, y nunca lee los archivos comprimidos. Asegúrese de que el patrón glob no coincida con los nombres de los archivos comprimidos.

Columnas virtuales

  • _filename - Nombre del archivo de registro. Tipo de dato: LowCardinality(String).
  • _offset - Desplazamiento en el archivo de registro. Tipo de dato: UInt64.
Columnas virtuales adicionales cuando handle_error_mode='stream':
  • _raw_record - Registro sin procesar que no pudo analizarse correctamente. Tipo de dato: Nullable(String).
  • _error - Mensaje de excepción que se produjo durante un análisis fallido. Tipo de dato: Nullable(String).
Nota: las columnas virtuales _raw_record y _error solo se rellenan en caso de excepción durante el análisis; siempre son NULL cuando el mensaje se analiza correctamente.

Durabilidad de los datos

El motor FileLog registra el offset consumido de un fragmento antes de que se confirme el insert al que pertenece, por lo que una interrupción del servidor puede dejar el offset registrado por delante de los datos que llegaron a la table de destino. Al reiniciarse, cada archivo de registro se reanuda desde el offset registrado en su directorio de metadatos, por lo que esas filas no se vuelven a leer: se pierden sin que se produzca ningún error y count() es simplemente menor. Basta un fallo normal del proceso para que esto ocurra, sin necesidad de una pérdida de alimentación, ya que el offset se registra en un archivo de metadatos que se renombra en su ubicación definitiva mientras la parte de destino aún se está escribiendo. La pérdida de la caché de páginas del SO también puede descartar datos que ya se habían escrito en la table de destino; por ejemplo, una pérdida de alimentación a nivel de dispositivo o un reinicio no limpio del host o del kernel. Los archivos de metadatos que contienen los offsets se escriben sin ejecutar fsync en el archivo ni en su directorio, por lo que tampoco ofrecen por sí mismos ninguna garantía de durabilidad. A diferencia de los motores de intermediarios de mensajes, FileLog no puede protegerse frente a esto haciendo primero duradero el destino. Como el offset se registra dentro del pipeline de lectura, antes de que finalice el insert al que pertenece, establecer fsync_after_insert = 1 en las tables MergeTree de destino no garantiza que la parte insertada sea duradera antes de que avance el offset. Trate el consumo de FileLog como un seguimiento de archivos locales de mejor esfuerzo: si no se puede perder ninguna fila, conserve los archivos de registro de origen hasta verificar los datos consumidos en el destino, de modo que el consumo pueda repetirse. Tanto SYSTEM RESET FILELOG como eliminar y volver a crear la table descartan los offsets registrados y vuelven a leer los archivos desde el principio.