Grüße !!!
Dies betrifft eine spezielle Anforderung an rsync, die wir erfüllen möchten. Wir haben versucht, dies durch die Verwendung verschiedener rsync-Optionen zu erreichen. Allerdings stoßen wir bei verschiedenen rsync-Optionen auf unterschiedliche Probleme.
Hintergrund: • Wir haben einen Prozess (unter AIX), dessen Protokolle in A.log (im Protokollverzeichnis vorhanden) protokolliert werden. • A.log wird nach A.CURRENT_DATE_TIME.log rotiert, sobald es 100 MB erreicht und ein neues A.log erstellt wird. • Wir übertragen diese Protokolle mit rsync auf einen zentralen Server. Wir verwenden rsync für das komplette Protokollverzeichnis. • Die INODE der Dateien auf dem Quellserver und dem Zielserver sind unterschiedlich. • Sobald sich die Protokolle auf dem zentralen Server befinden, besteht die Idee darin, diese Protokolle von einem zentralen Protokollprozess lesen/indizieren zu lassen, der die Eingabe von diesem zentralen Server abruft.
Problem: • Obwohl A.log (Zielserver) als Eingabe für den zentralisierten Protokollprozess angegeben wird, berücksichtigt dieser den INODE der Datei und nicht den tatsächlichen Dateinamen. • Wenn also die A.log-Datei überrollt wird, hat das neue A.log einen neuen INODE, der vom zentralisierten Prozess nicht erkannt wird. Dies geschah, als wir die Optionen -u –r –t mit rsync verwendeten. In diesem Fall änderte sich also der INODE der Datei bei jedem rsync und auch beim Überrollvorgang. Daher stoppt der Prozess die Indizierung, da er nach dem alten INODE sucht, der nicht vorhanden ist.
• Die Idee ist, rsync mit einer Kombination von Optionen zu verwenden, die den INODE der Datei zum Zeitpunkt von rsync nicht ändern, den INODE jedoch zum Zeitpunkt des Rollovers ändern sollten, wenn A.log zu A.CURRENT_DATE_TIME.log rotiert. Um dies zu erreichen, haben wir die Option –inplace aufgenommen und können den INODE beim rsync beibehalten und INODE-Änderungen zum Zeitpunkt der Dateirotation vornehmen. Allerdings ergibt sich jetzt ein anderes Problem, da sich der Dateiname nicht ändert und immer A.log bleibt. Sobald der Prozess mit der Indizierung von A.log fertig ist, wird er angehalten.
Es wäre toll, wenn jemand einen Vorschlag machen könnte, der uns dabei helfen könnte, die genannten Anforderungen zu erfüllen.
Mit freundlichen Grüßen, Puneet Sinha Middleware-Administrator
Antwort1
Ich empfehle nicht, sich auf den Inode zu verlassen. Er ändert sich jedes Mal, wenn die Datei von der Quell- auf die Zielmaschine verschoben wird. Er ändert sich auch, wenn die Dateien aus Backups wiederhergestellt werden. Wenn das Protokollverarbeitungssystem vom Inode abhängt, funktioniert das System nicht wie erwartet, wenn Sie jemals aus Backups wiederherstellen.
Meine Empfehlung ist, A.log NICHT zu kopieren, sondern nur A.CURRENT_DATE_TIME.log. Dies vereinfacht das Projekt.
Ich vermute, dass das Protokollverarbeitungssystem auf dem Zielserver den Inode überprüft, um festzustellen, ob die Datei, die es zuvor als A.log erkannt hat, jetzt A.CURRENT_DATE_TIME.log ist. Das ist nicht zuverlässig.
Die obige Lösung hat ein Problem: Die Zeit, die von der Generierung einer Zeile in der Protokolldatei bis zu ihrer Verarbeitung durch den zentralisierten Protokollprozess benötigt wird, wird länger. Wenn es beispielsweise 3 Tage dauert, bis A.log auf 100 MB anwächst, gelangt bis zu 3 Tage lang nichts aus dieser Datei in den zentralisierten Protokollprozess. Wenn die Protokolle nicht um mehr als 2 Stunden verzögert werden können, würde ich die Protokolle alle 1 Stunde rotieren. Auf diese Weise wissen Sie, dass Sie das 2-Stunden-Ziel einhalten.