Motor de tabela FileLog

Este motor permite processar arquivos de log de aplicativos como um fluxo de registros.

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:

1. Use o motor para criar uma tabela FileLog e trate-a como um fluxo de dados.
2. Crie uma tabela com a estrutura desejada.
3. 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 logs GROUP BY day, level;

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

Para deixar de receber dados dos fluxos 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.