メインコンテンツまでスキップ
メインコンテンツまでスキップ

FileLogエンジン

このエンジンは、アプリケーションログファイルをレコードのストリームとして処理することを可能にします。

FileLog を使用すると：

  • ログファイルにサブスクライブできます。
  • サブスクライブされたログファイルに新しいレコードが追加されると、それを処理できます。

テーブルを作成する​

エンジンの引数：

  • path_to_logs – サブスクライブするログファイルへのパス。ログファイルが保存されているディレクトリへのパスか、単一のログファイルへのパスを指定できます。ClickHouseはuser_filesディレクトリ内のパスのみを許可することに注意してください。
  • format_name - レコードのフォーマット。FileLogはファイル内の各行を別々のレコードとして処理するため、すべてのデータフォーマットが適しているわけではありません。

オプションのパラメータ：

  • poll_timeout_ms - ログファイルからの単一ポーリングのタイムアウト。デフォルト: stream_poll_timeout_ms。
  • poll_max_batch_size — 単一ポーリングでポーリングされる最大レコード数。デフォルト: max_block_size。
  • max_block_size — ポーリングの最大バッチサイズ（レコード単位）。デフォルト: max_insert_block_size。
  • max_threads - ファイルを解析するための最大スレッド数。デフォルトは0で、これはmax(1, physical_cpu_cores / 4)の値になります。
  • poll_directory_watch_events_backoff_init - ディレクトリ監視スレッドの初期スリープ値。デフォルト: 500。
  • poll_directory_watch_events_backoff_max - ディレクトリ監視スレッドの最大スリープ値。デフォルト: 32000。
  • poll_directory_watch_events_backoff_factor - バックオフの速度、デフォルトは指数的です。デフォルト: 2。
  • handle_error_mode — FileLogエンジンのエラー処理方法。可能な値: default（メッセージの解析に失敗した場合は例外がスローされる）、stream（例外メッセージと生のメッセージが仮想カラム_errorおよび_raw_messageに保存される）。

説明​

配信されるレコードは自動的に追跡されるため、ログファイル内の各レコードは一度のみカウントされます。

SELECTはレコードを読み取るためには特に役立ちません（デバッグを除く）。なぜなら、各レコードは一度だけ読み取れるからです。リアルタイムスレッドを作成するためには、materialized viewsを作成するのがより実用的です。これを行うには：

  1. エンジンを使用してFileLogテーブルを作成し、それをデータストリームと見なします。
  2. 希望する構造のテーブルを作成します。
  3. エンジンからデータを変換し、事前に作成したテーブルに挿入するマテリアライズドビューを作成します。

MATERIALIZED VIEWがエンジンに接続すると、バックグラウンドでデータを収集し始めます。これにより、ログファイルからのレコードを継続的に受け取り、SELECTを使用して必要なフォーマットに変換できます。 1つのFileLogテーブルには、必要なだけのマテリアライズドビューを持つことができ、それらはテーブルからデータを直接読み取るのではなく、新しいレコード（バッチ単位）を受け取ります。この方法により、異なる詳細レベルの複数のテーブルに書き込むことができます（グループ化 - 集計ありおよびなしで）。

例：

ストリームデータの受信を停止するか、変換ロジックを変更したい場合は、マテリアライズドビューを分離します：

ターゲットテーブルをALTERを使用して変更したい場合は、ターゲットテーブルとビューからのデータとの不一致を避けるために、マテリアルビューを無効にすることをお勧めします。

仮想カラム​

  • _filename - ログファイルの名前。データ型: LowCardinality(String)。
  • _offset - ログファイル内のオフセット。データ型: UInt64。

handle_error_mode='stream'の場合の追加の仮想カラム：

  • _raw_record - 正常に解析できなかった生のレコード。データ型: Nullable(String)。
  • _error - 解析に失敗した際に発生した例外メッセージ。データ型: Nullable(String)。

注意: _raw_record および _error 仮想カラムは、解析中に例外が発生した場合にのみ埋められ、メッセージが正常に解析された場合は常にNULLになります。