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
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épertoireuser_files_path, comme pour la fonction de table file ; un chemin relatif qui pointe déjà versuser_files_pathdepuis le répertoire de travail du serveur (par exemple,user_files/my_app/app.loglorsque 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épertoireuser_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.
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 (unSELECTdirect 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_erroret_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 unlogrotate 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 :
- Utilisez le moteur pour créer une table FileLog et considérez-la comme un flux de données.
- Créez une table avec la structure souhaitée.
- 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.
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 :
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 danspath_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 :
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.
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).
_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 moteurFileLog 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.