☰

rsyslog неожиданный конец файла в файлах журнала с OMFileZipLevel

tag-icon • tag-icon syslog rsyslog
rsyslog неожиданный конец файла в файлах журнала с OMFileZipLevel

ОС: Centos7
rsyslog: 8.24.0

У меня есть несколько хостов, отправляющих логи на мой централизованный rsyslogсервер. Я использую OMFileZipLevelопцию в своем конфигурационном файле для сжатия моих журналов, а затем zcatв любое время я хочу просмотреть их содержимое.

После обновления до rsyslog8, всякий раз, когда я пытаюсь открыть zcatодин из моих сжатых журналов, я получаю следующую ошибку:

#   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

если я останавливаю сервер rsyslog и обращаюсь к файлу, то я не получаю это сообщение об ошибке. Даже если я запускаю сервер, я все равно вижу файл журнала без этого сообщения EOF,однакокогда мой сервер rsyslog получает сообщение и записывает его в файл, я начинаю получать то же самое сообщение:

#   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

Мне удалось найти список рассылки, где кто-то упоминает похожую проблему, и она связана с тем, что файл все еще открыт rsyslog.

Дело в том, что у меня есть другая версия сервера rsyslog 5.8.10(Centos 6) с точно таким же файлом конфигурации rsyslog, но у меня нет такого поведения с сообщениями EOF в моих сжатых журналах.

Может ли это быть ошибкой в ​​rsyslog 8.24.0?

решение1

Кажется, это нормальное поведение. Я не уверен насчет closeTimeoutпараметра, потому что OMFileZipLevelон обычно применяется к службам, которые генерируют много выходных данных, поэтому у меня никогда не было файла, который не записывался бы в течение 10 минут (или 10 секунд, кстати)!

GZIP — это потоковый компрессор, поэтому файлы записываются с заголовком и хвостом, но хвост не записывается до тех пор, пока файл не будет считаться закрытым и завершенным, поэтому zcat и gunzip будут выдавать сообщение об ошибке при достижении конца обычного файла gzip, который все еще записывается.

Использование OMFileZipLevelпросто сообщает rsyslog о необходимости сжимать журналы в обычный файл gzip, поэтому это по-прежнему применимо.

Используя veryRobustZiprsyslog, можно создавать gzip-файлы, состоящие из небольших блоков gzip-данных, соединенных один за другим (что совместимо с gzip), и можно извлекать данные без ошибок с помощью zcat или gunzip (нообратитесь за помощью к rsyslogдля проверки некоторых деталей).

Тем не менее, я разработалgztoolдля простого управления сжатыми файлами журналов, созданными rsyslog, независимо от параметров: вы можете

  • непрерывно отслеживать файл .log.gz, как и tail -fдля текстовых файлов, используяgztool -T
  • извлечь все данные, даже если процесс отправки журналов был внезапно остановлен и затем перезапущен, что привело к появлению gzip-файлов с недоступными данными для zcat/gunzip, но gztool может безупречно извлечь их с помощьюgztool -p
  • извлекать данные из любой части gzip-файла, не читая его полностью (что обязательно для других инструментов)

Толькоознакомьтесь с примерами использованияизgztool.

Вопрос в том, почему этого не произошло до обновления: вы уверены, что этого не происходило раньше с той же конфигурацией rsyslog?

Связанный контент