FileLog permite que você:
- Monitore arquivos de log.
- Processe novos registros à medida que são adicionados aos arquivos de log monitorados.
Criando uma tabela
path_to_logs– Caminho para os arquivos de log a monitorar. Pode ser o caminho para um diretório com arquivos de log ou para um único arquivo de log. Um caminho relativo é resolvido em relação ao diretóriouser_files_path, como na função de tabela file; um caminho relativo que já esteja dentro deuser_files_patha partir do diretório de trabalho do servidor (por exemplo,user_files/my_app/app.logquando o servidor é executado em seu diretório de dados, como na imagem Docker oficial) mantém esse significado. O nome do arquivo no caminho pode conter globs (*,?,{abc,def},{N..M}) para ler apenas os arquivos correspondentes do diretório; consulte Selecionando arquivos com globs. Observe que o ClickHouse permite apenas caminhos dentro do diretóriouser_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.
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 interpretar 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 (umSELECTdireto lança uma exceção se não for possível interpretar um registro; quando a tabela envia dados em stream para visões materializadas, esse registro é ignorado e o erro é gravado no log do servidor), stream (a mensagem da exceção e o registro bruto serão salvos nas colunas virtuais_errore_raw_record).
Descrição
Os registros recebidos são rastreados automaticamente, portanto cada registro em um arquivo de log é contabilizado apenas uma vez. Se, na próxima leitura, um arquivo estiver menor do que o deslocamento registrado para ele, como ocorre após ologrotate com copytruncate, ele será lido novamente desde o início. Um truncamento não é detectado se o arquivo voltar a crescer até pelo menos esse deslocamento antes da próxima leitura. Um arquivo com vários nomes no diretório (hard links) é lido por meio de apenas um deles.
Um arquivo que não pode ser aberto (um link simbólico cujo destino foi removido, um arquivo sem permissão de leitura para o servidor ou o arquivo de uma tabela de arquivo único que foi removido) é ignorado, com um erro registrado no log do servidor, e a abertura é tentada novamente, enquanto a tabela estiver carregada, até que seja bem-sucedida; um arquivo que estava ausente passa então a ser lido desde o início. Um link simbólico só é lido se o seu destino existir no momento em que a tabela o encontrar.
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.
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:
ALTER, recomendamos desativar a visão materializada para evitar discrepâncias entre a tabela de destino e os dados provenientes da view.
Selecionando arquivos com globs
Quando o nome de arquivo empath_to_logs contém globs, a tabela lê os arquivos desse diretório cujos nomes correspondem ao padrão, inclusive os que forem criados depois. Não há suporte a globs na parte do caminho referente ao diretório.
Um arquivo que a tabela está lendo continua sendo lido mesmo depois de ser renomeado para um nome que não corresponde ao padrão, até ser removido do diretório. Um arquivo criado e renomeado para um nome que não corresponde ao padrão enquanto a tabela está desanexada ou o servidor está parado não é lido. No macOS, onde o diretório é monitorado pela comparação de suas listagens, o mesmo vale para um arquivo criado e renomeado para um nome que não corresponde ao padrão antes que a tabela o liste. É exatamente esse o comportamento de que a rotação de logs precisa. Por exemplo, o logrotate com compress e delaycompress mantém o diretório assim:
FileLog('/var/lib/clickhouse/user_files/my_app/*.log', 'JSONEachRow') lê app.log; após a rotação, ela continua lendo app.log.1, de modo que as linhas que a aplicação grava ali antes de reabrir seu log não se perdem, e ela nunca lê os arquivos comprimidos. Certifique-se de que o glob não corresponda aos nomes dos arquivos comprimidos.
Colunas virtuais
_filename- Nome do arquivo de log. Tipo de dado:LowCardinality(String)._offset- Offset no arquivo de log. Tipo de dado:UInt64.
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).
_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.
Durabilidade dos dados
O motorFileLog registra o deslocamento consumido de um fragmento antes que o insert ao qual ele pertence seja confirmado; portanto, a interrupção do servidor pode fazer com que o deslocamento registrado fique adiantado em relação aos dados que chegaram à tabela de destino. Ao reiniciar, cada arquivo de log é retomado a partir do deslocamento registrado em seu diretório de metadados, de modo que essas linhas nunca são lidas novamente: elas são perdidas sem gerar erro, e count() simplesmente retorna um valor menor. Uma falha comum de processo é suficiente para expor esse problema e não exige perda de energia, pois o deslocamento é registrado em um arquivo de metadados renomeado para o local definitivo enquanto a parte de destino ainda está sendo gravada.
A perda do cache de páginas do SO também pode descartar dados que já haviam sido gravados na tabela de destino; por exemplo, em caso de perda de energia no nível do dispositivo ou reinicialização inadequada do host ou do kernel. Os arquivos de metadados que armazenam os deslocamentos são gravados sem fsync do arquivo ou de seu diretório, portanto também não oferecem garantia própria de durabilidade.
Diferentemente dos motores de broker de mensagens, não é possível proteger o FileLog contra isso tornando primeiro o destino durável. Como o deslocamento é registrado dentro do pipeline de leitura, antes da conclusão do insert ao qual pertence, definir fsync_after_insert = 1 nas tabelas MergeTree de destino não torna a parte inserida durável antes do avanço do deslocamento. Trate o consumo do FileLog como acompanhamento de arquivos locais sem garantias: quando nenhuma linha puder ser perdida, mantenha os arquivos de log de origem até verificar os dados consumidos no destino, para que o consumo possa ser repetido. SYSTEM RESET FILELOG, ou remover e recriar a tabela, descarta os deslocamentos registrados e relê os arquivos desde o início.