final inesperado do arquivo rsyslog em arquivos de log com OMFileZipLevel

Question

SO: Centos7
rsyslog: 8.24.0

Tenho vários hosts enviando logs para meu rsyslogservidor centralizado. Eu uso OMFileZipLevela opção em meu arquivo de configuração para compactar meus logs e, zcata qualquer momento, desejo visualizar o conteúdo.

Desde que atualizei para o rsyslog8, sempre que tento zcatum dos meus logs compactados, recebo o seguinte erro:

#   zcat srv1.example.com.log.gz
2021-01-06T04:46:11-08:00 srv1.example.com lab: test_msg

gzip: srv1.example.com.log.gz: unexpected end of file

se eu parar o servidor rsyslog e acessar o arquivo, não recebo essa mensagem de erro. Mesmo se eu iniciar o servidor, ainda posso ver o arquivo de log sem a mensagem EOF,no entantoquando meu servidor rsyslog recebe uma mensagem e a grava no arquivo, começo a receber a mesma mensagem:

#   zcat srv1.example.com.log.gz
2021-01-06T05:54:22-08:00 srv1.example.com lab: test_msg

gzip: srv1.example.com.log.gz: unexpected end of file


#   systemctl stop rsyslog

#   zcat  srv1.example.com.log.gz
2021-01-06T05:54:22-08:00 srv1.example.com lab: test_msg


#   systemctl start rsyslog

#   zcat srv1.example.com.log.gz
2021-01-06T05:54:22-08:00 srv1.example.com lab: test_msg


srv1:~$ logger -p local5.info test_msg2 @my_rsyslog_server

#   zcat srv1.example.com.log.gz
2021-01-06T03:32:09-08:00 srv1.example.com lab: hab_test
2021-01-06T05:55:27-08:00 srv1.example.com lab: test_msg2

gzip: srv1.example.com.log.gz: unexpected end of file

Consegui encontrar uma lista de discussão onde alguém menciona um problema semelhante e isso tem a ver com o arquivo ainda aberto pelo rsyslog.

O problema é que tenho outra versão em execução do servidor rsyslog 5.8.10(Centos 6) com exatamente o mesmo arquivo de configuração rsyslog, mas não tenho esse comportamento com mensagens EOF em meus logs compactados.

Isso poderia ser um bug no rsyslog 8.24.0?

Answer 1

Parece um comportamento normal. Não tenho certeza sobre closeTimeouto parâmetro porque OMFileZipLevelgeralmente é aplicado a serviços que geram muita saída, então nunca tive um arquivo que não fosse gravado por 10 minutos (ou 10 segundos, aliás)!

GZIP é um compressor de fluxo, então os arquivos são gravados com um cabeçalho e um final, mas o final não é gravado até que o arquivo seja considerado fechado e finalizado, então zcat e gunzip reclamarão ao chegar ao final de um arquivo gzip normal que é ainda está sendo escrito.

Usar OMFileZipLevelapenas informa ao rsyslog para compactar os logs em um arquivo gzip normal, portanto, isso ainda se aplica.

O uso veryRobustZipdo rsyslog pode construir arquivos gzip compostos de pequenos blocos de dados gzip concatenados um após o outro (que é compatível com gzip) e pode permitir que os dados sejam extraídos sem erros com zcat ou gunzip (masconsulte a ajuda do rsyslogpara verificar alguns detalhes).

Mesmo assim, desenvolviferramenta gzpara gerenciar facilmente arquivos de log compactados produzidos pelo rsyslog, independentemente das opções: você pode

• seguir continuamente um arquivo .log.gz como acontece com tail -farquivos de texto, usandogztool -T
• extrair todos os dados mesmo se o processo de envio de logs for interrompido abruptamente e reiniciado, o que leva a arquivos gzip com dados inacessíveis para zcat/gunzip, mas que o gztool pode extrair perfeitamente comgztool -p
• extrair dados de qualquer parte do arquivo gzip sem ler tudo (o que é obrigatório para outras ferramentas)

Apenasconsulte os exemplos de usodeferramenta gz.

A questão seria por que isso não aconteceu antes da atualização: você tem certeza de que isso não aconteceu antes com a mesma configuração do rsyslog?