Motor de tabela FileLog - ClickHouse Documentation

Este motor permite processar arquivos de log de aplicativos como um fluxo de registros. FileLog permite que você:

Monitore arquivos de log.
Processe novos registros à medida que são adicionados aos arquivos de log monitorados.

Criando uma tabela

CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
    name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
    name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
    ...
) ENGINE = FileLog('path_to_logs', 'format_name') SETTINGS
    [poll_timeout_ms = 0,]
    [poll_max_batch_size = 0,]
    [max_block_size = 0,]
    [max_threads = 0,]
    [poll_directory_watch_events_backoff_init = 500,]
    [poll_directory_watch_events_backoff_max = 32000,]
    [poll_directory_watch_events_backoff_factor = 2,]
    [handle_error_mode = 'default']

Argumentos do motor:

path_to_logs – Caminho para os arquivos de log aos quais assinar. Pode ser o caminho para um diretório com arquivos de log ou para um único arquivo de log. Observe que o ClickHouse permite apenas caminhos dentro do diretório user_files.
format_name - Formato do registro. Observe que o FileLog processa cada linha de um arquivo como um registro separado, e nem todos os formatos de dados são adequados para isso.

Parâmetros opcionais:

poll_timeout_ms - Timeout para um único poll do arquivo de log. Padrão: stream_poll_timeout_ms.
poll_max_batch_size — Quantidade máxima de registros a serem obtidos em um único poll. Padrão: max_block_size.
max_block_size — Tamanho máximo do lote (em registros) para o poll. Padrão: max_insert_block_size.
max_threads - Número máximo de threads para analisar arquivos; o padrão é 0, o que significa que o número será max(1, physical_cpu_cores / 4).
poll_directory_watch_events_backoff_init - Valor inicial de espera para a thread de monitoramento do diretório. Padrão: 500.
poll_directory_watch_events_backoff_max - Valor máximo de espera para a thread de monitoramento do diretório. Padrão: 32000.
poll_directory_watch_events_backoff_factor - Velocidade do backoff, exponencial por padrão. Padrão: 2.
handle_error_mode — Como tratar erros no motor FileLog. Valores possíveis: default (uma exceção será lançada se não for possível analisar uma mensagem), stream (a mensagem da exceção e a mensagem bruta serão salvas nas colunas virtuais _error e _raw_message).

Descrição

Os registros recebidos são rastreados automaticamente, portanto cada registro em um arquivo de log é contabilizado apenas uma vez. SELECT não é particularmente útil para ler registros (exceto para depuração), porque cada registro só pode ser lido uma vez. É mais prático criar fluxos em tempo real usando visões materializadas. Para fazer isso:

Use o motor para criar uma tabela FileLog e trate-a como um fluxo de dados.
Crie uma tabela com a estrutura desejada.
Crie uma visão materializada que converta os dados do motor e os grave em uma tabela criada anteriormente.

Quando a MATERIALIZED VIEW é associada ao motor, ela começa a coletar dados em segundo plano. Isso permite que você receba continuamente registros de arquivos de log e os converta para o formato necessário usando SELECT. Uma tabela FileLog pode ter quantas visões materializadas você quiser; elas não leem dados da tabela diretamente, mas recebem novos registros (em blocos). Dessa forma, você pode gravar em várias tabelas com diferentes níveis de detalhamento (com agrupamento - agregação e sem). Exemplo:

  CREATE TABLE logs (
    timestamp UInt64,
    level String,
    message String
  ) ENGINE = FileLog('user_files/my_app/app.log', 'JSONEachRow');

  CREATE TABLE daily (
    day Date,
    level String,
    total UInt64
  ) ENGINE = SummingMergeTree(day, (day, level), 8192);

  CREATE MATERIALIZED VIEW consumer TO daily
    AS SELECT toDate(toDateTime(timestamp)) AS day, level, count() AS total
    FROM queue GROUP BY day, level;

  SELECT level, sum(total) FROM daily GROUP BY level;

Para deixar de receber dados dos streams ou alterar a lógica de conversão, desanexe a visão materializada:

  DETACH TABLE consumer;
  ATTACH TABLE consumer;

Se você quiser alterar a tabela de destino usando ALTER, recomendamos desativar a visão materializada para evitar discrepâncias entre a tabela de destino e os dados provenientes da view.

Colunas virtuais

_filename - Nome do arquivo de log. Tipo de dado: LowCardinality(String).
_offset - Offset no arquivo de log. Tipo de dado: UInt64.

Colunas virtuais adicionais quando handle_error_mode='stream':

_raw_record - Registro bruto que não pôde ser processado com sucesso. Tipo de dado: Nullable(String).
_error - Mensagem da exceção gerada durante a falha de parsing. Tipo de dado: Nullable(String).

Observação: as colunas virtuais _raw_record e _error são preenchidas apenas em caso de exceção durante o parsing; elas sempre são NULL quando a mensagem é processada com sucesso.

​Criando uma tabela

​Descrição

​Colunas virtuais

Criando uma tabela

Descrição

Colunas virtuais