Skip to main content
Ce moteur permet de traiter les fichiers de log d’application comme un flux d’enregistrements. FileLog vous permet de :
  • Vous abonner à des fichiers de log.
  • Traiter les nouveaux enregistrements à mesure qu’ils sont ajoutés aux fichiers de log suivis.

Créer une table

Arguments du moteur :
  • path_to_logs – Chemin des fichiers de log à suivre. Il peut s’agir du chemin vers un répertoire contenant des fichiers de log ou vers un seul fichier de log. Un chemin relatif est résolu par rapport au répertoire user_files_path, comme pour la fonction de table file ; un chemin relatif qui pointe déjà vers user_files_path depuis le répertoire de travail du serveur (par exemple, user_files/my_app/app.log lorsque le serveur s’exécute dans son répertoire de données, comme dans l’image Docker officielle) reste interprété de la même manière. Le nom du fichier dans le chemin peut contenir des motifs glob (*, ?, {abc,def}, {N..M}) pour ne lire que les fichiers du répertoire correspondant à ces motifs. Voir Sélectionner des fichiers avec des motifs glob. Notez que ClickHouse n’autorise que les chemins situés dans le répertoire user_files.
  • format_name - Format de l’enregistrement. Notez que FileLog traite chaque ligne d’un fichier comme un enregistrement distinct et que tous les formats de données ne s’y prêtent pas.
Paramètres facultatifs :
  • poll_timeout_ms - Délai d’expiration d’une opération de poll unique sur le fichier de log. Par défaut : stream_poll_timeout_ms.
  • poll_max_batch_size — Nombre maximal d’enregistrements récupérés lors d’une seule opération de poll. Par défaut : max_block_size.
  • max_block_size — Taille maximale du lot (en enregistrements) pour le poll. Par défaut : max_insert_block_size.
  • max_threads - Nombre maximal de threads pour analyser les fichiers. La valeur par défaut est 0, ce qui signifie que ce nombre sera égal à max(1, physical_cpu_cores / 4).
  • poll_directory_watch_events_backoff_init - Temporisation initiale du thread de surveillance du répertoire. Par défaut : 500.
  • poll_directory_watch_events_backoff_max - Temporisation maximale du thread de surveillance du répertoire. Par défaut : 32000.
  • poll_directory_watch_events_backoff_factor - Vitesse du backoff, exponentielle par défaut. Par défaut : 2.
  • handle_error_mode — Mode de gestion des erreurs du moteur FileLog. Valeurs possibles : default (un SELECT direct lève une exception si l’analyse d’un enregistrement échoue ; lorsque la table alimente des vues matérialisées en flux, cet enregistrement est ignoré et l’erreur est consignée dans le journal du serveur), stream (le message d’exception et l’enregistrement brut seront enregistrés dans les colonnes virtuelles _error et _raw_record).

Description

Les enregistrements reçus sont suivis automatiquement, de sorte que chaque enregistrement d’un fichier de log n’est compté qu’une seule fois. Si, lors de sa lecture suivante, un fichier est plus court que la position enregistrée pour lui, comme après un logrotate avec copytruncate, il est relu depuis le début. Une troncature n’est pas détectée si le fichier atteint de nouveau au moins cette position avant sa prochaine lecture. Un fichier possédant plusieurs noms dans le répertoire (liens physiques) est lu sous un seul d’entre eux. Un fichier qui ne peut pas être ouvert (un lien symbolique dont la cible a été supprimée, un fichier non lisible par le serveur ou le fichier d’une table à fichier unique qui a été supprimé) est ignoré, une erreur est consignée dans le journal du serveur, et l’ouverture est retentée tant que la table est chargée, jusqu’à ce qu’elle réussisse ; un fichier qui était manquant est alors lu depuis le début. Un lien symbolique n’est lu que si sa cible existe au moment où la table le détecte. SELECT n’est pas particulièrement utile pour lire des enregistrements (sauf pour le débogage), car chaque enregistrement ne peut être lu qu’une seule fois. Il est plus pratique de créer des flux en temps réel à l’aide de vues matérialisées. Pour ce faire :
  1. Utilisez le moteur pour créer une table FileLog et considérez-la comme un flux de données.
  2. Créez une table avec la structure souhaitée.
  3. Créez une vue matérialisée qui convertit les données du moteur et les insère dans une table créée précédemment.
Lorsqu’une MATERIALIZED VIEW est associée au moteur, elle commence à collecter des données en arrière-plan. Cela vous permet de recevoir en continu des enregistrements depuis des fichiers de log et de les convertir au format requis à l’aide de SELECT. Une table FileLog peut avoir autant de vues matérialisées que vous le souhaitez ; elles ne lisent pas les données directement depuis la table, mais reçoivent les nouveaux enregistrements (par blocs). Vous pouvez ainsi écrire dans plusieurs tables avec différents niveaux de détail (avec regroupement et agrégation, ou sans). Exemple :
Pour ne plus recevoir les données des flux ou pour modifier la logique de conversion, détachez la vue matérialisée :
Si vous souhaitez modifier la table cible à l’aide de ALTER, nous vous recommandons de désactiver la vue matérialisée afin d’éviter toute incohérence entre la table cible et les données de la vue.

Sélectionner des fichiers avec des motifs glob

Lorsque le nom de fichier dans path_to_logs contient des motifs glob, la table lit les fichiers de ce répertoire dont le nom correspond, y compris ceux qui apparaissent par la suite. Les motifs glob ne sont pas pris en charge dans la partie répertoire du chemin. Un fichier lu par la table continue de l’être lorsqu’il est renommé avec un nom qui ne correspond pas, jusqu’à ce qu’il soit supprimé du répertoire. Un fichier créé puis renommé avec un nom qui ne correspond pas pendant que la table est détachée ou que le serveur est arrêté n’est pas lu. Sous macOS, où le répertoire est surveillé en comparant ses énumérations successives, il en va de même pour un fichier créé puis renommé avec un nom qui ne correspond pas avant que la table ne l’ait énuméré. C’est précisément ce qu’exige la rotation des journaux. Par exemple, logrotate avec compress et delaycompress maintient le répertoire dans l’état suivant :
Une table basée sur FileLog('/var/lib/clickhouse/user_files/my_app/*.log', 'JSONEachRow') lit app.log ; après la rotation, elle continue de lire app.log.1, si bien que les lignes que l’application y écrit avant de rouvrir son journal ne sont pas perdues, et elle ne lit jamais les fichiers compressés. Veillez à ce que le motif glob ne corresponde pas aux noms des fichiers compressés.

Colonnes virtuelles

  • _filename - Nom du fichier de log. Type de données : LowCardinality(String).
  • _offset - Décalage dans le fichier de log. Type de données : UInt64.
Colonnes virtuelles supplémentaires lorsque handle_error_mode='stream' :
  • _raw_record - Enregistrement brut qui n’a pas pu être analysé correctement. Type de données : Nullable(String).
  • _error - Message d’exception survenu lors d’une erreur d’analyse. Type de données : Nullable(String).
Remarque : les colonnes virtuelles _raw_record et _error ne sont renseignées qu’en cas d’exception lors de l’analyse ; elles sont toujours NULL lorsque le message a été analysé avec succès.

Durabilité des données

Le moteur FileLog enregistre la position consommée pour un fragment avant que l’insertion à laquelle appartient ce fragment soit validée. Ainsi, en cas d’interruption du serveur, la position enregistrée peut être en avance sur les données ayant atteint la table cible. Au redémarrage, chaque fichier de log reprend à la position enregistrée dans son répertoire de métadonnées, de sorte que ces lignes ne sont jamais relues : elles sont perdues sans qu’aucune erreur ne soit signalée et count() est simplement inférieur. Une défaillance de processus ordinaire suffit à provoquer ce problème, sans nécessiter de coupure d’alimentation, car la position est enregistrée dans un fichier de métadonnées renommé à son emplacement définitif alors que la partie cible est encore en cours d’écriture. La perte du cache de pages de l’OS peut également entraîner la perte de données déjà écrites dans la table cible, par exemple lors d’une coupure d’alimentation au niveau du périphérique ou d’une réinitialisation non propre de l’hôte ou du kernel. Les fichiers de métadonnées contenant les positions sont eux-mêmes écrits sans fsync du fichier ni de son répertoire ; ils n’offrent donc aucune garantie de durabilité propre. Contrairement aux moteurs de courtiers de messages, FileLog ne peut pas être protégé contre ce problème en rendant d’abord la cible durable. Comme la position est enregistrée au sein du pipeline de lecture, avant la fin de l’insertion à laquelle elle appartient, définir fsync_after_insert = 1 sur les tables MergeTree cibles ne garantit pas la durabilité de la partie insérée avant l’avancement de la position. Considérez la consommation de FileLog comme un suivi au mieux des fichiers locaux : lorsqu’aucune ligne ne doit être perdue, conservez les fichiers de log source jusqu’à ce que les données consommées aient été vérifiées dans la cible, afin de pouvoir répéter la consommation. SYSTEM RESET FILELOG, ou la suppression puis la recréation de la table, effacent les positions enregistrées et relisent les fichiers depuis le début.