SO: Centos7
rsyslog: 8.24.0
Tengo varios hosts que envían registros a mi rsyslogservidor centralizado. Utilizo OMFileZipLevella opción en mi archivo de configuración para comprimir mis registros y luego, zcatcada vez que deseo ver el contenido.
Desde que actualicé a rsyslog8, cada vez que intento acceder a zcatuno de mis registros comprimidos aparece el siguiente error:
# 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
Si detengo el servidor rsyslog y accedo al archivo, no aparece ese mensaje de error. Incluso si inicio el servidor todavía puedo ver el archivo de registro sin ese mensaje EOF,sin embargocuando mi servidor rsyslog recibe un mensaje y lo escribe en el archivo, empiezo a recibir el mismo mensaje:
# 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
Pude encontrar una lista de correo donde alguien menciona un problema similar y esto tiene que ver con el archivo que rsyslog aún abrió.
La cuestión es que tengo otra versión del servidor rsyslog en ejecución 5.8.10(Centos 6) con exactamente el mismo archivo de configuración de rsyslog, pero no tengo ese comportamiento con los mensajes EOF en mis registros comprimidos.
¿Podría ser esto un error en rsyslog 8.24.0?
Respuesta1
Parece un comportamiento normal. No estoy seguro acerca del closeTimeoutparámetro porque OMFileZipLevelgeneralmente se aplica a servicios que generan una gran cantidad de resultados, por lo que nunca he tenido un archivo que no se haya escrito durante 10 minutos (o 10 segundos, por cierto).
GZIP es un compresor de flujo, por lo que los archivos se escriben con un encabezado y una cola, pero la cola no se escribe hasta que el archivo se considera cerrado y terminado, por lo que zcat y gunzip se quejarán al llegar al final de un archivo gzip normal, es decir. todavía se está escribiendo.
El uso OMFileZipLevelsimplemente le indica a rsyslog que comprima los registros en un archivo gzip normal, por lo que esto aún se aplica.
El uso de veryRobustZiprsyslog puede construir archivos gzip compuestos por pequeños bloques de datos gzip concatenados uno tras otro (que es compatible con gzip) y podría permitir que los datos se extraigan sin errores con zcat o gunzip (peroconsultar ayuda de rsyslogpara comprobar algunos detalles).
Sin embargo, he desarrolladoherramientapara administrar fácilmente archivos de registro comprimidos producidos por rsyslog, sin importar las opciones: puede
- siga continuamente un archivo .log.gz como
tail -fpara archivos de texto, usandogztool -T - extraiga todos los datos incluso si el proceso de envío de registros se detiene abruptamente y luego se reinicia, lo que genera archivos gzip con datos inalcanzables para zcat/gunzip pero que gztool puede extraer sin problemas con
gztool -p - extraer datos de cualquier parte del archivo gzip sin leerlos todos (lo cual es obligatorio para otras herramientas)
Justoconsultar los ejemplos de usodeherramienta.
La pregunta sería por qué no sucedió antes de la actualización: ¿está seguro de que esto no sucedió antes con la misma configuración de rsyslog?