rsyslog mit logrotate: lade rsyslog vs copytruncate neu

Ich arbeite an Ubuntu 14 mit dem Standard-Dienstprogramm rsyslog und logrotate.

In der Standardkonfiguration von rsyslog logrotate /etc/logrotate.d/rsyslogsehe ich Folgendes:

/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                reload rsyslog >/dev/null 2>&1 || true
        endscript
}

Soweit ich weiß, wird empfohlen, copytruncate in allen Logrotate-Szenarien zu verwenden, da es nicht das aktuelle Protokoll verschiebt, sondern das Protokoll abschneidet, damit jeder Prozess mit einem geöffneten Datei-Handler weiterhin darauf schreiben kann.

Wie kommt es also, dass die Standardkonfiguration stattdessen die Funktion zum erneuten Laden von rsyslog verwendet?

Um Ihre Frage zu beantworten, müssen Sie zunächst die verschiedenen Kompromisse zwischen Neuladen und Abschneiden von Kopien verstehen:

• reload : Die alte Protokolldatei wird umbenannt und der Prozess, der in dieses Protokoll schreibt, wird benachrichtigt (über das Unix-Signal), um die Protokolldatei neu zu erstellen. Dies ist die schnellste / niedrigere Overhead-Methode: Umbenennungs- / Verschiebevorgänge sind sehr schnell und haben eine konstante Ausführungszeit. Außerdem ist es eine fast atomare Operation: Dies bedeutet, dass (fast) kein Protokolleintrag während des Verschiebens / Neuladens verloren geht. Auf der anderen Seite benötigen Sie einen Prozess, mit dem die Protokolldatei erneut geladen und geöffnet werden kann. Rsyslog ist ein solcher Prozess. In der Standardkonfiguration von logrotate wird die Methode reload verwendet. Die Verwendung dieses Modus mit rsyslog wird von rsyslog upstream dringend empfohlen.
• copytruncate : Die alte Protokolldatei wird in eine Archivdatei kopiert und anschließend abgeschnitten, um alte Protokollzeilen zu "löschen". Während der Abschneidevorgang sehr schnell ist, kann die Kopie ziemlich lang sein (abhängig davon, wie groß Ihre Protokolldatei ist). Darüber hinaus kann während der Zeit zwischen dem Kopiervorgang (denken Sie daran, es kann langsam sein) und dem Abschneiden ein Teil des Protokolleintrags verloren gehen. Aus diesen Gründen wird copytruncate nicht standardmäßig für Dienste verwendet, die in der Lage sind, ihre Protokolldateien neu zu laden und zu erstellen. Auf der anderen Seite ist copytruncate die sicherste Wahl , wenn ein Server keine Protokolldateien neu laden / erstellen kann. Mit anderen Worten, es ist keine Unterstützung auf Serviceebene erforderlich. Das vorgelagerte rsyslog-Projekt rät dringend davon ab, diesen Modus zu verwenden.

Copytruncate ist als rsyslog-Autor eine sehr, sehr, sehr schlechte Wahl. Es ist von Natur aus rassig und die Verwendung ist fast eine Garantie dafür, dass Sie Protokolldaten verlieren. Je öfter in die Datei geschrieben wird, desto mehr verlieren Sie. Und dies ist nicht nur ein Teil der letzten Zeile, sondern kann mehrere hundert betragen, abhängig vom genauen Zeitpunkt und Zustand des Systems zum Zeitpunkt der Rotation.

Wenn die Datei verschoben und eine neue Inode (Datei) erstellt wird, verfolgt rsyslog die vorherige Datei und schließt die Verarbeitung ab. Sie haben also in diesem Fall keinen Verlust. Garantiert (außer wenn Sie das Dateisystem aushängen ...).

Zu "reopenOnTruncate": Ich persönlich habe gesehen, dass reopenOnTruncate auch in anderer Hinsicht rassig ist, insbesondere bei NFS und ähnlichem. Vor einiger Zeit habe ich diese Funktionalität vollständig entfernt, wurde aber später dazu überredet, ähnliche Funktionen wieder zusammenzuführen. Es wird höchstwahrscheinlich für immer "experimentell" bleiben, da ich wirklich weiß, dass Menschen auf sehr stark ausgelasteten Systemen auf Probleme stoßen. "copytruncate" ist einfach kein anständiger Modus, um mit Protokolldateien zu arbeiten.

Ich arbeite derzeit am Refactoring von imfile (ETA 8.34 oder 8.35). Die überarbeitete Version wird wahrscheinlich in der Lage sein, ein versehentliches erneutes Senden aufgrund eines API-Rennens zu verhindern, kann aber auch nicht vor Datenverlust schützen - da dies konzeptionell unmöglich ist.

Dies hängt vollständig davon ab, wie der Prozess Protokolle schreibt.
copytruncatefunktioniert nur, wenn die Logmeldungen an die Datei angehängt werden (z whatever >> logfile. B.
und nicht, wenn die Ausgabe umgeleitet wird (z whatever > logfile. B. ).

Seit Version 8.16 verfügt rsyslog über die Option imfile reopenOnTruncate, die das Problem copytruncte behandelt.

Für rsyslog ist es wahrscheinlich sinnvoller, die Dinge so zu belassen, wie sie sind.

Der Grund dafür ist, dass rsyslog interne Warteschlangen hat, die in Fällen verwendet werden können, in denen das Ausgabe-Handle nicht mehr verfügbar ist.

Durch das Neuladen wird a) veranlasst, dass rsyslog seine eigene Protokolldatei neu erstellt, und b) dass alle Ereignisse in der Warteschlange bei der Erstellung in die Datei geschrieben werden.

Es kann sein, dass copytruncate keinen Schaden anrichtet (obwohl ich besorgt darüber wäre, dass teilweise geschriebene Zeilen abgeschnitten werden), aber ich würde eher denken, dass copy / delete / reload unter dem Gesichtspunkt der Integrität "sicherer" ist.

Wie von @ faker erwähnt , gibt es keinen zwingenden Grund für die Verwendung von copytruncate, da rsyslog die Situation bewältigen kann, in der seine Datei nicht mehr verfügbar ist.

Und wie von @ SelivanovPavel erwähnt , benötigt rsyslog tatsächlich eine spezielle Konfiguration, um das Abschneiden von Kopien richtig zu handhaben.

Wenn die Verwendung des reloadAnsatzes nur eine geringere Abweichung von der Standardkonfiguration erfordert, würde ich ihn beibehalten.