Betriebssystem: Centos7
rsyslog: 8.24.0
Ich habe mehrere Hosts, die Protokolle an meinen zentralen rsyslogServer senden. Ich verwende OMFileZipLeveleine Option in meiner Konfigurationsdatei, um meine Protokolle zu komprimieren und mir dann zcatden Inhalt jederzeit anzeigen zu lassen, wenn ich möchte.
Seit ich ein Upgrade auf durchgeführt habe rsyslog8, erhalte ich immer die folgende Fehlermeldung, wenn ich versuche, auf zcateines meiner komprimierten Protokolle zuzugreifen:
# 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
Wenn ich den rsyslog-Server stoppe und auf die Datei zugreife, erhalte ich diese Fehlermeldung nicht. Selbst wenn ich den Server starte, kann ich die Protokolldatei ohne diese EOF-Meldung sehen.JedochWenn mein Rsyslog-Server eine Nachricht empfängt und sie in die Datei schreibt, erhalte ich immer wieder die gleiche Nachricht:
# 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
Ich konnte eine Mailingliste finden, in der jemand ein ähnliches Problem erwähnt, und dies hängt damit zusammen, dass die Datei immer noch von rsyslog geöffnet wurde.
Die Sache ist, dass ich eine andere Version des Rsyslog-Servers 5.8.10(Centos 6) mit der exakt gleichen Rsyslog-Konfigurationsdatei habe, aber bei meinen komprimierten Protokollen tritt dieses Verhalten mit EOF-Meldungen nicht auf.
Könnte dies ein Fehler in rsyslog sein 8.24.0?
Antwort1
Das scheint ein normales Verhalten zu sein. Ich bin mir bei dem closeTimeoutParameter nicht sicher, da OMFileZipLeveler normalerweise auf Dienste angewendet wird, die viel Ausgabe erzeugen. Daher wurde bei mir noch nie 10 Minuten (oder übrigens 10 Sekunden) lang keine Datei geschrieben!
GZIP ist ein Stream-Kompressor, die Dateien werden also mit einem Header und einem Tail geschrieben, das Tail wird jedoch erst geschrieben, wenn die Datei als geschlossen und beendet gilt. Daher beschweren sich zcat und gunzip, wenn sie das Ende einer normalen GZIP-Datei erreichen, die noch geschrieben wird.
Die Verwendung OMFileZipLevelweist rsyslog lediglich an, Protokolle in eine normale GZIP-Datei zu komprimieren. Dies gilt also weiterhin.
Mit veryRobustZiprsyslog können Gzip-Dateien erstellt werden, die aus kleinen Blöcken von Gzip-Daten bestehen, die aneinandergereiht sind (was Gzip-kompatibel ist) und die Daten ohne Fehler mit zcat oder gunzip extrahieren können (aberkonsultieren Sie die rsyslog-Hilfeum einige Details zu überprüfen).
Dennoch habe ich entwickeltgztoolzur einfachen Verwaltung komprimierter Protokolldateien, die von rsyslog erstellt werden, unabhängig von den Optionen: Sie können
- kontinuierlich eine .log.gz Datei wie
tail -fbei Textdateien anhängen, mitgztool -T - alle Daten extrahieren, auch wenn der Prozess, der Protokolle sendet, abrupt gestoppt und dann neu gestartet wird, was zu gzip-Dateien mit nicht erreichbaren Daten für zcat/gunzip führt, die gztool jedoch problemlos extrahieren kann mit
gztool -p - Daten aus jedem beliebigen Teil der GZIP-Datei extrahieren, ohne sie vollständig zu lesen (was bei anderen Tools zwingend erforderlich ist)
NurKonsultieren Sie die Anwendungsbeispielevongztool.
Die Frage wäre, warum dies nicht vor dem Upgrade passiert ist: Sind Sie sicher, dass dies mit derselben rsyslog-Konfiguration nicht schon einmal passiert ist?